The Spain IBAN Validator performs a three-layer structural check on any 24-character Spanish IBAN. Most online tools run only the international MOD-97 checksum; this validator goes further and also verifies the two internal CCC check digits that Spain uses on top of the IBAN standard — the same checks your bank’s systems apply when processing a domestic transfer.
The tool is aimed at developers integrating Spanish bank account fields, finance teams reconciling payment files, and anyone who wants to understand why a Spanish IBAN passes or fails, not just that it does.
How a Spanish IBAN is structured
A Spanish IBAN is always exactly 24 characters long. The characters break down left-to-right like this:
| Position | Length | What it is |
|---|---|---|
| 1–2 | 2 | Country code: always ES |
| 3–4 | 2 | IBAN check digits (ISO 7064 MOD-97) |
| 5–8 | 4 | Bank code (entidad) |
| 9–12 | 4 | Branch code (oficina) |
| 13 | 1 | First internal CCC check digit |
| 14 | 1 | Second internal CCC check digit |
| 15–24 | 10 | Account number (numero de cuenta) |
The last 20 characters (positions 5–24) form the BBAN (Basic Bank Account Number) and also correspond to the traditional Spanish CCC (Codigo Cuenta Corriente) that predates IBAN adoption. All 20 BBAN characters must be digits.
The three validation layers
Layer 1 — ISO 7064 MOD-97-10 (the IBAN standard checksum)
This algorithm is defined in ISO 13616 and applies to every IBAN in the world. The steps are:
- Move the first four characters (
ES+ two check digits) to the end of the string. - Replace every letter with its two-digit numeric equivalent:
Abecomes10,Bbecomes11, through toZwhich becomes35. For a Spanish IBAN onlyEandSneed substituting (E = 14,S = 28). - Interpret the entire digit string as one large integer and compute its remainder when divided by 97.
- The IBAN is valid under this layer only if the remainder equals exactly 1.
Because the digit string can be very long, the remainder is computed
progressively — one digit at a time using (remainder * 10 + digit) mod 97 —
so no arbitrary-precision arithmetic is needed.
Layer 2 — First internal CCC check digit (bank + branch)
Spain’s Algoritmo D applies a weighted sum to the 8 digits formed by
concatenating bank code and branch code, prepended with a 0 to give a
9-character input. The weights cycle as 1-2-4-8-5-10-9-7-3-6. After
summing the products, the total is reduced modulo 11, and the result is mapped
through the table {0:1, 1:0, 2:9, 3:8, 4:7, 5:6, 6:5, 7:4, 8:3, 9:2, 10:1}
to produce the expected check digit. The digit at position 13 of the IBAN
must match.
Layer 3 — Second internal CCC check digit (account number)
The same Algoritmo D is applied to the 10-digit account number directly (no leading zero prepended). The digit at position 14 of the IBAN must match the computed value.
Worked example
Take the test IBAN ES91 2100 0418 4502 0005 1332 (all spaces removed:
ES9121000418450200051332):
- Country:
ES - IBAN check digits:
91 - Bank code:
2100(CaixaBank) - Branch code:
0418 - Internal check digit 1:
4 - Internal check digit 2:
5 - Account number:
0200051332
For the MOD-97 check, rearranging gives 210004184502000513 32ES91. Expanding
E = 14, S = 28 gives a long numeric string. Computing that string mod 97
yields 1 — pass.
For check digit 1: prepend 0 to 2100 + 0418 = 021000418, apply
Algoritmo D weights 1-2-4-8-5-10-9-7-3-6 to each digit, sum, mod 11, map
through the table — the result is 4, matching position 13.
For check digit 2: apply the same weights to 0200051332 (10 digits, weights
cycle from the start), sum, mod 11, map — the result is 5, matching
position 14.
All three layers pass, so the IBAN is valid.
Privacy and offline use
All validation logic runs entirely in your browser tab. No IBAN, partial string, or timing signal is transmitted to any server. The tool contains no analytics hooks that capture form input. You can open this page, disconnect from the internet, and it will continue to work exactly the same way — making it suitable for validating sensitive financial data under GDPR or the Spanish LOPD-GDD.