Guide
How IBAN Checksum Validation Works
Learn the MOD97-10 idea behind IBAN checksum validation in plain English, including normalization, rearrangement, letter conversion, and chunked calculation.
Who needs to interpret a MOD97 result carefully
Developers, QA testers, finance operations teams, and curious users who want to understand IBAN format-check results.
Worked MOD97 sequence
| Step | Value or action | Expected observation |
|---|---|---|
| Normalize | GB82WEST12345698765432 | Spaces are removed and letters remain uppercase |
| Rearrange | WEST12345698765432GB82 | The first four characters move to the end |
| Convert letters | W=32, E=14, S=28, T=29, G=16, B=11 | Letters become their numeric values |
| Compute remainder | Apply MOD97 to the numeric sequence | A structurally valid checksum produces remainder 1 |
The checksum idea
The IBAN checksum is designed to catch many typing mistakes. It does this by converting the IBAN into a numeric sequence and checking whether the MOD97-10 remainder has the expected result.
The plain-English steps
An IBAN format checker normalizes the input, checks the country length, moves the first four characters to the end, converts letters to numbers, and calculates the remainder.
- Remove spaces and hyphens, then uppercase letters.
- Check that the country code and length are supported.
- Move the country code and check digits to the end.
- Convert A to 10, B to 11, through Z to 35.
- Run MOD97-10 and expect a remainder of 1.
Why chunked calculation is used
The converted numeric sequence can be too long for safe full-number conversion. A chunked MOD97 calculation processes smaller pieces so the full IBAN is never converted into one large Number.
Why implementations process the number in chunks
The converted sequence can exceed ordinary integer limits in some programming languages. A safe implementation carries a remainder through manageable chunks instead of parsing the whole value as one floating-point number. The mathematical result is the same, and the technique avoids precision loss. Test cases should include known passing and intentionally altered values so regressions are visible. It still tests only checksum consistency, not whether the underlying account is real or available for payment.
Boundary case: the wrong complete value also has a valid checksum
MOD97 is designed to detect many transcription errors, but it does not remember which account the sender intended. If an invoice contains a different complete IBAN whose own check digits are consistent, the remainder can still be 1. That outcome is not a checksum failure; it is a source or recipient-verification problem. Keep a checksum pass in its mathematical role and compare the complete value with independently confirmed payment instructions before treating it as usable.
Practical checksum example
For the example DE89 3704 0044 0532 0130 00, the checker uses DE as the country code, 89 as the check digits, and the remaining BBAN characters for the MOD97-10 process.
- Normalize to: DE89370400440532013000
- Move first four characters to the end before numeric conversion.
- Convert letters such as D and E into numeric values.
- A checksum-passing IBAN produces MOD97 remainder 1.
What a passing checksum still leaves unverified
Format checks only. This guide does not confirm account existence, ownership, bank reachability, or payment success. Read the detailed disclaimer for the full limitation list.
- Checksum validation does not catch every possible mistake.
- A passed checksum does not confirm account existence.
- A passed checksum does not confirm account ownership.
- A passed checksum does not confirm payment readiness or payment success.
FAQ
What does MOD97 mean?
It means the format checker checks the remainder after dividing the converted numeric sequence by 97.
Why should the remainder be 1?
The IBAN checksum standard expects a valid rearranged and converted IBAN to produce remainder 1.
Why not use Number for the full converted IBAN?
The converted sequence can be too large for safe full-number handling, so chunked calculation is safer.
Does checksum validation prove the recipient is correct?
No. It only checks the structure and checksum.
Sources and update note
BankCodeKit keeps payment-code checks browser-local and uses local reference data for format and country information. Local IBAN data was reviewed 2026-07-17 against Swift IBAN Registry Release 102 - Jun 2026. Official public source pages are used for reference, but BankCodeKit does not perform live bank, account, sanctions, or payment-network confirmation.
- Swift IBAN Registry Reference information for IBAN structure, country support, and format rules. Local IBAN data reviewed 2026-07-17 against Swift IBAN Registry Release 102 - Jun 2026.
- Swift BIC / ISO 9362 information Reference information for visible Business Identifier Code structure and usage context.
- European Payments Council SEPA scheme countries list Reference information for countries and territories in SEPA scheme scope. Local data reviewed 2026-07-17 against EPC List of SEPA Scheme Countries v8.0, issued 2025-12-24.
Format checks only. This page does not confirm account existence, ownership, bank reachability, or payment success. Read the detailed disclaimer.
Last reviewed: 2026-07-17 Sources: Swift IBAN Registry, Swift BIC / ISO 9362 information, European Payments Council SEPA scheme countries list Reference data is reviewed periodically. BankCodeKit does not perform live bank, account, sanctions, or payment-network confirmation.