PSD3 and the PSR: How Payment-Adjacent SaaS Should Prepare Its Architecture

If your SaaS product touches money without being a bank - invoicing, marketplace payouts, subscription billing, expense management, embedded checkout - you have probably told yourself that payment regulation is your payment provider's problem. PSD3 and the Payment Services Regulation (PSR) are about to test that assumption. PSD3 compliance will not only tighten the rules for licensed payment institutions; the package redraws the boundary between "regulated payment service" and "technical service provider", and some products that comfortably sat outside PSD2 will find themselves inside the new perimeter, or at least contractually dragged into it by their banking partners.

This post explains what the PSD3/PSR package changes, how to test whether your product is in scope, and which architecture decisions are worth making now, while you still have room to choose.

What PSD3 and the PSR Actually Are

The European Commission proposed the package in June 2023 as the successor to PSD2. It splits the old directive into two instruments, and the split matters more than it first appears:

• PSD3 is a directive aimed at the licensing and supervision of payment institutions. It absorbs the e-money regime, so e-money institutions and payment institutions converge into a single authorisation framework that member states transpose into national law.
• The PSR is a regulation, which means it applies directly and uniformly in every member state without national transposition. The conduct rules - strong customer authentication, open banking access, fraud liability, transparency requirements - live here.

That second point is the strategic one. Under PSD2, national regulators interpreted the rules differently, and many borderline products survived on a favourable national reading of the "technical service provider" exclusion. A directly applicable regulation removes much of that wiggle room. The interpretation that matters will be the EU-wide one.

The package is still moving through the EU legislative process, and the final application date will land roughly 18 months after adoption. That sounds comfortable. It is not. The architectural changes described below are the kind that take several quarters to execute well, and your partner banks will start pushing updated contractual requirements down to you well before any deadline, exactly as they did with DORA.

The Scope Test: Are You Actually Payment-Adjacent?

The PSD2 exclusion most SaaS products rely on is the technical service provider carve-out: you support the provision of payment services without ever entering possession of the funds. PSD3 and the PSR keep the concept but sharpen the edges around it. Three questions tell you most of what you need to know:

1. Do funds ever sit in an account you control? Marketplace models with payout delays, wallet-like balances, or "store credit" features are the classic trap. If money rests with you, even briefly, you are likely providing a payment service that needs authorisation or a clearly documented exemption.
2. Do you initiate payments or aggregate account data? Payment initiation and account information services remain regulated activities. If your product triggers payments from a user's bank account or pulls their transaction history, you are in open banking territory with its own access and security rules.
3. Do you operate the customer-facing authentication journey? The PSR pushes obligations around strong customer authentication outcomes towards whoever controls the user journey. Even as an unregulated technical provider, expect your regulated partners to impose SCA-related requirements on you contractually, because the PSR explicitly contemplates liability allocation between payment providers and the technical parties they rely on.

If you answered yes to any of these, treat PSD3 readiness as a product requirement, not a legal footnote. A code quality and architecture audit that maps where money and payment credentials actually flow through your system is the cheapest possible first step, because the gap between what your architecture diagram claims and what the code does is exactly what a partner bank's due diligence will find.

What PSD3 Compliance Changes for Strong Customer Authentication

The SCA regime survives, but with corrections aimed at the friction and fraud patterns PSD2 produced:

• Outcome-based exemptions. The package moves towards judging authentication by fraud outcomes rather than prescribing one rigid challenge flow, which rewards providers with good risk engines and clean data.
• Accessibility requirements. SCA must work for users without smartphones and users with disabilities. If your product embeds an authentication journey that assumes an app-based authenticator, you will need alternative paths.
• Impersonation fraud liability. The PSR extends liability for authorised push payment fraud, including cases where fraudsters impersonate bank staff. Banks will respond by demanding richer transaction context from every upstream party - your product included - to feed their fraud models.
• Verification of payee. IBAN-name matching becomes standard for credit transfers. If your SaaS submits payout batches, expect to handle match/no-match/close-match responses in your payout flow and to surface them to users in a way that creates a clean audit trail.

The engineering consequence: authentication and payout flows you currently treat as fire-and-forget API calls become stateful conversations with the bank, with results you must store, display, and act on.

Open Banking Gets a Performance Contract

For products built on account information or payment initiation, the PSR replaces the PSD2 fallback-interface debate with a clearer deal: banks must provide dedicated interfaces with defined availability and performance, plus permission dashboards that let customers see and revoke data access. In exchange, screen scraping's grey zone shrinks further.

Practically, this means your integration layer should assume API-only access, treat third-party providers' permission state as revocable at any moment from outside your product, and reconcile your local consent records against the bank-side dashboard state. A consent model that exists only as a boolean column in your users table will not survive this.

Five Architecture Moves to Make This Quarter

You do not need final legislative text to start, because these decisions are valuable under any plausible outcome:

1. Isolate the payment layer behind one internal interface. If billing, payouts, and checkout call your PSP from a dozen places, consolidate them behind a single internal service or module. Scope questions, audits, and provider migrations all become tractable when payments have one front door. This is standard practice in well-run custom software builds, and retrofitting it is far cheaper than retrofitting compliance into scattered call sites.
2. Build the money-flow map as a living artifact. Document every path where funds, payment credentials, or account data move through your system, and keep it in the repository next to the code so it changes when the code changes. This single document answers half of any regulator or partner-bank questionnaire.
3. Make consent and mandate state first-class. Model user consents (data access, payment mandates, stored credentials) as explicit entities with lifecycle events, not as flags. You will need the history, not just the current value.
4. Treat verification-of-payee and SCA results as stored events. Add the tables and event types now, even if today you discard these responses. Backfilling an audit trail is impossible; recording one is cheap.
5. Decide deliberately whether to stay outside the perimeter. Sometimes a small product change - removing a balance feature, shortening a payout delay, pushing funds flow fully to the PSP - keeps you cleanly in technical-provider territory. That is a strategic choice about your tech stack and product direction, and it deserves an explicit decision rather than drift.

Frequently Asked Questions

Is PSD3 already in force? No. The package was proposed in June 2023 and is still completing the EU legislative process. Application will follow roughly 18 months after adoption. The preparation window is real but shorter than it looks, because partner banks propagate requirements contractually before legal deadlines hit.

We never touch funds. Can we ignore the PSR? Not entirely. The technical service provider exclusion survives, but regulated partners will pass obligations through to you in contracts, particularly around SCA support, fraud data, incident notification, and audit access. Being out of scope legally does not mean being out of scope commercially.

Does PSD3 replace SCA? No. Strong customer authentication remains, with adjustments: more outcome-based exemption logic, accessibility requirements, and tighter links between authentication evidence and fraud liability.

How does this interact with DORA? DORA covers operational resilience for financial entities and their ICT providers; PSD3/PSR covers the conduct of payment services. If you sell into EU financial services you will likely face both, and they reward the same architectural property: a system whose data flows and dependencies you can actually evidence.

Prepare While It Is Still Cheap

The teams that suffered under PSD2 and DORA were not the ones with the most regulated products; they were the ones who discovered their obligations from a partner bank's questionnaire with 90 days to respond. The PSD3/PSR package is the rare case where you can see the requirements coming years out.

If you want a second pair of eyes on where your product sits relative to the new perimeter, or help isolating your payment layer before the contractual requirements arrive, write to hello@wolf-tech.io or visit wolf-tech.io. We audit payment-adjacent architectures, map the money flows, and build the modernization plan with your team.