Validate IBAN format, country length, and checksum

This validator normalizes ordinary spaces and hyphens, identifies the country code, checks the official length assigned to that country, and applies the ISO 7064 mod-97 checksum rule. It returns each decision separately, making the result useful both for a person checking one account number and for software deciding whether a payment record is ready for the next stage.

Start with a clean, recognizable IBAN

Paste or send the complete IBAN, including its two-letter country code and two check digits. Spaces used to group characters for readability are accepted, as are hyphens, and the validator removes them before checking the value. Lowercase letters are converted to uppercase in the normalized result. No other punctuation is silently discarded because doing so could hide a copy-and-paste mistake. A structurally usable value must begin with two letters followed by two digits, and every remaining character must be a letter or digit. The response includes the normalized IBAN so an integration can store or compare a consistent representation. It also exposes the country code, actual length, and expected length instead of returning only a vague yes-or-no answer. If the country prefix is not in the supported IBAN registry, the request produces an input error. That distinction matters: an unknown scheme cannot be evaluated reliably and should not be treated as merely a failed checksum. This first stage catches formatting problems before any arithmetic is attempted.

Understand the country-length and mod-97 checks

IBANs do not all have one universal character count. Each participating country defines a fixed length, so a German IBAN has a different expected size from a Norwegian or Maltese IBAN. The validator looks up the length associated with the leading country code and compares it with the normalized value. It then performs the checksum procedure defined for IBAN under ISO 7064: the first four characters move to the end, letters are expanded to their numeric values from A equals 10 through Z equals 35, and the resulting decimal sequence is evaluated modulo 97. A valid checksum leaves a remainder of one. The implementation calculates the remainder incrementally, digit by digit, rather than constructing an enormous integer that could exceed a language's safe numeric range. The response reports `length_valid` and `checksum_valid` independently, then sets `valid` only when both checks pass. A wrong length prevents a checksum pass, keeping the final decision conservative and easy for automated workflows to interpret.

Use validation at the right point in a payment workflow

Run this check when an IBAN enters your system: during form submission, CSV import, beneficiary onboarding, or a final review before a payment instruction is created. A failed result is evidence of a formatting, length, or checksum problem, so it is useful for catching common transcription errors early. It is not proof that the bank account exists, is open, belongs to the named recipient, or can receive a particular transfer. Those questions require bank or payment-provider services and may involve regulated identity checks. Keep the validator's role narrow: reject obviously malformed identifiers, show the specific failed checks, and ask the user to confirm the number from a trustworthy source. The algorithm is deterministic and uses no network, random value, clock, or external lookup during execution, which makes repeated calls reproducible. One API request costs $0.002, while the page can run the same pure validation logic in the browser. Avoid logging full account numbers unless your security and retention policies explicitly require it; validation does not remove the need to protect financial identifiers.