Forty eight seconds. That was the entire trick.

A supplier bank change email landed at 3:14 PM on a Friday. Forty eight seconds after an AP clerk saved the new IBAN, an automated check flagged it high risk. Here is what the AI actually checked, and why nine of twelve signals only work if your supplier data is clean.

Share
Forty eight seconds. That was the entire trick.

3:14 PM on a Friday. An email lands in the AP inbox from a long standing supplier's finance manager. Subject line: "Urgent: bank change for outstanding invoices before weekend." Body: the previous account has been suspended for internal audit, please pay all outstanding invoices to the updated account, kindly confirm by 4 PM because the team is closing for the weekend.

The treasurer I am describing here is a composite drawn from conversations with finance and treasury leads at buyer side businesses in Nigeria. She is not one real person. The scenario is a pattern I have heard from enough different people that the details rhyme even when the numbers change.

Her firm is a Lagos construction company. Around 400 employees. Around 3,500 supplier invoices a month. A monthly payment run that regularly clears N800 million in outbound wires. They run SAP Business One, a bank portal, and an internal supplier database that was last cleaned in 2022 and everybody knows it.

What the old flow would have done by 5 PM

The AP clerk opens the email at 3:16 PM. She pastes the new IBAN into SAP against three open invoices totalling N42 million. Under the old flow, she would have sent the pack to the treasurer for a "just approve it" click and the batch would have released before 5 PM. Everyone would have gone into the weekend. On Monday the supplier would have said no, and the money would have been three days gone.

That is not what happened. Three months earlier the treasurer had put in place a rule that sounds procedurally minor and is anything but. Every bank detail change triggers an automated risk check before the invoice can enter a payment run. Not a workflow gate that says "wait for treasurer approval." Not a callback. A parallel check the AP clerk cannot bypass and does not have to remember to run.

48 seconds after the clerk pressed save in SAP, the check returned a single line.

HIGH RISK. Do not release payment.

What the AI actually did in those 48 seconds

This is the part worth laying out plainly. Not one clever thing. Twelve boring things in parallel:

  1. Email domain age on the sender's address (recently registered lookalike, days old)
  2. Header path (routed via a residential IP, not a business or hosting network)
  3. IBAN registry lookup (issued to a shell entity, not to the supplier's incorporated name)
  4. Name match confidence between the invoice payee and the new account holder (72%, below the 92% threshold)
  5. Historical bank pattern (seven prior invoices, all paid to a different account that resolves to the supplier's incorporated name)
  6. Request time of day (Friday afternoon urgency is the most common BEC pattern in the sample data)
  7. Urgency language classifier (three flagged phrases in the body)
  8. SWIFT BIC lookup on the new account (points to a bank the supplier has never used before)
  9. Sender writing style compared to prior emails from this supplier's real finance manager (below match threshold)
  10. Change request frequency from this supplier (first bank change in three years)
  11. IP geolocation of the sender (outside the supplier's country)
  12. Sender domain (a Gmail address rather than the supplier's known corporate domain)

Each of those is a lookup a human could technically do. Any single one, taken alone, is not conclusive. A supplier could have a legitimate new bank. A finance manager could have written from a personal Gmail because their laptop got locked out. The signal is in the combination and the count.

Nine of the twelve lit up. A human would not have run any of them at 3:16 PM on a Friday with the AP clerk asking if she can go home.

Fraud AI is thorough. That is the whole trick.

Under time pressure, nobody is going to run twelve lookups before a Friday afternoon payment. Not the AP clerk. Not the treasurer signing off. Not the CFO who authorises the batch. Not the auditor two weeks later. Everyone looks at whatever comes to mind first and decides the email is plausible enough.

The AI is not doing anything clever. It runs twelve lookups every time on every change, and it does not get tired at 4 PM on a Friday.

A lot of vendor pitching in this category leans on the word intelligence. What is actually happening is parallel execution of checks that were always available and never got run. The BIC lookup is a bank register call. The header path is a plain text field. The historical bank pattern is a SQL query against the AP ledger. Nothing about any single check is exotic.

Doing all twelve every time, on every change, in under a minute, is what a human cannot do.

The part vendor decks do not mention

Here is the piece that is easy to miss. Six of the twelve signals depend entirely on the buyer's own historical data being clean and connected. The historical bank pattern. The prior email cadence. The prior sender identity. The change request frequency. The supplier's real corporate domain. The name check on the incorporated entity.

If the supplier master is dirty, if the AP ledger is fragmented across two systems, if the same supplier is onboarded three times under three slightly different legal names, none of those six signals mean anything. Six of the twelve go dark. The AI still returns an answer. The answer is now confident and wrong.

Fraud AI without a clean baseline is a very expensive smoke alarm. It flashes red on the ones so obvious that no one needed a machine to catch them. It quietly fails on the plausible ones, the ones that were built to sit inside the noise of your own records.

What I got wrong about all this

When I first started thinking about this problem, I treated fraud detection as an AI story and put the model at the front. What I have come to think is that the model is the last twenty percent of the work. The first eighty percent is your supplier master and your AP history being clean and joined.

That is not a sexy line. It is the true one. The interesting question is never which model flagged the change. It is whether the supplier baseline underneath it was clean enough for the flag to mean anything.

If you run treasury for a mid-market business, sign up at calabash.app and we will walk through your supplier master and bank-change controls against the workflow you have today.