OpenIBAN IBAN Validator — Bulk IBAN Checker

What this Actor scrapes

A customer hands us a list of IBANs — mixed formatting, mixed countries — and we return one row per IBAN: checksum validity, bank-code validation result, bank name/BIC where the free openiban.com directory has it, and the raw messages[] explaining which of two failure modes hit (bad checksum vs. unresolved bank code). Built for a recurring fintech/payments/AP-AR/KYC batch job against a whole customer list, not a one-off lookup: one bad IBAN never fails a 5,000-row batch.

What we handle for you

• 🧾 Any common IBAN format, one clean value — glued (DE89370400440532013000) or spaced (DE89 3704 0044 0532 0130 00) both normalize before we ever call openiban.
• 🧱 Bounded, polite concurrency — openiban is a free, shared keyless service, so we cap in-flight requests and back off automatically on 429/5xx instead of hammering it.
• ✅ Clean negatives are not errors — an invalid IBAN is a normal, useful answer. Every entry — valid, cleanly invalid, or unparseable — lands as its own row with a clear status, so one bad IBAN never fails your whole batch.
• 🔍 Two failure modes, disambiguated — messages[] passes through verbatim so you can tell a bad checksum apart from an unresolved bank code, instead of a single flattened boolean.
• 🧊 Typed, validated dataset rows — Pydantic-checked, one row per requested IBAN, every time — the row count you get back always matches the row count you sent in.
• 💰 Pay-Per-Event pricing — priced for volume, not per-lookup margin. You always know what a batch costs before you run it.

Use cases

• Payment/AP-AR teams — validate a beneficiary's IBAN before a wire transfer to avoid a bounced payment.
• Compliance/KYC onboarding — batch-check IBANs on file as part of a customer onboarding sweep.
• ERP/accounting pipeline enrichment — attach bank name and BIC to existing vendor or customer records.
• Data-quality cleanup — find and flag malformed IBANs sitting in a spreadsheet or CRM export.

Input

Paste this into the Apify Console, or send it as the run input over the API. Proxy settings are on by default; you rarely need to touch them.

{
  "ibans": [
    "DE89 3704 0044 0532 0130 00",
    "DE89370400440532013001",
    "NL91ABNA0417164300"
  ],
  "maxConcurrency": 3,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}

Output

One row per result, schema-validated before it is written. Export JSON, CSV, Excel or XML from the run, or read it over the API.

ibanvalidbankCodebankNamebicbankCitybankZipbankCodeValidmessagesskippedskipReason

{
  "iban": "DE89370400440532013000",
  "valid": true,
  "bankCode": "37040044",
  "bankName": "Commerzbank",
  "bic": "COBADEFFXXX",
  "bankCity": "K\u00f6ln",
  "bankZip": "50447",
  "bankCodeValid": true,
  "messages": [
    "Bank code valid: 37040044"
  ],
  "skipped": false,
  "skipReason": null
}

Pricing

You pay only for results that land. Cap any run with maxTotalChargeUsd. See pricing & billing for worked examples.

Limitations

• Bank-directory enrichment (bank name, BIC, city, ZIP) is confirmed for DE and NL only. AT, CH, and BE are unconfirmed — we neither claim support nor absence. FR, GB, ES, IT, and PL are confirmed checksum-only (no bank-directory match).
• Checksum validation itself works across all IBAN-format countries — the enrichment gap above only affects the bank-directory fields.
• Concurrency is capped at 5 requests in flight by design — openiban.com is a free, shared keyless service.
• No caching or dedup of previously-seen IBANs across runs — every run re-checks every IBAN you send.
• openiban.com is a free, single-maintainer service — its uptime and rate-limit posture aren't contractually guaranteed.