GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

Payments - Introduction / Learning brief

IBAN and BIC: anatomy and validation

Your notes

What this means in plain language

Breaks down the structure of an International Bank Account Number and a Business Identifier Code, explains how the IBAN's mod-97 check digits work, and shows why validating both catches routing errors early.

An International Bank Account Number (IBAN) and a Business Identifier Code (BIC) are the two identifiers that route much of the world's cross-border money, and both are built to be checked before a payment is ever sent. An IBAN identifies one specific account: it starts with a two-letter country code, then two check digits, then a country-defined block that encodes the bank and the account number. A BIC identifies an institution — which bank, in which country, and optionally which branch. The clever part of the IBAN is the check digits. They are computed from the rest of the number by a fixed arithmetic rule, so a single mistyped or transposed character makes the arithmetic fail. Validating an IBAN and a BIC before release does not prove the money will reach the right person, but it catches a large class of typing and routing errors at the cheapest possible moment — before the payment leaves the bank.

Understand the full idea, step by step

One wrong character is all it takes for a cross-border payment to point at the wrong account. Which is exactly why the two identifiers on a payment form — the account number and the bank code — are built so that a machine can check them before anything is sent.

IBANInternational Bank Account Number

An IBAN — International Bank Account Number — identifies one specific account for payments, under the ISO 13616 standard. Read left to right, it has three parts: a two-letter country code (from the ISO 3166-1 list) saying which country's numbering scheme applies; two check digits that validate the rest; and the BBAN — the Basic Bank Account Number — whose internal layout each country defines, typically encoding the bank, sometimes a branch, and the account itself. The total length is fixed per country by the ISO 13616 registry, so an IBAN of the wrong length for its country code is malformed on sight.

BICBusiness Identifier Code

A BIC (Business Identifier Code) — defined by ISO 9362, and still widely called a SWIFT code — identifies a financial institution, not an account. It is eight or eleven characters with a fixed anatomy, and it answers a different question from the IBAN: not which account, but which institution, and where.

Anatomy of a BIC — synthetic example NRDBDEFF

Characters 1–4 — institution
NRDB — the bank's short code
Characters 5–6 — country
DE — an ISO 3166-1 country code
Characters 7–8 — location
FF — the city or processing centre
Characters 9–11 — branch (optional)
An 8-character BIC means head office; in 11 characters, XXX also means head office, anything else names a branch

Two identifiers, two jobs

In a payment the two work together. The BIC routes: it gets the instruction to the right institution. The IBAN credits: it names the account to apply the money to once the instruction arrives. Reference directories map each BIC to the institution and the network address that actually receives messages — which is why a BIC that is perfectly formed but not registered is still unusable. Form is checkable locally; reachability lives in the directory.

Illustrative string — simplified, not a real IBANXX02 9876 5432
1. Move the first four characters to the end98765432 XX02
2. Replace letters with numbers (A=10 … Z=35, so X=33)98765432333302
3. Divide by 97 and keep the remainder98765432333302 mod 97 = 1
VerdictRemainder is exactly 1 — check digits consistent

This string is deliberately short so the arithmetic is visible; real IBANs are longer and follow their country's registered format. The mechanics, though, are exactly these — the mod 97-10 scheme of ISO 7064. To create the check digits in the first place, the issuer runs the same steps with 00 in the check-digit position and uses 98 minus the remainder (here 98 − 96 = 02). A single mistyped character, or two transposed digits, almost always moves the remainder away from 1 — which is how Asha Traders' typo surfaced at the keyboard instead of abroad.

So if the remainder is 1, is the payment safe to send?

No — and this limit is worth stating plainly. Mod-97 proves the IBAN is internally consistent: nothing more. The account could be closed, never have existed, or belong to someone other than the intended payee, and the arithmetic would still pass. Validation is a cheap first filter, which is why banks pair it with directory lookups and, increasingly, with payee-name verification before release.

COMMON CONFUSION

The IBAN and the BIC are two formats for the same identifier.

They identify different things. The IBAN names one account; the BIC names one institution (and optionally a branch). A payment needs the instruction delivered to the right bank — the BIC's job — and applied to the right account — the IBAN's job. Conflating them is like confusing a building's street address with a resident's name.

STRICTLY SPEAKING

Strictly speaking, everything country-specific about an IBAN — its total length and the internal layout of its BBAN — is fixed per country by the ISO 13616 registry, which is maintained by a registration authority and updated as countries join or change formats. Validation software must apply each country's registered structure rather than assume the bank code sits in the same position everywhere, and any claim about a particular country's format should come from the registry as it currently stands, not from memory.

FOR NOW, REMEMBER

  • An IBAN identifies one account: country code, two check digits, then a country-defined BBAN, with length fixed per country by the ISO 13616 registry.
  • A BIC identifies an institution under ISO 9362: four for the institution, two for country, two for location, and an optional three-character branch code.
  • Mod-97 validation — rearrange, convert letters, divide by 97, expect remainder 1 — catches most typos and transpositions before a payment is sent.
  • Passing validation proves consistency, not existence or ownership, so banks add directory checks and payee-name verification on top.

TRY IT YOURSELF

Bank Alfa's payment screen accepts a supplier IBAN — right length for its country, and the mod-97 remainder is 1. Which error could still slip through?

The supplier closed that account last month.

Correct — Exactly. Check digits are computed from the characters of the IBAN itself — they know nothing about whether the account is open, real, or the intended payee's. Catching a closed or wrong account takes directory checks and name verification, not arithmetic.

Two digits of the account portion were transposed when keyed in.

Not this one — A transposition almost always shifts the mod-97 remainder away from 1 — catching precisely this class of error is what the check digits are for, and it is how the clerk's earlier typo was flagged.

The IBAN is three characters too short for its country code.

Not this one — Length is fixed per country by the ISO 13616 registry, and the screen confirmed the length was right for the country code. A wrong-length IBAN is malformed on sight, before mod-97 is even computed.

IBANs are exact, but nobody memorises one. What if Riya could pay a phone number instead — with a lookup layer doing the translating between the alias and the account?

KEEP GOING

Three things to remember

  1. 01

    An IBAN identifies a single account and a BIC identifies an institution, and together they route many cross-border payments.

  2. 02

    The IBAN's two check digits are computed by a mod-97 rule, so most typos and transpositions make validation fail.

  3. 03

    Validating format and check digits before release catches routing errors at the cheapest possible moment.

Where you would use this

USE CASE 01

A payment engine rejects an IBAN whose check digits fail before the instruction enters the outbound flow.

USE CASE 02

An onboarding form validates a customer's IBAN and BIC as they are typed, so errors are corrected immediately.

USE CASE 03

An operations analyst uses the country code and length of an IBAN to spot an identifier entered in the wrong field.

Put the idea into a real situation

Illustrative example: a payment engine validates a fictional IBAN, GB66 MERD 6016 1331 9268 19, before release. It moves the first four characters to the end, giving MERD60161331926819GB66, converts each letter to two digits (M=22, E=14, R=27, D=13, G=16, B=11), and divides the resulting integer by 97. The remainder is exactly 1, so the check passes. A clerk who transposes two digits and types GB66 MERD 6016 1331 9628 19 produces a remainder of 61, not 1, so the engine rejects it before the payment leaves — turning a would-be misrouted transfer into an immediate correction.

Evidence & review

REVIEWED 2026-07-13

IBANs under ISO 13616 and BICs under ISO 9362, wherever used. Per-country IBAN lengths and BBAN layouts are defined by the ISO 13616 registry and are deliberately not listed here.

What this brief simplifies: The mod-97 walkthrough uses a deliberately short synthetic string; real IBANs are longer and country-formatted. Directory and reachability mechanics are compressed to their role in validation.

Sources for this brief2
  1. Official requirement

    SwiftRef reference data servicesSwift · ISO 13616 IBAN structure and registry; ISO 9362 BIC anatomy; BIC directories

    Describes the directories Swift publishes as a reference-data utility, including the BIC Directory, Bank Directory Plus, IBAN Plus, the Standing Settlement Instructions Directory, and the SEPA Routing Directory. · Checked 2026-07-13

    Used for public summaries of the SwiftRef directories and their delivery through files, a web application, and application programming interfaces.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal · Synthetic shortened mod-97 example and fictional BIC

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

View Payments - Introduction archive

BIC versus LEI: payment reference data

A BIC (Business Identifier Code) identifies a financial institution so a payment can be routed to it, while an LEI (Legal Entity Identifier) identifies a legal entity for transparency. The two are structured differently and complement each other in modern payments.

READ BRIEF

Misc Payment Concepts

Provides a compact glossary of foundational terms such as SWIFT, SEPA, ISO 20022, payment infrastructures, and related standards.

READ BRIEF

Charges and FOREX (FX)

Explains common payment charge allocations and how foreign-exchange conversion and margins affect cross-currency transfers.

READ BRIEF