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 correctly formatted IBANs for 34 European countries including Germany, France, UK, Spain, Italy, and more. 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 IBANs with the correct length, country format and MOD-97 check digits, made up from random digits and letters. 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 (34 are available)
Choose the number of IBANs to generate (1, 5, 10, 50, 100 or 500)
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 follow each country's IBAN length and account-number format, but the bank code and account number are random, so 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 countries (the tool covers 34 European countries, including most SEPA members). (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 34 European countries: Andorra (AD), Austria (AT), Belgium (BE), Bulgaria (BG), Switzerland (CH), Cyprus (CY), Czech Republic (CZ), Germany (DE), Denmark (DK), Estonia (EE), Spain (ES), Finland (FI), France (FR), United Kingdom (GB), Greece (GR), Croatia (HR), Hungary (HU), Ireland (IE), Iceland (IS), Italy (IT), Liechtenstein (LI), Lithuania (LT), Luxembourg (LU), Latvia (LV), Monaco (MC), Malta (MT), Netherlands (NL), Norway (NO), Poland (PL), Portugal (PT), Romania (RO), Sweden (SE), Slovenia (SI) and Slovakia (SK). Each country's IBAN length and account-number structure follows the SWIFT IBAN Registry (for example Germany is 22 characters, Belgium is 16). Countries outside this list, such as Turkey, the UAE, Saudi Arabia and Israel, are not supported.
Why is MOD-97 validity not the same as a real account?
An IBAN has two parts: the country code + check digits, followed by the BBAN (Basic Bank Account Number). MOD-97 validates the math relationship between the check digits and the rest of the IBAN. But the BBAN encodes the bank code (e.g., DE uses an 8-digit Bankleitzahl) and the account number — these point to specific banks and specific accounts. This generator fills the BBAN with random characters in the right pattern for the country, so even the bank-code part is random and usually doesn't match a real bank, and the account number almost certainly doesn't exist. A 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?
No. The bank code is random, so you can't pick a bank, and generated IBANs generally don't carry a real bank's code. If you need an IBAN for a specific bank (e.g., 'a Deutsche Bank IBAN' or 'an HSBC UK IBAN'), use the test IBANs provided by that bank's sandbox or by your payment processor, which publish bank-specific test data for testing mandate flows and IBAN handling at one specific institution.
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.