Reader question: An IBAN can contain letters, country-specific bank identifiers and a long account string. How can two check digits detect many typing mistakes with a calculation simple enough to run almost anywhere — and what does a successful checksum actually prove?
The short answer is modular arithmetic. An IBAN is rearranged, letters are converted to numbers, and the resulting digit string is tested modulo 97. A correctly formed IBAN produces remainder 1. The same arithmetic can be performed one digit at a time, so software never needs to store the full converted number as an ordinary machine integer.
That makes IBAN validation a useful miniature lesson in algorithm design: a small invariant can protect a much larger data object. But the protection has a precise boundary. A checksum can detect data-entry corruption. It cannot prove that an account exists, belongs to the intended person, is open, can receive a payment, or is safe from fraud.
What this page owns — and what it does not
This article owns the mathematics of IBAN structure and checksum validation. It does not replace the surrounding pages on ISO 20022 message validation, cross-border payment routing, or transaction reconciliation. Those systems answer different questions after or around identifier validation.
It is also not banking advice and not a payment instruction. Never infer from “checksum valid” that money should be sent.
The structure before the algorithm
ISO 13616 defines the International Bank Account Number as an international identifier designed for automated processing. At a high level an IBAN contains:
- a two-letter country code;
- two decimal check digits; and
- a country-specific Basic Bank Account Number, or BBAN.
The BBAN can contain bank, branch and account components whose positions and lengths vary by country. That matters because a checksum is only one layer of validation. Software should first ask whether the country participates in the IBAN system and whether the length and permitted character pattern match the current national format in the official registry.
As of June 2026, Swift’s public IBAN Registry was at Release 102. That is a reminder that format metadata is maintained data, not a timeless constant that should be hard-coded and forgotten.
The validation algorithm
For an IBAN written schematically as:
CCkkBBBB…
where CC is the country code, kk the two check digits and BBBB… the BBAN, the standard validation idea is:
- remove presentation spaces and normalise letters consistently;
- check the country-specific length and allowed character pattern;
- move the first four characters to the end;
- replace letters by decimal values A = 10, B = 11, …, Z = 35;
- interpret the resulting decimal sequence modulo 97;
- accept the checksum condition only if the remainder is 1.
The important word is modulo. We do not need the full giant number. We only need its remainder after division by 97.
Why rearranging the first four characters matters
The country code and check digits occur at the front for human and data-format convenience, but the MOD 97-10 calculation treats them as if they were at the end. For validation:
CCkkBBBB… → BBBB…CCkk.
For check-digit generation, the two check positions are temporarily replaced by 00, the same rearrangement and conversion are applied, and the check value is calculated from the resulting remainder.
If the remainder for the zeroed version is r, the two-digit check value is constructed from 98 − r, formatted as two decimal digits. The complete identifier is then designed to satisfy the remainder-1 condition.
The mathematics of the streaming remainder
A naive implementation might convert the whole alphanumeric IBAN into a decimal integer containing dozens of digits and then ask for that integer modulo 97. That can overflow fixed-width integer types.
The better algorithm uses the fact that modular arithmetic is compositional. Suppose the remainder after reading some prefix is r. If the next decimal digit is d, then the new remainder is:
r′ = (10r + d) mod 97.
This works because appending a decimal digit multiplies the existing number by 10 and adds the new digit. Reducing modulo 97 after every step does not change the final remainder.
If a letter has already been converted to a two-digit value such as 10 for A or 35 for Z, its two digits can simply be processed one after another. An implementation can therefore validate an IBAN using a remainder that is always between 0 and 96, regardless of how long the converted digit stream is.
A proof sketch of why chunking works
Let a processed prefix represent integer N, and let a new block contain k decimal digits representing B. Concatenating the block gives:
N′ = 10kN + B.
If N ≡ r (mod 97), then:
N′ ≡ 10kr + B (mod 97).
So the algorithm may retain only r. This is a general computational pattern: when a later decision depends only on a remainder, the remainder is a sufficient state variable for the prefix.
Inputs and outputs
A robust validator needs more than the visible string. Its inputs include:
- the candidate IBAN string;
- the current IBAN country-format registry;
- normalisation rules for spaces and case;
- permitted character constraints;
- country-specific expected length; and
- the MOD 97-10 checksum rule.
Useful outputs should be more informative than a single true/false value. A diagnostic validator can distinguish:
- unknown or unsupported country code;
- wrong national length;
- illegal character;
- checksum failure;
- checksum success; and
- validation not attempted because registry data are unavailable or stale.
This separation matters operationally. “Wrong length” and “valid format but bad checksum” are different defects.
What evidence supports confidence in an implementation?
Evidence for confidence includes agreement with official published test examples, passing country-format cases from the current registry, correct generation followed by successful re-validation, consistency between streaming and arbitrary-precision implementations, and mutation tests in which deliberately changed characters are rejected as expected.
Evidence against confidence includes a validator that accepts an impossible country length, produces different results depending on whether presentation spaces are present, silently drops non-ASCII characters, fails on leading zeroes, disagrees with an independent MOD 97 implementation, or accepts its own generated check digits but fails external standard examples.
What MOD 97-10 is protecting against
ISO/IEC 7064 specifies check-character systems intended to protect identifiers against human copying and keying errors. MOD 97-10 is a pure check-character system used in several financial identifiers. The checksum spreads information from the entire converted string into a two-digit condition, so changing one part will usually disturb the final remainder.
This is why the system is much stronger than merely checking whether the account number has the right number of characters. A malformed value can have exactly the expected length and still fail the arithmetic invariant.
But a checksum is not cryptography
This distinction is essential. MOD 97-10 is public, deterministic and easy to recompute. Anyone who deliberately changes an identifier can calculate new check digits. Therefore the checksum is not designed to establish authorship, secrecy, authenticity or resistance to malicious tampering.
A valid checksum means roughly: this string is arithmetically consistent with the IBAN check-digit rule and, if separately checked, with a national format.
It does not mean:
- the account exists;
- the bank has confirmed the account;
- the named recipient controls the account;
- the account can receive the intended currency or payment type;
- the account is not frozen or closed;
- the payment is legitimate; or
- the payer is protected from an authorised-push-payment scam.
A counterexample: perfectly valid, completely wrong recipient
Imagine a payer intends to send money to account A but accidentally pastes account B, which is also a real, correctly formed IBAN with valid check digits. The checksum succeeds because B is internally consistent. Yet the payment instruction is wrong relative to the payer’s intention.
This counterexample falsifies a common overclaim: checksum validity is not recipient verification.
Modern payment systems increasingly add separate name-to-account verification services precisely because syntactic and arithmetic validity do not answer the identity question.
Another counterexample: stale country metadata
Suppose the MOD 97 remainder is correct but the validator uses an outdated table of country lengths or BBAN patterns. It could reject a newly introduced legitimate format or accept a structure whose registry definition has changed.
The algorithm is mathematically correct yet operationally wrong because one of its inputs is stale. This illustrates a wider lesson in computational finance: correct code plus stale reference data still gives the wrong system answer.
Diagnostics for a good validator
- Registry check: verify country membership, length and national pattern against the current official registry.
- Round-trip check: generate check digits for a test BBAN, build the IBAN, then validate it independently.
- Mutation check: alter one character in standard test cases and confirm rejection.
- Leading-zero check: ensure account components beginning with zero are preserved as strings rather than coerced to integers.
- Large-input check: compare a streaming remainder with an arbitrary-precision calculation.
- Normalisation check: distinguish harmless presentation spaces from illegal embedded characters; do not silently delete arbitrary punctuation.
- Country-boundary check: test minimum and maximum expected lengths and invalid country codes.
- Determinism check: identical normalised input and registry version should produce identical output.
Implementation weak links
Integer overflow. Converting the entire expanded string to a machine integer can fail even though the mathematics is simple. Streaming modulo avoids the problem.
String-to-number coercion. Treating account components as numbers can erase leading zeroes.
Over-normalisation. A validator that deletes every unfamiliar character may transform a bad input into a different valid one. Normalisation should be explicit and narrow.
Registry drift. Country rules are reference data and require version control.
Boolean-only diagnostics. “False” without a reason makes testing and exception handling harder.
Security overclaim. Calling a checksum an authentication mechanism creates a dangerous conceptual error.
What would falsify confidence?
Confidence in the validator should be withdrawn if it disagrees with official registry examples; if a known-valid identifier fails after harmless presentation normalisation; if a known-invalid checksum passes; if streaming and independent big-integer implementations disagree; if the implementation modifies input silently; or if the deployed country-format dataset cannot be traced to a known registry release.
Alternatives solve different problems
A national bank-account validator may apply domestic branch and account rules in addition to the IBAN checksum. A payment-message schema validates the structure of an entire instruction. A bank-directory or routing service identifies institutions and reachable rails. Verification-of-payee services compare an account identifier with a claimed recipient name. Fraud systems assess behavioural risk. Cryptographic message authentication protects integrity and provenance.
None of these is a substitute for MOD 97-10, and MOD 97-10 is not a substitute for them. They are layered checks with different failure models.
How this connects to the surrounding knowledge estate
The IBAN algorithm is a clean example of a local invariant inside a much larger payment system. After the identifier passes its own structural and arithmetic checks, an ISO 20022 validation engine may still reject the message for semantic or business-rule reasons. A correspondent-banking route algorithm may still need to find a viable path. A payment system still needs queues, settlement rules and finality. And reconciliation still has to prove that the accounting records agree afterwards.
Verification and update triggers
Preserve the validator version, normalisation rules, MOD 97 implementation, test suite and IBAN registry release used. Re-test when Swift publishes a new registry release, when a country joins or changes its national IBAN structure, when input-normalisation libraries change, when payment channels start accepting new character representations, or when a production discrepancy appears between local validation and a bank or network validator.
Primary and high-quality references
- ISO, ISO 13616-1:2020 — Financial services — International bank account number (IBAN) — Part 1: Structure of the IBAN. ISO confirmed this edition as current in 2026.
- ISO, ISO/IEC 7064:2003 — Check character systems, which specifies the family containing MOD 97-10.
- Swift, Standards resources and IBAN Registry; Release 102 was listed in June 2026.
- Central Bank of the UAE, IBAN overview and standard structure, a public central-bank explanation of country code, check digits and BBAN structure.
Educational boundary: This article explains identifier mathematics and data-quality controls. It does not validate a reader’s real account, confirm a recipient, instruct a payment, or provide personalized financial advice.