PSD2's strong customer authentication (SCA) requirement was one of the most significant fraud prevention mandates in UK payment history. The logic was straightforward: multi-factor authentication for online card transactions would force attackers to compromise both something-you-know and something-you-have, raising the cost of card fraud substantially. UK Finance's data confirms the intended effect: card-not-present fraud rates fell following SCA implementation.
APP fraud went the other direction. While card fraud dropped, authorised push payment fraud grew. The reason is structural, and understanding it is important for any PSP that's wondering whether the next regulatory credential requirement — whatever form it takes — will move the APP fraud needle.
It won't. Not on its own. Here's why.
What SCA Actually Protects Against
Strong customer authentication protects against a specific threat model: an attacker who has obtained a customer's credentials and wants to use them to make unauthorised payments. The attacker doesn't have the customer's device or biometric data. SCA requires two factors from different categories (knowledge, possession, inherence), so having the password alone isn't enough.
This is effective against account takeover fraud and card-not-present fraud where the attacker is operating independently of the account holder. The attacker is the problem. Remove the attacker from the equation by requiring proof of possession (the customer's phone) or inherence (the customer's biometric), and the unauthorised access fails.
APP fraud is a completely different threat model. The attacker is not trying to access the account without the customer. The attacker's goal is to convince the customer to access the account themselves and make a payment the attacker directs. The customer authenticates fully — they have the right device, they pass biometrics, they receive and confirm the SCA push notification. From a technical standpoint, this is an unambiguously legitimate transaction. The fraud is in the customer's state of mind, not in their credentials.
SCA cannot protect against an attack that operates through the customer rather than around them.
The Open Banking API Surface and APP Fraud
PSD2's open banking provisions — requiring PSPs to provide standardised APIs for account information service providers (AISPs) and payment initiation service providers (PISPs) — created a new technical surface that some commentators initially worried would increase fraud exposure. The concern was that third-party PISP access to payment initiation could be a fraud vector.
In practice, that concern hasn't materialised significantly. PISPs are regulated entities with their own strong authentication requirements under PSD2 Article 97. PISP-initiated fraud looks different from APP fraud and remains relatively low volume.
What the open banking API surface has enabled, more interestingly, is richer account data access that could theoretically support better APP fraud detection. An AISP-powered service that a customer consents to can see account transaction history, counterparty patterns, and balance information. That data, with appropriate consent, could enrich a fraud detection model's feature set — particularly for detecting unusual payee patterns that transaction monitoring alone might miss.
The challenge is consent architecture. Open banking account information access requires explicit customer consent, renewed periodically. Asking customers to grant an AISP consent for fraud detection purposes before they've been targeted — and before they know they should be worried — is a poor user experience with predictably low uptake. By the time a customer might retrospectively consent after a fraud incident, it's too late.
The Payee Verification Gap and Confirmation of Payee
Confirmation of Payee (CoP) is the UK's name-matching service for Faster Payments and CHAPS. When a customer initiates a payment, CoP checks whether the account name they've entered matches the name on the destination account. A mismatch generates a warning. The intention is to reduce both misdirected payments and some types of APP fraud where the victim is given a mule account under a false name.
CoP is useful and its coverage has expanded substantially since mandatory participation requirements came into force for the six largest UK PSPs. It genuinely reduces the category of APP fraud where the scammer provides a mule account with a name that doesn't match the claimed identity — investment scams claiming to be from "Hargreaves Lansdown" but using a mule account registered to an individual, for example.
Where it doesn't help: mule accounts registered under the scammer's actual name or a synthetic name that matches the provided alias. Professional mule networks register accounts under real identities (often stolen or purchased). The name matches. CoP passes. The fraud proceeds.
Where it actively backfires: customers who have been coached by sophisticated scammers are often told in advance that the account name might show as different because "it's a holding account" or "the intermediary bank uses a different name." Counter-coaching around CoP is now standard in investment scam scripts. A customer who's been told to expect a name mismatch won't be deterred by one.
Where PSD2 and Open Banking Leave PSPs
The honest assessment of PSD2's contribution to APP fraud prevention is: close to zero direct impact on APP fraud rates, and some marginal indirect contribution through improved payment infrastructure that could support better fraud tools if PSPs invest in using it.
This isn't a criticism of PSD2's design. It was designed to address the fraud threats of its era — credential theft, card-not-present fraud, unauthorised account access. It addressed those threats well. APP fraud is a different category and requires a different response.
The response that works has to operate at the conversation layer. By the time the payment initiation hits the API, the SCA flow, and the CoP check, the victim has been fully prepared to authenticate and transfer. The intervention window has closed. Credential controls and payee name matching are not useless — they're part of a layered defence — but they cannot be the primary APP fraud countermeasure.
What the Open Banking Ecosystem Could Enable
There is a more optimistic read of open banking's potential contribution to APP fraud prevention, though it requires investment beyond basic compliance.
Enriched payment context APIs — where payment initiation can carry structured metadata about the communication channel that preceded the payment — could allow PSPs and their fraud detection tools to score the context rather than just the transaction. If a PISP-initiated payment includes a field indicating that the customer initiated the payment following receipt of a WhatsApp message from a new contact, that context changes the risk score even when the payment instruction itself is clean.
This requires industry coordination on schema and API design that doesn't currently exist. It's a five-year horizon, not a current capability. But the open banking infrastructure — standardised APIs, regulated third-party access, consent management frameworks — is a foundation that the industry could build on for richer fraud context if there were regulatory and commercial will to do so.
The Practical Implication for Fraud Ops Teams
PSP fraud ops teams sometimes ask whether they should be waiting for regulatory or infrastructure developments to solve the APP fraud problem. Our view is no. The regulatory framework — mandatory reimbursement, Consumer Duty, open banking — is the environment you operate in. It's not going to produce a technical solution for APP fraud on your behalf.
The tools that genuinely move the needle — conversation-layer interception, mule account network detection, cross-PSP fingerprint sharing — are available now, or close to it. They require integration investment and compliance work. They don't require waiting for PSD3 or the next iteration of open banking standards.
What PSD2's SCA requirements demonstrated conclusively is that credential and authentication controls at the payment layer are not APP fraud countermeasures. The attack is earlier in the chain. The defence has to be too.