IBAN Validator & Bank Enricher – Bulk IBAN API

What does IBAN Validator & Bank Enricher do?

Bulk IBAN validation for payment onboarding, supplier master data and accounting imports: every IBAN is validated offline against the Swift IBAN Registry (all 89 countries and territories that issue IBANs), split into bank code, branch code and account number, enriched with the bank name and BIC for German, Belgian and Dutch IBANs from public bank lists, and, when it is invalid, accompanied by the single-character fixes that would make it valid. The registry and the bank lists are bundled with the Actor: no third-party service is called, nothing is kept between runs, and the IBANs you send stay inside your own run: in its input, its dataset and, while it delivers, its key-value store.

What this Actor does not do

Read this before you rely on the output:

• It does not check that the account exists (geen bestaanscontrole). A valid result means the string is a correctly formed IBAN of that country and, where a bank list exists, that the bank code belongs to a real bank. Whether that bank has an account with that number is something only the bank knows.
• It is not a name check (geen naam-rekeningcontrole). It does not compare the IBAN with the account holder's name (Verification of Payee / IBAN-Name Check / Confirmation of Payee). Since October 2025 payment service providers in the euro area must offer that check for euro credit transfers (the rest of SEPA follows by 2027); use it there, or a licensed VoP provider.
• It does not say whether the account is open, blocked, or able to receive SEPA payments. sepa tells you the country takes part in SEPA, not the account.
• It does not return bank addresses or contact details, only the bank's name and BIC.

What it is good for: catching mistyped, truncated and mangled IBANs before you store a supplier record, submit a payment file, or send a customer a form error, and adding the BIC where a payment file or ERP still requires one.

How an IBAN is validated

Each IBAN goes through the checks in this order, and the first failure is the reason you get. One exception: a value whose positions 3 and 4 are not two digits is structure straight away, before the length and the check digits are looked at.

Reason	What was found
empty	Nothing left after removing spaces and separators
characters	Characters that never occur in an IBAN (only A–Z and 0–9 do); the text names them
country-unknown	The first two characters are not a country in the IBAN Registry: no IBANs are issued there
length	Wrong number of characters for that country (the text gives both numbers)
checksum	The ISO 13616 mod-97 check digits do not match: a character was mistyped or two were swapped (a dropped or added character shows up as length)
structure	The national format is not met: letters where digits belong, or the reverse. Positions 3 and 4 that are not two digits also land here, before the length and the check digits are checked

Spaces, dashes, dots, lower case and an "IBAN" prefix are removed first, so iban: nl91 abna 0417.1643-00 validates as NL91ABNA0417164300. Territories that use another country's IBAN format (GF, GP, MQ, RE, PF, TF, YT, NC, BL, MF, PM, WF for France; IM, JE, GG for the United Kingdom; AX for Finland) are validated with that format.

The mod-97 check digits catch every single-character error and every swap of two adjacent digits. A swap in which a letter is involved can slip through, because a letter counts as two digits in the calculation. National check digits inside the BBAN (Belgium and France carry one, for instance) are not verified separately: they would catch a few of the typos that survive mod-97, so read a valid result as "correctly formed IBAN of that country", not as "checked twice".

Bank name and BIC: only from lists that may be reused

The Swift BIC Directory, the one complete IBAN-to-BIC source, is licensed and may not be redistributed. This Actor therefore bundles only public lists whose reuse is permitted, and every record says which one answered (bankSource):

Country	List	Version	Bank codes	Coverage
DE	Deutsche Bundesbank, Bankleitzahlendatei (public download)	valid 2026-09-07 to 2026-12-06	3,432	complete: an unknown bank code is reported as a warning
BE	National Bank of Belgium, identification codes of Belgian banks	Version 01/09/2026	782	complete: an unknown bank code is reported as a warning
NL	Major Dutch banks, curated by hand from the BICs the banks publish	September 2026	45	major banks only: an unknown bank code is not a warning

• Germany and Belgium are complete: a valid IBAN whose bank code is not in the list gets an entry in warnings, because no bank uses that code (a typo that happened to keep the check digits right, or a bank that no longer exists).
• The Netherlands covers the major consumer and business banks. The Dutch Payments Association publishes the complete Dutch BIC list, but its terms forbid redistribution, so smaller banks and foreign branches return bankName: null without a warning.
• Other countries return the bank and branch code as parsed from the IBAN, without a name or BIC.

The table above is generated from the bundled files, so it always names the versions this release carries; bankSource tells you per record which of the three answered (bundesbank, nbb or curated), and a warning about an unknown bank code quotes the list version it was checked against.

Suggested corrections

An IBAN that fails the check digits (checksum) or the national format (structure) usually contains one of a few classic mistakes. With Suggest corrections on (default), the Actor tries each one and keeps only the candidates that validate:

• Letter/digit confusion at one position: O ↔ 0, I ↔ 1, L ↔ 1, S ↔ 5, B ↔ 8, Z ↔ 2, G ↔ 6
• Two adjacent characters swapped
• Wrong check digits with an otherwise plausible account part: it only says what the check digits would be if the rest is right, so it is the weakest kind and comes after the other kinds of equal plausibility. But, like any candidate, a check-digit candidate that names a bank from a bundled list is still listed before candidates that name none

A candidate that passes both the check digits and the national format is a strong lead: the chance that a random correction does so is about 1 in 97. At most three suggestions are returned per IBAN, the ones that name a bank from a bundled list first, because a corrected IBAN whose bank code belongs to a real bank is rarely a coincidence. An IBAN with the wrong number of characters (length), with characters that cannot occur (characters) or with an unknown country (country-unknown) gets no suggestions: a dropped or added character is not a single-character fix, and the reason already says what is wrong. Suggestions are proposals for a human or a retry prompt, not automatic replacements.

Features

• Bulk IBAN checker for up to 100,000 IBANs per run (20,000 by default; above 50,000 give the run 2 GB of memory), entirely offline inside your Apify run
• IBAN validation for all 89 IBAN countries from the Swift IBAN Registry (TXT edition, read on 15 September 2026): ISO 13616 mod-97 check digits, length and national format
• Bank code, branch code and account number split as the IBAN Registry defines them per country
• IBAN to BIC and bank name for German, Belgian and Dutch IBANs, from public bank lists that may be redistributed
• IBAN typo correction: up to three single-character fixes that turn an invalid IBAN into a valid one, the ones that name a real bank first
• Warnings on valid IBANs whose bank code no bank uses (Germany and Belgium), and on a territory prefix most banks there do not issue
• SEPA country flag per IBAN, straight from the registry
• Deterministic and private: no external API, nothing kept between runs, the same answer every time
• Runs through the Apify API, from Make, Zapier or n8n, or as a scheduled task over an export

Use cases

Payment onboarding and supplier master data

Validate the IBANs of new suppliers or customers when they are entered, in a nightly batch or before a payment run. Reject valid: false with reasonText and, when there is one, the suggestion ("did you mean NL91 ABNA 0417 1643 00?"); flag warnings for review; fill the BIC from bic where your bank or ERP still demands one.

// npm install apify-client
import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('lwsdjfls/iban-validator-enricher').call({
    ibans: suppliers.map((supplier) => supplier.iban),
});
const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });
const byInput = new Map(items.map(({ payload }) => [payload.input, payload]));

for (const supplier of suppliers) {
    const result = byInput.get(supplier.iban.trim());
    if (!result?.valid) {
        await flagSupplier(supplier.id, result?.reasonText, result?.suggestions[0]?.ibanFormatted);
    } else {
        await updateSupplier(supplier.id, { iban: result.iban, bic: result.bic, bank: result.bankName, review: result.warnings });
    }
}

10,000 supplier IBANs cost $5.00.

Accounting and CRM teams: cleaning an export

Export the bank account column, run it once, and sort by reason: length, checksum and structure are typos, characters are usually leftovers of another field that landed in the IBAN column, country-unknown are account numbers that were never IBANs.

Treasury: SEPA batch pre-check

Run the IBANs of a pain.001 batch before you submit it. A malformed IBAN comes back as a rejection of the single transaction or of the whole file, depending on the bank, and often hours later. This check answers in seconds and the same run gives you the German, Belgian and Dutch BICs for the batch.

Developers: form validation through the API

Call the Actor from a backend when a user submits an IBAN, and show reasonText or the first suggestion as the form error. For an interactive form the check digits alone are enough client-side; the value of this Actor is the bank identification and the corrections.

How to use it

1. Paste the IBANs into IBANs. Spacing and case do not matter, so a column copied straight out of a spreadsheet or an export works as it is. Nothing leaves the run: validation happens against the IBAN Registry and the bank lists shipped inside the Actor, with no external service involved.
2. Leave Suggest corrections on for a supplier or customer file. An IBAN that fails the check digit then comes back with the most likely repair, so a typed O instead of a zero or two swapped characters is something you can fix rather than merely reject.
3. Put it in front of your payment run. The validation view gives the verdict per IBAN and the bank view gives bank name, BIC, bank code and branch code where the national list covers them, which is what a treasury team pastes back into the master file.

Because there is no network call, a run of a few thousand IBANs takes seconds and the result is the same every time. Keep an eye on the log if you send very large batches: the run tells you how many IBANs fit in the memory it was given and what to raise if some were left over, rather than silently validating part of the list.

Be clear about the limit before you rely on it. This is a structural check, not a bank check. It proves the IBAN is well formed and which bank it belongs to. It cannot tell you that the account exists, that it is open, or that it belongs to the name on your invoice. For that you need your bank's own verification service.

{
  "ibans": ["NL91 ABNA 0417 1643 00", "DE89 3704 0044 0532 0130 00", "BE68 5390 0754 7034"],
  "suggestCorrections": true
}

Input

Field	What it does	Example
ibans	One IBAN per line, at least one, at most 80 characters per line. Spaces, dashes, dots, lower case and an "IBAN" prefix are fine. A duplicate is checked and charged once.	["NL91 ABNA 0417 1643 00", "DE89 3704 0044 0532 0130 00"]
suggestCorrections	For an IBAN that fails, list up to three single-character fixes that would make it valid. Default true.	true
maxIbansPerRun	Caps the validated (and charged) IBANs in one run; anything beyond it is skipped, not charged and mentioned in the log. Default 20000.	20000

By default a run validates the first 20,000 distinct IBANs. With the default 1 GB of memory you can raise maxIbansPerRun to 50,000; above that, start the run with 2 GB of memory or split the list. A run with less memory than its cap needs validates only what fits (20,000 below 1 GB, 50,000 below 2 GB) and says so in the log; skipped IBANs are not charged.

{
  "ibans": [
    "NL91 ABNA 0417 1643 00",
    "DE89 3704 0044 0532 0130 00",
    "BE68 5390 0754 7034",
    "GB29 NWBK 6016 1331 9268 19",
    "FR14 2004 1010 0505 0001 3M02 606",
    "NL91 ABNA 0417 1643 0O",
    "DE89 3704 0044 0532 0310 00"
  ],
  "suggestCorrections": true
}

ibans needs at least one non-empty line: a run with an empty list stops with Add at least one IBAN. before anything is charged, and a line over 80 characters fails the input check (no IBAN is that long: the longest anywhere, Russia's, is 33 characters, 41 with spaces). Empty lines and duplicates cost nothing; of a duplicate, the first spelling you gave is the one reported. Running the example above (the prefilled input) returns seven records. Five are valid: the Dutch and German IBANs with bank name and BIC, the Belgian one with a warning that bank code 539 is not in the Belgian list, and the British and French ones without bank data. Two are invalid, one with a single suggested correction and one with three.

Supported countries

All 89 entries of the Swift IBAN Registry (TXT edition, read on 15 September 2026), plus the 16 territory prefixes that share another country's format, shown with it. Positions are counted inside the BBAN, the part after the country code and check digits.

Prefix	Country	Length	SEPA	Bank code (BBAN positions)	Branch code	Example
AD	Andorra	24	yes	1–4	5–8	AD1200012030200359100100
AE	United Arab Emirates (The)	23	no	1–3	–	AE070331234567890123456
AL	Albania	28	no	1–3	4–8	AL47212110090000000235698741
AT	Austria	20	yes	1–5	–	AT611904300234573201
AZ	Azerbaijan	28	no	1–4	–	AZ21NABZ00000000137010001944
BA	Bosnia and Herzegovina	20	no	1–3	4–6	BA391290079401028494
BE	Belgium	16	yes	1–3	–	BE68539007547034
BG	Bulgaria	22	yes	1–4	5–8	BG80BNBG96611020345678
BH	Bahrain	22	no	1–4	–	BH67BMAG00001299123456
BI	Burundi	27	no	1–5	6–10	BI4210000100010000332045181
BR	Brazil	29	no	1–8	9–13	BR1800360305000010009795493C1
BY	Belarus	28	no	1–4	–	BY13NBRB3600900000002Z00AB00
CH	Switzerland	21	yes	1–5	–	CH9300762011623852957
CR	Costa Rica	22	no	1–4	–	CR05015202001026284066
CY	Cyprus	28	yes	1–3	4–8	CY17002001280000001200527600
CZ	Czechia	24	yes	1–4	–	CZ6508000000192000145399
DE	Germany	22	yes	1–8	–	DE89370400440532013000
DJ	Djibouti	27	no	1–5	6–10	DJ2100010000000154000100186
DK	Denmark	18	yes	1–4	–	DK5000400440116243
DO	Dominican Republic	28	no	1–4	–	DO28BAGR00000001212453611324
EE	Estonia	20	yes	1–2	–	EE382200221020145685
EG	Egypt	29	no	1–4	5–8	EG380019000500000000263180002
ES	Spain	24	yes	1–4	5–8	ES9121000418450200051332
FI (also AX)	Finland	18	yes	1–3	–	FI2112345600000785
FK	Falkland Islands (Malvinas)	18	no	1–2	–	FK88SC123456789012
FO	Faroe Islands	18	no	1–4	–	FO6264600001631634
FR (also GF, GP, MQ, RE, PF, TF, YT, NC, BL, MF, PM, WF)	France	27	yes	1–5	6–10	FR1420041010050500013M02606
GB (also IM, JE, GG)	United Kingdom	22	yes	1–4	5–10	GB29NWBK60161331926819
GE	Georgia	22	no	1–2	–	GE29NB0000000101904917
GI	Gibraltar	23	yes	1–4	–	GI75NWBK000000007099453
GL	Greenland	18	no	1–4	–	GL8964710001000206
GR	Greece	27	yes	1–3	4–7	GR1601101250000000012300695
GT	Guatemala	28	no	1–4	–	GT82TRAJ01020000001210029690
HN	Honduras	28	no	1–4	–	HN88CABF00000000000250005469
HR	Croatia	21	yes	1–7	–	HR1210010051863000160
HU	Hungary	28	yes	1–3	4–7	HU42117730161111101800000000
IE	Ireland	22	yes	1–4	5–10	IE29AIBK93115212345678
IL	Israel	23	no	1–3	4–6	IL620108000000099999999
IQ	Iraq	23	no	1–4	5–7	IQ98NBIQ850123456789012
IS	Iceland	26	yes	1–2	3–4	IS140159260076545510730339
IT	Italy	27	yes	2–6	7–11	IT60X0542811101000000123456
JO	Jordan	30	no	1–4	5–8	JO94CBJO0010000000000131000302
KW	Kuwait	30	no	1–4	–	KW81CBKU0000000000001234560101
KZ	Kazakhstan	20	no	1–3	–	KZ86125KZT5004100100
LB	Lebanon	28	no	1–4	–	LB62099900000001001901229114
LC	Saint Lucia	32	no	1–4	–	LC55HEMM000100010012001200023015
LI	Liechtenstein	21	yes	1–5	–	LI21088100002324013AA
LT	Lithuania	20	yes	1–5	–	LT121000011101001000
LU	Luxembourg	20	yes	1–3	–	LU280019400644750000
LV	Latvia	21	yes	1–4	–	LV80BANK0000435195001
LY	Libya	25	no	1–3	4–6	LY83002048000020100120361
MC	Monaco	27	yes	1–5	6–10	MC5811222000010123456789030
MD	Moldova, Republic of	24	no	1–2	–	MD24AG000225100013104168
ME	Montenegro	22	no	1–3	–	ME25505000012345678951
MK	North Macedonia	19	no	1–3	–	MK07250120000058984
MN	Mongolia	20	no	1–4	–	MN121234123456789123
MR	Mauritania	27	no	1–5	6–10	MR1300020001010000123456753
MT	Malta	31	yes	1–4	5–9	MT84MALT011000012345MTLCAST001S
MU	Mauritius	30	no	1–6	7–8	MU17BOMM0101101030300200000MUR
NI	Nicaragua	28	no	1–4	–	NI45BAPR00000013000003558124
NL	Netherlands (The)	18	yes	1–4	–	NL91ABNA0417164300
NO	Norway	15	yes	1–4	–	NO9386011117947
OM	Oman	23	no	1–3	–	OM810180000001299123456
PK	Pakistan	24	no	1–4	–	PK36SCBL0000001123456702
PL	Poland	28	yes	1–8	–	PL61109010140000071219812874
PS	Palestine, State of	29	no	1–4	–	PS92PALS000000000400123456702
PT	Portugal	25	yes	1–4	–	PT50000201231234567890154
QA	Qatar	29	no	1–4	–	QA58DOHB00001234567890ABCDEFG
RO	Romania	24	yes	1–4	–	RO49AAAA1B31007593840000
RS	Serbia	22	no	1–3	–	RS35260005601001611379
RU	Russian Federation	33	no	1–9	10–14	RU0304452522540817810538091310419
SA	Saudi Arabia	24	no	1–2	–	SA0380000000608010167519
SC	Seychelles	31	no	1–6	7–8	SC18SSCB11010000000000001497USD
SD	Sudan	18	no	1–2	–	SD2129010501234001
SE	Sweden	24	yes	1–3	–	SE4550000000058398257466
SI	Slovenia	19	yes	1–5	–	SI56263300012039086
SK	Slovakia	24	yes	1–4	–	SK3112000000198742637541
SM	San Marino	27	yes	2–6	7–11	SM86U0322509800000000270100
SO	Somalia	23	no	1–4	5–7	SO211000001001000100141
ST	Sao Tome and Principe	25	no	1–4	5–8	ST23000100010051845310146
SV	El Salvador	28	no	1–4	–	SV62CENR00000000000000700025
TL	Timor-Leste	23	no	1–3	–	TL380080012345678910157
TN	Tunisia	24	no	1–2	3–5	TN5910006035183598478831
TR	Turkiye	26	no	1–5	–	TR330006100519786457841326
UA	Ukraine	29	no	1–6	–	UA213223130000026007233566001
VA	Holy See	22	yes	1–3	–	VA59001123000012345678
VG	Virgin Islands (British)	24	no	1–4	–	VG96VPVG0000012345678901
XK	Kosovo	20	no	1–2	3–4	XK051212012345678906
YE	Yemen	30	no	1–4	5–8	YE15CBYE0001018861234567891234

sepa follows the SEPA column of the IBAN Registry (the 27 EU member states plus Iceland, Liechtenstein, Norway, Switzerland, the United Kingdom, Andorra, Monaco, San Marino, the Vatican City State and Gibraltar).

Output

One record per distinct IBAN:

• valid: true or false, and for invalid IBANs reason (empty, characters, country-unknown, length, checksum, structure) plus reasonText, one sentence you can show a user
• iban (normalised: upper case, no spaces or separators) and ibanFormatted (groups of four, for letters and screens; null for an invalid IBAN)
• countryCode, countryName, sepa (all null when the country code is not in the registry)
• checkDigits, bban, bankCode, branchCode, accountNumber as the IBAN Registry defines them for that country: filled for a valid IBAN, null for an invalid one, and branchCode also null for countries whose IBAN carries no branch code
• bankName, bic and bankSource when the bank code is in a bundled bank list (Germany, Belgium, the Netherlands)
• suggestions: for an invalid IBAN, the single-character corrections that would make it valid, each with the corrected IBAN and what was probably mistyped
• warnings: doubts about a valid IBAN. Two exist: a German or Belgian bank code that is not in the country's complete bank list, and an IBAN that starts with a territory prefix (GF, JE, AX …) where most banks issue IBANs of the parent country instead
• input: your value as you gave it, so you can join the results back to your own records

Each record is wrapped in the standard envelope of this portfolio (id, hash, changeType, sourceUrl, scrapedAt) with the fields above under payload. Below: a Dutch IBAN with the letter O typed for the last zero, invalid, with the corrected IBAN as suggestion.

{
  "envelopeVersion": 1,
  "id": "iban:NL91ABNA041716430O",
  "scope": "batch",
  "changeType": "added",
  "sourceUrl": "https://www.swift.com/standards/data-standards/iban-registry",
  "scrapedAt": "2026-09-15T10:00:00.000Z",
  "firstSeenAt": "2026-09-15T10:00:00.000Z",
  "hash": "3ac11d7bf692a0c82c28b4ff633f2b0eeff5df0c4c4979dd48b7c257224bf8d9",
  "previousHash": null,
  "changes": [],
  "summary": "Added: NL91ABNA041716430O",
  "diffText": null,
  "payload": {
    "input": "NL91 ABNA 0417 1643 0O",
    "valid": false,
    "reason": "checksum",
    "reasonText": "The check digits do not match (expected 64); a digit was mistyped, dropped or transposed.",
    "iban": "NL91ABNA041716430O",
    "ibanFormatted": null,
    "countryCode": "NL",
    "countryName": "Netherlands (The)",
    "sepa": true,
    "checkDigits": null,
    "bban": null,
    "bankCode": null,
    "branchCode": null,
    "accountNumber": null,
    "bankName": null,
    "bic": null,
    "bankSource": null,
    "suggestions": [
      {
        "iban": "NL91ABNA0417164300",
        "ibanFormatted": "NL91 ABNA 0417 1643 00",
        "kind": "letter-digit-confusion",
        "description": "O at position 18 read as 0",
        "bankName": "ABN AMRO Bank N.V."
      }
    ],
    "warnings": []
  }
}

The dataset opens on the Validation view: your input, valid or not, the normalised IBAN, country, bank code, bank name, BIC, the reason and explanation, the suggestions and the warnings. The Bank and BIC view shows what was parsed out of each IBAN (bank code, branch code, account number, bank name, BIC and which bank list answered) for filling a payment file or an ERP record; invalid IBANs appear in it too, with those fields empty. The RUN_SUMMARY record in the run's key-value store counts what the run saw, validated and delivered, and what it charged.

Pricing

Event	Name	What it means	Price
apify-actor-start	Actor start	Charged by Apify when a run starts: once for a run of up to 1 GB of memory, and once more for every extra GB. It covers the first five seconds of compute.	$0.00005 per run up to 1 GB of memory ($0.05 per 1,000)
iban-validated (primary)	IBAN validated	One IBAN checked (check digits, country format, bank and branch code), with bank name and BIC where a public bank list exists and suggested corrections when it is invalid. A duplicate in the same batch is checked and charged once.	$0.0005 per IBAN ($0.50 per 1,000)

Validation runs offline in your Apify account, so there is no per-call cost from a third-party API behind this price: 1,000 IBANs cost $0.50, 100,000 cost $50. A supplier file of 2,500 IBANs costs $1.25, plus $0.00005 for the start event of a run with the default 1 GB of memory (five cents per thousand runs). The compute is on us: more memory only raises that start event ($0.00005 more for every GB above the first), never the price per IBAN.

You pay for IBANs that were validated, not for the run. A duplicate in the same batch is checked and charged once, empty lines are skipped for free, and IBANs above maxIbansPerRun or above what the run's memory holds are skipped and not charged. A run that stops before validating anything (an empty list, a line over 80 characters, a cancelled run) costs the start event alone, so a failed run costs a fraction of a cent. There is no external source that can be down: the registry and the bank lists are in the image, so a run either validates your list or fails on its own input.

FAQ

The IBAN is valid but bankName is null. Is something wrong?

For Germany and Belgium, yes, probably: those lists are complete, so an unknown bank code comes with a warning. For the Netherlands the bundled list covers the major banks only. For every other country the Actor has no bank list and returns the bank code alone.

Can I get the BIC for French, Spanish or Italian IBANs?

Not from this Actor: no public, reusable bank list with BICs exists for those countries, and the Swift BIC Directory is licensed. In SEPA the BIC is no longer required for payments ("IBAN only" since 2016), so most systems can leave it empty.

Does a valid result mean I can pay this account?

No. It means the IBAN is well formed and, where a list exists, names a real bank. Existence, ownership and status of the account are only known to the bank; use Verification of Payee at your bank for that.

Is IBAN validation with this Actor GDPR-compliant?

An IBAN of a natural person is personal data. This Actor processes IBANs entirely inside the Apify run: no request goes to any external service, and the results exist nowhere outside your own run. The Actor keeps no state between runs: a later run knows nothing of an earlier batch. While a run delivers, its own key-value store holds the delivery plan with the results; the plan is deleted when the run ends. Only a run whose delivery failed keeps it in that run's store, so that resurrecting the run finishes delivery without charging twice. Delete the run's dataset, and such a failed run itself, when your GDPR retention rules require it. It is not affiliated with Swift, the Bundesbank, the National Bank of Belgium or any bank; it applies the public IBAN Registry and the public bank lists named above.

What are the limitations?

• Bank names and BICs are available for Germany, Belgium and the major Dutch banks only. Other countries return the bank and branch code as parsed from the IBAN, without a name or BIC.
• The IBAN Registry and the bank lists are bundled at build time (registry read on 15 September 2026; the list versions are in the table above). A country that starts issuing IBANs later is country-unknown, and a bank code registered after that date is unknown, until the next release of this Actor.
• National check digits inside the BBAN are not verified, so a valid result is one check (mod-97 plus the national format), not two independent ones.
• Suggestions only exist for an IBAN of the right length whose check digits or national format fail, at most three per IBAN, and they are leads for a human, not replacements.
• Up to 100,000 IBANs per run (20,000 unless you raise maxIbansPerRun); a run validates at most 20,000 below 1 GB of memory and 50,000 below 2 GB.

Related Actors

• VIES VAT Validator: the same bulk check for EU VAT numbers, live against VIES, with outage handling and consultation numbers.
• EU Sanctions Screening: check who is behind the account against the EU, UN and UK sanctions lists before you pay a new supplier.
• Peppol Participant Lookup: whether a customer can receive e-invoices over the Peppol network, by KvK, VAT, KBO, GLN or SIREN number.

Support

Missing a bank list that may be reused, or a country? Open an issue on the Actor page.