The mandatory APP reimbursement rules that took effect in October 2023 changed the financial calculation for PSPs in a specific and painful way. Under the previous regime, a PSP could dispute a significant proportion of APP fraud claims — "the customer authorised the payment, we can't be responsible for the recipient account." Under the new regime, that defence is largely gone. Sending PSPs absorb half the loss by default, with receiving PSPs covering the other half.
The immediate effect was a spike in reimbursement exposure. The medium-term effect, which is playing out now, is a reorientation of where digital banks invest in fraud prevention. Post-transfer recovery and dispute management are still necessary — but the return on that investment has a natural ceiling at the recovery rate, which for APP fraud is typically low. Pre-transfer interception, on the other hand, prevents the loss entirely. The economics of that shift are clear.
What the APP Reimbursement Model Actually Costs
For a digital bank processing a moderate volume of APP transfers, the direct reimbursement cost per year depends heavily on average transfer value and scam penetration rate. A conservative estimate for a growing UK digital bank with 200,000 active payment customers might look like this: if 0.1% of customers per year are successful APP fraud victims with average losses of £8,000, the gross exposure is £1.6M annually before recovery. Under the 50/50 split, the sending PSP absorbs £800K — before operational costs of managing those claims.
That operational cost is often understated. A complex APP fraud claim involves: initial claim receipt and triage, customer communication, evidence gathering, counterpart bank correspondence, potential FOS referral if disputed, and retrospective review for lessons learned. A fully loaded cost of £400–£800 per claim is not unreasonable for cases that require escalation. At 200 claims per year, that's £80–160K of operational overhead layered on top of the direct reimbursement.
The unit economics of preventing a single APP fraud case — through a honeybot engagement that identifies a scam campaign before the transfer clears — are significantly better than the unit economics of processing and reimbursing it after the fact.
The Shift to Pre-Transfer Detection
Digital banks that have moved their APP fraud investment toward pre-transfer detection are generally doing it in two complementary ways.
The first is richer friction at the payment confirmation stage. This goes beyond a static warning message. It involves dynamic risk scoring that looks at the counterparty account — age, transaction history, incoming transfer patterns — and calibrates the friction intensity to the risk level. A transfer to a new payee that's a few weeks old, receiving its first inbound transfer of this size, gets a different friction experience than a transfer to an established payee the customer has paid before.
The second, and more meaningful, shift is the move toward conversation-layer detection. Friction at the payment UI is too late in the kill chain for sophisticated investment scams — the victim has already been coached on how to respond to bank warnings. The intervention needs to happen before the customer initiates the payment instruction. That requires signal from before the transaction.
This is where conversation-layer tools like honeybots become relevant. When a suspected scam campaign is running — identifiable through a combination of mule account detection, customer reports, and pattern matching from other fraud intelligence sources — a digital bank can deploy honeybot engagement against suspected scammer contact points to generate a fingerprint and identify which customers may be in active scam conversations. Those customers can be prioritised for proactive fraud prevention outreach before they initiate a transfer.
What Proactive Outreach Looks Like in Practice
Consider a scenario: a digital bank's fraud ops team identifies a suspected investment scam mule account that has received six inbound transfers over three weeks, all from new payees, all of similar size. The mule account matches fingerprint patterns from a known investment fraud campaign that has been circulating since early 2025. The bank has three customers who have had recent interaction with the phone number associated with that campaign.
Under the old model, the bank waits for one of those customers to report a fraud claim after the transfer has already been made. Under the proactive model, the bank calls those three customers before any transfer is initiated. Not a generic fraud warning — a specific call that acknowledges the customer may have been contacted about an investment opportunity, explains what investment fraud looks like, and offers to review the investment entity's credentials together.
Of the three customers, one hasn't been contacted, one had initial contact but isn't pursuing it, and one is actively engaged with what is in fact a scam. That third customer gets an escalated intervention — perhaps a temporary payment limit adjustment with an explanation, followed by a detailed fraud advisory session. The transfer never happens. The reimbursement liability never arises.
This is not a hypothetical — it's the operating pattern of digital banks that have integrated fraud intelligence earlier in their workflows. The challenge is building the detection infrastructure to identify at-risk customers before they initiate payment, rather than triaging their claims after.
Integration Considerations for Pre-Transfer Signals
From an integration standpoint, the challenge is connecting the fraud intelligence pipeline to customer operations workflows in time to act. The technical components are:
Inbound fraud signal ingestion — feeds from mule account detection, counterparty risk scoring, honeybot fingerprint matching, and industry fraud intelligence networks (Cifas, Synectics Solutions, etc.) need to be ingested and correlated against customer account data in near real time.
Customer risk enrichment — the correlation between a scam campaign fingerprint and a specific customer account needs to surface in the fraud ops queue before the payment is initiated. This typically requires an API hook into the payment authorisation path, but also into customer service tooling so that proactive outreach can be triggered by the fraud ops team without waiting for a payment instruction to appear.
Outreach workflow — the fraud ops team needs tooling that supports structured proactive calls, not just reactive claim processing. Scripts, call recording, escalation paths, and outcome tracking need to be built for the pre-transfer scenario, which has a different workflow from post-transfer dispute management.
We're not saying this is simple. Integrating multiple fraud intelligence signals, correlating them to customer accounts in real time, and operationalising proactive outreach requires both technical investment and process change. But the cost of that investment, spread across the volume of prevented losses, is substantially lower than absorbing the reimbursement liability.
The Receiving Bank Problem
One structural challenge that digital banks face on the chargeback exposure front is the receiving PSP's incentive alignment. Under the 50/50 split, the receiving PSP absorbs half the loss on confirmed APP fraud cases. This creates a theoretical incentive for receiving PSPs to apply more rigorous scrutiny to incoming transfers to suspected mule accounts. In practice, that scrutiny is uneven.
Some receiving PSPs have invested in mule account detection and proactively flag suspicious incoming transfers. Others have not. The result is that the burden of pre-transfer interception falls disproportionately on the sending PSP, even though the sending PSP has less direct visibility into the receiving account's risk profile than the receiving PSP does.
Industry-level intelligence sharing — through Cifas member data or bilateral DPA-governed data sharing agreements between PSPs — partially addresses this. The scammer fingerprint data that a honeybot engagement generates for AVIEL's PSP clients is one example of fraud intelligence that, shared appropriately under UK GDPR constraints, can benefit both sending and receiving PSPs in the same way card fraud intelligence has historically been shared.
The chargeback exposure problem is a shared liability. The infrastructure to manage it effectively needs to be shared too — which is one of the structural arguments for industry-level investment in conversation-layer fraud detection rather than individual PSPs building it in isolation.