How can finance teams prevent payment fraud before wires go out?

A French restaurant group caught a fraud attempt that would have wired 28,000€ to a fraudster's account. The invoice looked legitimate, the supplier looked legitimate, the approval went through. The catch happened in a window most finance teams don't even know exists: the 60 seconds between "approved for payment" and "funds released." That window is where pre-payment fraud prevention lives, and it's where most controls stop short.

The 2025 AFP Payments Fraud and Control Survey reports that 79% of organizations experienced attempted or actual payments fraud in 2024, with business email compromise (BEC) the top fraud vector at 63%. The FBI's 2024 Internet Crime Report logged more than $16 billion in cyber-enabled fraud losses, a 33% jump from the previous year, with $2.77 billion specifically tied to BEC. The pattern is consistent: invoices arrive, look right, get approved, and the fraud happens at the payment release stage, not the approval stage.

This article maps what should happen between approval and wire release. Six pre-wire controls, each occupying a different attack surface: IBAN cross-reference, vendor banking change verification, payment-to-invoice match, dual control on threshold breaches, deepfake-resistant out-of-band verification, and payment file integrity. Run them all and the BEC playbook stops working. Skip any one and the wire goes out before anyone notices.

Why pre-payment Is the real fraud window

AP controls are built around the invoice: did it match the PO, did it pass the matrix, did the right person approve it. Those controls answer "is this a legitimate transaction?" They don't answer "is this transaction going to the right account?"

The gap between those two questions is where modern fraud lives. A real invoice from a real supplier can still pay into a fraudulent IBAN if the banking details were swapped between approval and release. Vendor banking changes are now prime targets for attackers, who have learned that exploiting payment workflows is faster and more profitable than breaking into IT systems.

The shift the article proposes: stop treating approval as the last gate. Approval validates the invoice. Pre-payment validates the wire. Those are two different controls, and only the second one stops a fund-diversion attack.

This reframes "pre-payment fraud prevention" away from generic security advice (train your staff, use MFA) and toward a specific control stack. The stack runs in the last-mile window between approval and release, and it owns four threat patterns at once: BEC, vendor impersonation (VEC), fake IBAN attacks, and deepfake-enabled urgency scams.

The 6 pre-wire controls that stop fraud at release

1. IBAN cross-reference against the vendor master

The first pre-wire check confirms the destination IBAN matches the one stored against the supplier in the master file. Not "the vendor exists in the master" but "the IBAN on this payment file matches the IBAN on this vendor record." A mismatch, even by a single character, blocks the wire.

This is the control that catches the most common wire fraud pattern: an invoice approved with the legitimate IBAN gets its banking details swapped before payment release. The attack works because most pipelines verify the IBAN at approval and never verify it again at release. A robust bank data validation check runs at the moment the payment file is built, not days earlier when the invoice was approved.

2. Vendor banking change verification (out-of-band)

When a banking change has been recorded on a supplier in the days before a wire, the change itself becomes the trigger. Was the change verified by callback to a known phone number? Was the verification logged with the verifier's identity, the time, and the source of the new IBAN? If any of those answers is no, the wire pauses until they're yes.

The verification must be out-of-band. Always verify wire instructions through a separate communication channel, not just email and preferably with someone other than the one making the request. Email-confirmed changes don't count: the email channel is exactly what the attacker has compromised. The fake IBAN fraud detection agent intercepts banking-change events specifically to enforce this protocol before any payment moves.

3. Payment-to-invoice match at the file level

The third control compares the payment file to the underlying invoices. Does each line in the wire batch correspond to an approved invoice? Does the amount on the payment line equal the amount on the invoice? Are any invoices in the batch that weren't approved, or any approved invoices missing from the batch?

This catches batch tampering: a fraudster who has access to the payment file (via a compromised credential or a malicious insider) can add a line, modify an amount, or substitute an IBAN. None of those changes touch the invoices, so AP-level controls don't see them. A file-level reconciliation between payment instructions and source invoices is the only thing that does.

4. Dual control with threshold-based escalation

The fourth control is the classic four-eyes principle, but applied at the wire-release moment, not at the approval moment. Implement a call-back verification process when setting up payment instructions for a new vendor or making changes to payment instructions for an existing vendor. Implement dual control and segregation of duties.

Threshold-based escalation refines it: any wire above 10,000€ requires a second approver. Any wire above 50,000€ requires a second approver plus an out-of-band verification. Any wire to a supplier whose IBAN has changed in the last 30 days requires both regardless of amount. The thresholds and escalation triggers should be enforced in the workflow, not in human memory, because human memory fails under deadline pressure.

5. Deepfake-resistant out-of-band verification

A new threat surface has appeared in 2024 to 2026 data. The 2026 AFP Payments Fraud and Control Survey for the first time examines the impact of AI-enabled fraud and deepfake technologies on payments fraud, with growing concern around the use of voice and video technologies to impersonate executives, vendors, and other trusted parties.

This breaks the standard "callback to a known number" protocol if the attacker can spoof or clone the voice on the receiving end. The countermeasure is layered: callbacks go to numbers from the vendor master only (not from the email or invoice), verifications include a non-vocal element (a written confirmation, a portal acknowledgment, a code exchange), and any "urgent" or "executive override" request triggers a mandatory cooldown rather than acceleration. Late Friday afternoon requests deserve extra scrutiny. Last-minute changes to wire instructions require verification. Demands to process transfers immediately are red flags.

6. Payment file integrity at submission

The final control is technical: the payment file submitted to the bank must be the same file that was approved. Hash the file at approval. Hash it again at submission. If the hashes differ, something modified it in between. The wire pauses until the modification is identified and authorized.

This is the control that closes the last attack surface: in-flight tampering between the AP system and the banking portal. Without file integrity, every other control upstream can pass and the wire still leaves with a swapped IBAN. With it, the system can prove that what got approved is what got submitted.

Why most pre-wire stacks are incomplete

Every CFO would describe their controls as "robust." Few finance teams actually run all six pre-wire controls. Three structural reasons:

The handoff between AP and Treasury is where controls fall through. AP owns approval. Treasury owns wire release. The pre-payment window sits between the two, and ownership is ambiguous. The IBAN cross-reference at release isn't AP's job (the invoice was already approved) and isn't Treasury's job (Treasury executes what AP approved). It's nobody's job, which is why it doesn't run.

Manual callback verification scales linearly with volume. A treasurer running callback verification on 50 wires a week works through them. The same treasurer at 500 wires a week samples them. Finance teams understand the risk but struggle to maintain the same control discipline against cyber threats that they bring to audits and reconciliations. The issue is no longer awareness; it's capacity.

Audit trails for pre-payment controls are thin. Approval has a clean audit trail. Wire release has a transaction log. The verification that happened (or didn't happen) between the two often lives in an email thread, a Slack message, or the treasurer's memory. When fraud surfaces, the question "was the IBAN verified?" frequently has no documented answer. A native audit trail for pre-payment controls is the structural fix.

How AI agents close the pre-payment window

Rule-based fraud detection handled controls 3 and 6 reasonably well: file-level reconciliation, threshold escalation, hash verification. It struggled on controls 1, 2, and 5: semantic IBAN matching when the master record had typos, vendor change detection when the change came from a slightly different email domain, urgency pattern recognition when the language was natural-sounding.

AI agents close that gap with the same architecture pattern Phacet uses across the stack:

The fake IBAN fraud detection agent runs controls 1 and 2 at every payment release. It cross-references the payment IBAN against the master, detects banking changes within a configurable lookback window, enforces the out-of-band verification protocol, and blocks the wire until the verification is logged. Every check, every block, every override is timestamped in the audit trail.

The supplier database enrichment agent maintains the master that control 1 depends on. It detects duplicates, surfaces near-look-alike records, and keeps the IBAN history that change-detection logic queries. Without a clean master, IBAN cross-reference returns false negatives.

The 3-way matching agent feeds control 3 by maintaining the link between approved invoice and payment line. When the payment file is built, every line traces back to an invoice with a verified PO, contract, and goods receipt.

The supplier billing control agent provides upstream protection: it catches the price-variance and overbilling patterns that fraudsters use to slip extra amounts into otherwise legitimate invoices. The control runs at AP, but it reduces the volume that pre-wire controls have to filter.

Each agent follows the same three-step pattern: it structures the input (IBAN, change event, payment file), controls against a reference (master, history, hash), then exposes the result with full justification. The agents run on every wire, not on a sample, which is the only way to keep up with volume. Pair that with the broader automated financial controls layer and the pre-payment window stops being a blind spot.

What 100% pre-wire coverage looks like in production

Three customer outcomes show what changes when all six pre-wire controls run on every payment:

La Nouvelle Garde (10 brasseries) intercepted 28,000€ of attempted fraud through the IBAN and banking-change controls running in the pre-wire window. The CFO described Phacet as a teammate that operates around the clock, which is the architectural point: pre-payment controls that run at machine speed catch what manual controls running at human speed are going to miss. The fraud attempt fit the textbook pattern: legitimate-looking invoice, plausible supplier, modified IBAN. AP-level controls would have approved it. Pre-wire controls blocked it.

Astotel (18 hotels) recovered roughly 5,000€ per year in surfacing supplier overbilling that fed the upstream protection layer. Less attack surface upstream means a smaller volume of legitimate payments competing for pre-wire reviewer attention. The Head of Purchasing put it directly: "I catch errors I would never have spotted on my own."

Vivason (audiology, multi-site retail) identified 180,000€ per year of supplier overcharges through the same upstream control stack. The pattern is consistent: pre-payment controls work best when the upstream invoice controls are also running, because the two layers reinforce each other. Without invoice-level controls, the pre-wire layer drowns in noise. Without pre-wire controls, the invoice layer leaves the diversion attack surface open.

The common thread: variance and fraud were not larger after the controls were in place, they were visible. Recovering funds once defrauded is hard, almost impossible. Pre-payment is the last realistic chance to stop a fraudulent wire, because the moment the funds settle, the legal recovery process is already losing the race.

FAQ

What is pre-payment fraud prevention specifically?

Pre-payment fraud prevention is the set of controls that run between invoice approval and wire release. It treats those two events as separate gates rather than a single moment, and runs verification on the payment instructions themselves, not just the underlying invoice. The goal is to catch fraud patterns (BEC, fake IBAN, batch tampering) that the invoice-approval process doesn't see. See more in our glossary entry on pre-payment controls.

How is pre-payment fraud different from invoice fraud?

Invoice fraud manipulates the invoice (fake invoice, duplicate invoice, inflated amount) and is best caught by invoice-level controls before approval. Pre-payment fraud manipulates the payment instructions (modified IBAN, swapped beneficiary, in-flight tampering) and slips past invoice controls because the invoice itself looks legitimate. The two need different controls. The pre-decision invoice control layer catches the first; the pre-wire layer catches the second.

What is BEC and why is it the top fraud vector?

BEC stands for business email compromise. Fraudsters use AI-powered tools to craft convincing emails, hijack legitimate threads, and impersonate trusted vendors or executives. It's the top vector because it bypasses technical controls entirely: the email is real (sent from a compromised mailbox), the request looks legitimate, and the person actioning it is acting in good faith. The defense is procedural: out-of-band verification, dual control, and pre-wire IBAN checks that don't trust the email channel.

How does deepfake fraud change pre-payment controls?

Deepfake voice and video tools make a callback to a known number less reliable: an attacker can clone the executive's voice or impersonate a supplier on a video call. The countermeasure is layered verification: callback to a number from the vendor master only, supplemented by a non-vocal channel (written confirmation, portal acknowledgment, code exchange), with mandatory cooldowns on any "urgent" override request.

Should small finance teams run all six pre-wire controls?

Yes, with priority. IBAN cross-reference, banking change verification, and dual control on threshold breaches (controls 1, 2, and 4) are non-negotiable at any size. Payment-to-invoice match, deepfake-resistant verification, and file integrity (3, 5, and 6) scale with payment volume and threat exposure. In small teams where staffing limits dual control, compensating controls (a delay between approval and release, a daily review of all wires, an external second eye on amounts above threshold) cover the gap.

Build the last-mile control stack

The question "how can finance teams prevent payment fraud before wires go out?" is really a question about what happens in the 60 seconds nobody owns. AP signed off. Treasury is about to release. The fraud lives in the gap.

The answer is a six-control stack that runs in that gap and treats payment instructions as a separate object from the invoice. Run all six controls on every wire and the BEC playbook stops working at the bank-instruction level. Skip any one and the diversion attack stays viable.

Phacet customers typically deploy the fake IBAN fraud detection agent first (controls 1 and 2 in production within two weeks), then layer the supplier database agent and 3-way matching agent to feed the upstream controls (3 and 4), and use the broader audit trail to close out the file-integrity loop (6). The 40+ agents in the catalog were built across 100+ real deployments, which means the controls reflect what finance teams actually need in production, not what looks good on a feature page.

Approval keeps the invoice honest. Pre-payment keeps the wire honest. They're different jobs, and the wire is the one that doesn't come back.