What Is an IBAN?

What an IBAN is and where you meet it

An IBAN identifies one bank account. It was designed so that payments can be processed automatically: a bank receiving a transfer can check the number and route it without anyone reading it, and the same layout works on paper. ISO 13616-1:2020 specifies the elements of an IBAN; the format of each country is not in the standard itself but in the IBAN Registry, which SWIFT publishes as the registration authority designated by ISO. Only a country’s national standards body or its central bank can register or change that country’s format, so the registry is the one place where lengths and layouts are official.

Saudi Arabia, the other Gulf states, Egypt, Jordan, Pakistan, the countries of Europe and many others are in the registry. The United States, Canada, Australia and India are not: accounts there are identified by an account number together with bank or branch codes, so an Indian or American account has no IBAN. If you work in Saudi Arabia or the UAE, your salary account there has one, starting with SA or AE.

An IBAN is not a SWIFT code. A BIC (Business Identifier Code, ISO 9362), which people often call the SWIFT code, identifies a bank or another institution, not an account: eight characters made of a party prefix, the country code and a suffix, plus an optional three-character branch code. An international transfer may ask for both — the BIC says which institution, the IBAN which account. Neither contains the account holder’s name. In software, IBANs turn up in many places:

• Onboarding, payroll and HR forms that ask for a salary or payout account.
• Supplier and payee records in ERP, accounting and procurement systems, and invoices that print the seller’s IBAN.
• Refund, withdrawal and payout flows in e-commerce, wallets and marketplaces.
• Bulk-payment and payroll files a company generates for its bank.
• APIs that accept a beneficiary’s IBAN and pass it on to a bank or a payment provider.

Try it: IBAN Checker

IBAN structure: country code, check digits and BBAN

Every IBAN has the same three parts. The country code is the ISO 3166-1 alpha-2 code of the country whose format the IBAN follows (SA, AE, DE). The two check digits come next and protect the whole number against typing mistakes. The rest is the BBAN (Basic Bank Account Number), the national account number, whose length and layout each country registers. The registry writes a layout in a compact notation: n stands for digits, a for upper-case letters, c for letters or digits, and a number followed by ! for a fixed count, so 2!n18!c means exactly two digits followed by exactly eighteen letters or digits. The registry also gives the position of the bank identifier inside the BBAN and, for some countries, of a branch identifier such as the British sort code.

Lengths are fixed within a country but differ between countries: 15 characters for Norway, 22 for Germany and the United Kingdom, 23 for the United Arab Emirates, 24 for Saudi Arabia and Pakistan, 29 for Egypt and Qatar, 30 for Kuwait and Jordan, 33 for Russia. ISO 13616 allows at most 34. A length check therefore needs the country first, and a field limited to 24 characters for Saudi IBANs cuts every Kuwaiti and Qatari one short.

An IBAN has two written forms. The electronic form has no spaces and is the one to store, compare and send to other systems. The print form splits it into groups of four characters separated by spaces, the last group possibly shorter, so that people can read and copy it; on paper it is often preceded by the word IBAN. Both are the same IBAN, so software should accept either and store the electronic one.

One IBAN, two forms (the SWIFT IBAN Registry example for Saudi Arabia)
Electronic   SA0380000000608010167519no spaces: store, compare and send this
Print        SA03 8000 0000 6080 1016 7519groups of four: show and print this

SA  03  80  000000608010167519
SA                      country code (ISO 3166-1 alpha-2)
    03                  check digits, 02 to 98 (ISO/IEC 7064 MOD 97-10)
        80              bank code: 2 digits (2!n), characters 5-6
            000000608010167519   account number: 18 letters or digits (18!c)

National formats in the SWIFT IBAN Registry, with the registry's own example IBANs
Country               Length  BBAN layout   Bank codeExample
Norway (NO)           15      4!n6!n1!n     characters 5-8NO9386011117947
Germany (DE)          22      8!n10!n       characters 5-12DE89370400440532013000
United Kingdom (GB)   22      4!a6!n8!n     characters 5-8GB29NWBK60161331926819 (sort code 9-14)
United Arab Emirates  23      3!n16!n       characters 5-7AE070331234567890123456
Saudi Arabia (SA)     24      2!n18!c       characters 5-6SA0380000000608010167519
Pakistan (PK)         24      4!a16!c       characters 5-8PK36SCBL0000001123456702
Egypt (EG)            29      4!n4!n17!n    characters 5-8EG380019000500000000263180002
Qatar (QA)            29      4!a21!c       characters 5-8QA58DOHB00001234567890ABCDEFG
Kuwait (KW)           30      4!a22!c       characters 5-8KW81CBKU0000000000001234560101

Layout notation: n = digits, a = upper-case letters, c = letters or digits;
a number with ! = exactly that many. 2!n18!c = exactly 2 digits, then exactly 18 letters or digits.

Try it: IBAN Checker

The Saudi IBAN: 24 characters starting with SA

A Saudi IBAN is 24 characters long and always starts with SA: two check digits, a two-digit bank code, then an 18-character account number (registry layout 2!n18!c). The bank code is characters 5 and 6, so in the registry example SA03 8000 0000 6080 1016 7519 the check digits are 03, the bank code is 80 and the account part is 000000608010167519. The Saudi format has no separate branch code, and the registry defines the account part as letters or digits, so a field that accepts only digits after SA is stricter than the registry.

The Saudi Central Bank (SAMA) also regulates how banks present the IBAN to customers. Its 2009 circular Printed IBAN Account Formats asks banks to print it on statements and other customer documents in groups of four characters, each group separated by a blank space or a dash, while the electronic IBAN has no separators. A 2010 circular lets banks give customers their IBAN on a certificate on the bank’s letterhead, or in the bank’s part of a claims form, so that it is not mistyped when entered by hand. For testing, it follows that Saudi users will paste IBANs with spaces and with dashes, and a form that rejects either rejects what a Saudi bank printed.

Your own IBAN comes from your bank: it is assigned to your account and shown in the bank’s app, on statements and on an IBAN certificate. No website can generate a personal IBAN. A generator produces numbers that are well formed, which is useful for testing software and useless, or worse, for receiving money. Points to cover when a product serves Saudi users:

• Exactly 24 characters with SA, in electronic form and in print form with spaces or dashes.
• Arabic interfaces: the IBAN must stay left to right inside right-to-left text, on screen, in e-mails and in PDFs, and copy as one unbroken value.
• Arabic-Indic digits typed on an Arabic keyboard: convert them to 0–9 or say clearly that they are not accepted.
• If the form also asks for the bank, test what happens when the chosen bank and the bank code inside the IBAN disagree.
• Error messages in Arabic that name the rule that failed — length, characters or check digits — rather than a generic “invalid”.

Try it: IBAN Checker Try it: Test IBAN Generator

How the MOD-97 check digits work

The two check digits are computed with MOD 97-10 from ISO/IEC 7064, a family of check-character systems made to catch the errors people make when they copy or key data. To check an IBAN, remove the spaces, move the first four characters (the country code and the check digits) to the end, replace every letter with two digits (A = 10, B = 11 … Z = 35), read the result as one large number and divide it by 97. If the remainder is 1, the check digits match the rest of the IBAN.

The bank that issues an IBAN runs the same calculation the other way round: it puts 00 in place of the check digits, computes the remainder and subtracts it from 98. That is why genuine check digits always lie between 02 and 98. The values 00, 01 and 99 are never issued, yet they can still leave a remainder of 1, because modulo 97 the value 99 behaves like 02, 00 like 97 and 01 like 98. A validator must therefore check the range as well as the remainder.

The number is too large for ordinary arithmetic: a Saudi IBAN becomes a 26-digit number, a Kuwaiti one 36 digits and a Qatari one 42. A 64-bit floating-point number keeps only about 15 to 17 significant digits, so Number(…) % 97 in JavaScript, or a double in any language, returns a wrong remainder — 27 instead of 1 for the Saudi example. Use a big-integer type (BigInt in JavaScript, BigInteger in Java and .NET, int in Python), or compute the remainder in pieces: take the first nine digits, replace them with their remainder, append the next digits and repeat.

MOD-97 check of SA0380000000608010167519 (ISO/IEC 7064 MOD 97-10)

1. Remove spaces, make upper case          SA0380000000608010167519
2. Move the first 4 characters to the end  80000000608010167519SA03
3. Letters to numbers (A = 10 ... Z = 35)  S = 28, A = 10
                                           80000000608010167519 28 10 03
                                           -> 80000000608010167519281003 (26 digits)
4. Remainder after dividing by 97          80000000608010167519281003 mod 97 = 1
5. Remainder 1: the check digits match the rest of the IBAN

The same remainder in pieces, nine digits at a time (no big-number type needed)
800000006 mod 97 = 72     first nine digits
720801016 mod 97 = 30     72 followed by the next seven digits
307519281 mod 97 = 84     30 followed by the next seven digits
84003     mod 97 = 1      84 followed by the last three digits

How the check digits 03 were computed when the IBAN was issued
80000000608010167519 + SA + 00 -> 80000000608010167519281000
80000000608010167519281000 mod 97 = 95, check digits = 98 - 95 = 03

The precision trap (JavaScript; the same happens with any 64-bit float)
Number("80000000608010167519281003") % 97   -> 27   wrong: 26 digits exceed a double
BigInt("80000000608010167519281003") % 97n  -> 1n   right

Try it: IBAN Checker

What a valid IBAN proves — and what it does not

A valid result means the IBAN is well formed: a country code that is in the registry, the right length and layout for that country, and check digits that match. Tried on the SWIFT registry examples of ten countries, the MOD-97 check caught every digit replaced by another digit, every letter replaced by another letter and every swap of two different neighbouring characters, in line with what ISO/IEC 7064 states for these systems; with two characters wrong at once, just under one variation in a hundred still passed. ISO/IEC 7064 also says what the check is not for: it excludes the detection of deliberate falsification, because anyone can compute correct check digits for any account number.

So a format check is the right first gate — it stops typing mistakes before a payment is rejected or returned — but it is not a verification of the account. A valid IBAN cannot tell you:

• That the account exists, is open or can receive money: a closed account has a perfectly valid IBAN.
• Who owns it: the IBAN holds no name. Confirm the beneficiary with the payee, or with your bank when you add the payee.
• Which bank it is, by name: the bank code is inside the IBAN, but turning it into a name or a BIC needs a maintained bank directory.
• That the national account number is right: many countries add their own check digits inside the BBAN (the French RIB key, the Italian CIN), which MOD-97 does not cover.
• That it is safe to pay: invoice fraud often arrives as an e-mail announcing a “new IBAN” for a known supplier, and that IBAN passes every check. Confirm any change through a number or channel you already trust.

What the MOD-97 check caught on the SWIFT registry examples
(SA, AE, KW, QA, EG, JO, BH, GB, DE, FR; every variation of each example tried)

One digit replaced by another digit                 all caught
One letter replaced by another letter               all caught
Two different neighbouring characters swapped       all 190 caught
Two characters replaced at once                     0.94% still pass (sample of 159,504)
A wrong account with check digits computed for it   passes: the check is not a security control

SA0380000000608010167519    remainder 1    valid
SA0380000000608010167518    remainder 71   last digit mistyped: invalid
SA0380000000608010167159    remainder 78   5 and 1 swapped: invalid

Try it: IBAN Checker

How to test an IBAN input field

An IBAN field is a small input with a long list of conditions. Test it at three levels: the input (what users type and paste), the validation (each rule on its own, with a message that says which one failed) and what happens afterwards (storage, display and, in a sandbox, the payment itself). Write the expected result of every case before you run it. Several cases — dashes, a leading IBAN label, Arabic-Indic digits — are product decisions rather than bugs until someone decides them, so raise them as questions during requirements review.

• Valid inputs: every country the product supports, in electronic and print form, in upper and lower case.
• Normalization: spaces, the IBAN label, dashes, invisible characters copied from PDFs and chat apps, and native digits.
• Each rule failing on its own: one character too few and one too many, a letter where the registry requires digits, a mistyped digit, two neighbouring characters swapped, check digits 00, 01 or 99, a country code without an IBAN format, and a country the business does not serve.
• Boundaries: the shortest and the longest supported country, 34 characters, an empty field and a very long paste.
• Messages: name the failed rule, keep the input, and never answer a format error with “account not found”.
• Server side: the API, file imports and bulk uploads apply the same rules; the browser check is a convenience, not a control.
• Display and privacy: groups of four on screen; IBANs masked in logs, e-mails and analytics, and never put in URLs.

IBAN field test cases: expected results for a form that accepts Saudi and foreign IBANs

Input                                       Expected
SA0380000000608010167519                    accepted
sa03 8000 0000 6080 1016 7519               accepted, stored as SA0380000000608010167519
IBAN SA03 8000 0000 6080 1016 7519          label removed and accepted, or a message (decide)
SA03-8000-0000-6080-1016-7519               dashes removed and accepted, or a message (decide)
SA03 8000 0000 6080 1016 751٩               Arabic-Indic digit read as 9, or a message (decide)
SA0380000000608010167519 + zero-width space accepted after removing the invisible character
SA0380000000608010167518                    rejected: check digits do not match (typo)
SA0380000000608010167159                    rejected: check digits do not match (5 and 1 swapped)
SA038000000060801016751                     rejected: 23 characters, a Saudi IBAN has 24
SAO380000000608010167519                    rejected: letter O where the check digits must be digits
check digits 00, 01 or 99                   rejected, even when the remainder is 1
US or IN followed by digits                 rejected: no IBAN format registered for the country
GB29NWBK60161331926819                      accepted if foreign IBANs are allowed, else "Saudi IBAN required"
KW81CBKU0000000000001234560101              accepted: 30 characters, so no Saudi-only maxlength
(empty)                                     "IBAN is required" when the field is mandatory

Shape checks with regular expressions (they cannot verify the check digits)
Any IBAN, electronic form   ^[A-Z]{2}[0-9]{2}[A-Z0-9]{11,30}$
Saudi IBAN                  ^SA[0-9]{4}[A-Z0-9]{18}$
UAE IBAN                    ^AE[0-9]{21}$

Try it: IBAN Checker Try it: Regex Tester Try it: Regex Generator

Test IBANs: registry examples, generators and sandboxes

A test IBAN, valid IBAN for testing or dummy IBAN is a number that a validator accepts and that is safe to use in a test environment. A regular expression can check the shape of one — the patterns above — but not its check digits, so test data must come from somewhere that computes them. There are three sources, each for a different job:

• Registry examples: the IBAN Registry gives one example per country, such as SA0380000000608010167519, DE89370400440532013000 and GB29NWBK60161331926819. They are documentation data that every validator should accept, which makes them the right fixed values for unit tests and for a quick manual check.
• Generated IBANs: a generator builds IBANs with the right length, layout and check digits, for volume and variety — hundreds of rows across several countries, plus rows with deliberately wrong check digits for negative tests. The Test IBAN Generator uses fictional letter bank codes (TEST, DEMO, MOCK) where a country’s bank code is letters; numeric bank codes are random and can coincide with a real bank, so a generated number could, by chance, be a real account.
• Sandbox accounts: to test an actual transfer, use the test accounts documented by the bank or the payment provider whose sandbox you are calling. Only that test environment knows how its accounts behave — accepted, rejected or returned.

Try it: Test IBAN Generator Try it: IBAN Checker

IBAN testing checklist and common mistakes

Never send money to a registry example or a generated IBAN, and never copy a colleague’s or a customer’s real IBAN into test data: it is personal financial data, and generated or masked values do the same job. Copy the checklist into a test plan or into a story’s acceptance criteria and strike out what does not apply. These mistakes let IBAN defects through:

• One length for every country: a field or a pattern written for Saudi IBANs rejects every Kuwaiti, Qatari and Egyptian one.
• Floating-point arithmetic for MOD-97: wrong remainders for numbers of 17 digits and more, so valid IBANs are rejected and invalid ones accepted.
• No range check: check digits 00, 01 and 99 pass the remainder test.
• Rejecting what banks print: spaces, dashes, lower case and the word IBAN in front.
• Treating “valid” as “verified”: a green tick that says “account verified” after a format check.
• Validating only in the browser: imports and APIs skip the check.
• Real IBANs in test data, logs, bug reports or screenshots.

IBAN field test checklist

Input
[ ] Spaces, lower case and a leading "IBAN" label accepted and normalized
[ ] Dashes and other separators: removed, or rejected with a clear message
[ ] Arabic-Indic and other native digits: converted to 0-9, or rejected clearly
[ ] Invisible characters from copy and paste (zero-width space, direction marks) removed
[ ] 34 characters plus spaces fit; a longer paste is handled, not silently cut

Validation
[ ] Country code is in the IBAN registry and allowed by the business rule
[ ] Length matches the country (SA 24, AE 23, DE 22, GB 22, QA 29, KW 30 ...)
[ ] BBAN layout matches the registry (digits where digits are required)
[ ] Check digits between 02 and 98, and the MOD-97 remainder is 1
[ ] Big-integer or piecewise arithmetic, never a 64-bit float
[ ] The same rules on the server, for the API and for file imports
[ ] The message names the rule that failed and keeps what the user typed

Storage and display
[ ] Stored in electronic form (no spaces, upper case)
[ ] Shown in groups of four; left to right inside Arabic text
[ ] Masked where the full IBAN is not needed (logs, e-mails, screenshots, analytics)

Beyond the format
[ ] "Valid" never shown as "account verified"
[ ] A change to a saved IBAN confirmed through a channel the owner already uses
[ ] Transfers tested only in the bank's or payment provider's sandbox
[ ] No real customer or employee IBAN in test data

Try it: IBAN Checker

Frequently asked questions

References

• ISO 13616-1:2020 — Financial services — International bank account number (IBAN) — Part 1: Structure of the IBANISO · 2020The international standard for the IBAN: a country code, two check digits and the national account number, designed for automated processing and usable on paper; SWIFT keeps the national formats as its registration authority.
• IBAN RegistrySWIFTThe official register of national IBAN formats (length, structure and check-digit rules per country), maintained under ISO 13616.
• ISO/IEC 7064:2003 — Information technology — Security techniques — Check character systemsISO/IEC · 2003The check character systems, MOD 97-10 among them, that protect strings against copying and keying errors — all single substitutions, nearly all transpositions — and by design do not detect deliberate falsification.
• Printed IBAN Account Formats (circular 301000000391)Saudi Central Bank (SAMA) · 2009SAMA instructs banks to print the IBAN for customers in groups of four characters separated by a blank space or dashes; the electronic IBAN has no separators.
• Providing Bank Customers Their IBAN Numbers (circular 311000022538)Saudi Central Bank (SAMA) · 2010SAMA lets banks give customers their IBAN on a certificate on the bank’s letterhead, or in the bank’s part of a claims form, to avoid errors from entering it by hand.
• Business Identifier Code (BIC)SWIFTThe BIC (ISO 9362), issued by SWIFT as registration authority: an 8-character code for an institution — party prefix, country code, suffix — plus an optional 3-character branch code; it identifies a party, not an account.