SEPA & STP: An IBAN & BIC Update
On 28 January 2008, the major European banks successfully sent their first live single euro payments area (SEPA) credit transfers. This marks a great achievement for the European banking sector after a lengthy and challenging preparation phase. Although SEPA still has much to deliver in the coming months, this is a significant first milestone.
More than 4,000 financial institutions have signed the European Payments Council (EPC) adherence agreement and are ready to receive and process SEPA Credit Transfer (SCT) instruments according to the EPC rulebook. Global transaction banks are committed to being able to receive credit transfers and to send them to their cross-border correspondents.
High straight-through processing (STP) rates and low processing costs are a prerequisite for the success of SEPA. The SEPA payment flows are a conversion of the old, cross-border payments within Europe, which now have to achieve the same levels of STP and the same processing cost as national payments.
The efficiency of national payments heavily depends on domestic bank identifiers, account numbers, and clearing and settlement systems. These are well managed and have been fine-tuned because they are local and have been supporting large volumes of traffic for many years. Now, SEPA payments have to achieve the same level of efficiency, while adopting international identifiers for banks and accounts, as well as new clearing and settlement systems.
A significant threat to the STP of SCTs are misrouted messages caused by the wrong selection of the clearing and settlement channel and the sender’s lack of awareness of the recipient’s operational readiness for SEPA. For each SCT, the sender will have to know whether the receiver is able to process it or not. The receiver identity can be as granular as a bank identifier code (BIC) or branch code of an institution and, unfortunately, the EPC’s register of participants doesn’t go into that level of detail. There must be an accurate translation of the EPC’s registry entry into the granular, operational BIC of the receiving institution.
Obviously, accurately translating a high level identifier into many granular ones is not an easy task, because not all granular destinations will be ready for SEPA. SWIFT has taken this challenge on by asking thousands of financial institutions to provide and validate the translation accurately in SWIFT’s SEPA routing directory, and to provide the list of SEPA-capable clearing and settlement channels through which the institutions can be reached. This data is volatile, however, as the clearing and settlement landscape in SEPA is expected to keep changing for a while. Producing an up-to-date, consolidated list of channels is a challenge in itself.
Another threat to STP is the incorrect identifiers used in the SCTs. The international bank account numbers (IBANs) identifying the payer and the beneficiary, and the BIC identifying the sending and receiving institutions and, in some cases intermediary institutions, have to be correct to be able to match the 95+% STP rates of domestic traffic. For domestic traffic, national authorities such as central banks and banking associations manage the national bank identifier to a high degree of accuracy and because in many countries they are an integral part of the account number, the relationship between the bank identifier and the account number is straightforward.
With SEPA, however, there is no central operational authority that can practically enforce and validate the relationships between IBANs and BICs – the banks are on their own. Either they build their own solutions, which, given the amounts of data (billions of IBANs, 220,000 national identifiers used in IBANs and 60,000 BICs) can only result in work-arounds such as elementary validations, or they can rely on commercial database offerings.
So what can a bank do with incorrect IBANs and BICs? One option is to refuse the customer’s payment instruction. This is a safe method but does not provide a good customer service. Another option is to provide a data repair service. The most customer-friendly option is to add the BIC systematically to each IBAN, which requires an efficient database in order to increase the STP rates. Producing an efficient database is not a simple task though because it must contain the many anomalies that exist in the real world in the IBAN/BIC relationships.
The anomalies occur when banks issue IBANs and BICs to their customers applying non-standard rules, and therefore the BICs can no longer be linked to the IBANs based on straightforward rules. There are numerous reasons why the relationships between the IBANs and the BICs are not simple. One example is that a bank may provide its clients with IBANs of one country with BICs of their processing hub in another country.
The only way to capture the anomalies is by collecting all IBAN-BIC relationships from the beneficiary banks themselves. This is why SWIFT has opened a data collection service on its website, supported by a team of assisting banks providing the right data. At the same time, SWIFT has introduced the concept of ‘BIC issued with IBAN’ in its database. This is the BIC that the bank issues to its client together with its IBAN, and that the client can find on bank statements and in home banking applications. This is by definition the only correct BIC to be used in a SCT, together with the IBAN.
For corporates, the SEPA challenge relates to BICs and IBANs but not in the routing of SCTs. Corporates must convert their clients’ account numbers and bank names into IBANs and BICs. This, in principle, is a one-time activity. The official way to do this is to ask all their clients, or their banks, to provide their IBANs and BICs.
For large corporates, with millions of clients (the ‘big billers’) and geographical disparity (i.e. the countries in which the data is maintained and where the clients reside can be different), asking all their clients for the IBANs and BICs is not feasible. The Eurosystem’s fifth SEPA progress report acknowledges this problem and urges the EPC to find a solution. Today, large corporates cannot do much more than convert the data themselves with the tools and information they can get their hands on.
Corporates are buying SWIFT’s and other vendors’ databases for converting account numbers to IBANs, and banks’ names and addresses to BICs. Converting account numbers into IBANs looks straightforward for many countries but not for everyone, because the conversion process needs to make choices that cannot be made correctly without additional information.
SWIFT does not recommend that corporates generate IBANs out of the account numbers. But if corporates do this, SWIFT recommends that they at least validate such IBANs, BICs and their combination against its new BICPlusIBAN directory. This directory contains the complete list of 260,000 bank identifiers used in the SEPA area, approximately 60,000 BIC codes, and it contains the cross-references, including the special cases, between the bank identifiers and the BICs. The directory also makes it possible to validate that the IBAN and the BIC belong to same financial institution, even if the BIC represents a bank’s processing hub. The users of the directory can automate these checks if they want.