Fake IBAN generator

What it generates

The IBAN field takes a country option and emits a value of the correct total length for that country, grouped in fours the way IBANs are conventionally displayed:

DE  22 chars   DE84 9137 2056 4180 3925 71
GB  22 chars   GB19 4820 7315 9064 2837 15
FR  27 chars   FR76 3018 4927 5061 8340 9271 583
TR  26 chars   TR42 0619 3748 2059 1637 4820
NL  18 chars   NL63 8241 5907 3618 42
ES  24 chars   ES91 7204 8316 5029 4718 36
IT  27 chars   IT38 5019 2746 3085 1927 4630 517

The country prefix is correct, the length is correct, and the grouping matches how banks print them. That covers the majority of what an IBAN column is used for in a test: does the input accept 34 characters, does the column not truncate, does the UI group the digits, does the layout survive France and Italy as well as the Netherlands.

They will not pass a checksum

This needs stating plainly, because it is the one thing that surprises people. A real IBAN carries two check digits in positions 3 and 4, computed over the rest of the value with a mod-97 algorithm. The generated values have random digits in those positions, so a validator that implements the ISO 13616 check will reject essentially all of them.

That is intentional. An IBAN that passes mod-97 and uses a real bank code is a plausible account identifier, and generating those in bulk is not something a test-data tool should do. If your form validates the checksum, generated IBANs will fail — which is a genuine test of your error path, and a signal to use a small hand-written list of known-valid test IBANs (banks and payment providers publish them) for the happy path.

The practical split: use generated IBANs for volume, layout, storage and rejection testing; use a published test IBAN when you specifically need one that validates.

Storing and displaying

IBANs are up to 34 characters, alphanumeric, and conventionally stored without spaces and displayed with them. The generator emits the spaced form, which means it is directly useful for testing display and for checking that your input handling strips whitespace before comparison. If you need the compact storage form, remove spaces downstream — a good reminder to test that two IBANs differing only in spacing are treated as equal.

Do not store an IBAN as a number. The leading country letters make that impossible anyway, but the same instinct that turns a phone number into an integer will happily strip a leading zero from a bank code.

Building a payments fixture

An IBAN on its own is rarely the whole record. Pair it with Full Name for the account holder, Company Name for business accounts, Currency Code, Price for the amount and a Date for the value date. Set Blank % on optional reference fields, and enable Unique on the IBAN column if it backs a unique constraint.

For card payments rather than transfers, the test card number field follows the same safety principle from the other direction: published, inert values rather than plausible ones.

Common questions

Related generators

• Test credit card numbers — the card-payment equivalent.
• Random name generator — account holders.
• Business field reference — prices, currencies, companies, barcodes.
• Methodology — the safety design behind every field.