IBAN Validator API

---

🎯 What this 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.

⚙️ How to use it

1. Click Try for free at the top of the page.
2. Fill in the input form — most fields have sensible defaults.
3. Click Start. Output streams into the run's dataset.
4. Export from Storage → Dataset as JSON, CSV, or Excel — or fetch via the API.

📥 Input

Field	Type	Required	Default	Notes
ibans	array	yes	—	IBANs to validate, one per list item. Whitespace is stripped before use.
maxConcurrency	integer	no	3	Cap on concurrent requests to openiban.com. Kept low by design — a free, shared keyless service.
proxyConfiguration	object	no	{}	Apify Proxy configuration. Present per org standard — openiban.com is a public keyless API, so no proxy is used unless you explicitly enable one here.

Example input

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

📤 Output

Every row is one dataset item.

Field	Type	Notes
iban	string	Normalised input (whitespace stripped, uppercased); also the path value used.
valid	boolean	openiban valid. Conflates checksum + bank-code validation. Null only for skipped rows.
bankCode	string	openiban bankData.bankCode; empty string normalised to null.
bankName	string	openiban bankData.name; empty string normalised to null.
bic	string	openiban bankData.bic, when present.
bankCity	string	openiban bankData.city, when present.
bankZip	string	openiban bankData.zip, when present.
bankCodeValid	boolean	openiban checkResults.bankCode, when present.
messages	array	openiban messages[] verbatim — the only field that disambiguates checksum vs. bank-code failure. Never null.
skipped	boolean	True only for empty input or unrecoverable transport/parse failure.
skipReason	string	Set only when skipped is true.

Example output

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

💰 Pricing

Pay-Per-Event — you pay only when these events fire:

Event	USD	What it is
actor-start	$0.20	One-off warm-up charge per run
iban-checked	$0.001	Charged once per input IBAN processed

Example: 1 000 IBANs checked at the rates above ≈ $1.20. No subscription, no minimum, no card to start — Apify gives every new account $5 of free credit.

🚧 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.

❓ FAQ

Why is valid sometimes false even though the IBAN's checksum is fine?

valid reflects both checksum AND bank-code/BIC validation. An IBAN can have a perfect checksum but still come back valid: false if its bank code doesn't resolve — check messages[] on that row to see exactly which check failed.

Is an invalid IBAN a failed run?

No. An IBAN openiban reports as invalid is a normal, useful answer — the run still succeeds, and that row simply says valid: false with an explanation in messages[].

What happens if one IBAN in my batch is malformed?

It's still sent to openiban and comes back as its own row with valid: false and a messages[] entry explaining why — the rest of your batch is processed normally. Only a genuinely empty entry, or a request that fails after retries, is marked skipped: true.

Does this actor call a paid IBAN-validation service?

No — openiban.com is free and keyless. We don't add a markup for data access; you're paying for bulk throughput, retry/backoff handling, and clean, typed dataset rows.

💬 Your feedback

Spotted a bug, hit a weird edge case, or need a new field? Open an issue on the Actor's Issues tab on Apify Console — we ship fixes weekly and we read every report.

---