Outside the Perimeter: Corporate APP Fraud and Where the Reimbursement Regime Stops

Mandatory reimbursement reorganised the way British banks think about authorised push payment fraud. Budgets, warning design, claim handling, receiving side controls and board reporting have been rebuilt around one question: will this loss be reimbursable, and who pays. The effect has been broadly positive and also narrowing, because the regime draws a perimeter and institutional attention has followed the perimeter rather than the fraud.

Outside that perimeter sits a population that loses money in larger individual amounts than any retail victim, has no statutory route to recovery, and whose losses in most firms never appear in the fraud reporting pack at all. These are businesses: the mid-market manufacturer, the professional services partnership, the housing association, the logistics operator. They are defrauded through invoice redirection, supplier bank detail change and compromised internal authorisation, and the payment leaves through a corporate channel the bank's retail models were never built to read.

This post is about that population, and about the gap between what the reimbursement rules require and what a bank actually owes a corporate client. It is deliberately not about receiving bank mule detection or about claim abuse in the reimbursement process, both of which have run recently and are separate controls with separate owners. The question here is what happens when a business, rather than a consumer, is the one who pressed approve.

Regulatory and Market Context

The Payment Systems Regulator's reimbursement requirement is scoped with deliberate precision. It applies to payments made over Faster Payments and CHAPS between accounts in the United Kingdom, and it protects consumers, microenterprises and charities. Microenterprise status follows the Payment Services Regulations definition, turning on headcount below ten and a turnover or balance sheet total below a modest euro threshold, and charitable status turns on an annual income limit. There is a maximum level of reimbursement, an optional excess, a claim window measured in months, and a consumer standard of caution that can defeat a claim. Everything above those thresholds sits outside the regime.

That boundary is a policy choice rather than an oversight. HM Treasury and the regulator framed the regime as consumer protection, on the reasoning that businesses negotiate their own banking terms, hold their own treasury controls and can buy crime insurance. In practice the mid-market corporate has the payment volumes of a business and the control environment of a small firm, and the legal position it falls back on is thin. The Supreme Court's decision in the Philipp litigation confirmed that where a customer personally and validly authorises a payment, the bank's duty is to execute it, and that the older line of authority requiring a bank to refrain from executing a suspected fraudulent payment does not extend to that situation. What survives is a narrower duty to act on notice, principally around recovery once fraud is reported, alongside whatever the contract says. For a corporate treasurer that is a materially different proposition from a statutory reimbursement right.

What the Data Is Showing

TrustSphere's own engagement data, drawn from business payment fraud reviews at UK and European banks, shows the corporate loss profile behaving almost nothing like the retail one. Retail losses are numerous, individually small and concentrated in purchase, romance and impersonation typologies. Corporate losses in our sample were far fewer in count, an order of magnitude larger by median value, and overwhelmingly concentrated in one typology: invoice redirection and supplier bank detail change. Where a firm could split its business book by reimbursement scope, the out of scope segment produced a minority of claims and a clear majority of the value.

The mechanics explain why the bank sees so little. In the cases we reviewed the decisive event happened weeks before the payment, inside an email estate the bank has no visibility of: a supplier's mailbox compromised, a thread observed, an invoice intercepted and reissued with amended details, or a convincing change of details letter on cloned letterhead. By the time the instruction reaches the bank it is a properly authorised payment, to a plausible beneficiary, for a plausible amount, from a customer who fully intends to make it.

The second finding has the most operational consequence. The behavioural signals carrying most of the weight in retail detection do not transfer to corporate payments, and in our reviews several actively mislead. A retail model leans on session behaviour: a new payee added minutes before a payment, an unusual hour, hesitancy in the payee fields, an unfamiliar device, an inbound call in progress, a remote access tool running. A corporate payment is made by a delegated user from a managed device, on a saved template or a bulk file, at a scheduled point in the payment cycle, often through a host-to-host channel with no session to observe. New payee is routine, out of hours is routine at period end, and device novelty is an artefact of estate management. Applying retail anomaly logic here produces alert volumes the corporate service desk will not tolerate and misses the actual signal.

What did discriminate, consistently across the firms we examined, sat at the beneficiary and mandate layer rather than the session layer: a change to a stored supplier's account details followed by a payment to the new details within a short window, a Confirmation of Payee mismatch overridden rather than investigated, a first payment to a newly created beneficiary at a value well above that customer's norm, and maintenance of the supplier master file by a user who does not normally hold that function. Dual approval, the third finding, was present in almost every defrauded corporate we reviewed and defeated in most, through the same small set of weaknesses: both approvers working from the same compromised mailbox, a second approver treating the first approval as the substantive check, delegated authority left open after a holiday, mobile approval screens showing an amount but not the beneficiary account, and emergency payment routes designed to bypass the control. The fourth finding is a measurement gap. Because a corporate loss sits with the customer it is not booked as a bank loss, and most firms in our sample could not state their out of scope business APP loss for the prior year at all.

Implications for Financial Institutions

The first implication is that the customer book has to be segmented by reimbursement scope, and the institution has to know which customers sit where and which sit near the line. Microenterprise and charity status is not static: a client crosses a headcount or turnover threshold and silently leaves the protected population, usually without anyone noticing on either side. Firms should hold a reviewed scope flag on the customer record, refresh it on a defined cycle, and be able to produce the boundary population on request, because that is the group most likely to believe it is protected when it is not.

The second implication is that corporate detection needs a different feature set rather than a retuned retail model. The signal lives in the mandate and the beneficiary: supplier detail change velocity, time from change to first payment against it, Confirmation of Payee mismatches and the disposition of the override, beneficiaries created outside the normal maintenance window, deviation from the established pattern for that supplier relationship, and maintainer to approver separation. These are unglamorous, auditable features, and in our reviews they outperformed anything ported from the retail estate.

The third implication is that Confirmation of Payee is weaker in the corporate context than most firms assume. It is not universally available across bulk file and high value channels, it is routinely overridden under period end pressure by staff measured on payment throughput, and a competent fraudster now presents a matching account name by incorporating a company with a near-identical name to the genuine supplier. Institutions should treat the mismatch override as a control event, capture a reason code, and monitor override rates by customer and by user.

The fourth implication is the important one for relationship management: what a bank owes a corporate client is real, and it is not a reimbursement duty. It is warning design that fires when a stored beneficiary's details change rather than generically at payment; a named contact and an out of hours route to raise a recall inside the window where recovery is still possible, since the duty to act on notice bites precisely there; honest disclosure about which channels are screened and what Confirmation of Payee does and does not tell the client; and practical support for the client's own controls, principally callback verification and separation of master file maintenance from payment approval. Banks that provide this are not accepting liability. They are doing the part of the job the reimbursement regime never assigned to anyone.

The fifth implication is governance. Corporate losses should be recorded and reported to the fraud committee even where the customer bears them, with value, typology, channel and reimbursement scope. Without that record the institution cannot size the exposure, cannot defend a business case for corporate detection, and cannot answer the question a supervisor will eventually ask about the population its consumer controls do not reach.

Conclusion

The reimbursement requirement did something valuable and something unintended. It gave consumers a clear route to recovery and the industry a shared definition of a loss worth preventing. It also created a strong incentive to concentrate detection and management attention on the payments that generate a reimbursable loss, leaving everything else to the relationship manager and the customer's own insurance. Fraudsters read policy documents, and value has moved towards the population where the bank has less at stake and the victim has no statutory remedy.

The corrective is not to extend reimbursement by analogy, which is a question for the regulator rather than a decision available to a bank. It is to recognise that corporate authorised push payment fraud is a distinct problem with distinct mechanics, detectable through mandate and beneficiary signals rather than session behaviour, and that the duty owed here is one of capability, warning and recovery rather than of payment. That capability is cheaper to build than most firms expect, because the feature set is small and the population is manageable. Firms that skip it will keep discovering the exposure one large loss at a time, in a category their own reporting does not measure.

Suggested Next Steps

• Flag reimbursement scope on the customer record for every business relationship, refresh it on a defined cycle, and produce the boundary population of clients close to the microenterprise and charity thresholds as a standing report.

• Build a corporate detection rule set on mandate and beneficiary features, covering supplier detail change velocity, time from change to first payment, first payment value against a new beneficiary, and maintainer to approver separation, and stop porting retail session models into the corporate channel.

• Treat every Confirmation of Payee mismatch override as a recorded control event with a reason code, and monitor override rates by client and by approving user.

• Publish a plain statement to corporate clients of which channels are screened, what warnings will and will not appear, how to reach a recall route out of hours, and which controls remain the client's own, and record corporate APP losses in fraud governance reporting whether or not the bank bears them.

Sources: Payment Systems Regulator, UK Finance, Financial Conduct Authority, Prudential Regulation Authority, HM Treasury, Pay.UK, EBA, TrustSphere Risk Index, April 2026.

Companion vendor assessment: today's TrustSphere Risk Index post assesses Cable against this problem. Read it at www.trustsphere.ai

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai