SpendYou may know it as accounts payable

Bank-detail-change fraud alert

Raise an alert when a supplier bank-detail request looks unusual, so a person can verify it with your existing call-back steps before any payment.

What to expect: ideas for what could change, what you need first, and how to test whether it helps. Nothing here is a measured result.

Impact: High
Ease: Medium
Prep: Some

Indicative rating based on the workflow described. Your readiness and implementation effort may differ.

Evidence status: Editorial / indicative assessment

What it does

This watches bank-detail change requests, and invoices that carry bank details different from your vendor master. It alerts on signals such as a recent change, an unusual country, or a mismatch with the record.

Each alert goes to a person with the reasons shown. The person verifies the request using your own call-back or verification steps and records the outcome.

Why it may help

A fake bank-detail request looks a lot like a real one.

A compromised email account or a convincing message can redirect a payment to the wrong account. The change often arrives as one more routine request among many.
An alert on the unusual ones may help your team notice them sooner and make sure each gets verified before the first payment.
The controller and the person who handles supplier changes would see it first, as a short list of requests worth a closer look.

Where it starts, where it stops

Starts at: A bank-detail change request or an invoice with different bank details is received.
Ends at: A person records a verified or rejected outcome using your existing steps.
Left out on purpose: Approving, applying or rejecting a bank-detail change
Making the verification call or contacting the supplier
Releasing or holding a payment
Replacing your call-back procedure
Supplier onboarding and tax checks

One way it could run, and where people stay in

Illustrative workflow

This is an illustrative improvement approach, not a final solution design. The workflow, level of automation, integrations, and review requirements will depend on your existing tools, available capabilities, data quality, company policies, and team needs. Confirm these during discovery and a controlled pilot before implementation.

Today, by hand

Bank-detail requests arrive by email, portal or invoice, to several people.
A person decides whether a request looks right, and follows the call-back steps when time allows.
Problems can come to light only after a payment goes to the wrong account.

If you adopt it

Requests and invoices with new bank details are checked against signals you agree.
An alert is raised with the reasons shown.
A person verifies the request using your existing call-back or verification steps.
The person records the outcome and the change is applied or rejected by people under your policy.
The controller reviews alerts and outcomes each month.

Checks that remain: Your call-back to a known contact, the separation between master-data changes and payment approval, and any payment hold on recently changed details all stay in place.

When a field is uncertain: An alert asks someone to look. A person decides. Too many alerts and people stop reading them. Too few and a real attempt goes unnoticed. Test the signals on your own history and adjust.

Work it may add: An alert adds a look for some requests. Compare that added time with the time taken today to verify requests.

Who does what

What AI does

Compares new bank details with the supplier record and recent changes
Raises an alert with the signals that triggered it
Ranks alerts so the unusual ones come first

What your system checks

Keeps a log of every alert and who looked at it
Shows the request, the current record and the reasons together

Finance team

Verify the request using your existing call-back or verification steps
Record the outcome and apply or reject the change under your policy
Hold payments to changed details until verification is recorded

Process owner

Sets which signals raise an alert and in what order
Owns the call-back procedure and the list of known contacts
Reviews alerts and outcomes, and changes the signals when they build up or miss

The alert never approves, applies or rejects a bank-detail change. It does not contact suppliers or release a payment.

What it could move, and how you would check

Of the five measures below, this use case may help two. These are expected effects to test against your own baseline, not measured results. The last column says how to check each one.

Possible effect on each of the five process facts
Fact	Expected effect	Why
Process steps	Depends on workflow design	An alert adds a look for some requests, but may cut time spent deciding which requests need extra care.How to check it in a pilot: Count steps and minutes per request, with and without the alert.
Cycle time	Depends on workflow design	Verification takes the time it takes. Alerts may start it sooner, and may add waiting if the queue builds up.How to check it in a pilot: Measure time from request to verified outcome.
Exception loops	Possible downstream benefit	Catching a bad request before payment may avoid chasing a misdirected payment later.How to check it in a pilot: Count payments to changed details that needed rework or recovery.
First-time-right rate	Potential direct benefit	More changes may be verified before the first payment, rather than checked after something looks wrong.How to check it in a pilot: Track the share of bank-detail changes with a recorded verification before first payment.
Cost per invoice	Not directly addressed	This use case aims at control, and any avoided loss is something to measure in your pilot. Handling cost may rise slightly.How to check it in a pilot: Compare handling time per item, including alert review, before and after, and note any avoided loss separately.

What you need first

Ease of getting started: Medium. The tools exist. Some of the setup work is yours.

Supplier master change log enabled
Known contact list for key suppliers
Call-back to a known contact for every bank-detail change
Segregation between master-data changes and payment approval
Payments to recently changed details held until verified

Evidence to keep

A log of every bank-detail change with the verification evidence
Every alert with the reviewer, the decision and the date
Payment holds applied and when they were released
The signals in use and a change log
Results against the known test cases, including the misses

What can go wrong, and how a pilot would show it

Too many alerts, and people start dismissing them without looking.
A well-made fake request does not trip any signal and goes through.
The call-back uses a number from the request itself, which defeats the check.
Requests that arrive outside the monitored routes are never seen.
Signals go out of date as fraud patterns and your supplier base change.

Your next step

List the bank-detail changes from the last year, with how each was verified. Mark any you could not verify. That shows where an alert might help and what your test cases should include. Keep the alert separate from approvals and payments during the pilot.

The pilot steps are under "See how to test it" in the Ways to start panel. Paid support is optional: use Get implementation support if you want help.

How to test whether it improves the work

Effort by stage

Pilot:: Build known test cases from past genuine changes and suspicious requests, and a starter set of about 100 requests as a discovery exercise. See which ones the alert catches. Mostly controller and AP time.
Production:: Connect the alert to the change log and to incoming invoices, agree the signals, and tie it to your payment hold. Effort depends on how your systems record changes.
Ongoing:: Review alerts and outcomes each month, retune the signals, and keep the contact list current.

What to measure, before and after

Known test cases:: How many of your planted risky requests raise an alert, and which kinds are missed.
Alert volume:: How many alerts per week reach people, and how many turn out to be routine.
Alert fatigue:: Whether alerts are looked at properly. Check how fast they are cleared and whether reasons are recorded.
Time to verified outcome:: Time from request to a recorded verified or rejected outcome.
Verification before payment:: How many changes are verified before the first payment to the new details.
Starter set:: About 100 requests is enough to learn from, not enough to prove the alert is ready for live use.

What we assumed when rating how easy this is

Your supplier master keeps a change log that someone can read.
You have known contacts on file for key suppliers.
A call-back or verification procedure already exists, or you will write one first.
Master-data changes and payment approval are done by different people.