IBAN MOD-97 and country lengths: what a “valid” IBAN actually proves

Published: 2026-09-05

How ISO 13616 IBAN structure, country-specific lengths, and the MOD-97-10 checksum work together—and why a passing check only catches typos, not a live bank account.

An IBAN (International Bank Account Number) is a standardized way to write a domestic account so cross-border payments and forms can share one string. Under ISO 13616, every IBAN starts with a country code and two check digits, then a country-specific BBAN (Basic Bank Account Number). Local validation usually combines a fixed length per country with the ISO 7064 MOD-97-10 checksum.

This guide explains the layout, the arithmetic, and what “valid” really means. Prefer public sample IBANs—a correct checksum is not proof that an account exists or that you may credit it. Practice offline with the IBAN validator.

Anatomy of an IBAN

Part	Length	Example (`GB82 WEST 1234 5698 7654 32`)
Country code	2 letters	`GB`
Check digits	2 digits	`82`
BBAN	Rest (country-defined)	`WEST12345698765432`

Two common spellings:

Electronic form: no spaces — GB82WEST12345698765432
Print format: groups of four for humans — GB82 WEST 1234 5698 7654 32

Spaces and case are ignored for validation; tools uppercase A–Z and strip whitespace first. Structure must match CC + two digits + alphanumeric BBAN. Absolute ISO bounds are 15–34 characters (electronic form).

Country lengths (the first filter)

Each participating country publishes a fixed electronic length for its IBANs (via the SWIFT IBAN registry). Germany is always 22, the Netherlands 18, the UK 22, France 27, and so on. A string that claims DE but has 18 characters fails before you bother with checksum math.

Country	Code	Typical length
Germany	DE	22
United Kingdom	GB	22
Netherlands	NL	18
France	FR	27
Norway	NO	15
Malta	MT	31

Unknown country codes still have a global 15–34 window, but you lose the registry length check. Length alone never proves a BBAN is a real bank/branch/account—only that the string matches the country’s expected size.

MOD-97-10 checksum (ISO 7064)

Valid IBANs satisfy: after a fixed rearrangement and letter→digit mapping, the big integer is congruent to 1 modulo 97.

Steps

Take the electronic IBAN (uppercase, no spaces).
Move the first four characters (country + check digits) to the end.
Replace each letter with two digits: A = 10, B = 11, …, Z = 35 (same alphabet idea as base conversion through 36). Digits stay as themselves.
Interpret the result as a large decimal integer and compute N mod 97.
The checksum passes if and only if the remainder is 1.

Because N can be dozens of digits, implementations process the digit string in chunks (for example nine digits at a time) while carrying the running remainder—same idea as long division, whether you use BigInt or careful string math.

Computing check digits

Given country code CC and BBAN only:

Build a provisional IBAN with check digits 00: CC00 + BBAN.
Run MOD-97 on that provisional string → remainder r.
Check digits = 98 − r, zero-padded to two digits (01 … 97).

That is how issuers (and local tools) fill the two digits so a finished IBAN yields remainder 1.

Tiny walk-through (structure)

For GB82WEST12345698765432:

Rearrange → WEST12345698765432GB82
Expand letters (W→32, E→14, …, G→16, B→11) into one long digit string.
… mod 97 === 1 → checksum OK (and length 22 matches GB).

Flip the check digits to 00 and the remainder stops being 1—a classic invalid sample for UI demos.

What “valid” actually proves

Result	Means	Does not mean
Length matches registry	Country size rule satisfied	Account is open or funded
MOD-97 remainder = 1	Check digits fit the BBAN	Bank will accept a credit
Both pass (“valid IBAN”)	Strong typo / transcription filter	KYC, ownership, or SEPA reachability
Remainder ≠ 1	Likely mistype or wrong digits	Fraud by itself
Wrong length for country	String is not a well-formed IBAN for that CC	Which character was mistyped

MOD-97 catches many single-character errors and some transpositions. It does not authenticate a payment rail, look up the account at a bank, or replace sanctions / beneficiary checks. Treat it like the spelling check for bank strings—same spirit as Luhn for cards/IMEIs, different algorithm.

IBAN vs Luhn (and other checksums)

Scheme	Typical use	Rule of thumb
IBAN MOD-97	Bank account numbers (ISO 13616)	Rearrange + A=10…Z=35; remainder 1
Luhn (mod-10)	Cards, IMEI, some IDs	Double every second digit from the right
GS1 barcode checks	EAN/UPC	Alternating ×3 / ×1 weights

Do not run Luhn on an IBAN or MOD-97 on a PAN. Wrong algorithm → false “invalid” and wasted debugging.

Safe practice tips

Prefer documented sample IBANs (Wikipedia, bank test docs, sandbox fixtures) over live customer data.
A green checksum is format hygiene, never authorization to send money.
Keep experiments local when strings might be sensitive—see why local-only matters.
Bulk lists (one IBAN per line, # comments OK) help QA fixture files without uploading spreadsheets.

Try it locally

On the IBAN validator:

Paste a single IBAN (spaces OK) or load a public example → see print/electronic form, country, BBAN, length vs expected, and MOD-97 remainder.
Use bulk list mode for one-per-line checks and copy TSV for spreadsheets.
Use check digits mode with country code + BBAN to compute the two digits, then validate the result.

Nothing leaves your device—the same privacy model as the rest of LocalTools.