PSD3 is coming, and if you run a payment firm, EMI, wallet product, merchant acquirer, or anything that touches customer funds, this isn’t background noise. It will change how you document your setup, how you explain fraud controls, how you handle agents and distributors, and how banks and regulators look at you.
Not overnight. But fast enough that leaving it for “later” is a mistake.
A lot of founders treated PSD2 like a licensing hurdle. Get approved, plug into banking rails, move on. PSD3 doesn’t really allow that mindset anymore. The direction of travel is pretty obvious: more scrutiny, less tolerance for fuzzy controls, and more pressure to prove that your compliance framework actually works in the real world, not just in a policy folder.
First, what is PSD3 actually trying to fix?
At a high level, PSD3 is meant to clean up the messier bits left behind by PSD2. Different interpretations across EU states. Fraud issues that didn’t go away. Open banking friction. Confusion around which players fall inside the perimeter and which don’t. And, honestly, too many firms with nice slide decks and weak operational controls.
There are also linked changes around payment services access, fraud data sharing, customer protection, and the relationship between payment firms and banks. So if you’ve spent the last two years fighting for accounts, scheme access, or a stable SEPA route, pay attention.
The policy detail keeps moving, so check current requirements in the jurisdictions you care about. But the practical message for operators is simpler than people make it sound.
You should expect:
- tighter governance expectations
- clearer fraud prevention and authentication controls
- more pressure around safeguarding and customer fund handling
- closer review of agents, outsourcing, and group structures
- less room for vague cross-border operating models
That’s the real story.
PSD3 isn’t just a legal update. It’s a due diligence update.
This is the bit founders miss.
Regulatory change doesn’t stay with the regulator. It flows downhill. Your bank asks sharper questions. Your EMI partner wants new documents. Your card acquirer reviews your fraud ratios. A correspondent wants to understand your source of funds controls. Then an investor’s counsel asks why your safeguarding narrative says one thing while your customer terms say another.
Sound familiar?
I’ve seen payment firms get stuck not because they were doing something obviously wrong, but because the business had grown in patches. A UK entity here, an EU entity there, a third-party processor in the middle, one outsourced compliance person juggling too much, and customer journeys that had changed six times since the original licence application. On paper, everything existed. In practice, nobody could explain the whole machine from end to end.
PSD3 will expose that kind of setup pretty quickly.
What payment firms should review now
You do not need to rewrite your entire business this week. You do need a proper gap review. A real one. Not a half-hour call and a red-yellow-green spreadsheet.
Start with these areas.
1. Your permissions versus your actual activity
Plenty of firms drift beyond their original model. Maybe you started with merchant collections and added virtual IBANs. Maybe you now issue payment accounts in practice, even if your marketing still describes the product like a dashboard tool. Maybe your “technology provider” role looks suspiciously close to regulated payment execution.
If your live product has outgrown your licence narrative, fix that first. Everything else sits on top of it.
2. Fraud controls and authentication
PSD3 is heavily shaped by fraud concerns. So expect more attention on transaction monitoring, strong customer authentication logic, exemptions, device risk, mule account detection, and customer communication during disputed payments.
And no, “our vendor handles that” won’t save you. Regulators and banks will still ask how the control works, what alerts fire, who reviews them, what gets escalated, and how fast.
If your fraud stack is outsourced, map it clearly. Decision trees. Manual review thresholds. SAR escalation logic where relevant. Incident logs. Keep it boring and easy to follow.
Honestly, this is where a lot of firms look weaker than they think.
3. Safeguarding and fund flows
Customer money handling has always been sensitive. It’s likely to stay that way, with more focus on how firms actually segregate, reconcile, protect, and explain fund flows. Especially if the model includes multiple PSPs, nested relationships, omnibus accounts, or wallet layers.
If you need a sanity check on whether your banking setup matches your regulatory story, this guide on EMI vs traditional bank account: what a fintech actually needs is worth reading. Founders mix these up alot, and that confusion bleeds straight into safeguarding explanations.
Open banking will keep evolving, but access headaches won’t vanish by magic
Some firms hope PSD3 will suddenly make bank connectivity simple. I wouldn’t bet on that.
Yes, the reforms aim to improve consistency and access. Yes, account information and payment initiation frameworks should get cleaner over time. But banks are still banks. Their risk teams won’t stop caring about complaints levels, chargebacks, AML exposure, sanctions touchpoints, or whether your customer base includes high-risk merchants.
So if your whole plan assumes “the law says they have to work with us”, slow down.
What helps in the real world is structure. The right entities. The right account mix. The right explanation pack. Sometimes a normal corporate account, sometimes an EMI account, sometimes a safeguarding account strategy across more than one provider. Usually not the cheap shortcut the founder wanted on day one.
That’s exactly why firms spend time on Payment Strategy & Banking Access before they start spraying applications everywhere. Random applications with messy docs usually end the same way – silence, declines, or endless follow-up questions.
Group structure matters more than people think
PSD3 will hit operating models, not just policy wording.
If you’ve got a holdco in one country, a licensed entity in another, tech contractors somewhere else, and commercial contracts signed by whichever group company happened to exist at the time, clean that up now. Banks hate ambiguity. Regulators hate it more.
You want a structure that answers basic questions fast:
- Which entity contracts with the customer?
- Which entity provides the regulated service?
- Which entity receives revenue?
- Which entity holds client money or interfaces with the safeguarding bank?
- Who actually controls the technology and key outsourced functions?
If those answers are scattered across old board minutes, Slack messages, and a half-finished data room, you’re asking for trouble.
This is also where founders sometimes realise they built the company in the wrong place for the next phase. If that’s you, look at Company Formation in Multiple Jurisdictions early, before tax, licensing, and banking all start pulling in different directions.
AML under PSD3: don’t treat it like a separate workstream
Formally, PSD3 isn’t “the AML law”. Fine. But in practice, the firms that struggle with PSD changes are often the same firms with weak AML operations.
Why? Because the evidence overlaps.
If your onboarding is sloppy, your fraud controls usually are too. If your transaction monitoring rules don’t match your customer profiles, your risk governance is probably weak elsewhere. If your merchant due diligence pack is thin, good luck explaining how you prevent misuse of payment rails.
For payment firms, the smart move is to review AML and fraud together, not in seperate silos. Customer risk scoring. alert handling. PEP and sanctions screening. suspicious activity escalation. Adverse media review. Merchant underwriting. Chargeback trends. Refund abuse. Agent oversight. They all connect.
And if your internal team is tiny, get help before the regulator, bank, or scheme asks the awkward questions. I’ve seen outsourced compliance setups work very well, especially for firms that aren’t ready for a full in-house MLRO bench. This article on what an MLRO actually does – and when outsourcing beats hiring lays that out pretty plainly.
A practical prep list for the next 90 days
Here’s a sensible short-term plan.
- Map your actual payment flows from customer onboarding to settlement, refunds, chargebacks, and safeguarding reconciliation
- Compare your live business model against your licensed permissions, exemptions, and disclosures
- Review fraud controls, especially SCA logic, alert escalation, and responsibility split with vendors
- Check whether outsourcing agreements, agent oversight, and board reporting are current and usable
- Test whether your group structure still makes sense for passporting, banking, and investor diligence
- Refresh your AML risk assessment so it matches real products, geographies, and customer types
That’s enough to surface most of the ugly stuff.
Then prioritise. Don’t try to polish every policy at once. Fix mismatches first – product versus permission, funds flow versus safeguarding story, actual controls versus what your docs claim.
The firms that do well under PSD3 won’t be the ones with the prettiest policies
They’ll be the ones that can explain their business cleanly. Who does what. Where the money moves. Why the controls make sense. How issues get spotted. Who’s accountable. Simple. Coherent. Believable.
That’s what regulators want. It’s what banks want too, even if they ask for it in a more annoying format.
So don’t wait for the final wording of every technical standard before you move. By then, the better-prepared firms will already have cleaned up the bits that actually slow approvals, trigger remediation, or kill banking relationships.
PSD3 is partly a legal change. Sure. But for most payment firms, it’s really an operational honesty test.
And some businesses are about to find out they don’t like the answer.