International Bank Account Number

Background

Before IBAN, differing national standards for bank account identification (i.e. bank, branch, routing codes, and account number) were confusing for some users. This often led to necessary routing information being missing from payments. Routing information as specified by ISO 9362 (also known as Business Identifier Codes (BIC code), SWIFT ID or SWIFT code, and SWIFT-BIC) does not require a specific format for the transaction so the identification of accounts and transaction types is left to agreements of the transaction partners. It also does not contain check digits, so errors of transcription were not detectable and it was not possible for a sending bank to validate the routing information prior to submitting the payment. Routing errors caused delayed payments and incurred extra costs to the sending and receiving banks and often to intermediate routing banks.

In 1997, to overcome these difficulties, the International Organization for Standardization (ISO) published ISO 13616:1997. This proposal had a degree of flexibility, which the European Committee for Banking Standards (ECBS) believed would make it unworkable, and they produced a "slimmed down" version of the standard which, amongst other things, permitted only upper-case letters and required that the IBAN for each country have a fixed length. ISO 13616:1997 was subsequently withdrawn and replaced by ISO 13616:2003. The standard was revised again in 2007 when it was split into two parts. ISO 13616-1:2007 "specifies the elements of an international bank account number (IBAN) used to facilitate the processing of data internationally in data interchange, in financial environments as well as within and between other industries" but "does not specify internal procedures, file organization techniques, storage media, languages, etc. to be used in its implementation". ISO 13616-2:2007 describes "the Registration Authority (RA) responsible for the registry of IBAN formats that are compliant with ISO 13616-1 [and] the procedures for registering ISO 13616-compliant IBAN formats". The official IBAN registrar under ISO 13616-2:2007 is SWIFT.

IBAN imposes a flexible but regular format sufficient for account identification and contains validation information to avoid errors of transcription. It carries all the routing information needed to get a payment from one bank to another wherever it may be; it contains key bank account details such as country code, branch codes (known as sort codes in the UK and Ireland) and account numbers, and it contains check digits which can be validated at source according to a single standard procedure. Where used, IBANs have reduced trans-national money transfer errors to under 0.1% of total payments.

Structure

The IBAN consists of up to 34 alphanumeric characters, as follows:

The check digits enable a sanity check of the bank account number to confirm its integrity before submitting a transaction.

The IBAN should not contain spaces when transmitted electronically. When printed it is expressed in groups of four characters separated by a single space, the last group being of variable length as shown in the example below:

Permitted IBAN characters are the digits 0 to 9 and the 26 upper-case Latin alphabetic characters A to Z. This applies even in countries (e.g., Thailand) where these characters are not used in the national language.

Basic Bank Account Number

The Basic Bank Account Number (BBAN) format is decided by the national central bank or designated payment authority of each country. There is no consistency between the formats adopted. The national authority may register its BBAN format with SWIFT, but is not obliged to do so. It may adopt IBAN without registration. SWIFT also acts as the registration authority for the SWIFT system, which is used by most countries that have not adopted IBAN. A major difference between the two systems is that under SWIFT there is no requirement that BBANs used within a country be of a pre-defined length.

The BBAN must be of a fixed length for the country and comprise case-insensitive alphanumeric characters. It includes the domestic bank account number, branch identifier, and potential routing information. Each country can have a different national routing/account numbering system, up to a maximum of 30 alphanumeric characters.

Check digits

The check digits enable the sending bank (or its customer) to perform a sanity check of the routing destination and account number from a single string of data at the time of data entry. This check is guaranteed to detect any instances where a single character has been omitted, duplicated, mistyped or where two characters have been transposed. Thus routing and account number errors are virtually eliminated.

Processing

One of the design aims of the IBAN was to enable as much validation as possible to be done at the point of data entry. In particular, the computer program that accepts an IBAN will be able to validate:

The check digits are calculated using MOD-97-10 as per ISO/IEC 7064:2003 (abbreviated to mod-97 in this article), which specifies a set of check character systems capable of protecting strings against errors which occur when people copy or key data. In particular, the standard states that the following can be detected:

The underlying rules for IBANs is that the account-servicing financial institution should issue an IBAN, as there are a number of areas where different IBANs could be generated from the same account and branch numbers that would satisfy the generic IBAN validation rules. In particular cases where 00 is a valid check digit, 97 will not be a valid check digit, likewise, if 01 is a valid check digit, 98 will not be a valid check digit, similarly with 02 and 99.

The UN CEFACT TBG5 has published a free IBAN validation service in 32 languages for all 57 countries

that have adopted the IBAN standard. They have also published the Javascript source code of the verification algorithm.

An English language IBAN checker for ECBS member country bank accounts is available on its website.

Validating the IBAN

An IBAN is validated by converting it into an integer and performing a basic mod-97 operation (as described in ISO 7064) on it. If the IBAN is valid, the remainder equals 1. The algorithm of IBAN validation is as follows:

1. Check that the total IBAN length is correct as per the country. If not, the IBAN is invalid
2. Move the four initial characters to the end of the string
3. Replace each letter in the string with two digits, thereby expanding the string, where A = 10, B = 11, ..., Z = 35
4. Interpret the string as a decimal integer and compute the remainder of that number on division by 97

If the remainder is 1, the check digit test is passed and the IBAN might be valid.

Example (fictitious United Kingdom bank, sort code 12-34-56, account number 98765432):

Generating IBAN check digits

According to the ECBS "generation of the IBAN shall be the exclusive responsibility of the bank/branch servicing the account". The ECBS document replicates part of the ISO/IEC 7064:2003 standard as a method for generating check digits in the range 02 to 98. Check digits in the ranges 00 to 96, 01 to 97, and 03 to 99 will also provide validation of an IBAN, but the standard is silent as to whether or not these ranges may be used.

The preferred algorithm is:

1. Check that the total IBAN length is correct as per the country. If not, the IBAN is invalid.
2. Replace the two check digits by 00 (e.g., GB00 for the UK).
3. Move the four initial characters to the end of the string.
4. Replace the letters in the string with digits, expanding the string as necessary, such that A or a = 10, B or b = 11, and Z or z = 35. Each alphabetic character is therefore replaced by 2 digits
5. Convert the string to an integer (i.e. ignore leading zeroes).
6. Calculate mod-97 of the new number, which results in the remainder.
7. Subtract the remainder from 98, and use the result for the two check digits. If the result is a single digit number, pad it with a leading 0 to make a two-digit number.

Modulo operation on IBAN

Any computer programming language or software package that is used to compute D mod 97 directly must have the ability to handle integers of more than 30 digits. In practice, this can only be done by software that either supports arbitrary-precision arithmetic or that can handle 220 bit (unsigned) integers, features that are often not standard. If the application software in use does not provide the ability to handle integers of this size, the modulo operation can be performed in a piece-wise manner (as is the case with the UN CEFACT TBG5 Javascript program).

Piece-wise calculation D mod 97 can be done in many ways. One such way is as follows:

1. Starting from the leftmost digit of D, construct a number using the first 9 digits and call it N.
2. Calculate N mod 97.
3. Construct a new 9-digit N by concatenating above result (step 2) with the next 7 digits of D. If there are fewer than 7 digits remaining in D but at least one, then construct a new N, which will have less than 9 digits, from the above result (step 2) followed by the remaining digits of D
4. Repeat steps 2–3 until all the digits of D have been processed

The result of the final calculation in step 2 will be D mod 97 = N mod 97.

Example

In this example, the above algorithm for D mod 97 will be applied to D = 3214282912345698765432161182. (The digits are colour-coded to aid the description below.) If the result is one, the IBAN corresponding to D passes the check digit test.

1. Construct N from the first 9 digits of D N = 321428291
2. Calculate N mod 97 = 70
3. Construct a new 9-digit N from the above result (step 2) followed by the next 7 digits of D. N = 702345698
4. Calculate N mod 97 = 29
5. . Construct a new 9-digit N from the above result (step 4) followed by the next 7 digits of D. N = 297654321
6. Calculate N mod 97 = 24
7. Construct a new N from the above result (step 6) followed by the remaining 5 digits of D. N = 2461182
8. Calculate N mod 97 = 1

From step 8, the final result is D mod 97 = 1 and the IBAN has passed this check digit test.

Adoption

International bank transactions use either an IBAN or the ISO 9362 Business Identifier Code system (BIC or SWIFT code) in conjunction with the BBAN.

EEA and territories

The banks of most countries in Europe publish account numbers using both the IBAN format and the nationally recognised identifiers, this being mandatory within the European Economic Area.

Day-to-day administration of banking in British Overseas Territories varies from territory to territory — some, such as South Georgia and the South Sandwich Islands, have too small a population to warrant a banking system while others, such as Bermuda, have a thriving financial sector. The use of the IBAN is up to the local government — Gibraltar, being part of the European Union is required to use the IBAN, as are the Crown dependencies, which use the British clearing system and the British Virgin Islands have elected to do so. As of April 2013, no other British Overseas Territories have elected to use the IBAN. Banks in the Caribbean Netherlands also do not use the IBAN.

Single Euro Payments Area

The IBAN designation scheme was chosen as the foundation for electronic straight-through processing in the European Economic Area. The European Parliament mandated that a bank charge needs to be the same amount for domestic credit transfers as for cross-border credit transfers regulated in decision 2560/2001 (updated in 924/2009). This regulation took effect in 2003. Only payments in euro up to €12,500 to a bank account designated by its IBAN were covered by the regulation.

The Euro Payments regulation has been the foundation for the decision to create a Single Euro Payments Area (SEPA). The European Central Bank has created the TARGET2 interbank network that unifies the technical infrastructure of the 26 central banks of the European Union (although Sweden and the UK have opted-out). SEPA is a self-regulatory initiative by the banking sector of Europe as represented in the European Payments Council (EPC). The European Union made the scheme mandatory through the Payment Services Directive published in 2007. Since January 2008, all countries must support SEPA credit transfer, and SEPA direct debit must be supported since November 2009. The regulation on SEPA payments increases the charge cap (same price for domestic payments as for cross-border payments) to €50,000.

With a further decision of the European Parliament, the IBAN scheme for bank accounts fully replaced the domestic numbering schemes from 31 December 2012. On 16 December 2010, the European Commission published proposed regulations that will make IBAN support mandatory for domestic credit transfer by 2013 and for domestic direct debit by 2014 (with a 12 and 24 months transition period respectively). Some countries have already replaced their traditional bank account scheme by IBAN. This includes Switzerland where IBAN was introduced for national credit transfer on 1 January 2006 and the support for the old bank account numbers has not been required from 1 January 2010.

Based on a 20 December 2011 memorandum, the EU parliament resolved the mandatory dates for the adoption of the IBAN on 14 February 2012. From 1 February 2014, all national systems for credit transfer and direct debit must be abolished and replaced by an IBAN-based system. This will be extended to all cross-border SEPA transactions from 1 February 2016 (Article 5 Section 7). After these dates the IBAN will be sufficient to identify an account for home and foreign financial transactions in SEPA countries and banks will no longer be permitted to require that the customer supply the BIC for the beneficiary's bank.

In the run-up to the 1 February 2014 deadline, it became apparent that many old bank account numbers had not been allocated IBANs—an issue that has to be addressed on a country-by-country basis. In Germany, for example, the German Federal Bank and the German Banking Industry Committee require that all holders of German bank codes ("Bankleitzahl") publish the specifics of their IBAN generation format taking into account not only the generation of check digits but also the handling of legacy bank codes, thereby enabling third parties to generate IBANs independently of the bank. The first such catalogue was published in June 2013 as a variant of the old bank code catalog ("Bankleitzahlendatei").

Non-EEA

Banks in numerous non-European countries including most states of the Middle East, North Africa and the Caribbean have implemented the IBAN format for account identification. In some countries the IBAN is used on an ad hoc basis, an example being Ukraine where account numbers used for international transfers of four of the national banks have additional aliases that follow the IBAN format as a precursor to formal SWIFT registration.

The degree to which bank verifies the validity of a recipient's bank account number depends of the configuration of the transmitting bank's software—many major software packages supply bank account validation as a standard function. Some banks outside Europe may not recognize IBAN, though this is expected to diminish with time. Non-European banks usually accept IBANs for accounts in Europe, although they might not treat IBANs differently from other foreign bank account numbers. In particular, they might not check the IBAN's validity prior to sending the transfer.

Banks in the United States do not use IBAN as account numbers for U.S. accounts. Any adoption of the IBAN standard by U.S. banks would likely be initiated by ANSI ASC X9, the U.S. financial services standards development organization: a working group (WGAB20) was established as an X9 subcommittee to generate an IBAN construction for U.S. bank accounts.

Canadian financial institutions have not adopted IBAN and use bank transit numbers issued by the Canadian Payments Association for domestic transfers, and SWIFT for international transfers. There is no formal governmental or private sector regulatory requirement in Canada for the major banks to use IBAN.

Australia and New Zealand do not use IBAN. They use Bank State Branch codes for domestic transfers and SWIFT for international transfers.

IBAN formats by country

This table summarises the IBAN formats by country:

In addition to the above list, Nordea has catalogued IBANs for countries listed below.

In this list

Addition list of countries, in the process of introducing the IBAN retrieved from SWIFT partner website are listed below.

In this list

Criticism

There is criticism about the length and readability of IBAN. Printed on paper the IBAN is often difficult to read. Therefore, it is popular to group the IBAN with four symbols. However, for electronic documents (e.g. PDF invoice) the copy and paste of grouped IBAN can result in errors with online banking forms. Only a few user friendly bank institutes allow and detect the copy and paste of both grouped and ungrouped IBAN.