Last gate before the wire.

The fraud arrives by email, and the payment run executes it faithfully.

The pattern is depressingly standard. A "vendor" emails updated bank details on plausible letterhead. An AP clerk updates the vendor master, because processing detail changes is the job. Invoices then approve through the normal flow, since nothing about them is unusual: right vendor, right amounts, right coding. On Friday the payment run generates the bank file and treasury releases it in bulk. The real vendor calls about non-payment three weeks later, the recovery window is long gone, and the insurer and the bank begin arguing about whose negligence it was.

The scale of this is documented. AFP's payments fraud survey reports that 79% of organisations experienced attempted or actual payment fraud, with business email compromise the leading vector. The FBI's IC3 attributes US$2.77 billion in reported BEC losses in a single year, and reported losses undercount by construction. Meanwhile only a minority of AP teams apply any automated screening to outbound payments; the industry brief this demo responds to cites 17% using AI against it. Where a control exists at all, it is usually "call the vendor if something feels off", which is a sentiment, and sentiments do not fire at 4pm on a Friday with 182 payments in the queue.

You cannot ask a language model to guard the vendor master.

The tempting move is to paste the change-request email into an LLM and ask whether it looks fraudulent. That fails for structural reasons that better prompting cannot repair:

• the attacker writes the inputA BEC email is engineered to read as legitimate. Judging its tone means grading the fraudster's homework. The signal is never in the text; it sits in the record: when the bank details changed, through which channel, and what the payment history looks like.
• non-determinismA hold/release decision on money must be reproducible. The same payment on the same facts must quarantine for the same stated reason every time. A model's judgement drifts between runs, and that drift is itself an audit finding.
• no citation"This payment seems risky" is unusable. Treasury needs the verdict tied to a rule and a record: bank details changed 2 days before the run, change-log line CHG-14. A paragraph of plausible prose cannot be re-performed.
• the gate must bindEven a correct AI opinion stops nothing. The control that matters is physical: the suspicious payment must never reach the bank file, and the release path must refuse a single approver in code.

So the screening is a deterministic rules engine over the vendor master, the change log and the run itself. The language model gets exactly one job: it assembles the anomaly pack and drafts the call-back script for each payment the rules already held, and every value it cites is checked against the record by code before it is displayed. Where there is no evidence, it abstains and says so.

Rules quarantine. The model narrates. Two humans and a phone call release.

Four red-flag rules screen every payment in the run before any bank file is generated: a bank-detail change within 14 days of the run (R1), a first-time payee at or above US$10,000 (R2), a remittance account whose country no longer matches the vendor's (R3), and a sequence of payments to one vendor each sitting just under the US$25,000 single-approver limit (R4). A rule hit quarantines the payment. The model cannot quarantine anything and cannot release anything. Release requires a recorded call-back to the phone number that was on file before the change, never the number in the email, followed by approvals from two different named users. The user interface physically blocks a solo release, and every refused attempt is logged with the missing evidence named.

Here is the release decision from the shipped file. It is deliberately small, because a control this consequential should be readable in one breath:

// The release decision. This is the whole gate: no call-back evidence or no
// second distinct approver means the function refuses, whoever is asking.
function releaseDecision(rel) {
  const missing = [];
  if (!rel.callback) missing.push("a recorded call-back to the pre-change number on file");
  const ids = [...new Set(rel.approvals)];
  if (ids.length < 2) missing.push(`a second, different named approver (${ids.length}/2 so far)`);
  return { allowed: missing.length === 0, missing };
}

The deduplication through Set is the dual-control: the same named user approving twice still counts as one. And because the function returns the missing evidence rather than a bare no, every blocked attempt lands in the ledger with its reason attached.

You send the email. The gate reads the record.

The demo opens with the attacker's console because the fastest way to trust a control is to fail against it. You pick a real vendor to impersonate, and one click does what the real fraud does: a lookalike-domain email lands, the vendor master updates to a GB account with no verification, and a fresh US$48,750 invoice joins Friday's queue. At that point nothing has stopped you, which is the honest state of most AP processes.

Then you run the screen. Your payment quarantines on R1 + R3: the bank details changed two days before the run, and the account now sits in a country the vendor has never banked in. The anomaly pack cites the exact change-log line you created, quotes your own email back at you, and drafts the call-back script pointed at the phone number that was on file before your change. When you try to push your own release through solo, the gate refuses and logs the attempt. Your fraud is now stuck behind a phone call to the real vendor, which is exactly where it dies.

• The seeded field. Beyond your attack, the run carries 12 seeded BEC patterns across 16 payments: five detail changes inside the window, three patient offshore switches made weeks early to age out the window rule (R3 catches what R1 no longer can), two first-time shell payees, and two just-under-limit splitting sequences. The rules quarantine all 12 patterns, and the app shows the catch computed live, never asserted.
• The collateral. Once you compromise a vendor, its other pending payment is held too. That is correct behaviour, and the app labels it separately rather than hiding it in the false-positive count.
• The honest cost. Four legitimate, portal-verified bank migrations and one genuine first-time payee also quarantine: 5 of 166 legitimate payments, 3.0%, each held for one extra day and released through the same call-back-plus-two-approvals path. A screening control that claims zero false positives is either lying or not screening.
• The file that leaves. The bank file is built only from clean and gate-released payments, and its hash is printed at build and at every amendment, so the file that left can be matched against the file that was approved.

What the engine computed, and what it cannot prove.

Every figure on this page is live output of the deterministic engine. Over the 182-payment run: 12 of 12 seeded BEC patterns quarantined (16 of 16 attack payments) before the bank file was generated; 21 payments held, 161 written to the file, hash printed; 5 of 166 legitimate payments (3.0%) held one extra day; and 0 releases without call-back evidence plus two distinct named approvals, with every blocked attempt logged. The engine is seeded and client-side, so a third party gets identical quarantines, identical reasons and identical hashes on every run.

The payments are real: an 1,800-row slice of the City of Chicago's public Payments dataset, fetched from the city's open API with the script shipped alongside the app, with real vendors, amounts and voucher numbers. Everything banking-related is synthetic and labelled, because real bank account data is never public, by design; Chicago's dataset carries no banking fields at all. Real vendors cast in attack roles are victims of impersonation in the scenario, and the app says so.

The honest limits, stated flatly:

• The rule set and thresholds (14 days, US$10,000, US$25,000, the 90% band) are illustrative and demo-tuned. Real BEC adapts to whatever gate it meets, so production rules need red-teaming and continuous tuning against live loss data, and the 12/12 catch rate is true of this constructed field, never a promised detection rate.
• Call-back evidence here is a recorded click. In production that control is only as strong as its telephony or attestation integration, and a checkbox version of it would be an audit finding.
• Because I author both the attacks and the rules, the headline numbers hold by construction. What the demo defends is the mechanism: screening before the file exists, citations checked against the record, a release function that physically refuses solo action, and a ledger that locates its own corruption.

Attempt the fraud yourself.

Impersonate a vendor, send the fake bank-change email, run Friday's payments, and watch your own attack land in quarantine with the change-log line that betrayed you quoted back. Try to release it solo. Then record the call-back, gather the second approver, and check the amended bank-file hash. Tamper with the ledger afterwards and watch Verify locate the broken row.