IBAN Structure and Check Digits: How to Read and Verify an IBAN

The four parts of an IBAN

IBAN stands for International Bank Account Number and is standardised in ISO 13616. It uses only uppercase letters and digits and is at most 34 characters long. The spaces are a reading aid: banks print groups of four so a person can compare the number with a statement; the spaces are not part of it.

Only the first four characters mean the same thing everywhere. From position 5 onward you are reading the BBAN, the Basic Bank Account Number, whose internal layout is set nationally.

The BBAN: why the rest of the string differs by country

Two IBANs from different countries have little in common beyond those four characters. Lengths vary - in the country table used here, Norway is 15 characters and Saint Lucia is 32 - and each country splits its BBAN differently.

Because segmentation is national, a parser needs a per-country table of offsets. This site's checker splits bank code, branch code and account number that way, and fills the branch field only where the country table defines one. In countries with a branch code, the last BBAN characters are often a national check digit rather than part of the account.

The check digits: ISO 7064 MOD-97-10 in five steps

The check digits are arithmetic, not something a bank allocates: ISO 13616 points at the ISO 7064 MOD-97-10 scheme.

1. Remove spaces and hyphens and uppercase the string.
2. Move the first four characters, the country code plus the check digits, to the end.
3. Replace each letter with two digits by alphabet position: A is 10, B is 11, up to Z as 35.
4. Read the result as one long integer.
5. Take it modulo 97 and look at the remainder. A valid IBAN leaves exactly 1.

Step 4 is the awkward one by hand: a German IBAN converts to 24 digits and longer countries exceed 34. Work in chunks of about nine digits and keep only the running remainder - multiply it by ten to the power of the chunk length, add the chunk, then take the remainder modulo 97 again. Programs hit the same wall, which is why the check needs a big-integer type.

A worked example you can check by hand

Take the Norwegian IBAN NO93 8601 1117 947. At 15 characters it is short enough for paper, and every intermediate result below was verified by calculation.

1. Split it: country code NO, check digits 93, BBAN 86011117947.
2. Move the first four characters to the end: 86011117947NO93.
3. Convert the letters: N is 23 and O is 24, so the number is 86011117947232493, which is 17 digits.
4. Reduce in chunks: 860111179 mod 97 = 54, then (54 x 100000000 + 47232493) mod 97 = 1.
5. The remainder is 1, so the check digits are consistent with the rest of the string.

A longer IBAN behaves the same way. DE89 3704 0044 0532 0130 00 becomes 370400440532013000DE89, then 370400440532013000131489 once D is 13 and E is 14. Chunking gives 370400440 mod 97 = 23, then (23 x 1000000000 + 532013000) mod 97 = 16, then (16 x 1000000 + 131489) mod 97 = 1.

Where the two digits come from in the first place

Generating check digits runs the same arithmetic backwards: append the country code and two zeros to the BBAN, convert, take the remainder modulo 97, then subtract it from 98. For the Norwegian BBAN the remainder is 5, and 98 - 5 = 93, exactly the 93 in NO93. The same recipe gives 89 for the German example and 82 for GB82 WEST 1234 5698 7654 32.

What a passing checksum proves, and what it does not

A checksum is a typo detector, not proof that an account exists. The gap between those ideas is where payments go wrong: valid IBAN gets read as this account is real.

• What it proves: the country code is supported, the length matches that country, only uppercase letters and digits are used, and the check digits agree with the rest of the string.
• What it catches: a wrong digit, a wrong letter, a missing or extra character, and almost any swap of two adjacent characters.
• What it cannot prove: that the account is open or was ever issued, that the holder is who you think, that the bank code belongs to the institution you wrote down, or that a payment will be accepted.
• What a bank lookup adds: the bank code is assigned to an institution in a national registry. It says nothing about an individual account.

Closed accounts keep structurally valid IBANs, because the check digits depend on characters rather than account status, and an IBAN from an old invoice stays valid after the bank has merged or been renamed.

The input errors that break validation most often

Most failed validations are mundane:

• Spaces, hyphens and line breaks from copy and paste: harmless here, because the checker strips them and uppercases the input first.
• Full-width characters from a Chinese or Japanese input method. Full-width DE89 is not ASCII DE89: those characters are not A-Z or 0-9, so the tool reports invalid characters rather than a checksum failure. Switch the input method to half-width.
• A BIC or SWIFT code in the IBAN field. A BIC such as DEUTDEFF is 8 or 11 characters and identifies a bank; an IBAN identifies one account at a bank. Neither can be derived from the other.
• A national account number pasted instead of an IBAN: it fails the length check at once, because an IBAN is longer and starts with a country code.
• A truncated paste, usually a dropped final character, which fails the country length check before any arithmetic runs.
• Two digits swapped while retyping. Swapping two digits inside the German bank code turns DE89 3704 0044 0532 0130 00 into a string whose remainder is 28 instead of 1; changing the check digits by one, as in DE88 3704 0044 0532 0130 00, leaves a remainder of 0.

The error message says which stage failed. Expected 22 characters, got 21 means the paste was short; a MOD-97 failure means the characters themselves are wrong.

Frequently asked questions

Tools used in this guide

More guides