IBAN Validator

The IBAN standard (ISO 13616) defines a deterministic verification procedure. Reading any official spec will give you the same five steps:

1. Strip whitespace and uppercase the string.
2. Confirm the total length matches the country-specific length defined in the IBAN Registry (e.g. Poland: 28, Germany: 22, United Kingdom: 22, Norway: 15, Malta: 31).
3. Move the first four characters (country code + check digits) to the end of the string.
4. Replace every letter with two digits using A=10, B=11, ..., Z=35.
5. Compute the resulting integer modulo 97. The IBAN is valid if and only if the remainder is exactly 1.

Because the integer is too large for native 64-bit math, the modulo is computed in chunks of 9 digits — see the worked example below.

This is the canonical UK test IBAN published in the SWIFT registry. Working through the algorithm:

GB82 WEST 1234 5698 7654 32

1. Strip spaces → GB82WEST12345698765432
2. Length: 22 ✓ (UK requires 22)
3. Rotate → WEST12345698765432GB82
4. Convert letters → 3214283212345698765432161182
5. mod 97 → 1 ✓

Result: VALID

MOD 97-10 reliably detects all single-digit errors and almost all transpositions of adjacent characters — historically the dominant typo classes when humans copy account numbers off paper statements. It catches the vast majority of two-digit independent errors as well.

It does not catch: an IBAN that is well-formed but belongs to a different person at the same bank, a closed account, or a deliberately constructed valid-but-fake IBAN. The check digit is an integrity test, not an authentication or ownership test. For "is this account actually open and owned by John Doe", you need bank-level APIs (Open Banking AIS in the EU, name-and-account-matching services in the UK).

• You added an IBAN field to a checkout form and want to catch typos before payment submission, without bundling a 10kB validation library you have to keep updated.
• You exported customer data from a CRM that accepted free-text IBANs and need to flag rows that will fail at the bank.
• You received a confusing rejection from a SEPA payment and want to confirm whether the IBAN itself was malformed or the rejection came from elsewhere (KYC, sanctions, account closed).
• You are writing a backend validator and want to sanity-check your implementation against a trusted reference for a tricky country (looking at you, MT — 31 characters with mixed alphanumeric BBAN).

• It will not verify that the account exists or is open. That requires a paid bank-data API or the Account Identification Service offered by some PSPs.
• It will not verify the account holder's name. UK CoP and EU VoP services do this, but they are bank-side and require regulated access.
• It will not detect IBANs from countries outside the SWIFT registry. Some non-IBAN countries (US, Canada) use ABA/transit numbers instead — paste those into a routing-number validator, not here.