How IBAN Validation Works (the Mod-97 Check)

An IBAN is valid when it passes the ISO 13616 mod-97 checksum — rearrange it, turn every letter into digits, read the result as one big integer, and a well-formed IBAN leaves a remainder of exactly 1. That’s the whole of how IBAN validation works: a single division that catches typos and transposed digits before a payment goes out. Run the check in the IBAN Validator & Formatter — it does the mod-97 math locally, so your account number never leaves the browser.

The structure of an IBAN

An IBAN is three parts read left to right: a country code, two check digits, then the BBAN. The country code is two letters (GB, DE, FR) that identify which national format follows. The two check digits come next — a number from 00 to 99 that acts as a built-in tripwire for typos. Everything after that is the BBAN (Basic Bank Account Number), the country-specific block that packs the bank identifier and the account number into a fixed layout.

Take the standard example GB82 WEST 1234 5698 7654 32:

• GB — the country code (United Kingdom)
• 82 — the two check digits
• WEST 1234 5698 7654 32 — the BBAN: a bank code (WEST), a sort code (123456), and the account number

The country code tells any validator which length and layout to expect, and the check digits let it confirm nothing was mistyped — without ever contacting a bank.

This layered design is what makes an IBAN self-checking. The country code narrows the problem (now the validator knows exactly how many characters to expect and where the bank and account fields sit), and the check digits then guard the whole string. Nothing in the number is decorative: every character is either identifying an institution, addressing an account, or protecting the rest against transcription errors.

The mod-97 check, step by step

Validation is one calculation, defined by ISO 13616 and ISO 7064, in three moves. Using GB82 WEST 1234 5698 7654 32:

1. Move the first four characters to the end. Take the country code and check digits (GB82) off the front and append them to the back: WEST 1234 5698 7654 32 becomes the head, with GB82 now trailing → WEST12345698765432GB82.
2. Replace each letter with two digits. Every letter maps to a number: A=10, B=11 … Z=35. So W=32, E=14, S=28, T=29, and the trailing G=16, B=11. After substitution the whole string is one long run of digits.
3. Take the whole thing modulo 97. Read that giant digit string as a single integer and divide by 97. For a valid IBAN the remainder is exactly 1. GB82 WEST 1234 5698 7654 32 gives remainder 1, so it passes.

The two check digits (82 here) were originally computed to force that remainder to 1. That’s why the test is so sensitive: change one digit, or swap two adjacent digits, and the remainder almost never stays at 1 — the error is caught instantly.

What validation does and doesn’t prove

Validation proves structure, not existence. A passing mod-97 check confirms the IBAN is well-formed: the country code is real, the length matches, and the check digits are consistent with the rest of the number. That is genuinely useful — it stops most fat-finger mistakes before a transfer leaves your account.

What it cannot do is confirm the account is real, open, or owned by the person you think. The checksum is pure arithmetic; it has no connection to any bank’s records. A perfectly valid-looking IBAN might belong to a closed account, or to no account at all. Only the receiving bank can confirm the account during an actual payment. So treat a green checkmark as “not mistyped,” never as “money will arrive.”

The practical upshot is that IBAN validation is a first line of defence, not the last word. It’s ideal for catching the honest mistakes that happen when someone reads a number off an invoice or retypes it into a form — a dropped digit, a swapped pair, a wrong country prefix. For confirming that a beneficiary is who they claim to be, banks increasingly run a separate name-and-account check at payment time. Validation and that confirmation solve different problems: one guards the format, the other guards the destination.

Country lengths and formatting

Each country fixes its IBAN to a single length, and the validator checks that first. Germany is 22 characters, the United Kingdom is 22, and France is 27 — and every other country has its own fixed number too. Because the length is part of the specification, a wrong length is caught before the mod-97 math even runs.

Formatting, on the other hand, is cosmetic. IBANs are conventionally printed in groups of four characters for readability — GB82 WEST 1234 5698 7654 32 — but those spaces carry no meaning. Validators strip them before doing anything, so GB82WEST12345698765432 and the spaced version are identical as far as the checksum is concerned. When you store or transmit an IBAN, the spaces are optional; when you print it for a human, the groups of four make it far easier to read back.

Common mistakes

A few misreadings trip people up again and again:

• Assuming valid means the account exists. The single most common error. Validation checks spelling, not reality — the account behind a valid IBAN could be closed or fictional.
• A missing or extra digit. Drop or add one character and the length is wrong, or the checksum fails. This is exactly what the check is designed to catch, so trust the failure and re-check the source.
• The wrong country length. Pasting a 20-character string as a German IBAN (which must be 22) fails immediately — the length gate rejects it before the checksum.
• Treating spaces as significant. They aren’t. Spaces are for humans; a validator ignores them. Don’t assume two IBANs differ just because one has groups of four and the other doesn’t.
• Trusting a lookalike. Two swapped digits usually break the mod-97 remainder, which is the whole point — but always copy IBANs from an authoritative source rather than retyping them.

Check an IBAN privately

To validate or tidy up an IBAN, paste it into the IBAN Validator & Formatter. It runs the mod-97 check in your browser, confirms the length and structure, and formats the number into readable groups of four — all locally, so the account number never leaves your device. Because an IBAN is sensitive financial data, that local-only handling matters: nothing is uploaded, logged, or sent anywhere.

For other checksum-based identifiers, the same idea powers the ISBN converter, which uses a check digit to catch mistyped book numbers. And if you need to share a document that contains account numbers, run it through the PII redactor first to mask the sensitive digits — also entirely in your browser.