The IBAN Checksum Explained: How Mod-97 Catches a Mistyped Bank Account Before It Costs You

Type one digit wrong in a US routing and account number and there's a decent chance the transfer still goes through — to the wrong account. Banks in the US generally don't verify that the account holder name matches the number; they just move money to whatever account the digits point to, and reconciling the mistake afterward is your problem. This is a large part of why wire fraud and typo-driven misdirected payments are a persistent headache in ACH and wire systems.

The International Bank Account Number (IBAN), used across Europe and much of the world outside the US, Canada, and a handful of other countries, was designed to make that specific failure mode catchable before the transfer is submitted. It does this with two check digits sitting right after the country code, computed using a checksum algorithm called mod-97 (ISO 7064 MOD 97-10, referenced by the IBAN standard ISO 13616). Get one digit wrong anywhere in the IBAN and the checksum almost certainly fails, right there in the form, before any money moves.

This post walks through exactly how that checksum works, with real arithmetic on a real-looking IBAN, and where it does and doesn't protect you.

What an IBAN actually encodes

An IBAN has three parts, always in this order:

1. Country code — 2 letters (ISO 3166-1 alpha-2), e.g. DE for Germany, GB for the United Kingdom.
2. Check digits — 2 numeric digits, the mod-97 checksum this post is about.
3. BBAN (Basic Bank Account Number) — the country-specific part: bank code, branch code, account number, sometimes its own internal check digit. Length and structure vary entirely by country; Germany's BBAN is 18 characters, the UK's is 18, Norway's is 15.

Total IBAN length is fixed per country — Germany is always 22 characters, the UK is always 22, Norway is always 15 — and that fixed length is itself a first-pass sanity check, separate from the checksum. A German IBAN with 21 characters is wrong regardless of what the checksum says.

Here's a real-looking (not a real account) German IBAN: DE89 3704 0044 0532 0130 00.

Stripped of spaces: DE89370400440532013000.

• DE — country code
• 89 — check digits
• 370400440532013000 — BBAN (bank code 37040044, account number 0532013000)

The mod-97 algorithm, step by step

The check digits aren't arbitrary — they're derived from the rest of the IBAN using arithmetic that produces a remainder of exactly 1 when the whole number is divided by 97, if and only if nothing has been altered. Here's the validation procedure, run on the example above:

Step 1 — Rearrange. Move the first four characters (country code + check digits) to the end of the string.

370400440532013000 + DE89 → 370400440532013000DE89

Step 2 — Convert letters to numbers. Each letter becomes a two-digit number: A=10, B=11, ... Z=35. Digits stay as-is.

D → 13, E → 14. So DE89 becomes 131489, and the full string becomes:

3704004405320130001314 89

Full numeric string: 370400440532013000131489

Step 3 — Compute the value mod 97. Because this number is far too large for ordinary integer arithmetic, it's computed piecewise: process the digits in chunks, taking the remainder mod 97 after each chunk to keep the intermediate value small. Done correctly, the final remainder is what matters — not the enormous intermediate number.

370400440532013000131489 mod 97 = 1

A remainder of exactly 1 means the IBAN is structurally valid. Change any single digit anywhere in the string — the bank code, the account number, even the check digits themselves — and the remainder will almost never come out to 1 again.

Why mod-97 specifically

A few properties make this checksum well-suited to catching human-entry errors, which is the whole point:

• 97 is prime, which maximizes the algorithm's ability to detect single-digit substitution errors and adjacent-digit transpositions (swapping two neighboring digits, the single most common typo when copying a long number by hand).
• Two check digits give 100 possible values (00–99), but not all values are valid for the checksum, so a random typo has roughly a 1-in-97 chance of accidentally producing a passing checksum. That's not cryptographic-grade protection — it's not meant to stop fraud — but it reliably catches the transcription errors that happen when someone reads a number off a screen or a printed statement and mistypes a digit.
• It's cheap. No hashing, no keys, just modular arithmetic — which is why it can run client-side in a browser form the instant someone finishes typing, with no server round-trip needed.

What a passing checksum does not tell you

This is the part that trips people up: a structurally valid IBAN is not the same as a real, open, reachable account.

• It confirms the number wasn't mistyped in a way the checksum can detect.
• It does not confirm the account exists, is open, or belongs to the person or business the payer thinks it does.
• It does not replace your payment processor's own account verification, which typically involves an actual lookup against the receiving bank (sometimes via a real-time service, sometimes via a small test deposit).
• Some countries' BBANs have their own internal check digit beyond the IBAN-level mod-97 check (Germany's does, computed differently per bank), which a generic IBAN validator that only checks mod-97 and length won't verify.

In other words: mod-97 is a fast, local, zero-cost first filter that catches a large share of fat-finger errors immediately, not a substitute for real account verification before a transfer actually executes.

Where this shows up in practice

Any form that accepts an IBAN — a SEPA transfer setup, an invoicing tool, a payroll system, a fintech onboarding flow — should validate the checksum client-side before submission. It costs nothing, needs no network call, and turns a wrong-account wire transfer (hard to reverse, sometimes impossible) into an inline form error the user fixes in three seconds.

The practical validation flow, mirroring what payment processors do internally:

1. Strip whitespace and uppercase the string.
2. Check total length against the expected fixed length for that country code (ISO 13616 publishes the registry — Germany is 22, France is 27, Norway is 15, and so on).
3. Run the mod-97 check described above.
4. Only then, if you need real assurance the account exists, hand off to your payment processor's own verification.

Utilix's IBAN Validator runs exactly this sequence — mod-97 checksum plus the ISO 13616 length cross-check per country — entirely client-side, which matters if you're pasting in a real customer IBAN and don't want it touching a server.

The takeaway

The two check digits after an IBAN's country code aren't decoration — they're a mod-97 checksum designed specifically to catch the kind of single-digit or transposition typo that turns a routine transfer into a support ticket. It's a first-line filter, not a guarantee the account is real, but it's the cheapest and fastest error you'll ever catch: right in the form, before the money moves.