What an IBAN is
An International Bank Account Number (IBAN) is a standardized way to write a national account identifier so cross-border payment systems can route and validate it consistently. In Europe and many other regions, payment forms, invoices, and banking apps ask for an IBAN instead of—or in addition to—older domestic formats.
This guide explains structure and check digits for learning and software testing. It does not help anyone misuse account numbers. Use only accounts you are authorized to work with, and prefer official bank documentation for live payments.
To experiment with format checks on sample or test values, see the IBAN verify tool.
High-level layout
An IBAN is a single string (often shown in groups of four characters for readability) with this conceptual layout:
- Country code — two letters (ISO 3166-1 alpha-2), for example
DE,FR,IT,ES,NL. - Check digits — two digits computed from the rest of the number.
- Basic Bank Account Number (BBAN) — a country-specific domestic part that may include bank codes, branch codes, account numbers, and national check characters.
The overall length is fixed per country but not the same across countries. German IBANs have a different length than French or Italian ones. Validators therefore look up expected length by country code before applying deeper checks.
Why check digits exist
Typing or OCR errors in long account strings are costly. The IBAN check digits catch many single-character mistakes and some swaps before a payment is submitted. They are not a secrecy mechanism and do not prove that an account is open, funded, or owned by a particular person—they prove that the string is well-formed according to the checksum algorithm.
The MOD-97 check (conceptual)
The international check uses ISO 13616 / MOD-97:
- Move the first four characters (country code + check digits) to the end of the string.
- Replace letters with numbers (A = 10, B = 11, …, Z = 35).
- Interpret the result as a large integer and compute that integer modulo 97.
- A valid IBAN yields remainder 1.
Because the integer can be very long, implementations use chunked modular arithmetic rather than storing the whole number as a single native integer in languages with fixed-width ints.
When you write tests, include known-valid fixtures from public documentation and known-invalid strings that fail length, character set, or checksum checks.
Country-specific BBAN patterns
After the country code and check digits, each country defines its BBAN:
- Some include an explicit national bank identifier.
- Some include a branch or sort-code analogue.
- Some embed a domestic checksum separate from the IBAN check digits.
- Character sets may be numeric only or alphanumeric depending on the national scheme.
Software that only verifies the international MOD-97 check will accept structurally checksum-valid numbers even if the national bank code is not issued. Full routing validation requires national rules or directory services beyond the IBAN string alone.
Formatting and storage
Display. Grouping in fours improves readability (DE89 3704 0044 0532 0130 00 style). Spaces are not part of the electronic value.
Storage. Persist the compact form: uppercase alphanumeric characters without spaces. Normalize user input by stripping spaces and converting letters to uppercase before validation.
Paper forms. People often keep spaces; your input layer should tolerate them.
SEPA context (educational)
Within the Single Euro Payments Area, IBANs (and often BICs) identify accounts for euro credit transfers and related schemes. The IBAN’s role is standardized identification; payment success still depends on bank systems, mandates, balances, and compliance checks that sit outside the format itself.
Implementing validation in applications
A practical checklist:
- Reject empty input.
- Normalize case and spacing.
- Confirm allowed characters (A–Z, 0–9).
- Read the country code; look up expected total length.
- Run MOD-97.
- Optionally apply national BBAN structure checks if you maintain those patterns.
- Return stable error reasons (
invalid-length,invalid-checksum,unsupported-country) for UI mapping.
Do not silently “fix” a near-miss account number in payment software; ask the user to confirm with their bank.
Testing without live accounts
Developers need fixtures. Strategies that stay appropriate:
- Use officially published examples from standards bodies or bank developer portals labeled as samples.
- Generate checksum-valid test vectors in isolated test environments where your organization permits.
- Prefer dedicated test credentials from payment providers’ sandbox systems for integration tests.
Never harvest or redistribute real customer IBANs from production logs into public repositories.
Common user-facing errors
- Mixing up
0andO, or1andI, in handwritten forms. - Pasting an IBAN with a leading BIC or account-holder name.
- Using a domestic account format where an IBAN is required (or the reverse).
- Assuming a correct checksum means a payment will succeed.
Clear UI copy should separate “format looks valid” from “payment completed.”
Privacy and security
IBANs identify accounts. Treat them as sensitive financial data in logs, analytics, and support tickets. Mask all but the last few characters in UIs where full disclosure is unnecessary. Browser-side verification can keep a string on-device for format checking; that still does not make screenshots or copied values safe to share.
Related tooling
Format verification helpers such as IBAN verify are educational and operational aids for structure checking. Pair them with bank-grade APIs when you must confirm account existence or name matching under regulated payment flows.
Summary
European IBANs prepend a country code and two check digits to a national BBAN. Length depends on country; MOD-97 catches many transcription errors; national structure and live banking systems go further. Learn the layout to build careful validators and to read payment forms confidently—always within authorized, lawful use of account identifiers.