PSD3 in SMEs: What Finance Chiefs Must Prepare for Banking APIs and Embedded Finance by 2026
8 Min. Reading Time · Updated: 21.04.2026
Since 27 November 2025 the political agreement on PSD3 and the new Payment Services Regulation (PSR) has been in place. Publication in the EU Official Journal is expected at the end of Q2 2026, followed by 18 months of transposition and 21 months of transition. For mid‑size firms this means: the operational pressure won’t arrive in 2026, but the decisions that will be under pressure in 2028 are being made now. Companies that refresh payment flows, embedded‑finance partnerships or treasury APIs in 2026 either comply cleanly with the PSD3 foreword or create integration debt that will become costly after the regulation takes effect.
Key Takeaways
- PSD3 isn’t arriving tomorrow, but the decisions are due today. Publication Q2 2026, transposition by Q4 2027, full application mid‑2028. Banking‑API projects with a duration over 18 months must already account for the new obligations.
- IBAN‑name verification becomes a liability requirement. 24 months after the PSR enters into force, the initiating payment service is liable for ensuring that the beneficiary name matches the IBAN. For SME treasury processes involving cross‑border payments, this is the most palpable operational impact.
- Harmonised APIs replace the current PSD2 patchwork landscape. Banks must provide third‑party providers (TPP) with an interface that matches their own online‑banking performance and availability. This will markedly improve embedded‑finance integrations once banks have implemented it.
- FiDA as an open‑finance parallel construction site. The Financial Data Access Regulation expands access beyond payment data to credit, insurance and investment data. For mid‑size firms with integrated finance processes, this opens new automation possibilities, provided data‑privacy and compliance governance are clarified in time.
RelatedGenerative AI in Customer Service: From Pilot to Production / Predictive Analytics in ERP: Making Customer Retention Measurable
What is PSD3 and what changes compared to PSD2
What is PSD3? PSD3 is the EU’s third Payment Services Directive. Together with the new Payment Services Regulation (PSR) it replaces the existing PSD2. PSD3, as a directive, sets the licensing and supervisory framework for payment institutions. PSR, as a directly applicable regulation, governs user rights, security standards and the concrete obligations between banks, third‑party providers and customers. The political agreement between the European Parliament and the Council was reached on 27.11.2025, with publication in the Official Journal expected in Q2 2026. It will enter into force roughly 20 days after publication, with most provisions becoming applicable 18 months later.
The substantive shift from PSD2 is relevant in three key areas. First, the core user‑rights matter moves from the directive into the directly applicable regulation, forcing harmonisation because Member States will no longer have gold‑plating leeway. Second, banks must build their TPP APIs to meet the same performance and availability standards as the bank’s own online‑banking channel. The previous situation, where TPP APIs were slower, less stable or less functional than the end‑customer interface, is prohibited. Third, IBAN recipient‑name verification becomes a legal requirement with a liability shift 24 months after entry into force.
For finance leaders in mid‑size companies this does not mean PSD3 will become an acute daily issue in 2026. It means that projects with longer timelines (treasury‑system migrations, new embedded‑finance integrations, replacement of payment‑processing platforms) must already be planned with the 2028 requirement in mind. A treasury migration that starts in 2026 and goes live in Q3 2027 will experience its first full year of production under PSD3/PSR. Those who integrate the verification and API obligations only afterwards will end up paying twice.
Three entry points where SMEs decide now
The first construction site is the treasury and payments stack. Many SMEs have switched in the last three to five years to a Treasury Management System (TMS) with SWIFT connectivity, SEPA automation and, in some cases, open‑banking integration. The IBAN‑recipient‑name check changes the standard process there. Whoever initiates a payment today relies on the entered IBAN reaching the right person. Under PSR the initiating service provider is liable for the IBAN and name matching. Technically the check is not rocket science, but it has to be built into the TMS processes and, in part, passed on to ERP interfaces.
The second construction site is Embedded Finance. More and more SMEs are integrating financial products directly into their own platforms: automated credit decisions in B2B shops, factoring in inventory management, split‑payments in booking flows. Under PSD3/PSR the requirements for the licence holders of these embedded products become clearer. The SME as a user of an embedded‑finance partnership must ensure that the partner is set up to meet PSR requirements. In practice this means an additional checkpoint in the vendor assessment, a discussion about API availability guarantees and, if necessary, a contract renegotiation before the end of 2027.
The third construction site is Open Finance via FiDA. The Financial Data Access Regulation runs as a separate EU regulation alongside PSD3/PSR and has not yet been finalised. It expands data access beyond pure payment data to include credit, insurance and investment data. For SMEs that are increasingly automating their financial planning, FiDA opens new possibilities: a finance cockpit that aggregates not only bank accounts but also credit lines, insurance policies and investment portfolios becomes technically more realistic. The governance question, however, remains who within the company manages the consents and which data may actually be shared.
Between these three entry points there is a common fundamental question that SMEs rarely ask explicitly: Who inside the company is actually responsible for the new financial interface? In the past payments were clearly the domain of treasury, credit and factoring issues belonged to the CFO and embedded‑finance pilots often lived in product development. Under PSD3/PSR this evolves into a shared responsibility zone, because the same APIs, the same verification standards and the same governance rules apply at every touchpoint. Whoever does not resolve the responsibility question in the coming months will, in three years, find themselves in a situation where three departments push the PSR audit preparation onto each other.
Checklist for CFOs through Autumn 2026
The sequence below is not a framework but a series of concrete checks that finance leaders should run through in Q2 and Q3 2026. It replaces neither external legal advice nor an IT assessment, but it structures the conversations with your bank, TMS provider and embedded‑finance partners. The timeline is intentional: anyone who has a clear inventory on the table in Autumn 2026 can move into operational preparation in 2027 and secure implementations in 2028.
“The most common regulatory transformation I’ve seen in recent years fails not on the law but on translating it into systems. PSD3 will succeed with mid‑size firms that already document their payment and data processes in a way that makes them changeable.” Eva Mickler, Senior PM Evernine
Treasury & Banking side (Q2 2026)
- Inventory: Which banks, TMS providers, payment gateways and PSD2 APIs are used today?
- Contact your house bank: How will IBAN‑name verification be built into online banking and the API by mid‑2028?
- Talk with the TMS provider: When will a PSD3/PSR‑compliant release plan be on the table?
- Update internal process documentation: Who confirms recipient names today, who will do it under PSR?
Embedded finance & partner side (Q3 2026)
- Vendor mapping: Which embedded‑finance services (factoring, payment providers, credit decisioners) are in production?
- Partner discussion: What PSD3/PSR preparation is documented, and which liability rules will change?
- Review contracts: Are renegotiations due before 2028 that can be started proactively now?
- Assess IT integration: Which APIs are currently built on PSD2 logic, and which need to be adapted?
What is deliberately left out of this sequence is an internal PSD3 project with its own project team. Most mid‑size firms lack the resources for a regulatory project that only takes effect operationally in 2028. It is more realistic to weave PSD3 topics into ongoing initiatives: add the IBAN‑name check to the treasury migration that is already planned, and expand the embedded‑finance tender—already being prepared—to include PSD3 readiness as a criterion. This saves resources and places the requirements where they will be implemented anyway.
The critical point is the timing of communication with your house bank. Banks are currently planning their own PSD3 roadmaps, and corporate‑client questions feed directly into their prioritisation. If you don’t ask now, you’ll receive in autumn the answer that another client fed in spring. For CFOs using multiple banks, a standardised questionnaire sent to all banks is worthwhile. The bank that replies cleanly has done its homework.
A second argument for early communication is budgeting. PSD3‑related adjustments to the TMS, the ERP interface or the embedded‑finance integration are not classic compliance line items; they usually appear as extensions of existing IT projects. In the 2026 budgeting rounds, CFOs decide whether these extensions show up as separate line items or flow within the normal IT budget. The latter is operationally easier but requires early alignment with the CIO, otherwise project teams cannot cover the new requirements with existing budget approaches.
The final consideration concerns external service providers. Mid‑size firms that have outsourced payment processing and parts of treasury to specialised providers do not bear the implementation risk themselves, but they do bear the contractual risk. The PSR regime shift will be reflected in many providers’ standard contracts from 2027 onward through price adjustments and service‑level updates. If you simply sign those changes without negotiating, you give away leverage that could be used in a mature provider relationship. A structured contract review in autumn 2026, before the main negotiation season, is the cost‑free way to prepare.
A frequently underestimated dimension is internal acceptance. The accounting team that today checks and releases a payment works with a stable process it has known for years. With IBAN‑name verification under PSR, the expectation for release changes: when a system flags a name‑IBAN mismatch, clear rules are needed about who decides and on what criteria. This is not a technology question; it’s a process and role question. CFOs who ready their teams for the upcoming changes will save a lot of friction from 2028 onward, because they won’t block releases or trigger escalations in the first weeks of rollout.
Frequently Asked Questions
When will PSD3 become practically applicable?
According to the current schedule, the PSR will be applicable 18 months after entry into force, i.e., likely early 2028. PSD3 as a directive must be transposed into national law by then. The IBAN name verification only comes into effect 24 months after entry into force, typically around mid‑2028. For mid‑size companies this means: operational impact from 2028, preparation in projects starting now.
What distinguishes PSD3 from the PSR?
PSD3 is a directive that must be implemented in national law and mainly governs licensing and supervisory rules for payment service providers. The PSR is a directly applicable regulation that sets user rights, security requirements and operational obligations. For corporate clients the PSR is more relevant because it contains the concrete requirements for APIs, authentication and verification.
Do I, as a mid‑size company, need to set up my own PSD3 project?
In most cases, no. The operational implementation lies with banks and payment service providers. For corporate clients it is sufficient to extend existing treasury and embedded‑finance projects with PSD3 requirements. A dedicated PSD3 project team only makes sense for business models that are heavily finance‑service oriented, such as fintechs, factoring providers or embedded‑finance platforms.
What is FiDA and how does it relate to PSD3?
FiDA (Financial Data Access Regulation) is a standalone EU regulation that expands data access beyond payment data to credit, insurance and investment data. It runs in parallel to PSD3/PSR with its own timeline. For mid‑size firms planning financial dashboards or automated analyses, FiDA will become relevant between 2027 and 2029. Preparation in 2026 is a governance task, not a technical one.
How does PSD3 affect cross‑border payments?
For SEPA payments the main change is the verification logic: the recipient’s name and IBAN must be checked, and liability for mis‑payments shifts. For payments outside SEPA PSD3 changes little, as other procedures already apply there. Mid‑size companies with a high share of foreign payments should discuss with their house bank how verification will be handled in the correspondent‑bank network.
Source cover image: Pexels / anurag upadhyay (px:10958528)