What an IBAN Tells You, and What It Does Not

The short answer

An IBAN is a structured account identifier with a built-in checksum. It reliably tells you which country and which institution an account sits at, and it will catch almost any typo you make copying it. It tells you nothing about who owns the account, whether the name you were given matches, or whether the account is under someone else’s control.

That gap — a number that validates perfectly while pointing at the wrong person — is the mechanism behind most invoice-redirection fraud. The checksum passing is not a sign that the payment is safe. It is a sign that you typed it correctly.

How the identifier is built

IBAN is defined by ISO 13616. The format is the same everywhere, even though the length is not:

FI 21 1234 5600 0007 85
│  │  └─────────────────  BBAN — the domestic account number, country-specific
│  └────────────────────  Check digits
└───────────────────────  ISO 3166-1 country code

The first two characters are the country code. The next two are check digits. Everything after that is the Basic Bank Account Number — the account identifier as the country’s own domestic system already understood it, padded to a fixed national length. A Finnish IBAN is always 18 characters. A German one is 22. A Maltese one is 31. The maximum the standard allows is 34.

This matters when you are validating input: an IBAN field with a fixed length limit of 18 will silently reject valid foreign accounts. Length is per-country, and the country is the first thing you read.

What the check digits actually do

The two digits after the country code are not random and not assigned by the bank. They are computed from the rest of the string using MOD-97-10, specified in ISO 7064. You can verify any IBAN by hand:

1. Move the first four characters to the end of the string.
2. Replace every letter with a number, where A = 10, B = 11, up to Z = 35.
3. Interpret the result as a single large integer and take it modulo 97.
4. If the remainder is 1, the checksum is valid.

That is the whole algorithm. It requires no network call, no bank directory and no lookup table. Any IBAN validator that claims to “check the account exists” and does only this is checking arithmetic, not existence.

MOD-97-10 catches every single-character substitution and every transposition of two adjacent characters, which is what human copying errors overwhelmingly look like. The residual false-pass rate is roughly 1 in 97 for a completely random string. In practice, if you mistype a digit, you will be told.

The three things it cannot tell you

Whether the account exists. A checksum-valid IBAN for a bank that has never issued that account number is still checksum-valid. The number is generated by arithmetic, not by consulting a register. Your bank finds out it is undeliverable only when the payment is routed and returned, which can take days.

Who owns it. There is no name inside an IBAN. Historically, euro payments were executed on the account number alone — the payee name travelled with the message as a text field that no system compared against the account record. Sending €4,000 to a valid IBAN with the beneficiary name spelled “Acme Oy” would succeed even if the account belonged to someone else entirely.

This is the design flaw behind business email compromise. An attacker does not need to break anything cryptographic. They need to change one string in an invoice PDF and wait for finance to pay it.

Whether the bank is who you think. Characters 5 onward encode a national bank identifier, and you can look up which institution that is. But an IBAN at a legitimate bank can belong to a payment institution reselling accounts, a money-mule account opened with stolen ID, or a perfectly ordinary customer who has been socially engineered into forwarding money. The institution is identifiable; the intent is not.

Verification of Payee closes part of the gap

European regulation has been moving toward payee-name checking: before you confirm a transfer, your bank queries the receiving bank and reports whether the name you entered matches the name on the account, usually as a match, a close match with the real name shown, or no match. You then choose whether to proceed.

This is a genuine improvement and it directly attacks invoice redirection. Two things are worth understanding about it:

• A “no match” warning is advisory. You can almost always click through it. Fraud that survives this control survives because the person clicked through, often because a plausible explanation arrived by email thirty seconds earlier.
• Coverage is not universal. The check works where both institutions participate. Payments outside that perimeter fall back to number-only execution.

Whether the check is live on your own accounts, and what exactly it covers, is something to confirm with your bank rather than assume — the rollout dates and the scope have moved more than once.

What to actually do

Confirm changed bank details out of band, always. If a supplier emails new payment details, telephone them on a number you already had — not one in the email — and read the IBAN back. This single habit defeats the entire attack class. It is unglamorous and it works.

Treat the first payment to any new IBAN as a test. Send a small amount, confirm receipt through a channel you trust, then send the rest. The cost is one extra transfer fee against the entire exposure.

Read the country code. A supplier you have paid in Germany for four years does not suddenly invoice from a LT or HU account because of an “internal treasury migration”. Payment-institution accounts in unexpected jurisdictions are a recognised laundering pattern, and the country code is the first two characters — you do not have to be an analyst to notice.

Do not rely on the warning screen. If your bank shows a name-match warning, stop and verify by phone. The warning is the control working. Clicking through it is the failure.

Understand what you can recover. A completed push transfer is not a card payment. There is no chargeback right. Your bank can request a recall from the receiving bank, but the money has usually been moved onward within hours, and recovery depends on the receiving bank’s cooperation and whether funds remain. Speed matters enormously — report it the same day.

Where this sits

The IBAN is a good identifier doing exactly the job it was designed for: unambiguous, self-checking, machine-routable account addressing across borders. The problem is that people read a passing checksum as a safety signal, and it was never that.

If you are sending money across borders, the identifier is only one of the things worth understanding — why “no fees” transfers are not free covers what the transfer actually costs once the exchange-rate spread is counted, and exchange rate spread, explained with worked examples shows the arithmetic.