Any code that accepts, stores or sends IBANs needs test data: form validation, onboarding flows, database fixtures, payment integrations, load tests. Real customer IBANs have no place in a test environment, and IBANs typed by hand rarely have correct check digits. A test IBAN, sometimes called a fake or dummy IBAN, solves both problems: it passes structural validation and no bank ever issued it.
What a validator checks
IBAN validation happens in layers. Each layer catches different problems, and a test IBAN only gets through some of them.
| Check | What it verifies | A generated test IBAN |
|---|---|---|
| Characters | Only letters and digits after removing spaces | Passes |
| Country | The first two letters are a country that uses IBAN | Passes |
| Length | The length matches that country, for example 22 for Germany | Passes |
| Pattern | Each BBAN position has the right kind of character (digit or letter) | Passes |
| Check digits | MOD-97 remainder equals 1 | Passes |
| National check digits | Country rules inside the BBAN, such as Italy's CIN or France's clé RIB | Passes in the 27 countries whose official algorithm we compute; elsewhere random, may fail |
| Bank directory | The bank code exists | Passes for the 84 countries with real bank codes in realistic mode, the default; otherwise usually fails |
| Account lookup | The account exists and the name matches | Fails |
The last two checks need data from banks. In the UK, Confirmation of Payee compares the account holder's name with the one the payer entered; in the euro area, Verification of Payee does the same before a transfer. A random IBAN cannot pass those checks, and it should not. National check digits in the IBAN explains the national layer country by country.
The first five checks, plus the national check digits where the rule is known, need no outside data. Our IBAN validator runs them in your browser and shows which one fails. Our open-source JavaScript library iban-check runs all five against the SWIFT IBAN Registry and returns an error code that says which one failed. Algeria and Morocco are not in the registry, so it rejects their IBANs. It is on npm as iban-check.
Mistakes that break IBAN handling
These are the bugs that show up again and again in IBAN code:
- One length for every country. German IBANs have 22 characters, but Norwegian ones have 15 and Maltese ones 31. Validate the length per country, not with a single fixed number.
- Digits only after the country code. Dutch, British and many other IBANs contain letters in the BBAN (
NL91ABNA0417164300). A regex that only allows digits rejects them. - Storing the print format. Store IBANs in electronic format, without spaces and in uppercase, and add spaces only when you display them.
- Treating the IBAN as a number. It contains letters and can start the BBAN with zeros. Store it as a string.
- Integer overflow in MOD-97. For every country except Norway and Belgium, the converted number is longer than a 64-bit integer can hold (about 19 digits); Germany's has 24. Use arbitrary precision or the step-by-step remainder shown in How IBAN check digits work.
- Invisible characters from copy and paste. Users paste IBANs with non-breaking spaces, tabs or line breaks. Strip all whitespace, not only the normal space.
- Lowercase input. People type
de89.... Convert to uppercase before you validate.
Which test IBAN to use
Random test IBANs suit most tests: form validation, fixtures, seed data, load tests and screenshots. Use several countries, not only your own, so that length and pattern handling get exercised; long formats such as Malta (31) and short ones such as Norway (15) are good edge cases. By default the generator uses realistic mode: digits only and, where available, the bank code of a real bank, with a random account number, so code that looks up the bank finds it. Such an IBAN was not issued by any bank either, but it could match a real account by chance. Turn Realistic off for fully random IBANs: the bank code is random too, which tests an unknown bank, and letters can appear where the format allows them.
Payment providers often publish their own test IBANs that trigger specific results in their sandbox, such as a successful debit or a failed one. When you test a provider's flow end to end, use the IBANs from that provider's documentation.
Never use a real person's IBAN in tests, demos or documentation, and never send money to a generated IBAN. The chance that a random IBAN matches a real account is very small, but it is not zero.
Getting test IBANs into your pipeline
The generator shows one IBAN with its segments explained. Its "Generate a list" option makes 5 to 100 IBANs of one country at once, to copy or to download as CSV, JSON, SQL or plain text, with one column per segment. For automated tests:
- The REST API returns up to 100 valid IBANs per request for any supported country, and validates IBANs too. It needs an API key; see the API documentation.
- The public MCP server lets AI agents and coding assistants generate and validate test IBANs without a key.
- The download behind "Generate a list" is a plain URL that needs no key, so a script can fetch a fixture file directly (30 downloads per minute).
- For tests that must run offline, generate a set of IBANs once and commit them as fixtures.
# 50 Dutch IBANs as CSV, no key needed
curl -o fixtures.csv "https://generaterandomiban.com/export/nl?format=csv&count=50"
# 5 IBANs from the API, with a key
curl -H "X-API-Key: YOUR_KEY" \
"https://generaterandomiban.com/api/v1/generate/NL?count=5"
Sources
- SWIFT IBAN Registry: the length and BBAN structure of every country.
- ISO 13616-1:2020: the structure of the IBAN.
- ISO/IEC 7064: the MOD 97-10 check digit method.
- Regulation (EU) 2024/886: Verification of Payee for euro transfers.