Payment Fraud Prevention and Controls in Treasury

Payment fraud in treasury is stopped not by one clever control but by layers of them — segregation of duties, approval workflows, beneficiary verification, screening, system controls and reconciliation — arranged so that no single failure lets money leave. A treasury system exists to move funds out of the company, which is exactly why it draws fraud. The threats are mostly unglamorous: a convincing email, a changed bank account, a rushed exception. The defence is defence-in-depth, and the honest lesson from years of running these systems is that the control which fails is almost never the one that was missing — it's the one that got skipped under pressure.

This is general guidance on common, well-established controls, not security advice tailored to a specific organisation. Treat it as a map of the usual layers, then apply your own risk assessment.

The threats worth designing against

Four recur often enough to design around, and it helps to see them as two pairs.

The first pair attacks from outside, through people. Business email compromise (BEC) — including CEO-fraud — is a spoofed instruction that impersonates someone trusted: an "urgent and confidential" transfer that appears to come from a senior executive, or a message from a supplier's finance contact. Invoice redirection is its close cousin: a genuine invoice for a genuine supplier, but the beneficiary account has been fraudulently changed, so a legitimate-looking payment goes to the fraudster. Neither of these is a hack of your system. They're a hack of your process.

The second pair attacks the data. Internal fraud is an insider diverting a payment — someone with legitimate access using it to move money where it shouldn't go. Standing-data tampering is the quiet one: changing a bank account on a supplier or counterparty record so that entirely normal future payments flow to the wrong place. As I covered in segregation of duties, changing a beneficiary's account number is functionally identical to redirecting a payment — but it usually lives outside the payment approval flow, which is what makes it dangerous. The payment that follows looks perfectly ordinary, because it is ordinary; only the destination is wrong.

The pattern across all four: the most damaging frauds don't look like attacks. They look like business as usual.

Defence-in-depth: the control layers

No single control catches everything, so you stack them. Each layer assumes the one before it might have been bypassed.

Segregation of duties and four-eyes

This is the foundation, and I won't repeat the full case for it here. The essentials for fraud prevention: the person who enters a payment is not the person who releases it, and — just as important — a change to a beneficiary account or standing settlement instruction requires independent approval in its own right. If static-data changes aren't four-eyes and audited, you've locked the front door and left the back one open.

Approval workflows and authorization limits

Payments move through defined states, and the authority required scales with the amount: bigger payments need more approvers, or higher ones. A five-figure payment and a seven-figure payment should not clear the same way. The system must enforce these limits rather than trust people to remember them, and the same discipline applies inside straight-through processing, where automation can otherwise carry a bad instruction all the way to the bank without a human ever pausing on it.

Beneficiary and bank-account verification

Before you pay a new or changed account, you verify it out-of-band. The classic control is a callback to a known number — one you already hold on file, never the number printed on the suspicious email or the changed invoice. Increasingly this is reinforced by Confirmation of Payee-style checks, where the account name you intend to pay is matched against the name the receiving bank holds, so a mismatch surfaces before the money moves rather than after.

Sanctions and watchlist screening

Every payment should be screened against sanctions and watchlists before release. This is where clean, structured data earns its keep: ISO 20022 payment messages carry richly structured party information, which makes screening more accurate and generates fewer of the false positives that train people to click "approve" without looking.

"

The control that isn't followed under pressure is the control that fails. Most real losses aren't an exotic breach — they're a rushed exception to a control that was working fine until someone was told it was urgent.

System controls

Beyond process, the platform itself should be configured to make fraud harder. Whitelist known beneficiaries so payments to established accounts are routine and payments to new ones are exceptional and scrutinised. Restrict who can add or change beneficiaries to a small, controlled group, and require out-of-band verification for those changes. Apply payment-run controls so batch runs can't be quietly altered between assembly and release. Each of these narrows the path a fraudulent payment can travel.

Reconciliation and monitoring

The last layer assumes something got through. Prompt reconciliation against bank statements, and monitoring for anomalies — a new beneficiary, an unusual amount, a payment just under an approval threshold — is how you catch what the earlier layers missed, and how you catch it in hours rather than at month-end. A control that only detects fraud after the quarter closes is a control that detects it too late.

Docs vs reality: where the money actually goes

Here's the part the policy binder tends to underplay. In practice, the large losses I've seen or heard about up close rarely come from an attacker defeating a well-designed control. They come from someone stepping around one that was working perfectly well.

The pattern is almost always the same. A payment is flagged urgent, a senior name is invoked, the callback "can't be done right now because the contact is travelling" — and the exception, this one time, just to unblock things, is granted. The control didn't fail on its own; it was suspended by the same organisation that built it, in the moment it mattered most.

So the practical work of fraud prevention isn't only designing the layers. It's making the layers survive contact with a deadline: no verbal-only overrides, a defined and logged exception path so skipping a callback is itself a visible, approved event rather than a quiet favour, and a culture where "urgent and confidential" is treated as a warning sign rather than a reason to hurry. The strongest control set on paper is worth nothing if pressure can talk it out of the room.

Pulling it together

Design for the four threats — BEC and invoice redirection, insider diversion, and standing-data tampering — with layers that each assume the last one failed: segregation of duties on payments and on static data, workflows with real authorization limits, out-of-band beneficiary verification, screening before release, platform controls that restrict and whitelist, and reconciliation to catch the remainder. Then do the harder thing and make those layers hold when someone is in a hurry. That combination — defence-in-depth that survives pressure — is why treasury architecture treats controls as a first-class design concern rather than something bolted on afterwards.

Part of the Treasury Systems Architecture guide. See also segregation of duties in treasury systems and straight-through processing. The newsletter sends one finance-systems pattern every two weeks.