IBAN in Context

The need to standardize bank account numbers across international boundaries has arisen as a result of demand for higher quality, more automated, less costly and faster cross-border payments. The solution is embodied in IBAN (The International Bank Account Number) concept, which was developed by ECBS and by the International Organization for Standardization (ISO) and is an internationally agreed standard ISO 13616: 1997.

Being a viable and practical international bank identifier, it enables the recognition of a particular customer during overseas transactions. IBAN helps eliminate errors at cross-border payments and enhances the potential for straight through processing (STP), with a minimum amount of change within domestic schemes.

The main design rationale behind IBAN is to process foreign account numbers easier than the traditional scheme with regard to cost, speed and quality. The central attribute of such a process is obviously the validation of the account number in a different country from the one where the account is originally held. The IBAN design provides a standard method to enable the cross-border account number formats to be recognised and validated. In practice, the IBAN is additional information placed on the beginning of the national account number format of each country. The IBAN algorithm is quite straightforward and performed on a digit-by-digit basis on the account number to ensure that individual digits are not transposed. The IBAN commences with the ISO 3166 two-letter country code. The IBAN also implicitly demands that the holding bank of the account be unambiguously identified.

In particular, the private individual customers or small/medium sized enterprise (SME) customers experience problems when they receive payment details from abroad upon conducting a business. They are not very much familiar with the different bank account formats of the country from which they have received the invoices. When these customers delegate the task of collection of payments to their banks they mostly provide incomplete or incorrect information for cross-border STP. This situation leads to costlier transactions with delays when compared with national payment orders with which the customers are quite confident and familiar with the norms and formats. The IBAN standard was created to solve the cross-border problem. When implemented and used widely, IBAN will greatly enable the end-to-end STP of cross-border transfers.

The rewards for promoting to IBAN standards are very promising. The IBAN is, first and foremost, an account identifier. Its adoption is being driven within Europe, as it is supportive towards monetary union and the preparation of a "Euro-domestic" payment system. The IBAN contains all information needed to route a payment order through any national clearing system (i.e., national bank code also called clearing or sorting code and the account number itself). Thus the IBAN could, given clearing system changes, be used to feed inbound foreign payments to the national clearing system without any preceding table conversion as is done today when the beneficiary's bank is identified by the BIC. However, at the present time, there is only a very scant awareness of the ISO standard worldwide. It will take considerable effort, and an essentially long elapsed time, before IBANs are used in a majority of worldwide cross-border transactions.

It is therefore somewhat too early to consider IBAN as a cross-border routing tool in the short-to medium term. But it is fruitful to think about the implications of adopting the IBAN as a routing tool eventually, in order to create a long-term strategic plan. Cross-Border Routing Banks want to avoid intermediaries in order to reduce the time taken in processing commercial payments to a minimum. Consequently they wish to address payment messages directly to the beneficiary's bank or, in the case of mass payments, to a preferred correspondent bank in the country of the beneficiary's bank.

The BIC code of the beneficiary's bank will be required alongside the IBAN because the IBAN cannot be used as a routing tool until:

• IBANs are validated on input of payment orders/credit transfers for processing; and

• The routing mechanisms are generally able to recognise and interpret IBANs from all over the world.

The routing mechanisms will need to be able to interpret all IBANs to optimize network routing. As a first, simple, stage they will need to recognise the country code. At the second, more sophisticated, stage they will need to recognise the bank identification within that country by understanding the various national formats.

The routing mechanism operating outside the destination country initially only needs to recognise the destination country from the IBAN, in order to pass the transaction cross-border. The ordering bank then has the choice of sending the payment to their contractual partner in that country (mass payments), or sending the payment direct to the beneficiary's bank on establishing its identity within the destination country (direct routing). Only the routing mechanism operating inside the destination country needs to know the full construction of its own country's IBAN. It also needs access to the authoritative and up-to-date version of its own country's ‘sort code directory' or equivalent. Until IBAN can be used with confidence as a routing tool, it is essential to rely on the BIC of the beneficiary's bank as, for example, in SWIFT FIN messages. Therefore we have to accept a period while such BIC codes will run alongside IBANs, and the inherent redundancy of the two overlapping concepts, while IBAN adoption spreads across the world. For example, the International Payment Instruction (IPI) supports the combination of IBAN and BIC. We also have to accept that at some, probably relatively distant, future point the banking community will have to convince and request SWIFT to make the BIC an optional field overriding the IBAN rather than a mandatory field regardless of whether the account number is an IBAN or not. (BICs may continue to be required by specific applications, even if SWIFT does not.)

For further information, please do not hesitate to contact us.