How IBAN validation works

Check 1: Country code

The first two letters must be a country prefix supported by the toolkit’s bundled IBAN format table. "XX" or a non-participant like "US" fails immediately.

Check 2: Length

Each country has one exact length: Germany 22, France 27, Norway 15. A single missing or extra character fails. This is the cheapest check, so validators run it first.

Check 3: BBAN structure

The national part must match the country's pattern: digits where digits belong, letters where letters belong. Example: a UK BBAN needs a 4-letter bank code + 6-digit sort code + 8-digit account; letters in the sort code fail.

Check 4: mod-97 checksum

Move the first 4 characters to the end, convert letters to numbers (A=10 … Z=35), divide by 97: the remainder must be 1. This helps detect common transcription errors. Full walkthrough: check digits explained.

What validation cannot tell you

Format validation confirms an IBAN is well-formed: not that the account exists, is open, or belongs to a given person. Only the recipient's bank (or Confirmation/Verification of Payee schemes) can confirm that. Try it: validate an IBAN.

Follow one value through the checks

Use DE89370400440532013000 as a documentation example, not a payment destination. The prefix is DE, so the validator selects the German format. That format requires 22 characters. Its national component is numeric, so letters in that component would fail the pattern check. Finally, the rearranged and converted value must have a remainder of 1 when divided by 97.

Format validation is only one layer

Our browser validator checks the registered country layout and the international checksum. It does not run every country’s domestic account checksum, search current bank directories, or check the beneficiary’s name. A BBAN pattern describes where letters and digits belong; it does not prove the national account number was issued by a bank.

This distinction matters when a payment form says “valid.” A green result can mean only that an identifier is well formed. A payment service may still reject it because the bank code is unknown, the account is closed, the payment scheme is unsupported, or recipient verification fails. Read each service’s definition of validation before relying on its result.

Design useful validation errors

Preserve the user’s input and identify the failed rule. “Germany requires 22 characters” is more useful than “invalid bank details.” Avoid automatically changing account digits or suggesting a new beneficiary. For a payment, the next step is to confirm the bank-issued information, not to modify the number until its checksum passes.

For QA, keep a small fixed test set alongside randomly generated values. The fixed set tells you whether an update changed a known result. Random values help exercise the interface but cannot replace regression cases or a payment provider’s official sandbox data.