How to Validate an IBAN: Country Code, Check Digits, and the mod-97 Test

A wire transfer has no undo button. Once the money leaves, getting it back depends on the goodwill of a stranger's bank in another country. So before anyone clicks send, it is worth spending ten seconds confirming the destination account number is at least structurally sound. That is exactly what an IBAN check does, and the math behind it is simple enough to explain in one sitting.

An IBAN, or International Bank Account Number, is the standardized account string used across Europe and dozens of other regions. It is not a random blob. It has a fixed shape, and that shape carries a built-in self-test. If you understand the three parts and the one calculation that ties them together, you can spot a bad IBAN long before your bank does.

The three parts of every IBAN

Every IBAN starts the same way: a two-letter country code, then two check digits, then the country's own account number. That last part has a name, the BBAN (Basic Bank Account Number), and it is just the domestic format each country already used, repackaged.

So the structure reads left to right as:

Country code (2 letters): DE for Germany, GB for the United Kingdom, FR for France. These are standard ISO country codes.
Check digits (2 digits): a two-digit number, 02 through 98, that guards the rest of the string.
BBAN (the rest): the bank identifier and account number in that country's national layout.

The total length is fixed per country. A German IBAN is always 22 characters. A French one is always 27. Spain is 24, the Netherlands is 18, Italy is 27, Norway is the shortest at 15, and Malta is the longest at 31. There is no flexibility here, which is the first cheap check available to you: if a string claims to be a German IBAN but has 23 characters, it is wrong, full stop, before you even look at the digits.

How the check digits actually work

The two check digits are where the real protection lives, and they come from a calculation called the mod-97 test, defined in ISO 7064. Here is the whole algorithm:

Move the first four characters (the country code and the two check digits) to the end of the string.
Replace every letter with a number, where A becomes 10, B becomes 11, and so on up to Z becoming 35.
You now have one very long string of digits. Read it as a single big integer.
Divide that integer by 97. If the remainder is exactly 1, the IBAN passes.

That single rule, remainder equals 1, is the whole game. It is not approximate and it is not a heuristic. Any well-formed IBAN produces a remainder of 1, and changing even one digit almost always changes that remainder to something other than 1. A single mistyped character, or two characters swapped, will be caught the vast majority of the time. That is why a finance team that runs the mod-97 check before a payment catches the copy-paste slip that would otherwise send four figures into the void.

A worked example

Let me walk through a real one. Take the British test IBAN GB82 WEST 1234 5698 7654 32. Strip the spaces and uppercase it: GB82WEST12345698765432. It is 22 characters, which matches the United Kingdom's expected length, so the first check passes.

Now the mod-97 step. Move the first four characters GB82 to the end:

WEST12345698765432GB82

Replace the letters: W is 32, E is 14, S is 28, T is 29, G is 16, B is 11:

3214282912345698765432161182

Read that entire string as one integer and divide by 97. The remainder comes out to 1, so the IBAN is well formed. Now flip a single digit, say change the final 2 to a 3, and rerun the calculation. The remainder is no longer 1, and the check fails instantly. That is the typo guard doing its job: the two check digits near the front are mathematically bound to every character that follows them, so nothing can be quietly altered without breaking the test.

What a green result does and does not mean

Here is the part people get wrong. A passing IBAN is well formed and free of common typos. That is all it is. The mod-97 test and the length table cannot tell you whether the account is open, whether it has money in it, or whether it belongs to the person you think it does. A randomly assembled string can pass mod-97 by sheer luck roughly one time in 97. Validity is a structural property, not a statement about reality.

I learned to respect that distinction the hard way. I once helped a small studio set up its first overseas supplier payment. The IBAN validated cleanly, everyone relaxed, and the transfer went out. It turned out the vendor had sent details for a closed account that they had forgotten to update. The number was perfectly well formed, every check passed, and the money still bounced back two weeks later after a confusing round of emails. Format validity never proves ownership. The only reliable move is to confirm the account name and bank with the recipient over a channel you already trust, then validate the format as a second line of defense against typos.

There is a related trap worth naming: not every country uses IBAN at all. The United States, Canada, and China are all outside the system. US transfers use routing numbers, China uses CNAPS codes plus the account number, and cross-border payments into those countries rely on the SWIFT/BIC code. If you paste a US or CN account number into an IBAN checker, it will report an unknown country prefix, which is correct, not a bug.

Build the check into your workflow

If you handle payments by hand, the simplest habit is to validate every IBAN at the moment you receive it, not at the moment you pay. Paste the number into the IBAN validator the instant a supplier emails new details, before it ever lands in your records. The tool strips spaces, uppercases the input, confirms the country length, runs the mod-97 arithmetic, and regroups the output into clean blocks of four so you can eyeball it against the original. Everything runs in your browser; nothing is uploaded.

The mod-97 idea is not unique to banking, either. It belongs to the same family of check-digit schemes that protect credit card numbers and many ID numbers. If you work with card data, the Luhn validator does the analogous job for the 16-digit card number, using a different but equally simple modular calculation. Once you have seen one check-digit algorithm, the rest stop looking like magic and start looking like what they are: a cheap, deterministic guard against the one wrong keystroke that would otherwise cost real money.

So the next time a bank account number lands in your inbox, give it the ten-second test. Confirm the length matches the country, run the mod-97 check, and only then trust the string enough to act on it.

Made by Toolora · Updated 2026-06-13