A note for fraud and risk leaders on what open banking actually defends against — and why the quiet wins (CoP, VoP) and the unsolved problems (APP, mules, fairness) both point the same direction: layered defence, customer journey first.
Two numbers that disagree
Cifas members recorded 444,000 cases of fraud against UK consumers in 2025. That is the highest single-year total on record, and a 6% jump on 2024. Identity fraud alone accounted for 242,000 of those cases — more than half of everything filed. UK Finance puts total losses for 2024 at £1.17 billion, of which roughly £572 million was on cards and a further ~£450 million was authorised push payment fraud — money that customers themselves transferred to criminals because they had been convinced to. Twelve hundred new fraud cases hit the Cifas National Fraud Database every single day.
Against that scale, here is the headline number the open banking industry has been printing on every press release for the last two years:
Fraud on open banking transactions is running at 0.013% by volume, against 0.045% for the wider payments sector. By value, 0.020% versus 0.027%. And while the wider industry's fraud rate has risen over the last eighteen months, open banking's has fallen.
Two stories. Both true. Almost incompatible.
This is a post about what is happening in the space between them.
That headline contrast also hides a more interesting structure. The OBL report splits open banking fraud and the wider industry by type, and the result is not what most of the press releases imply. Open banking is dramatically safer on unauthorised fraud — 0.003% by volume against the industry's 0.040%. That single number does almost all the work in the overall comparison.
But on authorised push payment fraud specifically — the kind where the customer themselves transfers the money — open banking is actually higher than the industry average (0.009% vs 0.005% by volume; 0.016% vs 0.011% by value). Open banking has all but solved one half of the fraud problem and made the other half slightly worse.
That is the spine of this post. Both findings matter, and the rest of what follows is about the controls that get you each of them.
The two strands you have to keep separate
There are two completely different conversations going on under the banner of open banking and fraud, and treating them as one is how we end up with confused boards and overstated press releases.
Strand one: open banking as a defence. The data that lets firms detect fraud they previously couldn't see — verifying an applicant's identity, confirming a beneficiary's name, spotting income mismatches, layering bank-account behaviour onto an underwriting decision.
Strand two: open banking as a new attack surface. Fresh APIs, consent flows, account-linking journeys, third-party providers — each of them a new place for fraudsters to engineer their way in.
Both are real. Both deserve their own post. This one is about defence. The next in this series will cover the attack surface — because the rapid growth of open banking has changed the shape of the threat in ways the early proponents did not advertise.
The defence rests entirely on the use case
There is a respectable argument — made by every major open banking vendor and most of the regulators — that open banking data is the highest-fidelity source available for verifying who someone is. It comes directly from the consumer's own bank account. It is real, current, structured and consented. For account authentication and identity verification, you cannot — in principle — do better.
In principle.
The whole defence story depends on a single, brutal question: will the customer connect their account?
For some use cases the answer is yes, comfortably. We want to pay you money. A fraud check before a loan disbursement. KYC for opening a new investment account. The value exchange is obvious, the customer cooperates, and you get the highest-fidelity signal in the industry.
For other use cases — please connect your bank so we can verify you for something low-value — the answer is, increasingly, maybe. And the moment the customer hesitates or says no, the highest-fidelity signal in the industry collapses to zero.
What the journey doesn't yet support
UK open banking adoption is genuinely impressive. 16.5 million active user connections by the end of 2025, up 36% year on year. 24 billion successful API calls in the ecosystem, up 27%. 351 million payments. For the first time on record, one in five UK consumers and small businesses used open banking in the previous month.
That is mainstream traction. But it needs to be put next to the rails the wider payments industry is actually running on.
- Faster Payments processed around 5.9 billion transactions in 2024, with payments overall across UK rails totalling roughly 44 billion. Open banking PIS payments — 351 million — are about 6% of Faster Payments volume, and under 1% of all UK payments. The growth rate is excellent (+57% year on year). The base is small.
- Account Information Services (AIS) — the data side, which is what the fraud-defence argument mostly rests on — still account for roughly 4 in 5 of all open banking API calls. AIS user growth was +35% in 2025, PIS +36%; PIS users are now 55% of the total user base, up from 25% in 2021. The data-sharing flows are still doing most of the work, but payment initiation is catching up fast.
- And the proportion of UK adults using open banking at all is still about a third. Card payments, by comparison, are universal.
So inside the third of the population that has used it, the journey is still not built for what we now want it to do. Customers have started to understand that connecting a bank account is what you do to share a statement, or to set up a payment from a fintech. They are not yet used to doing it to confirm who they are. Every time a journey adds it as a step, you can see the question forming on their faces: what else can they see? Just the account name? Why is the page so big, then?
That is not a settled UX. That is a UX that is still being built.
There are operational frictions sitting underneath the customer-facing ones, too:
- Account name data isn't returned consistently across banks. Barclays, Santander, Starling and AIB are among the institutions where the account-name field has historically been delivered in inconsistent ways across the consent flow. The cleanest fraud-detection signal in the stack only works if the field is actually populated.
- Category labels can be gamed. Open banking transaction categorisation is famously messy — only around 63% of transactions are correctly categorised by MCC alone — and fraudsters know it. A "professional services" merchant code is cheap. A serious verification stack cannot rest on category labels in isolation.
- First-party fraud is hard to see in a current account. A customer can keep an immaculate-looking current account precisely because they have stopped paying anyone else. (We made this argument in detail for credit scoring last month; the same logic applies to fraud detection.)
None of this makes open banking bad. It makes it incomplete — in exactly the way every new defensive technology is incomplete before it has been wired up to everything else.
The quiet success story is Confirmation of Payee
The most-cited operational example of open-banking-style data being used against fraud is Confirmation of Payee (CoP) in the UK, and its European counterpart Verification of Payee (VoP), now mandatory across the Eurozone from 9 October 2025 under the Instant Payments Regulation.
CoP answers one specific question: does the name you typed match the name on the account you're about to pay?
It does it with zero customer friction. There is no consent flow. There is no journey choice. There is no please connect your bank. It just runs, before the payment is sent, and tells you whether the names match.
It does it at near-100% coverage. The PSR has now extended CoP to 99% of Faster Payments. Every major UK bank participates. More than 300 organisations are live, and over two million CoP checks happen every day.
And — for the specific problem of mistaken-identity payments and impersonation scams — it works.
Rabobank's original 2017 pilot in the Netherlands, the scheme's origin, reported a 70% drop in invoice fraud and 50% fewer transfers to the wrong account after nine months. The product that came out of it, SurePay, has now analysed more than four billion CoP-equivalent checks; on the latest published numbers, that book of evidence shows an 81% fall in reported fraud and scams and a 67% reduction in misdirected payments. In the UK, Lloyds has reported a 31% reduction in APP fraud since rolling out CoP. The UK government has been characteristically more cautious, noting that CoP "provides a critical safety net for consumers" while also "introducing new risks for firms to manage", and the PSR has committed to an independent post-implementation review.
The takeaway is not that CoP solves fraud. It is that a low-friction, near-universal verification check, run at the right point in the journey, can shift a fraud curve in a way no high-friction process ever will. That is the lesson of CoP, and it defines everything that comes next.
The defensible architecture is what we call the triple match: the name the applicant gives you, the name on the open banking bank statement, and the CoP return on the destination account, all reconciling. Where any two diverge, you investigate. Where all three align, you can move fast. That is a high-confidence, low-friction control surface — and it is doing actual work right now.
CoP becomes even more powerful when it is taken out of the bank and pushed into the everyday situations where consumers actually get defrauded. A nice current example is whoamipaying.co.uk, which lets a person upload an invoice from a builder, paste a Facebook Marketplace listing for a used car, or enter the payment details of a tradesperson they have never used before — and then runs CoP alongside Companies House, HMRC VAT, DVLA vehicle records, online reviews and an AI price-check, returning a single traffic-light verdict in under thirty seconds for £2.50. That is the right architectural instinct: take the verification signal, fuse it with every other data source you can legitimately reach, and meet the customer in the actual scenario where the fraud happens — not in a separate, abstract "fraud check" journey they will not naturally seek out.
Where CoP runs out of road: APP fraud and social engineering
CoP catches scams where the name does not match the account. It is much less effective against scams where the customer genuinely intends to pay the named beneficiary — because the customer has been socially engineered into believing the named beneficiary is real. Romance scams. Investment scams. Purchase scams (which now account for 72% of APP fraud cases). The match comes back green. The customer hits send. The money is gone.
That is the heart of the UK's remaining APP fraud problem. Losses still ran close to £450 million in 2024. The PSR's mandatory reimbursement regime came in on 7 October 2024, capped at £85,000 per claim. The early data is genuinely encouraging: 88% of money lost to APP scams is now being returned to victims (up from 66% the year before), 84% of claims resolved within five days, claim volumes down ~15% year on year. A 2024 Journal of Financial Regulation article argued — fairly — that mandatory reimbursement is valuable but its specific coverage is too narrow, and the priority for regulators should be a more joined-up response to APP fraud across the payment ecosystem.
The mule literature picks up the same thread from the other end. RUSI's recent research with Lloyds data, summarised in Outseer's review of UK fraud research, made a striking observation: open banking is known to be used to pull money into mule accounts, but there is no published evidence of it being used to push money onwards from them. The rails are being abused asymmetrically. Stopping that asymmetry needs behavioural and network-level signals layered on top of account-level data — and a new generation of mule-intelligence specialists like aviel.tech, which builds an AI-driven live feed of identified mule accounts that PSPs can consume in real time, is starting to do exactly that. It is also exactly the kind of cross-firm cooperation PSD3 is now trying to make mandatory.
And one harder question the industry has been slow to ask
Open banking is, in effect, a permission system that lets third parties access transactional data that the banks themselves already hold. If transactional patterns are the highest-fidelity fraud signal we have — and the entire open banking case is built on the argument that they are — then the institutions sitting on the source data have an obvious obligation to use it more aggressively at source.
Banks already hold everything a mule-detection model needs. HMRC, on a parallel rail, routinely closes down shell businesses where reported VAT and corporation-tax performance deviates aggressively from the sector mean — using exactly the kind of statistical anomaly detection that the OB community is now selling back to lenders. There is no architectural reason a high-street bank could not flag and freeze a current account whose inflow / outflow pattern deviates from its own historical baseline by more than the population variance — before a mule cash-out has cleared. The defence stack does not have to wait for an open banking consent flow to start working. The first line of defence is the bank that holds the account, not the third party asking to look at it.
That conversation, however, is somebody else's blog post. The point here is simply: the layered defence does not end at the open banking edge.
The regulatory direction of travel reinforces all of this
It is worth saying out loud what the regulators have already concluded.
PSD2 was built around authentication — make sure the right person is logging in, make sure the right person consented to the payment. As open banking transaction volumes rose from 410 million a month in mid-2020 to over a billion a month by mid-2022, and PSD2's liability rules made banks fully responsible for unauthorised or fraudulent open banking transactions, the limits of authentication-as-defence became obvious. APP fraud is what happens when authentication works perfectly and the wrong thing happens anyway.
PSD3 and the accompanying Payment Services Regulation, agreed in late 2025, are the regulatory acknowledgement of that gap. They redistribute accountability across the payments ecosystem, treat fraud prevention as a transactional and behavioural risk-control problem sitting inside the payment-execution layer, and embed VoP-style checks as a baseline. The Eurozone is live now. The rest of the EU follows in July 2027.
The implication is straightforward: authentication alone is no longer a defensible fraud strategy in Europe. Layered defence — verification, behavioural signals, network data, with open banking as one input among several — is.
Three takeaways
One. The customer journey will decide which defences actually scale. The single biggest reason CoP works and direct open-banking-for-identity is uneven is friction. CoP added none. OB-direct asks the customer to do something they're not yet used to doing. The defences that win this decade are the ones the customer doesn't notice.
Two. Open banking is the highest-fidelity fraud signal available, but only inside the use cases where the customer will connect. Where they will, lean on it hard, with the triple match as your default control. Where they won't, you need a different layer.
Three. CoP, VoP, behavioural signals, mule-network data and bureau records are not competing with open banking. They are the layered defence that makes open banking's high-fidelity moments actually count. That is the same answer we came to for credit scoring. It turns out to be the same answer for fraud.
Coming next: the other side of the coin
Two threads we have deliberately left for follow-up posts.
The first is open banking as an attack surface — the consent flows, the third-party-provider model, the impersonated authorisation screens, the bits of the new architecture fraudsters are already adapting to. That is its own post, and it is the more uncomfortable one.
The second is a fairness question raised most rigorously by Savina Kim, Galina Andreeva and Michael Rovatsos at the University of Edinburgh, whose work on 180 million transactions from 100,000 UK consumers gave the first solid evidence that the granularity of open banking transaction data can act as a proxy for sensitive and prohibited characteristics. The false-positive cost of a fraud model, in particular, falls disproportionately on financially vulnerable customers whose transaction patterns deviate from the modal customer. If more data is always better is the implicit assumption of every open banking deck, that assumption deserves to be tested. We will.
This is the problem Credit Canary was built to solve.
We did not start Credit Canary because we thought open banking was a silver bullet for fraud. We started it because we watched firms being asked to pick between bureau or open banking, CoP or open banking, behavioural signals or open banking — when the answer was always and.
Credit Canary brings open banking, Confirmation of Payee, credit bureau data, identity signals and behavioural / network data into a single decisioning layer — so risk teams can run the triple match where it adds defence, run it invisibly where the journey demands it, and call in the rest of the stack the moment any one signal is weak or missing.
A defensible fraud architecture — the kind that survives an FCA review and a determined fraudster — is the one with no single point of failure. Not the one with the loudest single signal.
The fraud problem is bigger than open banking can fix on its own.
The layered defence, quietly, is already winning.
← Back to News & Opinion