Vendor payment fraud prevention that proves every bank change with a call-back before a dollar moves
Every bank change proven by a call-back before a single dollar moves.
See one case, screen by screen ↓Vendor payment fraud prevention for accounts payable: it checks every vendor bank-detail change and suspicious payment request before money moves, to stop business email compromise and vendor impersonation. Four agents act as independent witnesses — the email, the account owner, the vendor's history and a call-back to the number on file — and their verdict goes to the AP manager to decide. Only the payments under investigation are held, and a named treasury approver releases them.
How to choose AI solutions for back-office and enterprise work →
Updated
Fraudsters don't hack the payment system. They ask accounts payable to change a vendor's bank account, then let the next payment run do the rest. The request arrives as an email to the AP inbox, a letter on headed paper, a phone call, a vendor portal update or new remittance details printed on an invoice. An AP specialist keys it on a vendor change form, policy says to call the vendor back on a known number, and in practice the number comes from the email signature — the fraudster's own — or the call is skipped because the run is close.
The control fails in the gaps. The person who logged the change also approves it. The bank change and the contact change arrive together, so the call-back reaches the fraudster. A bank's name-check warning is overridden. The evidence sits in inboxes, so the auditor can't see that the control ran. Fraud usually surfaces weeks later, when the real vendor chases its overdue invoices, and by then the money has moved on.
Estimated split for one vendor bank-detail change request, checked by hand and with the solution.
Four sealed agent witnesses check every bank change; a person decides and treasury releases.
Kestrel & Vane Group runs accounts payable for its four entities from shared services in Columbus. On Tuesday at 16:52 an email asks AP to pay all six of Tarnwick Logistics' open invoices, $186,240.00, to a new account in Lithuania. Thursday's payment file goes to the bank at 16:00 on Wednesday. Here is how Renata Duarte, the AP manager, works the case with the agents, screen by screen, in the working solution.
Renata's day opens as a briefing, not a dashboard: 6 open requests, 9 payments held, 2 that need her. The verdict clerk writes first: Tarnwick Logistics is being impersonated. It proposes three things — reject the change and keep First Meridian ••4471, have treasury release the four Thursday payments to ••4471 only, and block the Lithuanian account and send the report pack. Every claim carries a numbered source.
“You decide · I may not change the vendor record or release a payment.”
Each witness answered one question on its own, sealed from the others, and the clerk unsealed all four together at 08:44. The email witness finds fraud signs (97%), the account witness finds fraud signs (96%), the history witness finds fraud signs (93%), and the call-back witness reports that the vendor denies the change (99%). Four payments on Thursday's run, $131,580.00, are held, with two more due 22 Oct, $54,660.00.
Logged by Dylan Ferris, who may not approve or release it.
The email came from accounts@tarnwick-logistlcs.com — an “l” in place of the “i”, one character from tarnwick-logistics.com, registered 10 Oct 2026. Replies go to billing.tarnwick@mailbox-relay.net, a third domain, and DMARC is none where the real domain says reject. The text carries urgency, a cover story about a frozen account and “Please do not call our office”. Renata reads the marked email beside the finding, then agrees and continues; her review goes on the record with the finding.
Each witness asks her: “Do you agree?” — she can agree, or challenge it in her own words.
The bank-validation service returns TRN Logistik Partners UAB as the owner — no match to Tarnwick Logistics Inc. The account at Baltic Ledger Bank UAB was opened in Sep 2026, 31 days ago, and Tarnwick has no Lithuanian entity. The same IBAN was in the Quarry Lane Packaging request on 9 Oct, which was rejected.
The owner name comes from the bank-validation service, not from the request. A close match is never treated as a match.
Tarnwick has been a vendor since Mar 2019: 212 payments, $6,941,385.20, all by ACH to First Meridian ••4471, and never a bank change. Its contacts were verified on 2 Mar 2026. The request lands two days before a $131,580.00 payment, and the change would redirect six invoices, TL-88412 to TL-88521.
The history witness never takes its baseline from the request.
The witness dialled +1 (614) 555-0148 — on file since 2019, verified on 2 Mar 2026 by Tomás Lindqvist — and never the +1 (380) 555-0199 in the email. To confirm who answered, it asked for the amount of our last payment; Ingrid Solberg, Tarnwick's AP manager, said $36,812.50 on the first of October, which matches our remittance record. The 3:12 call is recorded and transcribed as a source.
“No. We have not changed our bank. Our First Meridian account is open and we have no account in Lithuania.” — Ingrid Solberg
The guard screened every payment in Thursday's run, $48,612,905.40, against six rules at 07:15. It holds 9 payments, $254,570.80, while 4 bank changes are checked: Tarnwick, Sandal Point Chemicals, Ellery Brook Foods and Westmere Facilities. A first payment to a new vendor was flagged, and Kofi Mensah cleared it at 08:02. The other 1,274 go out as planned.
Held lines are left out of the file, not deleted; only a named treasury approver releases them, and only to a verified account.
The decision screen puts the four findings, her review of each and the hold in one place. The clerk's plan is a list she can untick: reject the change and keep ••4471, release the four Thursday payments to ••4471 only, block LT65 3580 0016 6248 1307 in every vendor record, send the report pack. She rejects with reason code FR-01, “Impersonation confirmed by call-back”, and signs at 09:46 with her authenticator.
Every decision needs a reason code and a signature from someone who did not log the request.
Releasing the four payments to ••4471 needs a treasury signature. The release dialog checks each person: Dylan Ferris logged the request, Renata decided the case, and Tomás Lindqvist approves bank changes, so none of them may release. Kofi Mensah may release up to $250,000 and had no part in the case; Amara Holt may release any amount.
“Refused by the platform. Dylan Ferris logged this change request, so may not release the payments it held (policy 7.2).”
Kofi signs at 09:48 with RL-01: four payments, $131,580.00, go to First Meridian ••4471 on Thursday's run, and the two invoices due 22 Oct stay on the verified account. The fraud reporter has five notices drafted — to Tarnwick, to Kestrel & Vane's bank, to IT security, an IC3 complaint and the control evidence — and nothing is sent until a person presses Send.
“Released to the verified account. The $186,240.00 never left.” — Payment run guard
The same bank change, seen by the four people who carry it — what their week looked like, and what it looks like now.
Four sealed agent witnesses check every bank change; a person decides and treasury releases.
Reads every bank-change request — email, letter, portal, phone note or invoice remittance block — and opens a case with the vendor, both accounts and the invoices at stake.
Checks whether the request really came from the vendor: authentication, lookalike distance, domain age, reply-to, sending network and wording.
Asks the bank who owns the new account, and checks where the account has appeared before.
Compares the request with the vendor's own history: banks, countries, payments, contact changes and timing against the payment run.
Calls the vendor on a number on file that is older than 90 days, asks a challenge from our remittance history, and records and transcribes the call.
Unseals the four findings together, states agreement or dissent, recommends, and proposes rule tuning from its own past verdicts.
Screens every payment in each run; holds payments to changed or blocked accounts and flags first payments to new accounts.
Drafts the notices and the evidence pack when an attempt is confirmed, and runs the recall clock if money left.
Decides; treasury releases. The agents propose; a named person decides.
Every screen has a box to ask the agents about the case, the vendor, a call or the run. Answers cite their sources, and you decide.
Why is the Tarnwick request held?
Four independent witnesses found impersonation. The email came from tarnwick-logistlcs.com, registered 4 days ago, with replies going to a third domain. The bank says the Lithuanian account belongs to TRN Logistik Partners UAB, not Tarnwick. Tarnwick has been paid 212 times, always to First Meridian ••4471, and Ingrid Solberg confirmed on the number on file that nothing changed. Four payments ($131,580.00) are held on Thursday's run; the decision is yours.
Which other vendors did this Lithuanian account target?
One more: Quarry Lane Packaging, on 9 Oct. The same IBAN was in a request from quarrylane-packagng.com for $244,615.00, rejected after a call-back. Both lookalike domains share name servers, and a lookalike of our own domain, kestrelvane-payables.com, was registered on 11 Oct. I suggest blocking the account everywhere and sending the links to IT security.
What leaves at 16:00 today?
1,275 of 1,284 payments. I screened the whole run at 07:15. 9 payments ($254,570.80) stay out of the file until a named treasury approver releases them; nothing else waits on us.
How many genuine vendors did we hold by mistake?
9 false holds in 90 days, 3.1% of 287 requests. Five were names that differed only in a legal suffix or a trailing “s”. Treating those as a match would cut false holds to 4, and the replay still catches all 11 fraud attempts. The change needs Margit Halloran's signature.
13 screens from the working solution, on its sample data. Pick one to see it large.
The thresholds every bank change and payment run is checked against are settings. Changes are drafts until the group controller signs.
| Setting | Default | Choose from |
|---|---|---|
| Hold payments to an account changed in the last | 30 days | Any number of days, until the change is verified and approved |
| Call back on every bank change above | $0 — every change, any amount | Any amount in USD |
| Second approver for releases above | $50,000 | Any amount in USD, in addition to the named releaser |
| Flag lookalike sender domains up to | 2 characters apart | Any distance from a vendor's known domain |
| Treat a sender domain as new when younger than | 30 days | Any number of days; raises the email witness to high |
| Refuse call-back numbers changed in the last | 90 days | Any number of days; a person sources a trusted number |
| Case service level | 4 business hours | From request to a verified decision |
| Payment-file cut-off alert | 4 h and 1 h before | To the AP manager and treasury |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (AFP 2025 Payments Fraud and Control Survey — 79% of organisations faced attempted or actual payments fraud in 2024, business email compromise the top route, 22% recovered 75% or more of lost funds; FBI IC3 Internet Crime Report 2024 — $2.77B in business email compromise losses). Kestrel & Vane Group, its vendors, the banks and the people named on this page are fictional — characters and sample data in the working solution.
Vendor payment fraud prevention for accounts payable: it checks every vendor bank-detail change and suspicious payment request before money moves, to stop business email compromise and vendor impersonation. Four agents act as independent witnesses — the email, the account owner, the vendor's history and a call-back to the number on file — and their verdict goes to the AP manager to decide. Only the payments under investigation are held, and a named treasury approver releases them.
The email witness reads the headers and the text: SPF, DKIM and DMARC, lookalike distance from the vendor's known domain, domain age, a reply-to on another domain, the sending network, and urgency or secrecy language. On its own that is one finding; the account, history and call-back witnesses each check the request from a different side, and the case is only cleared when all four agree.
Because it may be the fraudster's. The call-back witness dials only a number already on file and older than 90 days, never one from the request, and asks a question built from our own remittance history, such as the amount of our last payment. If the only number on file was changed recently, it refuses to call and asks a person to source a trusted number.
No. The payment run guard screens every payment against six rules and holds only those tied to an open bank change, a recently changed or blocked account, or bank details that differ from the record. In the working solution it holds 9 of 1,284 payments in Thursday's run; held lines are left out of the file, not deleted, and the rest go out as planned.
The verdict clerk never averages a dissent away. If any witness disagrees, the case goes to a named person with each witness's evidence side by side. In the working solution three witnesses clear a bank-merger change for Ellery Brook Foods, but the bank returns a close match on the name, so the vendor master data steward decides.
Yes. The agents propose and cite; they never change the vendor record, release a payment or send a notice. The AP manager decides each case with a reason code and a signature, a treasury approver releases held payments, and the platform refuses anyone who logged, prepared or decided the same item, or who is outside their release limit.
Yes. The hold window, call-back and second-approver thresholds, lookalike distance, domain age, call-back number age, service levels, cut-off alerts and the signals that hold or escalate are all settings. Changes are drafts until the group controller signs, and the verdict clerk can replay a proposed change on the last 90 days first.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your vendor change policy, approval limits and a sample of past bank-change requests — connected to your ERP, bank-account validation, email gateway and bank file. It goes live once every quality gate has passed. We will walk you through it on your own requests first.
Blocked invoices released before late fees and supplier holds, every fix checked twice.
1-min demoExpense Report AuditEvery report checked, not a sample, and no forged receipt paid without proof of payment.
1-min demoDuplicate Payment Detection & Recovery AuditTwins stopped before the payment run, paid ones recovered in house, every claim signed.
1-min demoWe'll run Vendor Payment Fraud Prevention on a sample of your own past bank-change requests and a payment run.