8 Min. Reading Time · Updated: 21.04.2026<\/p>\n
Since 27\u202fNovember\u202f2025 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\u202f2026, followed by 18\u202fmonths of transposition and 21\u202fmonths of transition. For mid\u2011size firms this means: the operational pressure won\u2019t arrive in 2026, but the decisions that will be under pressure in 2028 are being made now. Companies that refresh payment flows, embedded\u2011finance 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.<\/strong><\/p>\n Key Takeaways<\/p>\n Related<\/span>Generative AI in Customer Service: From Pilot to Production<\/a> \/<\/span> Predictive Analytics in ERP: Making Customer Retention Measurable<\/a><\/p>\n What is PSD3?<\/strong> PSD3 is the EU\u2019s 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\u2011party 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\u202f2026. It will enter into force roughly 20\u202fdays after publication, with most provisions becoming applicable 18\u202fmonths later.<\/p>\n The substantive shift from PSD2 is relevant in three key areas. First, the core user\u2011rights matter moves from the directive into the directly applicable regulation, forcing harmonisation because Member States will no longer have gold\u2011plating leeway. Second, banks must build their TPP APIs to meet the same performance and availability standards as the bank\u2019s own online\u2011banking channel. The previous situation, where TPP APIs were slower, less stable or less functional than the end\u2011customer interface, is prohibited. Third, IBAN recipient\u2011name verification becomes a legal requirement with a liability shift 24\u202fmonths after entry into force.<\/p>\n For finance leaders in mid\u2011size companies this does not mean PSD3 will become an acute daily issue in 2026. It means that projects with longer timelines (treasury\u2011system migrations, new embedded\u2011finance integrations, replacement of payment\u2011processing platforms) must already be planned with the 2028 requirement in mind. A treasury migration that starts in 2026 and goes live in Q3\u202f2027 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.<\/p>\n 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\u2011banking integration. The IBAN\u2011recipient\u2011name 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.<\/p>\n 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\u2011payments 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\u2011finance 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.<\/p>\n 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.<\/p>\n 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\u2011finance 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.<\/p>\n The sequence below is not a framework but a series of concrete checks that finance leaders should run through in Q2 and Q3\u202f2026. It replaces neither external legal advice nor an IT assessment, but it structures the conversations with your bank, TMS provider and embedded\u2011finance partners. The timeline is intentional: anyone who has a clear inventory on the table in Autumn\u202f2026 can move into operational preparation in 2027 and secure implementations in 2028.<\/p>\n \u201cThe most common regulatory transformation I\u2019ve seen in recent years fails not on the law but on translating it into systems. PSD3 will succeed with mid\u2011size firms that already document their payment and data processes in a way that makes them changeable.\u201d Eva Mickler, Senior PM Evernine<\/cite><\/p>\n<\/blockquote>\n Treasury & Banking side (Q2\u202f2026)<\/p>\n Embedded finance & partner side (Q3\u202f2026)<\/p>\n What is deliberately left out of this sequence is an internal PSD3 project with its own project team. Most mid\u2011size 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\u2011name check to the treasury migration that is already planned, and expand the embedded\u2011finance tender\u2014already being prepared\u2014to include PSD3 readiness as a criterion. This saves resources and places the requirements where they will be implemented anyway.<\/p>\n The critical point is the timing of communication with your house bank. Banks are currently planning their own PSD3 roadmaps, and corporate\u2011client questions feed directly into their prioritisation. If you don\u2019t ask now, you\u2019ll 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.<\/p>\n A second argument for early communication is budgeting. PSD3\u2011related adjustments to the TMS, the ERP interface or the embedded\u2011finance 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.<\/p>\n The final consideration concerns external service providers. Mid\u2011size 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\u2019 standard contracts from 2027 onward through price adjustments and service\u2011level 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\u202f2026, before the main negotiation season, is the cost\u2011free way to prepare.<\/p>\n 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\u2011name verification under PSR, the expectation for release changes: when a system flags a name\u2011IBAN mismatch, clear rules are needed about who decides and on what criteria. This is not a technology question; it\u2019s 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\u2019t block releases or trigger escalations in the first weeks of rollout.<\/p>\n 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\u20112028. For mid\u2011size companies this means: operational impact from 2028, preparation in projects starting now.<\/p>\n<\/details>\n 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.<\/p>\n<\/details>\n 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\u2011finance projects with PSD3 requirements. A dedicated PSD3 project team only makes sense for business models that are heavily finance\u2011service oriented, such as fintechs, factoring providers or embedded\u2011finance platforms.<\/p>\n<\/details>\n 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\u2011size 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.<\/p>\n<\/details>\n For SEPA payments the main change is the verification logic: the recipient\u2019s name and IBAN must be checked, and liability for mis\u2011payments shifts. For payments outside SEPA PSD3 changes little, as other procedures already apply there. Mid\u2011size companies with a high share of foreign payments should discuss with their house bank how verification will be handled in the correspondent\u2011bank network.<\/p>\n<\/details>\n Source cover image: Pexels \/ anurag upadhyay (px:10958528)<\/em><\/p>\n\n
What is PSD3 and what changes compared to PSD2<\/h2>\n
Three entry points where SMEs decide now<\/h2>\n
Checklist for CFOs through Autumn 2026<\/h2>\n
\n
\n
\n
Frequently Asked Questions<\/h2>\n
When will PSD3 become practically applicable?<\/strong><\/summary>\n
What distinguishes PSD3 from the PSR?<\/strong><\/summary>\n
Do I, as a mid\u2011size company, need to set up my own PSD3 project?<\/strong><\/summary>\n
What is FiDA and how does it relate to PSD3?<\/strong><\/summary>\n
How does PSD3 affect cross\u2011border payments?<\/strong><\/summary>\n
More from the MBF Media Network<\/h2>\n