IBAN Validator

Paste an IBAN and this checks three things: that the country code is one it recognises, that the length matches what that country registers, and that the check digits agree with the rest of the number. It then shows the IBAN in both the forms you need: unspaced for electronic transfers, grouped in fours for print.

The check digits are the interesting part. They are not a hash or a guess: over digits, the ISO 7064 mod-97 scheme is exhaustive: every mistyped digit is caught, and so is every swap of two adjacent digits, which is exactly the shape of the mistakes people make copying a twenty-two character string off a PDF. An IBAN with one digit wrong is essentially never also a valid IBAN.

What it cannot tell you is whether the account exists, or whose it is. That distinction is the whole reason to be careful with the result: a valid IBAN is a well-formed one. Invoice redirection fraud works precisely because the substituted account number passes every check on this page.

Nothing is transmitted. An IBAN identifies a bank account, and uploading one in exchange for a division by 97 would be a poor trade for arithmetic your own browser can do in a millisecond.

An IBAN is not a new kind of account number. It is a wrapper around the account number a country already used (the sort code and account number in the UK, the BLZ and Kontonummer in Germany) with two things bolted on the front: a country code, so a bank knows which national scheme to interpret the rest under, and two check digits, so a mistyped one can be caught before the payment is sent rather than after.

The check digits are computed over the whole rest of the number, which is why they detect changes anywhere in it. Move the first four characters to the end, turn each letter into a number, and divide the resulting very long integer by 97; a correct IBAN always leaves a remainder of exactly one. The scheme is chosen for its error-detecting properties rather than for elegance: over digits, every substitution changes the remainder, and so does every transposition of two neighbouring ones.

There is one gap in that, and it is worth stating rather than glossing over. Letters expand to two digits before the division (A becomes 10, Z becomes 35), so replacing a digit with a letter makes the number one digit longer as well as different, and the guarantee, which assumes a fixed length, stops applying. Sweeping every such substitution across the published specimen IBANs finds 23 collisions out of 2,340 attempts, against none at all in the 918 digit-for-digit substitutions. It is a small hole and a real one: a checksum pass is strong evidence that an IBAN was typed correctly, not proof.

That is a strong guarantee against typing, and no guarantee at all against anything else. The arithmetic knows nothing about banks. It cannot tell you the account is open, that the bank code inside it corresponds to a real institution, or that the person who sent you the number owns the account. Those are questions only the receiving bank can answer, and it answers them when the payment arrives, or does not.

This matters because of how invoice fraud actually works. Somebody intercepts or imitates a supplier's email and changes the bank details, and the IBAN they substitute is a real, valid IBAN for an account they control. It passes the checksum. It passes the length check. It passes every offline check that exists, because there is nothing wrong with it except that it is not your supplier's. The defence is not a validator; it is confirming a change of bank details by voice, on a number you already had.

The lengths are worth knowing because they are fixed rather than variable. Each country registers exactly one length (15 in Norway, 22 in Germany and the UK, 27 in France, 31 in Malta), so a length mismatch is a specific, findable error, and telling somebody their IBAN is one character short of a German one is far more useful than telling them the check digits do not match. Checking length first is why this reports the former.