How the fake bank-change scam actually works
The technical name is business email compromise (BEC) — a scam where an attacker impersonates a trusted vendor or executive over email to redirect a legitimate payment. The version that hits accounts payable is brutally simple. A vendor you really do business with sends what looks like a normal invoice. Buried in it is a note: "Please update our remittance details — our bank account has changed." Your AP clerk updates the vendor record, pays the next invoice, and the money lands in the fraudster's account instead of your vendor's. Weeks later the real vendor calls asking where their payment went.
It works because nothing about it looks wrong. There's no malware, no obvious typo, no Nigerian-prince theatrics. The attacker has either compromised the vendor's email or spun up a lookalike domain, and the request rides on a real relationship. According to the FBI's Internet Crime Complaint Center (IC3) 2023 Internet Crime Report, business email compromise drove $2.9 billion in reported losses in a single year — and invoice-and-payment redirection is one of its most common forms. That figure is reported losses only; the real number is higher, because most victims never file.
What a fraud-detection scanner checks for — step by step
Here's the logic I built into the scanner Aptria uses, and that I test against fake invoices on purpose. It's roughly nine checks. None of them is clever on its own — the point is that an attacker has to beat all of them, and a single bank-change invoice almost never does. Each check runs before any payment is released:
- Bank-detail change vs. vendor master. Compare the bank account on the invoice against the account already on file for that vendor. If they differ, the invoice is flagged immediately. This is the single highest-value check — it's the exact move every BEC redirect has to make.
- Mismatched remittance domain. Check whether the email or remittance domain matches the vendor's known domain. "billing@acme-corp-payments.com" is not "acme.com," and the scanner treats that gap as a red flag.
- New payee. If this payee has never been paid before, hold it. First contact is the moment fraud is easiest, so a brand-new payee never sails straight through.
- Urgency and pressure language. Scan the message for phrases like "urgent," "process today," "before close of business," or "keep this confidential." Real vendors rarely demand secrecy; fraudsters lean on it to short-circuit your normal checks.
- Lookalike sender domain. Detect near-miss domains — character swaps, extra hyphens, swapped letters (the digit "1" for the letter "l"). These are designed to pass a five-second human glance.
- Out-of-band confirmation requirement. For any bank-detail change, require confirmation through a separate channel — a phone call to a number already on file, not the number printed on the suspicious invoice. The scanner won't clear the change until that confirmation is logged.
- Amount anomaly vs. history. Compare the invoice amount against what this vendor has historically billed. A payment far outside the normal range gets held for a human to look at.
- First-time-payee hold. Any payment to a payee with no payment history is held automatically, regardless of amount. No first payment leaves on autopilot.
- Human approval gate before release. Anything that trips a flag stops and waits for a named person to approve it. The AI's "I'm done" releases nothing on its own — a human has to sign off, and that approval is written to the record.
The core idea: Fraud detection isn't one genius rule. It's a stack of dumb, boring checks that a real invoice passes effortlessly and a fraudulent one trips on. The fraudster has to beat every check; you only need one to catch.
Why doesn't ordinary AP automation catch this?
Here's the uncomfortable part. Most "AP automation" automates data entry, not verification. It reads the invoice with OCR, extracts the line items, codes the GL account, and pushes the payment into the queue — fast and accurate at the task it was built for. But it was built to move invoices through, not to doubt them. It has no concept of "this bank account doesn't match the one on file" or "this is a first-time payee" because catching fraud was never its job.
So the bank-change invoice gets read perfectly, coded perfectly, and paid perfectly — to the wrong account. The automation did exactly what it was designed to do. That's the gap a fraud-detection layer fills: it sits in front of the payment and asks the questions a careful Controller would ask, on every invoice, without getting tired or rushed.
Most AP automation makes paying invoices faster. It does nothing to make paying the wrong invoice less likely. Speed without verification just helps the fraud arrive on time.
See it run
I don't ask you to take my word for it. There's a live demo on the Proof page where the scanner catches a fake bank-change invoice in real time — the same nine-check logic described above, running against a planted fraudulent invoice and flagging it red before payment. You watch it happen instead of reading a slide about it.
If you want to understand why the record of that catch holds up later — when an auditor asks "who approved this, and can you prove the log wasn't edited?" — that's a related topic worth reading next.