Payments not ready for Sepa - Experian

Source: Experian

Since 2006, the use of Iban (international bank account numbers) and BIC (bank identifier codes) have been compulsory for all international euro transactions.

However under SEPA, the use of BIC and IBAN will be mandatory for domestic as well cross-border payments, replacing the existing BBANs (basic bank account numbers).

According to the latest data* drawn from Experian's SEPA Data Conversion service, many corporates across Europe are unaware that there are significant problems with data currently held in their business systems. Jonathan Williams, Director of Strategic Development at Experian Payments, looks at the issues for corporates migrating existing payments data to the new format:

Key findings:
• More than 20% of the records analysed were in an invalid format or contained errors
• The most common problem was "bank or branch code not in use", meaning that either data has not been kept up to date as branches close or invalid data has been supplied at point of capture
• Quality of data varies significantly by country; the majority of data from some countries is invalid. For instance, 94% of the Swedish records analysed contained errors.
• Error rates vary significantly between industries from around 5% to more than 60%; for example 18% of the records from the travel and leisure industry contained errors, compared to 6% from the banking industry.

"Over the last 20 years many banks have repaired faulty domestic transactions where possible without charge or notification to the originator of the transaction. This has perpetuated poor data quality in business systems used for national payments. SEPA makes little or no provision for such repairs and charges for both repaired and rejected payments are a real possibility, up to as much as €70 per transaction1.

"Experian Payments' analysis showed that the percentage of records containing one or more errors was 13%. This is in contrast to the typical error rates reported by companies of between 2% and 10%. It is clear that the domestic schemes are therefore coping with some degree of error, whether this is manual error correction or automatic error correction such as redirection of transactions for branches of merged banks, for example. As the IBAN data format is a relatively new standard, and it differs greatly between countries, correcting these payment errors will become more difficult and error rates are likely to increase.

"These high error rates demonstrate the need for validation both as part of a data conversion process and as a periodic cleansing process. The statistics show that account checking is necessary not only for cross-border transactions but also for domestic payments, as these will also have to move to the new standard. Without significantly better data quality, error rates will rise and the confidence of consumers will be undermined. In addition, this will mean greater error handling costs for business, further affecting consumer confidence. It is therefore essential to the SEPA project that businesses and payment service providers deliver good validation tools to ensure that payments are successful first time, every time."

*About the data:
Data in the analysis comes from 55 data conversions scans performed in the year September 2009 to August 2010. The analysis covers a number of sectors: in the case of the Banking sector, this relates primarily to payments on behalf of customers. The remaining sectors represent supplier, customer or salary payments.

Comments: (1)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 26 October, 2010, 12:27Be the first to give this comment the thumbs up 0 likes

Given that IBAN+BIC required for SEPA contains more than twice the number of characters when compared to BBAN+SortCode required under legacy systems, it appears that SEPA for domestic payments would entail an explosion in field lengths of bank account related fields. It would be interesting to know if this study contains any data around the field lengths currently supported by typical corporate payment processing applications. If they are not easily extensible to the larger sizes demanded by SEPA, we could be looking at a migration exercise that could rival Y2K in its scope and cost.