IBAN Validation Is Two Different Jobs: The Mod 97 Check and Everything It Cannot Prove

What each layer actually checks

Layer one is structure: the country code has a fixed IBAN length, the national bank code portion sits in the right positions for that country, and the characters allowed are respected. Layer two is the mod 97 checksum itself, computed by moving the first four characters to the end, converting letters to numbers, and checking the remainder is one. Layer three, the one format libraries do not provide, is registry truth: does that bank code correspond to a live institution and branch in the national registry, and is it the institution the payee named. Layer four is the account itself, existence and name, which only a bank facing check, a confirmation of payee scheme where available, or a small verification payment can address. Most payment errors that reach a finance team's incident log live in layers three and four, in systems that validated layers one and two and reported the IBAN as verified.

Country quirks defeat generic code

IBAN formats are national dialects under an international frame. Lengths run from fifteen characters to well over thirty. Some countries embed a second, national check digit inside the BBAN with its own algorithm, so an IBAN can pass mod 97 and still contain an invalid domestic account number. Others are migrating bank codes through mergers, leaving validly formatted IBANs pointing at codes that now route elsewhere. A validation library that has not been maintained against current national specifications and bank registries will pass all of these cheerfully. Ask a vendor when their registry data was last refreshed and which national checks they implement. The answer separates serious payment tooling from a regex with a pricing page.

Where to validate in the payment flow

Validate at entry, in the payee setup screen, with specific feedback: this bank code is not recognised, this length is wrong for the country, rather than a flat invalid message that invites the user to guess. Then validate again at file generation, because payee records age and registries change between setup and payment. For first payments to a new payee above a threshold, add the human or scheme based name check before release, not after a failed payment or a successful payment to the wrong account. Recovery of a misdirected cross border payment is slow, uncertain, and priced in correspondent bank fees. Every control in this flow is cheaper than one recovery attempt.

Keep the audit trail a payment deserves

Log the validation result, the library or service version, and the registry date with the payee record, and log any override where a user or operator proceeded despite a warning. Overrides are sometimes right, a brand new bank branch, a registry lagging a merger, and the log is how a team later distinguishes a justified override from the pattern that precedes a fraud. Internal fraud and payment diversion both love an unlogged override. Make the legitimate path easy, make the override visible, and review override reports monthly. Validation is arithmetic. Trustworthy payment operations are arithmetic plus memory.

Keep reading

Related guides on this site: Address Validation and the Unit Designator Problem Disposable Email Domains at Signup: Block, Flag, or Allow? https://validatorwall.com/blog/index.md.

Frequently asked questions

How does the IBAN mod 97 check work?

The first four characters are moved to the end, letters are converted to numbers, and the resulting number divided by 97 should leave a remainder of one. It detects most typing and transposition errors.

Does a valid IBAN mean the account exists?

No. Format and checksum validation prove the string is well formed and consistent. They do not prove the account exists, is open, or belongs to the named payee.

What is a BBAN?

The Basic Bank Account Number: the domestic part of an IBAN after the country code and check digits, containing the national bank code and account number in a country specific format.