Playbook
How to Catch a Vendor Bank-Account Change Automatically
Why this is hard
A vendor bank-account change is dangerous precisely because it is mundane. Vendors really do change banks, so an updated set of details on an invoice rarely triggers a second look, and that is exactly what business email compromise exploits. The change is small, it arrives right before a scheduled payment, and by the time the real vendor asks where their money is, the funds have cleared.
- Banking-detail changes look routine, so they are rarely questioned
- The change is timed to arrive just before a payment
- Manual review depends on someone happening to notice
- Once funds clear to a fraudulent account, recovery is unlikely
The approach, step by step
From quiet change to caught payment
Treat a payment as a decision, not a task
Route every consequential payment through a policy decision before funds move, instead of letting it flow straight from invoice to bank.
Detect the change on the graph
Compare the payment’s banking details against the vendor’s known record and flag any change to account or routing information as an anomaly.
Hold and verify out-of-band
When details change, hold the payment and require verification through a channel other than the one the change arrived on: a phone call to a known contact, not a reply to the email.
Make it a decision, not a notification
Present the flag as a decision with the dollar exposure and a recommended hold, so a human either releases or rejects it rather than triaging an alert.
Seal the decision to evidence
Record the flag, the verification, and the outcome to a tamper-evident ledger, so the control is provable and the pattern is auditable.
How Fintra does the work
This one is live, not a roadmap promise. Fintra’s governance decision endpoint is called before a money move and runs a vendor-bank-change anomaly check alongside live OFAC SDN screening, delegated-authority, and budget checks, then seals every verdict to a tamper-evident, recomputable evidence ledger. The AI Inbox surfaces that detection as a decision with a recommended hold: the human-facing inbox is in active development, but the detection and the ledger are real today.
What you get out of the box
- A payment held for a policy decision before funds move
- A vendor-bank-change anomaly check on the banking details
- A recommended hold with the dollar exposure attached
- Out-of-band verification prompted before release
- The flag, verification, and outcome sealed to a tamper-evident ledger
Avoid the common pitfall
Questions people ask
How do I catch a vendor bank-account change automatically?
Route every payment through a policy decision before funds move, compare the banking details against the vendor’s known record, flag any change as an anomaly, hold the payment, and require out-of-band verification, with the whole exchange logged to a tamper-evident ledger.
Is this live in Fintra today?
Yes. The governance decision endpoint runs a vendor-bank-change anomaly check before a money move, alongside OFAC SDN screening and delegated-authority and budget checks, and seals every verdict to a recomputable evidence ledger. The AI Inbox that surfaces it as a decision is in active development.
Why is a vendor bank-account change so risky?
Because it looks routine and is timed just before a payment, so it rarely gets a second look, which is exactly how business email compromise diverts funds before anyone notices.
How should I verify a changed bank account?
Out-of-band, through a channel other than the one the change arrived on, for example a phone call to a contact you trusted before the change, never by replying to the email or calling the number on the new invoice.
Keep reading
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
Catch the change before the money moves
See the live vendor-bank-change anomaly check and the evidence ledger behind it. Talk to us: we will map it to your stack.