Verify New Supplier Banking Details
Business email compromise attacks that target vendor payments almost always work the same way, a fraudulent email impersonating a supplier requests a banking detail change or submits new banking details for a supplier being onboarded, worded convincingly enough that whoever's processing supplier setup doesn't think twice before updating the record, and the first real payment goes straight to a fraudster's account instead of the actual vendor's. The fraud usually isn't discovered until the genuine supplier calls asking why they haven't been paid, by which point the money is typically unrecoverable, and the gap that let it happen was simply that nobody independently verified the banking details through a channel the fraudster couldn't also control.
STARTING PRICE
From €299
Standard tier · Multi-step workflow with AI extraction/decisioning and 2-3 integrations.
Get a quote →Saves roughly 0.5-1 hr per new supplier or banking change, plus prevented losses from a fraud pattern that's expensive and often unrecoverable when it succeeds.
How the automation works
We require independent verification of banking details for every new supplier and every banking detail change on an existing one, confirming the details through a channel separate from wherever the request originated, a callback to a phone number already on file rather than one provided in the same email as the change request, before the record is updated or the first payment is released. Any banking detail submission that arrives through an unusual channel, a new email domain, an unexpected request timing, gets flagged with the specific anomaly for extra scrutiny before verification even begins. The verification step adds a short delay to onboarding or a banking change, but it's the one control that reliably catches this specific and expensive fraud pattern before money actually moves.
Process flow
- 01
Banking details submitted trigger
New supplier banking details, or a change request on an existing supplier, are submitted as part of onboarding or update.
- 02
Check for submission anomalies ai
The submission channel and context are checked for anomalies, an unfamiliar email domain, an unusual request timing, flagged for heightened scrutiny.
- 03
Verify through an independent channel output
Details are confirmed through a channel separate from where the request originated, a callback to a phone number already on file, not one provided in the request itself.
- 04
Hold payment until verified output
No payment is released against new or changed banking details until independent verification is confirmed and documented.
- 05
Record verification evidence output
The verification method, date, and confirming contact are logged against the supplier record, creating an audit trail for the control.
Inputs
- Submitted banking detail (new or changed)
- Prior verified contact information on file
- Submission channel/context metadata
- Verification confirmation record
Outputs
- Independently verified banking detail confirmation
- Anomaly flags on suspicious submission patterns
- Payment hold status pending verification
- Audit trail of verification method and contact
Works with
Prefer a fully custom build instead of an off-the-shelf integration? We scope both options during your free consultation — most jobs like this one work fine on standard connectors, but higher-volume or non-standard systems sometimes need bespoke API work, reflected in the complex tier.
Where this goes wrong if you get it wrong
- Verification only works if the callback or confirmation channel is genuinely independent of the original request, calling a phone number provided in the same email as the change request doesn't verify anything, it just confirms the fraudster answers their own phone, the callback number has to come from a source predating and separate from this specific request.
- A legitimate supplier that's genuinely changed banks will find this verification step slower and slightly more friction-filled than a simple record update, that friction is the point, but it needs a fast, clearly communicated verification process so a real vendor doesn't experience unreasonable payment delay over a legitimate change.
- Anomaly detection based on email domain or submission pattern can miss a sophisticated attack that closely mimics a legitimate request, or false-flag a genuine supplier's request that happens to look unusual for an innocent reason, the verification step needs to happen regardless of whether anomaly detection flags anything, not act as the sole gate.
- A verification process that gets treated as a formality, a box checked without a real independent conversation confirming the details, provides no actual protection even though it looks compliant on paper, the control only works if the verification step is performed with real rigor every time, not occasionally skipped under time pressure to get a payment out.
Frequently asked questions
Does this slow down onboarding for every new supplier significantly?
It adds a short, focused verification step, typically a same-day or next-day callback confirmation, not a lengthy delay, the goal is a fast but genuinely independent check, not a bottleneck.
What if the supplier's on-file phone number is also out of date?
A callback to an unreachable or clearly wrong number is itself a flag worth investigating further, potentially through another independently sourced contact method, rather than falling back to whatever number the request itself provided.
Does this apply to existing suppliers changing their bank details, or just new ones?
Both, a banking change on an established supplier is actually one of the more common fraud vectors, since an existing, trusted vendor relationship makes the change request feel routine and less scrutinized.
Who is responsible for performing the independent verification call?
Typically the procurement or AP team member processing the supplier setup or change, following a defined verification script and logging the confirmation, not left to informal or inconsistent practice.