IBAN & SWIFT Validator: four checks, one verifier

An IBAN like DE89 3704 0044 0532 0130 00 looks like noise until you realise every character is there for a reason. Two letters tell you the country. Two digits tell you the modulo-97 checksum. The rest is the domestic account number, padded to the country’s required length. SWIFT/BIC codes are shorter — eight or eleven characters — but the same pattern holds: every field maps to a piece of the institution’s identity, and a single wrong digit means the payment bounces back three days later, not three seconds.

Validating these identifiers by hand is possible, but it is the kind of work you automate on day one of any cross-border workflow. The IBAN & SWIFT Validator on Elysia Tools handles both formats in one pass, breaking each value into its structural parts and flagging the precise reason a code fails before it ever reaches a real payment rail.

What an IBAN actually is

The International Bank Account Number was introduced by the European Committee for Banking Standards in 1997 and is now used in 80+ countries. It is not a replacement for a domestic account number — it is a wrapper. A German IBAN still contains the old BLZ (Bankleitzahl) and account number inside it; a Spanish IBAN contains the old CCC (Código Cuenta Cliente). The wrapper simply adds the country code, the two check digits, and enough leading zeros to make the whole thing a fixed length for that country.

Length is the most common source of validation failures. A UK IBAN is 22 characters. Norway’s is 15. Lebanon’s is 28. A length check alone catches a meaningful fraction of typos, and it is the first thing any validator runs.

The mod-97 checksum in 30 seconds

After the country code, the two check digits encode a mod-97 of the rest of the number. The procedure is the kind of thing that looks strange on paper but is fast mechanically:

1. Move the four leading characters (country code + two check digits) to the end of the string.
2. Convert every letter to a number: A=10, B=11, …, Z=35.
3. Treat the result as one big integer and compute it mod 97.
4. If the result is 1, the IBAN is valid. Anything else means at least one digit is wrong.

The reason mod-97 is used instead of mod-10 (like Luhn) or mod-11 (like ISBN-10) is that 97 is the largest prime below 100, which gives the checksum enough entropy to detect nearly all single-digit errors and most transposition errors. A 22-character IBAN has roughly 138 bits of information, and mod-97 catches almost every common typo in that space.

What a SWIFT/BIC code is

SWIFT codes (technically BIC — Business Identifier Code) identify the institution, not the account. The same bank has the same SWIFT code across all of its accounts, and the same SWIFT code is used by every sender who wants to route a payment there. There are two registered lengths:

• 8 characters — bank code (4) + country code (2) + location code (2). This is the most common form.
• 11 characters — the same 8 plus a 3-character branch identifier. Use the 11-character form when you need to reach a specific branch; the 8-character form usually routes to the bank’s head office.

A real SWIFT code: DEUTDEFF is Deutsche Bank’s head office in Frankfurt. The full 11-character form for the same institution is DEUTDEFF500, where 500 identifies a specific branch. The “passive” branch code XXX is reserved for the head office when you only have 8 characters.

Country codes, location codes, and the silent trap

SWIFT’s two-letter country code is the same ISO 3166-1 alpha-2 you would expect. The location code is two alphanumeric characters that identify a city or district inside that country. The trap is that the location code does not have to be meaningful — it is just whatever SWIFT registered when the bank joined the network in 1985. DEUTDEFF has FF for Frankfurt because someone at Deutsche Bank typed FF. There is no rule that says LONDON banks must have a LO location code; you can find a UK bank with the location code 2V.

This is why a length check and a country-code check are necessary but not sufficient. The only authoritative test is to send a test payment and confirm the receiving bank credits it — anything else is best-effort validation.

Common validation traps

Five patterns account for almost every IBAN or SWIFT code that fails in production:

1. Spaces and dashes in the input. Most systems accept either DE89370400440532013000 or the human-readable DE89 3704 0044 0532 0130 00. A naive length check on the dashed form will reject the spaced form even though they encode the same account. Strip whitespace and uppercase before you run any structural check.
2. Lowercase vs uppercase. IBANs and SWIFT codes are case-insensitive by spec, but some parsers treat them as case-sensitive strings and trip on de89 instead of DE89. Always uppercase the input first.
3. Wrong country in the wrong place. A GB prefix on a 27-character string is a UK IBAN. A GB prefix on a 22-character string is a typo — there is no UK IBAN of that length. The country code and length must agree.
4. Trailing zeros that should not be there. Many IBANs pad with leading zeros to hit the country length. FR1420041010050500013M02606 has 00 after the bank code; some validators strip them and break the mod-97 check. Do not strip leading zeros before you compute the checksum.
5. Live vs test IBANs. Some sample collections (and a few online generators) publish IBANs that pass mod-97 but are not assigned to any real account. Use the IBAN & SWIFT Code Samples on Elysia Tools for test data, and route any real transfer through your bank’s confirmation channel before you treat a result as final.

Putting it all together

The shortest correct way to validate an IBAN or SWIFT code is to (a) strip whitespace and uppercase, (b) check length against the country code, (c) compute mod-97 for IBANs, (d) verify the 8 or 11 character structure for SWIFT/BIC. Any validator that skips one of these steps will accept some real-world inputs it should reject, or reject some it should accept.

The IBAN & SWIFT Validator runs all four steps and surfaces the specific reason a value fails — wrong length, bad checksum, unrecognised country prefix, malformed branch identifier. If you need test data to drive the validator, the IBAN & SWIFT Code Samples hub on Elysia Tools gives you valid IBANs and SWIFT/BIC codes from 30+ countries, and a text-with-sensitive-data collection if you want to validate extraction against realistic bank-card and account-number fields. Run your test data through the validator first, and you will catch the bad-IBAN class of bug long before it reaches a payment rail.