How IBAN Works
An IBAN is constructed from a fixed sequence of fields defined by the ISO 13616 standard. Each segment carries specific information that banks and payment networks use to locate the destination account without ambiguity. Understanding the structure helps merchants validate IBANs before submitting a wire transfer and helps developers build reliable collection flows.
Country Code
The first two characters are an ISO 3166-1 alpha-2 country code — for example, DE for Germany, GB for the United Kingdom, or FR for France. This tells the receiving bank's system which national format rules to apply when parsing the rest of the string, ensuring the BBAN segment is interpreted correctly.
Check Digits
Characters three and four are two numeric check digits calculated using the MOD-97 algorithm. They allow any bank or payment system to detect typos or transposition errors before a payment is initiated — catching mistakes that would otherwise cause returns, delays, or misrouted funds that are expensive to recover.
Basic Bank Account Number (BBAN)
The remaining characters form the BBAN, which is the domestic account identifier used within the originating country. The BBAN structure — and therefore total IBAN length — differs by country. A German IBAN encodes an 8-digit bank code and a 10-digit account number, while a UK IBAN encodes a 6-digit sort code and an 8-digit account number.
MOD-97 Validation
Before transmission, the IBAN is validated by rearranging it so the country code and check digits move to the end, converting letters to digits (A=10, B=11 … Z=35), and confirming the resulting integer modulo 97 equals 1. Any result other than 1 means the IBAN is structurally invalid and the payment must be rejected immediately.
Pairing with a BIC for Routing
Once validated, the IBAN is typically paired with a BIC (Bank Identifier Code) to route the payment message to the correct financial institution. Within the SEPA zone, the BIC can often be derived automatically from the IBAN, making it technically optional for domestic SEPA transactions — though including it remains good practice for international flows.
Why IBAN Matters
IBAN adoption has reshaped international payments by giving every bank account a globally unique, machine-readable address. Before IBAN, cross-border transfers relied on inconsistent domestic account formats that were error-prone, slow to reconcile, and costly to return. The statistics below illustrate just how central IBAN has become to global payment infrastructure.
- 76+ countries have formally adopted the IBAN standard as of 2025, covering the entire SEPA zone, the Middle East, and parts of Africa and the Caribbean (SWIFT IBAN Registry, 2025).
- 51.5 billion bank transfer transactions were processed across the SEPA zone in 2023 alone, every one of them relying on a valid IBAN for routing (European Payments Council Annual Report, 2024).
- Payment return rates for international transfers drop by an estimated 70% when senders pre-validate IBANs before submission, according to benchmarks published by major European clearing banks — a direct impact on reconciliation costs and customer experience.
SEPA Compliance Requirement
Since February 2016, all Euro-denominated credit transfers and direct debit mandates within the SEPA zone must use the IBAN format. Providing only a domestic account number is no longer accepted by SEPA-compliant banks, and non-compliant transactions are rejected at the gateway level.
IBAN vs. SWIFT Code
IBAN and SWIFT codes are frequently confused because both appear on international payment forms, but they serve entirely different purposes. The IBAN identifies the destination account; the SWIFT/BIC code identifies the destination bank. Think of the IBAN as a street address and the SWIFT code as the postal code and city — you need both to deliver a payment reliably across borders.
| Attribute | IBAN | SWIFT / BIC Code |
|---|---|---|
| Purpose | Identifies a specific bank account | Identifies a bank or branch |
| Length | 15–34 alphanumeric characters | 8 or 11 alphanumeric characters |
| Structure | Country code + check digits + BBAN | Bank code + country + location + branch |
| Required for SEPA | Yes, mandatory | Optional (auto-derived within SEPA) |
| Required internationally | Yes | Yes |
| Built-in validation | Yes — MOD-97 check digits | No built-in checksum |
| Primary use | Payment destination routing | Interbank message routing |
| Issued by | National banking authority | SWIFT organization |
Types of IBAN
IBAN appears in two standard format variants, and some regions have introduced locally extended formats. Knowing which format to use and when prevents silent failures in payment APIs and reduces manual processing errors in back-office workflows.
Electronic Format (E-IBAN): No spaces, all uppercase — for example, GB29NWBK60161331926819. This is the machine-readable format required by all payment systems, APIs, and SWIFT messages. Any spaces in electronic format will cause MOD-97 validation to fail and the payment will be rejected.
Paper Format (P-IBAN): Grouped into blocks of four characters separated by spaces — for example, GB29 NWBK 6016 1331 9268 19. This is a human-readable convenience format printed on bank statements, invoices, and payment instruction letters. Never store or transmit this format in a programmatic context.
QR IBAN (Switzerland): Switzerland introduced a QR-IBAN variant alongside its QR-bill payment system. QR IBANs begin with CH but use a specific IID range (30000–31999) reserved for QR billing. They are only valid within the Swiss QR-bill standard and cannot be used for standard IBAN credit transfers — mixing them causes immediate rejections.
Best Practices
IBAN handling is an area where small implementation details have an outsized impact on payment success rates and operational overhead. The guidelines below separate merchant-facing operational concerns from technical implementation requirements for engineering teams.
For Merchants
- Always collect the full IBAN as a single field — never ask customers to split it into country code and account number separately; splitting increases transcription errors and complicates validation.
- Display the paper format for readability — show IBANs in spaced four-character groups on invoices and confirmation emails so customers can verify them against their bank statement at a glance.
- Re-validate before retrying a failed payment — if a transaction returns due to an invalid account, ask the customer to re-enter and reconfirm the IBAN rather than retrying the same value blindly.
- Store IBANs encrypted at rest — IBANs combined with a name constitute sensitive financial data; treat them with the same care as card numbers and log only masked versions (e.g.,
GB29****6819). - Confirm currency compatibility — an IBAN identifies an account, not the currencies it supports; verify that the destination account accepts the target currency before initiating a transfer.
For Developers
- Validate on the client before the API call — implement MOD-97 validation in the browser or mobile app to surface formatting errors before a network round-trip is made to your payment provider.
- Normalize input immediately — strip all whitespace and convert to uppercase on receipt; never rely on users formatting the IBAN correctly.
- Use the electronic format in all API payloads — never send spaced or lowercase IBANs to a payment provider or in a SWIFT message field.
- Validate country-specific lengths dynamically — build validation against the SWIFT IBAN Registry rather than hardcoding a single maximum length; Norway's IBAN is 15 characters while Malta's is 31.
- Cache BIC lookups — if your stack auto-derives the BIC from the IBAN, cache the result to avoid redundant registry calls when the same IBAN appears in multiple transactions.
Common Mistakes
Even experienced payment teams make recurring IBAN errors that lead to returns, processing delays, and reconciliation costs. These five mistakes account for the majority of IBAN-related payment failures.
1. Confusing IBAN with BIC/SWIFT. Submitting a BIC in the IBAN field (or vice versa) is the single most common data-entry mistake on payment forms. Both are alphanumeric and visually similar; use strict field-level format validation — checking prefix characters and length — to catch this before submission.
2. Sending the paper format electronically. Spaces in an IBAN string will fail MOD-97 validation and be rejected by the vast majority of payment APIs. Always strip all whitespace and normalize to uppercase before sending any IBAN over a network interface.
3. Assuming a fixed IBAN length. Hard-coding a maximum of 22 characters — common for UK and German IBANs — silently truncates longer IBANs from France (27 characters), Italy (27), or Malta (31), corrupting the account number and guaranteeing a return. Always reference the SWIFT IBAN Registry for per-country lengths.
4. Skipping pre-flight validation. Sending an invalid IBAN to a payment processor costs a round-trip, may incur a return fee, and delays settlement. A client-side MOD-97 check catches the vast majority of structural errors at zero marginal cost before any funds move.
5. Storing IBANs in plain text. IBANs are not in PCI DSS scope by default, but they are sensitive financial data that can enable unauthorized transfers when combined with other account information. Encrypt at rest, restrict access by role, and mask all logging output to a safe partial format.
IBAN and Tagada
Tagada's payment orchestration layer handles IBAN-based payment methods natively, including SEPA Credit Transfer and SEPA Direct Debit flows. When you configure a SEPA collection or payout through Tagada, the platform validates the IBAN format and check digits before routing the instruction to the appropriate banking rail — reducing returns and reconciliation overhead for your operations team.
IBAN Validation in Tagada
Tagada performs MOD-97 validation and country-specific length checks on every IBAN submitted through its API. If an IBAN fails validation, the API returns a structured error identifying the specific field and failure reason — so your checkout or back-office UI can surface a precise, actionable message to the user without a failed payment attempt ever reaching the clearing network.