PSD3, the PSR and the Case for Network APIs

Fraud just became a balance-sheet problem...

Europe has decided that fraud is no longer something banks manage. It is something they pay for. PSD3 and the new Payment Services Regulation (PSR) turn fraud prevention from a compliance checkbox into a direct liability, and that changes every conversation I have with financial institutions.

Here is the part most commentary misses. The fraud the PSR targets most explicitly - impersonation, or "spoofing" - rarely starts on a payment rail. It starts with a phone call, a text, a swapped SIM or a diverted number. The first signal of the attack lives in the mobile network, long before money moves.

I have spent more than a decade building identity on top of the network, from the first Mobile Identity API specification in 2013 to Number Verify in 2016 and Mobile Connect across 60+ operators. So let me be direct. The regulation has finally caught up with what the network can do. The question now is whether banks will use it.

Where PSD3 and the PSR stand

The rules are agreed, but not yet the law. The Commission proposed the package in June 2023, splitting PSD2 into a directive (PSD3) and a directly applicable regulation (PSR). Political agreement came on 27 November 2025, the final compromise texts followed on 23 April 2026, and the Parliament's ECON committee approved them on 5 May 2026.

The last step has slipped more than once. As of late summer, the package was still waiting for its final votes, and PSD2 remains the law until then. Current estimates put the Official Journal publication in December 2026 or January 2027.

Once published, most rules apply 21 months later and Verification of Payee at 27 months - so realistically late 2028 and spring 2029. That sounds like plenty of time. For fraud architecture, it isn't.

What actually changes for fraud

The PSR rewrites who pays when things go wrong. Five provisions matter most for fraud and identity teams.

1. Liability for weak controls. A PSP that fails to put suitable anti-fraud mechanisms in place will carry the customer's loss (Taylor Wessing).
2. Impersonation refunds. Where a fraudster impersonates the provider, for example by spoofing its name or number, the provider may have to refund the customer (Dudkowiak). The scope was narrowed to impersonation of the payer's own PSP or its staff, not "any relevant entity" (Finologee).
3. Failure to block. If a PSP had objectively justified reasons to suspect fraud and did not suspend or block the payment, the payer should not bear the loss (Finologee).
4. Mandatory fraud data sharing. Sharing moves from encouraged to required where there are reasonable grounds to suspect fraud (Finologee).
5. Name and IBAN matching. PSPs must check that a payee's name and unique identifier match (Taylor Wessing).

Read points two and three together. Liability now follows the signals a bank could have seen. That is a profound shift. The defensive question is no longer "did we follow the process?" It is "what did we know, and when?"

And if your fraud stack cannot see the network, there is a whole class of signals you will never know about.

Telcos are in the fraud chain - as partners, not defendants

The most interesting fight in the trilogues was about telecom operators. The European Parliament wanted to extend impersonation liability to electronic communications service providers. Operators pushed back hard, arguing they are a "mere conduit" with no visibility into the content they carry (GSMA and Connect Europe).

The compromise is sensible. Direct reimbursement liability for telcos looks set to give way to cooperation duties and technical measures against spoofing, possibly backed by a voluntary code of conduct (Finologee). Connect Europe welcomed the outcome, saying a consistent EU-wide framework gives operators and financial institutions the certainty to scale anti-fraud solutions (Connect Europe).

In the same position paper, operators were clear about what they can do. Track and flag unusual SIM swap activity. Work with banks. Act on network-level signals. That list reads almost exactly like the CAMARA API catalogue.

So the policy has defined the cooperation. Network APIs are how that cooperation actually gets delivered - at scale, with consent, and without anyone opening the envelope.

Network APIs are the missing fraud signal

Every major account takeover and impersonation scam I see has a network fingerprint. A SIM was swapped hours before the payment. Calls were quietly forwarded. The device on the session isn't the one tied to the number on file. A bank's fraud engine sees none of this unless it asks the network.

Here is how the main Network API signals line up against the PSR.

Network API signal	What does it tell the bank	PSR obligation strengthens
SIM Swap	Whether the SIM behind a customer's number changed recently	Failure to block; stronger authentication
Call Forwarding	Whether calls to the customer are being diverted elsewhere, conditionally or unconditionally	Impersonation refunds; failure to block
Number Verify	Silent proof that the device with the SIM in session holds the registered number	Strong customer authentication
KYC Match	Whether customer-supplied details match operator records	Onboarding: complements name-IBAN matching
Live number lookup and portability	Whether a number is active, and which network serves it today	Fraud monitoring: evidence for data sharing

None of these signals involves reading a message or listening to a call. They are network facts, shared with consent, at the moment a decision is made. That is exactly the line operators drew in the PSR debate.

There is a second benefit that compliance teams will appreciate. Each API call produces a timestamped, auditable record of what the bank checked and what the network said. When a disputed impersonation claim lands, that record is the difference between "we had no reason to suspect" and "we should have blocked it".

Digital identity: life after the SMS OTP

The PSR also refines strong customer authentication, with new attention to accessibility (Dudkowiak). Across the EU and beyond, regulators are steering banks away from weak methods like SMS OTP (NHIMG on OneSpan's analysis).

I understand why, as this is what I have been working on for more than a decade. An SMS code proves one thing: that a message reached a number. It says nothing about who holds the phone with that number today. SIM swap, call forwarding and social engineering all attack that exact gap.

But ripping out SMS and replacing it with an app-only flow has its own problems. It leaves behind the customers who need protection most - older users, people with basic phones, and people who struggle with complex apps. The PSR's accessibility push makes that trade-off harder to ignore.

The network offers a middle path. Number Verify confirms possession silently, with no code to type and nothing to intercept. Pair it with a SIM Swap and Call Forwarding check, and you have a possession factor that is both stronger and simpler than the OTP it replaces. Add KYC Match at onboarding, and you can verify the person, the device and the payee in one flow rather than three.

There is a bigger reason to get this right now. Agentic AI is starting to initiate payments on people's behalf. When the actor is a piece of software, the bank needs an anchor that ties it back to a real, verified human. I believe the mobile number - verified by the network, not by a code - is the strongest anchor we have. It is a theme I explore in my book, The Internet of Agents, and the PSR is going to make it a practical question much sooner than most expect.

From signals to intelligence: solutions on top of the network

A single API call answers a single question. Has this SIM changed? Are these calls being forwarded? Useful - but it is not what a fraud team actually needs. They need a decision, pay, hold or step up, delivered in sub-second with the reasoning attached.

This is where I believe the real value sits, and it is where we are focusing at XConnect. Not on passing operator signals through, but on turning them into intelligence. We do that by combining four layers.

1. Network APIs. The CAMARA API signals - SIM Swap, Call Forwarding, Number Verify, KYC Match - straight from the operator, with privacy considerations.
2. Network intelligence. Our own number data: live status, portability, routing and range ownership. It tells us whether a number is genuine, active and served by the network it claims to be.
3. Contextual exhaust data. Every lookup and every API call leaves a trace. Patterns across that traffic - velocity spikes, clusters of recent ports, the same number suddenly checked by several institutions - reveal fraud no single check would ever see.
4. Third-party authoritative data. Numbering plans, regulator do-not-originate lists, business registries and consortium fraud data add context the network alone cannot provide.

Trained machine learning models sit across all four. They weigh the signals together and return one risk score, with the reasons behind it.

Why does this matter under the PSR? Because the regulation never asks "did you call an API?". It asks whether the bank had reasonable grounds to suspect fraud, and whether it acted. A SIM swap on its own may be innocent - people lose phones every day. A SIM swap, followed by call forwarding, on a number that ported last week and is now being queried by three other banks, is a very different story. Only a combined view can tell those two apart.

Take impersonation fraud. A customer is on the phone with someone claiming to be their bank. The intelligence layer can ask: is the customer's line being forwarded right now? Does the calling number sit outside the bank's genuine ranges? Has this pattern surfaced elsewhere today? The answer comes back as one explainable signal, before the payment leaves.

Explainability is not a nice-to-have here. Under the failure-to-block test, a bank must show why it acted - or why it didn't. A black-box score won't survive a dispute. A score that says "high risk: recent SIM change, active forwarding, number linked to fraud reports this week" will.

The same intelligence feeds the PSR's mandatory data sharing. Network-anchored insights give banks a common language they can share without exposing customer content, which makes cooperation practical rather than theoretical.

Our role is simple to state. Liability now follows the fraud signals a bank could have seen. We don't just make those signals visible - we make them mean something.

What should financial institutions do now?

The application date looks distant. It isn't. Fraud architectures take years to change, and the evidence you will need in 2028 is generated by the controls you build in 2027. Here is where I would start.

1. Map your impersonation exposure. Trace your last year of payment fraud and spoofing cases back to their first touchpoint. Count how many began with a call, a text or a SIM change.
2. Move from single checks to combined risk intelligence. Don't treat SIM Swap or Call Forwarding as isolated yes/no answers. Fuse them with network intelligence, contextual data and third-party sources into one risk score before high-risk payments, new payees and changes to contact details. These are the moments the "failure to block" test will scrutinise.
3. Plan your exit from OTP-only authentication. Pilot Number Verify as a silent possession factor, and test it with the customers who struggle most with apps.
4. Demand explainable decisions. Every risk score should arrive with its reasons. Log each signal, the decision it informed and why - that record supports both dispute defence and mandatory data sharing.
5. Buy intelligence, not plumbing. Choose a partner that turns network signals into decisions - combining APIs, exhaust data, authoritative sources and trained models - rather than stitching raw feeds together yourself.

The bottom line

PSD2 opened up bank data. PSD3 and the PSR make banks answerable for what they fail to see. That is uncomfortable, but it is also overdue.

For years, the mobile network has held some of the clearest early warnings of fraud, and for years those warnings went unheard. The regulation now gives banks a financial reason to listen and gives operators a clear framework to speak. The advantage will go to whoever turns those signals into intelligence.

The banks that move first won't just cut their refund bills. They will build something rarer: payments that customers - and soon their AI agents - can genuinely trust. I know which side of that line I would want to be on.

Think carefully. Stay curious.