How to Validate an IBAN Programmatically

Validating an IBAN programmatically requires normalizing user input, applying country-specific length and format rules, and running the MOD-97 checksum algorithm — steps that are easy to get wrong when IBAN schemes change or users paste values with spaces and mixed case. The IBAN Validator API handles these checks for IBANs from 70+ countries, returning structured JSON you can branch on in onboarding forms, payment rails, and bulk import jobs.

This guide walks through normalization, MOD-97 checksum logic, production integration patterns, and error handling — with real request examples from IdenticAPI's RapidAPI-hosted IBAN validator.

IBAN structure in brief

An International Bank Account Number (IBAN) encodes:

1. Two-letter country code (ISO 3166-1 alpha-2)
2. Two check digits (MOD-97 checksum)
3. BBAN (Basic Bank Account Number) — country-specific length and format

Example (Germany):

DE89370400440532013000
││└─ BBAN
│└── check digits (89)
└─── country (DE)

Users often submit DE89 3704 0044 0532 0130 00 or lowercase variants. Your pipeline must strip whitespace, uppercase, and validate before calling payment providers.

Deep dive on the two validation stages: IBAN Validation: Format Check vs Checksum Validation.

Step 1: Normalize input

Before validation:

function normalizeIban(raw) {
  return raw.replace(/\s+/g, "").toUpperCase();
}

Reject empty strings early. Optionally reject characters outside [A-Z0-9] before API calls to save quota on obviously invalid paste.

Step 2: Format and length rules

Each country defines allowed IBAN lengths (for example, DE is 22 characters total). A validator must:

• Confirm the country code is supported
• Confirm total length matches the scheme
• Validate BBAN structure where country rules apply

Maintaining this table in-house is workable for one country; supporting 70+ countries is why teams adopt a dedicated validation API — see Validation API vs Building In-House.

Step 3: MOD-97 checksum

The check digits are computed with MOD-97-10 (ISO 13616):

1. Move the first four characters to the end: 370400440532013000DE89
2. Replace letters with numbers (A=10 … Z=35)
3. Compute the entire number modulo 97
4. Valid IBANs produce remainder 1

Invalid checksums indicate typos — even when the string "looks" structurally correct.

The IdenticAPI IBAN Validator applies country rules and MOD-97 verification, returning explicit fields such as checksum_valid in the response payload.

IdenticAPI IBAN Validator integration

Legacy utility APIs authenticate via RapidAPI. Subscribe on RapidAPI to obtain your API key. Replace YOUR_RAPIDAPI_KEY with your subscription key.

cURL example

curl -X GET "https://iban-validator3.p.rapidapi.com/validate?iban=DE89370400440532013000" \
  -H "X-RapidAPI-Key: YOUR_RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: iban-validator3.p.rapidapi.com"

Example response

{
  "iban": "DE89370400440532013000",
  "valid": true,
  "country": "DE",
  "checksum_valid": true
}

Product page with Node.js and Python samples: IBAN Validator API.

Node.js example

const response = await fetch(
  "https://iban-validator3.p.rapidapi.com/validate?iban=DE89370400440532013000",
  {
    headers: {
      "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
      "X-RapidAPI-Host": "iban-validator3.p.rapidapi.com"
    }
  }
);

const data = await response.json();
console.log(data);

Python example

import requests

response = requests.get(
    "https://iban-validator3.p.rapidapi.com/validate?iban=DE89370400440532013000",
    headers={
        "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
        "X-RapidAPI-Host": "iban-validator3.p.rapidapi.com",
    },
)
print(response.json())

Store RAPIDAPI_KEY in environment variables or a secrets manager — not in client-side code or public repositories.

Branching on API responses

Recommended server-side flow:

User submits IBAN
    → normalize locally
    → call IBAN Validator API
    → if valid === false: show field error, do not proceed
    → if valid === true: continue onboarding / store tokenized reference

Important limitation: Format and checksum validation do not confirm the account exists, is open, or accepts SEPA credits. Your core banking or payment provider performs account verification. The IBAN API catches structural errors before expensive downstream calls.

For mixed text that may contain IBAN-like strings (chat logs, LLM prompts), use PII & Secrets Detection for full-text scanning — the dedicated IBAN validator is for isolated field validation.

Error handling and resilience

Production integrations should define behavior for:

Issue parallel requests for bulk imports within your RapidAPI plan limits, or queue server-side workers for large CSV jobs.

Testing strategy

Use documented valid test IBANs from your target markets — the German example above is widely used in integration tests. Also test:

• IBANs with spaces and lowercase input (normalization)
• Wrong check digits (should fail checksum)
• Unsupported or wrong-length country codes
• Empty and partial paste during form autofill

Never use real customer IBANs in unit test fixtures checked into git.

When to validate programmatically

Common fintech and SaaS workflows:

• SEPA payment validation before initiating transfers
• Banking SaaS onboarding and KYC data capture
• Invoice and e-invoicing compliance checks
• Bulk customer record normalization during migrations

Compare build vs buy tradeoffs in Validation API vs Building Validation In-House.

Security notes

• Call the validator from your backend — not browser JavaScript exposing RapidAPI keys
• Log validation outcomes (valid/invalid, country) — avoid retaining full IBAN in verbose logs if policy requires minimization
• Pair field validation with authorization — validating an IBAN does not prove the submitter owns the account

Quick reference

Programmatic IBAN validation is a solved infrastructure problem when you use country-aware rules and MOD-97 verification. Integrate the IBAN Validator API, handle errors explicitly, and treat valid: true as "structurally consistent" — not "payment guaranteed."