Fake IBAN Generator
Generate fake IBAN numbers for testing purposes. Choose from multiple countries and specify the number of IBANs to generate.
Generator Settings
Generated IBANs
Generated IBANs will appear here
Select a country and click "Generate" to create fake IBANs
About Fake IBAN Generator
The Fake IBAN Generator is a developer tool that creates realistic but fake International Bank Account Numbers (IBANs) for testing and development purposes. Generate valid IBAN formats for multiple countries including Germany, France, UK, Spain, Italy, and many others. Perfect for testing payment systems, form validation, and financial applications without using real banking data.
Why use a Fake IBAN Generator?
Using fake IBANs for testing ensures you never accidentally use real banking information during development. This tool generates properly formatted IBANs that pass basic validation checks but are completely fictitious. Essential for developers building financial applications, payment systems, e-commerce platforms, and banking software that need realistic test data.
Who is it for?
This tool is perfect for software developers building financial applications, QA engineers testing payment systems, fintech startups developing banking software, e-commerce developers implementing payment flows, and anyone who needs realistic but fake banking data for testing purposes.
How to use the tool
Select the country for which you want to generate fake IBANs
Choose the number of IBANs to generate (1-10)
Click "Generate" to create the fake IBAN numbers
Copy the generated IBANs for use in your testing environment
Use these fake IBANs for development and testing only - never for real transactions
Frequently Asked Questions
Are these IBANs real, usable bank accounts?
No — these are SYNTHETIC test IBANs. They pass the ISO 13616 MOD-97 checksum and use real country/bank-prefix patterns, but no bank ever issued them. They will be recognized as well-formed by your client-side validation and most sandbox payment processors, but will be rejected by any real bank or settlement system when you actually attempt a transfer. Never attempt to use them in real transactions — at best, the transfer fails immediately; at worst, you trigger fraud-prevention systems that flag your account. They're strictly for development, QA, sandbox testing, and educational purposes. Treat the IBANs as you'd treat test credit card numbers like 4242 4242 4242 4242 — useful, valid syntactically, never spendable.
What is the MOD-97 / ISO 13616 algorithm?
MOD-97 is the checksum algorithm used to validate IBANs (International Bank Account Numbers) per ISO 13616. The check: move the first 4 characters (country code + 2-digit check digits) to the end, replace each letter with two digits (A=10, B=11, ..., Z=35), then compute the result modulo 97. A valid IBAN gives a remainder of 1. The algorithm catches single-character typos and most digit transpositions in 96 out of 97 attempts. This tool generates IBANs whose check digits make them MOD-97 valid — they pass any standard IBAN validator. But MOD-97 validity is necessary, not sufficient: a syntactically valid IBAN can still fail because the BBAN portion doesn't correspond to a real account.
How do I test SEPA payments?
Standard workflow: (1) Generate test IBANs for the relevant SEPA countries (EU + EEA + UK + Switzerland — 36 countries total). (2) Use them in your payment-form QA, Cypress/Playwright E2E tests, or directly in your sandbox payment processor (Stripe Sandbox, Adyen Test, Mollie Test). (3) Sandbox processors accept test IBANs and simulate SEPA transfer flows (success, failure, mandate authorization) without moving real money. (4) For production-readiness validation, your processor likely provides specific test IBANs that trigger specific scenarios — use those for behavior testing. Use this generator for unit tests where you just need 'a valid IBAN' (e.g., testing your client-side validation rules).
Which countries are supported?
The tool generates IBANs for 30+ countries with documented IBAN formats per ISO 13616 and the SWIFT IBAN Registry. Coverage includes: all SEPA countries (Germany DE, France FR, Italy IT, Spain ES, Netherlands NL, Belgium BE, Austria AT, Portugal PT, Ireland IE, Finland FI, Greece GR, Luxembourg LU, etc.), the UK (GB), Switzerland (CH), and major non-EU IBAN adopters (Turkey TR, UAE AE, Saudi Arabia SA, Israel IL, Norway NO, Iceland IS, Sweden SE, Denmark DK, Poland PL, Czech Republic CZ). Each country has its own IBAN length and structure — Germany is 22 chars, UK is 22 chars, Belgium is 16 chars, etc. The generator picks the right length and bank-code prefixes for the selected country.
Why is MOD-97 validity not the same as a real account?
An IBAN has two parts: the country code + check digits + Bank Identifier (BBAN). MOD-97 validates the math relationship between the check digits and the rest of the IBAN. But the BBAN portion encodes the bank code (e.g., DE always starts with 8-digit Bankleitzahl) and the account number — these point to specific banks and specific accounts. This generator picks valid bank-code prefixes (so the IBAN starts with a real bank routing code), but the account-number portion is random and almost certainly doesn't correspond to a real account at that bank. The bank's settlement system rejects it immediately when you attempt a real transfer.
Is this similar to the credit-card-validator's test PAN generator?
Yes — same defensive design pattern. The [Credit Card Validator](/tools/credit-card-validator/) tool generates Luhn-valid test PANs that pass card-number checks but are not real card accounts. This IBAN generator follows the same approach: MOD-97-valid syntactic structure, but no real bank account behind it. Both tools serve the same QA-engineering use case: seeding test fixtures, validating client-side form rules, and testing sandbox payment processors without real financial primitives. Both come with the same warning: SYNTHETIC, never use in real transactions. The patterns and warnings are aligned to make the test-data-generation strategy consistent across financial primitives.
Can I use these IBANs in a payment form to bypass validation?
You shouldn't — the IBANs pass MOD-97 validation but real payment systems will reject them when they attempt the transfer (most reject at the moment of sender-bank verification, never actually moving funds). 'Bypassing validation' in a real payment form just delays the failure to a later stage; you won't successfully extract money. Some sandbox processors do accept these IBANs and simulate successful flows — that's intentional, for testing. If you're trying to bypass validation in a production payment system, that's likely fraud and illegal under EU PSD2, US banking regulations, and most national laws. Use synthetic IBANs only for legitimate QA workflows on systems you have authorization to test.
Can I generate IBANs for a specific bank?
Partially. The tool uses real published bank-code prefixes (Germany's Bankleitzahl, UK's Sort Code patterns, etc.), so generated IBANs route to real banks — they fail at account-number verification rather than at bank-routing. If you need an IBAN for a specific bank (e.g., 'a Deutsche Bank IBAN' or 'an HSBC UK IBAN'), look up the bank's published bank code in the SWIFT IBAN Registry and verify the generated IBAN's prefix matches. For more specific scenarios — testing a particular bank's mandate flow, or simulating IBAN handling at one specific institution — use the test IBANs provided by that bank's sandbox or by your payment processor (Stripe, Adyen, GoCardless all provide bank-specific test data).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.