Case studies travel further than explainer posts on fraud risk. The walkthrough below describes a real AP fraud sequence at a mid-market UK firm, sanitised to remove identifying details. The point of the walkthrough is not the loss. The point is the four moments where the fraud could have been caught with controls that any mid-market AP function can implement. Every business reading this carries some version of the same exposure.
The setup
A mid-market UK firm in the manufacturing sector, annual turnover £80 million, AP function of three people, ERP in place since 2019. The supplier in question was a long-standing component vendor, on the master since 2017, monthly invoicing in the £12,000 to £18,000 range, consistent pattern, no prior incidents. The wider category context sits in why AP fraud will explode in the AI era.
The fraud sequence began in February. By the end of April, the firm had paid £164,000 to an account the supplier did not own. The supplier raised the chase in early May. The firm discovered the loss in mid-May.
The intrusion vector
The attacker compromised the supplier's email through credential stuffing on a third-party platform the supplier had used. Mailbox rules were set up to intercept and redirect any messages mentioning bank details, invoices or remittance. The attacker had read-and-write access to the supplier's email for approximately three months before the active phase began.
During that observation period, the attacker mapped the buyer-supplier relationship: typical invoice frequency, recent contacts, format conventions, and the firm's response patterns. The attacker also identified the AP manager and the FD by name.
The bank-detail switch
In late February, the attacker, posing as the supplier's account manager, emailed the firm's AP manager with a request to update bank details. The email was sent from the supplier's actual email account, used the supplier's normal signature, and referred to the supplier's bank by name in a way consistent with the supplier's prior correspondence.
The firm's bank-detail change process required a confirmation email from the supplier and verbal confirmation from a known contact. The confirmation email arrived (it was sent by the attacker). The verbal confirmation was attempted by the AP manager, who called the supplier's main switchboard. The attacker had set up a redirect rule that ensured the AP manager's call was answered by a phone number the attacker controlled, listed as the account manager's mobile. The verbal confirmation came back clean.
The bank details were updated on the master.
The four moments where this could have been caught
Moment one. The first invoice on the new account arrived in early March, for £17,400. The amount was at the high end of the supplier's normal range but within tolerance. A behavioural baseline that included account-level history would have flagged the combination of new account and high-range invoice. The firm's manual review did not, because the invoice itself looked normal. The pattern is exactly the one set out in the sub-£10k invoice problem, scaled up by an order of magnitude.
Moment two. The bank-detail change verification. The verbal confirmation step relied on a phone number provided by the (attacker-controlled) email. An independent verification step, calling the supplier on a number from the master record or from a separately verified source, would have caught the redirect. The firm's process did not require an out-of-channel verification. Open banking and Confirmation of Payee would have given a second signal but not closed the loop on the controller deception.
Moment three. The supplier-side communication. The supplier sent its own routine invoice three weeks later, against the supplier's actual bank account. The firm received both the attacker's invoice (which was paid) and the supplier's invoice (which sat unpaid because the new bank details on the master diverted everything to the attacker). A reconciliation between supplier-side records and the firm's payment history would have surfaced the discrepancy. None ran.
Moment four. The cross-buyer pattern. The same attacker had run the same playbook against four other buyers of the same supplier in the same period. A network-level signal sharing mechanism would have produced a cross-buyer pattern alert within days of the first incident on any of the buyers. The firm received no such signal. This is the structural argument that supplier verification and payment behaviour are converging.
What the network layer would have surfaced and when
By the time of moment one, the supplier identity graph would have noted a new bank account associated with the supplier, with no prior history. The supplier behavioural baseline would have flagged the change.
By the time of moment two, the network would have observed similar bank-detail change requests on at least two other buyers' instances of the same supplier within a 30-day window. The cross-buyer signal would have surfaced a high-confidence compromise alert.
By the time of moment three, the network would have logged the divergence between the supplier-side invoice flow and the buyer-side payment flow. The discrepancy would have triggered an exception review.
Each of these would have produced a flag well before the third payment ran. The total loss would have been closer to £18,000 than £164,000.
The lessons that translate
Three lessons survive translation to other businesses.
Out-of-channel verification matters more than in-channel verification. Any bank-detail change request that uses contact information provided in the same email or thread as the change request is structurally vulnerable. The verification has to go through a separately maintained channel.
Behavioural baselines have to include account-level history. The combination of a new account and an invoice value at the top of the supplier's normal range should always be a flag. Individual flags are not sufficient. Combined flags are decisive.
Cross-buyer signals catch what single-buyer controls miss. The same attacker was running the same playbook against multiple buyers. None of them caught the pattern, because none of them had visibility into the others' exposure. The network layer is the only structural answer to coordinated attacks.
One more note on disclosure
The firm in this case has been generous in allowing the walkthrough to be published, sanitised. The decision was made in the belief that the lessons compound when they are shared across the AP community. The default in the sector is to keep fraud incidents quiet. That posture protects individual firms in the short run and benefits attackers in the long run. The network model rests in part on the willingness of affected firms to share what they learn.
.jpg)
