Most IBAN validators fail in three predictable places: the country code prefix, the length expectation, and the mod-97 checksum. None of them are exotic edge cases. They are exactly the cases the bank’s payment gateway will reject on Friday afternoon, after your spreadsheet has already emailed a hundred invoices. This guide walks through what a real IBAN check looks like, why regex-only validators miss the silent failures, and how to validate the number your customers actually paste instead of the one you wish they had.
What an IBAN actually contains
An IBAN is not a single identifier. It is a layered string with four parts, each of which has to be right for the payment to clear:
1. Country code (two letters, ISO 3166-1 alpha-2). This is the field that tells you the length and the check-digit algorithm. A number that starts with GB is 22 characters. A number that starts with DE is 22 characters. A number that starts with FR is 27 characters. The country code is the only part of the IBAN that you can use to predict the rest, so any validator that does not look at the first two characters first is going to false-positive on half its inputs.
2. Check digits (two decimal digits). These are computed via mod-97 over the rearranged string and are the IBAN’s own checksum. They are not sequential, not derived from the account number, and not optional. An IBAN with check digits of 00 or 01 or 99 is suspicious because the range of valid check digits is intentionally biased away from the extremes. Most homegrown validators skip this step and rely on length-only checks.
3. Bank identifier (4 to 8 characters). Country-specific. In Germany this is the BLZ (8 digits). In the UK it is the sort code (6 digits). In Spain it is the entidad and sucursal (8 digits). The bank identifier does not have to be globally unique; it is unique only within the country code.
4. Account number (the rest). Country-specific length and allowed character set. Norway uses only digits. Some countries allow alphanumeric. The account number always carries the most failure modes because it is the longest part and the most permissive in formatting.
The IBAN Validator at Elysia Tools handles all four layers in a single pass: country-code resolution, length enforcement against the official registry, mod-97 checksum, and alphanumeric allowance per country.
The three failure modes every regex-only validator misses
If your current IBAN check looks like this, it is wrong:
^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$
That regex says: “starts with two uppercase letters, then two digits, then up to 30 alphanumeric characters.” It will accept GB0000000000000000000000 even though no such IBAN exists, and it will accept FR00000000000000000000000000 even though French IBANs are always exactly 27 characters. Length matters. Country matters. Here are the three silent failures that result.
1. The country code is real but the length is wrong
This is the most common silent failure. A French customer pastes FR76 3000 6000 0112 3456 7890 189 — 23 characters instead of the required 27. A regex validator that only checks character classes returns valid. The bank’s payment gateway returns RC03 (invalid BBAN structure). Your customer gets an email saying “your payment failed,” and you have no idea why.
The official IBAN registry maintained by SWIFT lists the exact length for each country code. GB is 22. DE is 22. FR is 27. ES is 24. IT is 27. NL is 18. BE is 16. The list is not fixed — new countries have been added over the years, and a few have extended their length. A real validator has to look the length up against the registry, not against a hard-coded constant.
2. The mod-97 check digits are mathematically invalid
Every IBAN encodes a checksum in positions 3 and 4. To verify, you move the first four characters to the end of the string, replace every letter with two digits (A=10, B=11, … Z=35), and compute the result mod 97. If the result is 1, the IBAN passes. Anything else fails. This is the same algorithm used in ISO 7064 and it has been the IBAN standard since 1997.
A regex check accepts DE00123456789012345678. A real checksum rejects it because the check digits 00 are not reachable for the trailing portion. Worse, a checksum failure on a real customer IBAN almost always means a typo — and the typo is almost always in the bank identifier, not the account number, because the bank identifier is what staff read off the customer’s form letter.
3. The number was pasted with spaces and they were never stripped
GB82 WEST 1234 5698 7654 32 is one IBAN. GB82WEST12345698765432 is the same IBAN. The difference is whitespace. IBANs are conventionally written in groups of four characters for readability, and the standard explicitly allows whitespace between groups. A validator that does not normalize whitespace first will report the formatted version as invalid.
The same trap applies to hyphens, dots, and uppercase/lowercase mixed. Some banks send IBANs in lower case; some in upper case; some mixed. The standard says uppercase is canonical but the input is never canonical.
Why length-only checks are worse than no checks at all
A length-only check tells you the IBAN is not obviously broken. It tells you nothing about whether the bank can route the payment. Worse, it gives a false sense of safety to anyone using the validator: a green check mark after a length-only validation looks like a confirmation, not a probabilistic filter.
The correct mental model is: IBAN validation is a two-stage process. Stage one is structural (country code present, length correct for the country, character classes allowed). Stage two is mathematical (mod-97 checksum). If stage one fails, you do not need to run stage two. If stage one passes, you must run stage two to get a confident answer.
Run both stages. Run them in this order. Skip stage two only if the input is a partial IBAN that you intend to combine with other data later — for example, a country-code-only field on a country-picker form.
A working IBAN check, in five lines of code
The cleanest minimum-viable IBAN check looks like this:
iban = iban.replace(/\s+/g, '').toUpperCase();
if (!/^[A-Z]{2}\d{2}[A-Z0-9]+$/.test(iban)) return false;
if (iban.length !== LENGTHS[iban.slice(0, 2)]) return false;
const rearranged = iban.slice(4) + iban.slice(0, 4);
const numeric = rearranged.replace(/[A-Z]/g, c => c.charCodeAt(0) - 55);
return mod97(numeric) === 1;
That is the entire algorithm. Five lines. The hard part is not the code — it is keeping LENGTHS up to date as the registry changes. The official SWIFT IBAN registry is the source of truth and is updated whenever a country changes its format. If you are maintaining your own validator, plan for a registry refresh at least once a year.
For interactive validation, the Elysia Tools IBAN Validator bundles the registry lookup, mod-97, and whitespace normalization into a single form. You paste, it tells you whether the number clears, and it shows you the country, length, and check-digit status so you can see exactly which stage failed.
How IBAN validation differs from BIC and SWIFT lookups
IBAN tells you the account. BIC (also called SWIFT) tells you the bank. They are not interchangeable. An IBAN does not contain the BIC. A BIC does not contain the IBAN. A payment needs both: the IBAN says “this account,” and the BIC says “at this bank.”
A real-world SEPA payment on the Single Euro Payments Area uses IBAN-only transfers, but the underlying clearing still routes by BIC. If you have an IBAN and need to know which bank holds the account, you look up the BIC separately. If you have a BIC and need to know which accounts at that bank can receive a transfer, you do not derive that from the BIC alone — you need the IBAN from the payee.
For working samples of valid IBANs and BICs across countries, the IBAN & SWIFT code samples at Elysia Tools give you a quick reference of the format differences you will hit when building or testing a cross-border payment flow.
What to log when an IBAN fails your validator
When a customer’s IBAN fails, log four things: the masked IBAN (first four and last four characters only, the rest replaced with asterisks), the failure stage (length, checksum, country, character class), the country code, and the length as-pasted before whitespace was stripped. The masked IBAN lets support verify what the customer actually entered. The failure stage tells you whether this is a customer typo or a system bug. The country and length together let you spot the “customer pasted their local account number by accident” case, which is more common than you would think.
Do not log the full IBAN. Treat it like a password. IBANs in the wrong hands are a phishing and account-takeover vector, and your logging pipeline is one of the places they leak. The masked form is enough to debug; the unmasked form is a liability.
When a valid IBAN is still a bad payment
A green IBAN check is not the end of the story. The number can be syntactically valid and still reject at the bank. Three cases to expect:
Closed account. The IBAN is correctly formatted but the account has been closed since the number was issued. Common with European business accounts that rotate when a company changes banks. Your validator cannot detect this; the bank will.
Sanctions list. Some banks reject IBANs that match sanctioned entities even when the IBAN itself is well-formed. The check happens at the clearing layer, not the validation layer.
Currency mismatch. SEPA payments require the IBAN to be in the correct euro-zone country. A GB IBAN can still receive SEPA credit transfers, but a CH IBAN (Switzerland) cannot, even though both are technically valid IBAN strings. This is not a syntax issue; it is a clearing-network issue.
For all three cases, the fix is the same: surface the bank’s error message to the customer, do not retry automatically, and let the customer re-enter or contact support. A clean IBAN validator upstream prevents maybe 80 percent of payment failures, but the last 20 percent are not solvable in the validation layer.
Wrapping up
If you are building a payment form that accepts IBANs, run country-code-aware length checks, run mod-97 checksums, normalize whitespace before either check, and treat any “valid” result as a probabilistic green light rather than a confirmation. The IBAN standard is designed so that well-formed numbers route correctly almost all of the time, but the small failure rate you cannot catch at the validator layer will still come back to your support inbox if you do not communicate clearly what the green check means.
For a working reference of country codes, lengths, and valid test IBANs, see the Elysia Tools IBAN & SWIFT code samples. For an interactive validator that runs the full pipeline, see the IBAN Validator. And for everything else in the cross-border-payment-tooling stack, the rest of Elysia Tools covers the adjacent formats and checks you will hit on the way.
