IBAN Test Data for Developers: Generate Valid Fake IBANs

Payment features, invoicing flows or form validation – at some point every project needs IBAN test data. Using your own IBAN is a bad idea; dummy strings like DE000000000000000000 fail check-digit validation. What you want: formally valid but fictitious IBANs.

What makes an IBAN formally valid

IBAN is standardized in ISO 13616 and consists of:

• Country code (2 letters, e.g. DE, AT, CH)
• Check digits (2 digits, computed via modulo-97)
• BBAN (country-specific account details; for DE: 8-digit bank code + 10-digit account)

Example from Germany:

DE89 3704 0044 0532 0130 00
└┬┘ └┬┘ └──┬──────────────┘
│  │     │
│  │     └ BBAN (bank code + account)
│  └ Check digits
└ Country code

Modulo-97 check – how it works

1. Move the first four characters (country code + check digits) to the end.
2. Convert letters to numbers: A = 10, B = 11, … Z = 35.
3. Take the resulting large number modulo 97.
4. Result must be 1, otherwise the IBAN is invalid.

Pseudocode (abbreviated):

function isValidIban(iban) {
  const rearranged = iban.slice(4) + iban.slice(0, 4);
  const numeric = rearranged.replace(/[A-Z]/g, c => c.charCodeAt(0) - 55);
  // BigInt required due to length
  return BigInt(numeric) % 97n === 1n;
}

Fake IBANs – what's safe and sensible

Unlike credit cards there is no "official" test IBAN range (where 4242 4242 4242 4242 is well known). Rules of thumb for test data:

• Generate IBANs that are formally valid (correct check digit).
• Fill the BBAN with values that do not correspond to a real bank account.
• Never run SEPA test payments against these IBANs – they point to nothing.

Our test data generator produces exactly this kind of IBAN: with a correct check digit, but random BBANs that do not match any real account.

Sample IBANs for development

These are formally valid (correct check digit) but point to nothing real:

DE89 3704 0044 0532 0130 00    (DE, 22 chars)
AT61 1904 3002 3457 3201         (AT, 20 chars)
CH93 0076 2011 6238 5295 7        (CH, 21 chars)
FR14 2004 1010 0505 0001 3M02 606 (FR, 27 chars)
GB82 WEST 1234 5698 7654 32       (GB, 22 chars)

Lengths per country

Common validation pitfalls

• Spaces and hyphens: always strip before validating.
• Case: uppercase letters before converting to digits.
• Length not checked: a modulo-97 check does not verify the per-country length. Validate both.
• Integer overflow: the numeric representation grows to 20+ digits – use BigInt or do piece-wise modulo arithmetic.

Workflow for your project

1. Enable IBAN as a field in the test data generator.
2. Pick a country mix (e.g. DE only, or DACH).
3. Export as JSON, CSV or SQL.
4. Store in fixtures or seed files – but never in VCS paths that count as "production-ready".

That gives you clean, formally valid IBANs for testing anytime – without accidentally embedding a real bank account in your test data.