The IBAN Changed: Why the #1 Invoice Fraud Vector Is Still Working

The attack is simple, which is why it works:

1. 1

   The attacker identifies a supplier relationship

   They look at public invoices, LinkedIn, or compromised email accounts to find a supplier you regularly pay. The supplier name, tax ID, and invoice format are all publicly available or easily obtained.

2. 2

   A fake email or invoice arrives

   The attacker sends an email that looks like it comes from the supplier — either by spoofing the sender address, using a look-alike domain (supplier-corp.com vs suppliercorp.com), or replying to an existing email thread if they have compromised the supplier's account. The email says: "We have updated our bank details. Please use the new IBAN for all future payments." Or it simply attaches an invoice with the new IBAN printed on it.

3. 3

   Your AP team processes the invoice

   The invoice looks legitimate. Same supplier name. Same tax ID. Same format as always. The only difference is the IBAN — and nobody checks it, because the ERP trusts the document. The invoice is approved, the payment is scheduled, and the money leaves your account.

4. 4

   Weeks later, the real supplier calls

   "Where is our payment?" By the time you investigate, the money is in the attacker's account — often moved to a second account, withdrawn as cash, or transferred to a jurisdiction with no recovery treaty. The loss is typically unrecoverable.

The root cause is an assumption baked into almost every ERP and accounts payable workflow: if the supplier identity matches (tax ID, supplier code), the payment details on the invoice are correct.

This assumption was reasonable when invoices arrived on paper from known addresses. It is dangerous when invoices arrive as PDF attachments via email, and it is catastrophic when an attacker has compromised a supplier's email account (which is how most of these attacks start).

The ERP's logic is:

if invoice.supplier_tax_id in known_suppliers:
    pay(invoice.iban, invoice.total)
    # ← no comparison against supplier.iban_on_file

There is no step that says: "Does this IBAN match the one we have on file for this supplier?" The invoice is the source of truth for payment details — when it should be the master data that is the source of truth, and the invoice that is verified against it.

The fix is a single deterministic signal, computed at invoice ingestion time:

def check_iban_changed(invoice, supplier_master):
    if supplier_master.iban_on_file is None:
        return "unverifiable"  # flag for review — cannot compare

    invoice_iban = normalize_iban(invoice.iban)
    master_iban = normalize_iban(supplier_master.iban_on_file)

    if invoice_iban != master_iban:
        return "changed"  # flag for human review
    else:
        return "ok"

def normalize_iban(iban):
    return iban.replace(" ", "").upper()

The signal has three states:

• ok — IBAN on invoice matches the one on file. No action needed.
• changed — IBAN on invoice differs from the one on file. Route to human review. Never auto-approve.
• unverifiable — no IBAN on file for this supplier. Also route to human review. You cannot verify what you cannot compare — and a missing IBAN in your master data is a data quality issue that should be fixed, not silently bypassed.

The normalization step is critical. IBANs can be written with spaces (ES91 2100 0418 4502 0005 1332), without spaces (ES9121000418450200051332), or with mixed case. Without normalization, two representations of the same IBAN would trigger a false positive. With normalization, the comparison is exact.

An IBAN is personal data under GDPR (it identifies a bank account, which can be linked to a natural person). When you surface an IBAN in a Slack card, a dashboard, or an audit log, you should redact it — show only the first 4 characters (country + check digits) and the last 4 characters, masking the middle:

ES91 **** **** **** 1332

This gives the approver enough context to recognize the bank account ("ends in 1332, that's the one we usually pay") without exposing the full IBAN in a channel that may have broader visibility than intended. The full IBAN is stored in the database, encrypted at rest (AES-256-GCM), and is only accessible to authorized personnel through the admin UI.

In Pliuz, IBAN redaction is automatic — the Slack card shows the masked version, and the audit trail stores the hash, not the plaintext. This is both a GDPR compliance measure and an antifraud measure: if an attacker gains access to the Slack channel, they do not get a list of your suppliers' bank accounts.

The FBI's IC3 report for 2023 records $2.7 billion in adjusted losses from Business Email Compromise — the category that includes IBAN fraud. The UK's Action Fraud receives thousands of reports per year. The average loss per incident is €30,000-€50,000 for mid-market companies, though cases exceeding €500,000 are not uncommon.

And these are only the reported cases. Many companies do not report IBAN fraud because they are embarrassed, because they hope to recover the funds privately, or because they do not realize what happened until the trail is cold. The actual cost is higher.

The indirect costs compound: audit findings (your controls did not catch a basic payment redirection), regulatory exposure (SOX, GDPR, EU AI Act), insurance premiums (cyber insurance rates rise after a claim), and trust erosion (the board asks: "How did this happen?").

IBAN changed fraud is the most successful invoice fraud vector in existence. It is low-tech, high-success, and targets companies of every size. It exploits a single assumption: that the IBAN on the invoice is correct because the supplier identity matches.

The fix is a single comparison: normalize both IBANs, compare, flag if different. It is deterministic, auditable, and takes milliseconds to compute. If your AP process does not do this today, you are trusting the invoice — when you should be trusting your master data and verifying the invoice against it.

One comparison. That is the difference between catching the fraud and paying for it.