Does valid bank account data matter? A guide to payments globally: how payment failures can be reduced through managing bank account data.

Transcription

1 Does valid bank account data matter? A guide to payments globally: how payment failures can be reduced through managing bank account data.

2 Contents 1. Introduction 3 2. What is poor data quality and how does it affect payment operations Payment Types Where do errors in bank account data occur? How much does it cost to fix? US ACH error rates Cross-border error rates Exception handling Repair or rejection IBAN Case Study: Account validation in the UK Case Study: Single Euro Payments Area (SEPA) and IBAN What regulations or standards are appropriate US ACH rules Dodd-Frank International ACH Transaction (IAT) Payment Services Directive 2 and SEPA Rules ISO What can be done? What needs to be checked Overview of solutions available Directories of branches Rules on account structures Full account validation and conversion Pre-notification check ( pre-note ) in US ACH Account verification Where to check At point of capture Before usage or periodically Case study Step Guide Conclusion About Experian s bank account validation and verification solutions Glossary 28 2

3 1. Introduction Sending and receiving payments are business critical processes and because of the impact that failure has on any company s bottom line there is a very low tolerance of error. One area that can cause payment failure but which may be overlooked is in the collection and storage of bank account data. Those businesses who have studied how they handle bank account data have realized benefits including: improved cash management increased customer/supplier satisfaction higher efficiency fewer exceptions increased fraud prevention reduced return and repair charges The collection and maintenance of bank account data is by its nature prone to inaccuracy. When collecting data information may be mis-heard or mis-keyed or the provider may simply give false or inaccurate data. In addition recent industry moves such as SEPA (Single Euro Payments Area) in the Eurozone and Dodd- Frank 1073 in the USA have sought to impose clarity and standardization on the payments process. In doing this they have on occasions increased the risk of error entering the payments data by necessitating the collection of information, such as IBAN (International Bank Account Number) and BIC (Bank Identifier Code) which is unfamiliar to those who need to provide it. While in the USA tentative steps are being made towards using the IBAN standard, it is not yet a required format, however, for those organizations who must make or collect payments internationally, the understanding and management of IBAN and BIC is vital to payments continuity. In this guide we will provide an understanding of how and why error occurs, what the implications of this are and how the issue can be tackled. 3

4 2. What is poor data quality and how does it affect payment operations Worldwide, businesses are moving to electronic payments and collections, the clear reasons for this are the reduction of cost and the speed of transactions. This however requires accurate data to be exchanged between the counterparties and means that data once captured needs to be kept up to date. 2.1 Payment Types There are three categories of commonly used payment instruments: ACH (debit and credit) wire transfers payment cards In the case of payment cards, online authorization ensures good data quality, however ACH and wire transfers rely on having good quality destination bank account data. For that reason this guide will focus on the challenges around ACH and wire transfer. For ACH and wire payments, whether domestic or international poor data quality can be defined as having insufficient or inaccurate data to a degree which would cause a payment to fail or remedial action to be taken for it to succeed. This includes one or more of the following types; bank codes, account numbers, check digits, routing information and counterparty name and address. The data required varies by payment instrument and whether the intended recipient is domestic or cross-border. In the US, domestic ACH transactions require TRN s (Transit Routing Numbers) and account numbers. International transactions tend to use the International Bank Account Number (IBAN). In addition some mechanisms require specialized routing code such as the Bank Identifier Code (BIC). 2.2 Where do errors in bank account data occur? Errors in the information used to make payments can occur in any part of the payment process from customer acquisition to clearing and settlement. Errors relating to data rarely occur in banks systems or clearing systems but are most commonly created at the point of capture, when data is transferred between applications especially due to re-keying and over time as account information ages and is not maintained. Businesses experience the results of poor data quality at a number of places in their operations from where the data is collected to where they are used and maintained: customer acquisition supplier management treasury and cash management accounts payable accounts receivable customer support and account management 4

5 Data acquisition Business application process Payment batch creation Payment Initiation Clearing and settlement Reconciliation Connective action Exceptions Handling Returns and rejections Many organizations separate the processing of failures from the straight-through process and therefore miss the implications of poor data hygiene at the start of the process. There are a number of points in payment processing where errors can become apparent. In the following diagram the type of error which is most costly, most time-consuming and involves the most parties is when most of the information is correct; more simple errors are easier to identify and tend to get detected earlier. A B C Counterparty D E Business Payment Account Clearing Payment Account Beneficiary Increasing Time and Cost a) Error in reference number This is where the account number is mostly correct but the reference such as the invoice or account number is incorrect and cannot be related to a supplier or customer account. This results in payments held in suspense while they are investigated, with the payer believing they have paid but the payee is unable to reconcile. 5

6 b) Error in account number This where the payment instruction reaches a bank but the account does not exist. In the US ACH systems this is typically referred to as an administrative return using codes R03 and R04. Typically these are rejected immediately although industry practice varies and in Europe banks do attempt to repair these transactions. c) Invalid or missing bank codes In this case the bank/branch code, in the US the Transit Routing Number, is incorrect. This tends to occur either from capture of incorrect account details or from changes due to mergers, acquisitions or restructuring operations. d) Badly-formatted data Business applications without sufficient data hygiene protection may capture bank account information which is so invalid that it cannot be transferred to the banking application. e) Validation at point of capture In the ideal case, errors are identified at the point that the counterparty supplies them. This optimal solution enables counterparties to make corrections where necessary and avoids time and remedial actions. In addition, the further through the process the error is detected, the more time will have passed from the initial data capture, the increased number of parties involved in remedial action and the greater cost of investigation and correction. 2.3 How much does it cost to fix? The cost to a business of poor quality data is controlled by two factions: rate of error cost of failure These errors are generally detected at the point of first transaction and then remedial action is taken to avoid it for subsequent transactions US ACH error rates In US ACH transactions, these failures are referred to as administrative returns and are mostly identified by the return reason codes R03 and R04 No Account/ Unable to Locate Account and Invalid Account Number Structure. It is also likely that in a small proportion of cases the incorrect details may relate to a real, but different account and therefore may be returned as R05 and R02 Improper Debit to Consumer Account and Account Closed. It is worth noting that there were 1.1 million unauthorized ACH debits in 2012¹ and 0.5 million unauthorized ACH credits, accounting for $800 million and $400 million respectively. From the NACHA request for comment on modifying ACH rules² to manage risk: Account data quality issues were identified by NACHA s³ consultant as the most widespread cause of ACH quality exceptions, occurring at a rate of 0.28 percent of ACH debit Entries originated during the period studied by NACHA s consultant ³ ¹The 2013 Federal Reserve Payments Study, Federal Reserve Board, ² ACH Network Risk and Enforcement and Improving ACH Network Quality - ³NACHA s Request for Comment Letter copy at 6

7 Statistics are rarely available concerning poor first transactions and therefore assessing this rate of error must rely on estimating from the whole volume of transactions. Since businesses do not resubmit transactions they know are in error without first undertaking actions to correct the error, to get an estimate of the rate of error in first transactions it is necessary to make assumptions about the ratio of first transactions to total transactions: Transaction group Average length4 Number per year Total error rate Estimate of error rate in first transactions All ACH 3 years % 5.4% ACH Debits 3 years % 7.1% An estimate, therefore, of the error on first transaction for all ACH transactions is around 7 percent of debit transactions, significantly more than the 0.28% quoted for debits and 0.18% for ACH transactions in general. Error in recurring and first US ACH transactions Recurring transactions First transactions - successful First transactions - administrative error 96.1% 3.9% 3.7% 0.2% 4 Experian regular and one-off payments model 7

8 Error rate per new instruction = Total error rate/number of transactions per instruction In , NACHA conducted research 5 on the rate of error in debit sign-ups between businesses and clients initiated over the telephone. This study looked at whether the originator of the call made a difference and whether new client relationships had an effect. Existing client-relationship Initiated by Administrative error rate Yes Consumer 1.7% Yes Business 4.99% No Consumer 6.48% This clearly shows that error rates of first transactions depend critically on the method used and are significantly greater than the 0.2% administrative error rate quoted across all transactions Cross-border error rates Statistics on cross-border transactions are also difficult to obtain. From analysis conducted by Experian of multi-country, European data held by large organizations 6, it is clear that lack of familiarity with foreign bank codes and account numbers increases the rate of error: the average error rate of bank account data was 12.7% - far higher than that experienced by corporates and suggesting that repair of transactions is common in Europe. From analysis, 7.0% of errors are related to incorrect bank codes. Given that this data has been used to initiate payments, the conclusion can be only that the data is no longer correct and the bank codes have become out of date. To prevent this sort of error, validation scans should be undertaken periodically to ensure that data quality is preserved in financial databases Exception handling In addition, the remedial action required varies depending on the type of error. In most cases it is necessary at least to contact the other party and verify their details; this typically costs between $5 and $20 depending on volume. In addition other costs can be incurred including transaction charges, repair or rejection fees, debt servicing charges and additional operational expenses related to handling the exceptions and reconciliation. A typical exception process might look like this: Process for valid details: Capture bank details Submit transaction Reconcile Process for invalid details: Capture bank details Submit transaction Handle return Obtain valid bank details Re-submit transaction Reconcile 5http://legacy.cuna.org/reg_advocacy/reg_call/wp_ html?hd=1 6Experian White paper on SEPA data quality 8

9 Every business therefore has its own operating cost model depending on volumes, efficiency and the cost of systems maintenance. It is therefore up to each business to estimate their overall costs, but European estimates are that end-to-end total for a failed payment/collection is 50 7 ($67). In some cases in the US organizations are charging $50 for failed payments. Costs of failed wire and international payments are likely to be higher because of higher transaction costs and suffer a higher error rate because of the general lack of familiarity with foreign account numbers. Examples of repair costs for failed transactions reported to Experian commonly range between $10 and $ Repair or rejection It has also become clear that different regions have varied approaches to correcting errors in payments. In the US it is general practice to reject payments which do not meet the strict NACHA rules or which contain some form of error, for example a transaction or keying error in an account number. In some other countries, banks will repair transactions, for example re-routing payments to a closed branch to the relevant open branch, in most cases not informing the sender of the error and in many cases not charging fees for the fix. This second practice is common in most European countries and has the sideeffect that information is not kept up to date in business applications as it changes. 2.5 IBAN The International Bank Account Number is an ISO standard for representing bank and branch codes and account numbers in a form which is standard across countries. In addition to the international envelope which specifies the country code where the account is located and two check digits which help to identify transcription errors, there is a country specific part which identifies length, the fields included, such as national bank code and account number, and the format of those fields, such as whether they accept alphabetic characters. Global framework (ISO13616) including country of origin integrity check standardized domestic account number goal of increased efficency through consistency ISO Country code DE IBAN Check digit Bank/Branch code Account number 7Returned Check and ACH policy, Illinois Institute of Technology, 9

10 A number of countries have adopted IBAN, including all of the European Union for ACH transactions in euro, but many other countries are seeing the benefits of using a single format for all their payments data, including countries in large parts of Asia, the Middle East and South America. In the meantime some corporates are independently standardizing their payments function on IBAN frequently as part of a migration to the ISO20022 XML format for their payment files or to standardize the way account information is held in their business applications. 2.6 Case Study: Account validation in the UK In the UK, the scheme rules for the Direct Debit service mandates account checking for all electronic direct debit instructions and mandates account verification, proving a link between a customer and their account, for paperless (telephone and web-based) authorizations. This has led most originators of direct debits to employ account validation soltuions at the front end of their business operations. In addition, unlike all but a few countries, the UK allows businesses, which have been approved by their bank, to send payment instructions directly to the clearing system, Bacs, over an IP-based service called Bacstel-IP. The software used to transmit batches of instructions must comply with service rules including the validation of account numbers prior to transmission. The UK also makes change notifications ADDACS and AWACS advices, available directly to originators so that they can update their databases; there is evidence that this does not always happen correctly, but at least a process is in place to check. The UK has a complicated account structure, with some banks using numbers which are longer than standard or include alphabetic characters. In these cases the numbers must be standardized to the 6-digit bank code and 8-digit account number supported by Bacs. Furthermore since bank codes could not be held by building societies (savings and loan) or credit unions, in some cases the account number must also include a reference or roll number which specifies the customer account at the non-bank financial institution. All of these exceptional cases made the issue of account validation both more complicated and more important than other countries moving to electronic payments. The UK does not have an equivalent to prenotification but there are commercial, account-verification services, such as Bank Wizard Absolute, which allow payment information and ownership of account to be confirmed prior to an ACH payment. These are used by not only UK customers, but also international payers into the UK such as the remittance company Xoom which checks UK bank account details and ownership before making a faster payment from its accounts in the UK. This has led to a high degree of data accuracy, especially in debits, in the UK s bulk payments. Research on data provided as part of Experian s data validation service strongly backs this up. The UK error rates are noticeably lower than those of similar European countries such as France, Spain and Germany; it is Experian s hypothesis that the maturity and incorporation of data validation which results in the high degree of payment confidence and low rate of administrative exceptions in the UK system, despite the increased complexity. 10

11 3. Case Study: Single Euro Payments Area (SEPA) and IBAN As part of the Single Euro Payments Area, (SEPA) designed to drive down barriers between countries for payments, most of Europe has adopted the IBAN as its format for domestic payments as well. This has resulted in businesses having to validate and convert the bank account data they held in domestic format, into IBANs. As part of the migration to SEPA, which in most cases finished on 1 August 2014, organizations were faced with a number of options: contact all of their counterparties to get IBANs use an automated solution to simply change the format of their existing data to IBAN validate their data to separate good data from bad, convert the good and contact counterparties to get correct data in IBAN format The business case for good data quality was outlined by a pan-european telcos company with over 100 million accounts: They estimated it cost them 10 to contact each client. If they had to phone or mail every customer to get new bank account data, it would cost them over 1 billion and they could not be sure that the data had better accuracy than when they started 8. Experian published a deeper analysis of these errors in One of the lessons learnt from SEPA is that even though payments data works, it may still be incorrect; use of automated tools to validate data can avoid costly exceptions and remedial action. 8International Payments conference, London, Experian whitepaper on SEPA and data quality click here to download 11

12 4. What regulations or standards are relevant Data accuracy is an issue which affects many parties in the payments ecosystem. From recipients unable to reconcile to senders unable to initiate payments, poor data accuracy has a negative impact. Many bodies therefore set standards associated with data. In the UK, for example, the payment scheme company Bacs sets mandatory rules and establishes best practices for organizations intending to make payments or collections. This section touches on a few of those rulesetting entities and what the implications are. 4.1 US ACH rules In the US the Electronic Payments Association NACHA establishes the rules 10 concerning the operation of the automated clearinghouses including the FedACH and New York Clearinghouse. These Operating Rules 11 govern how payment instructions are formatted and submitted; NACHA establishes the polices on monitoring the rates of ACH Return Reason Codes for originators. Concern with the overall stability of the payment systems is also held by the Federal Reserve System which maintains Regulation E (12 CFR 206) concerning Electronic Fund Transfers. Research is ongoing into risk and data quality of ACH operations by a number of the Federal Reserve Banks, including those of Atlanta, Cleveland, Kansas City, Minneapolis and Philadelphia. The Minneapolis 12 research suggests that, of a 1.6% return rate, on average 1 in 6 returns are for administrative reasons. To proactively manage these operational risks, NACHA recently proposed changes 13 to its Operating Rules to govern risk management related to data quality: Reduce the existing return rate threshold for unauthorized debits from 1.0 percent to 0.5 percent Establish a return rate threshold for account data quality returns (i.e., administrative returns) at 3.0 percent, and an overall debit return rate threshold of 15.0 percent NACHA classifies account data errors as administrative Returns with reasons No Account/Unable to Locate Account and Invalid Account Number related to Reason Codes R03 and R04; it estimates total returns for these reasons are around 0.2% of all transactions which has been comparatively stable for the last 8 years at least. These rates vary significantly with method of capture of data; this is significantly higher for telephone or web authorizations or remote check transactions (TEL, WEB or RCK). It is clear that NACHA is concerned about the quality of data and the volume of returns caused by poor data quality; US businesses would be well advised to address their own data quality issues ahead of any industry action. 10NACHA Operating Rules NACHA Rules Online A Method for Improving the Benchmarks Used to Monitor ACH Returns, Federal Reserve Bank of Minneapolis, fpwp_10-03_ach.pdf 13 NACHA Seeks to Amend Operating Rules, PaymentsJournal, 2013, 12

13 4.2 Dodd-Frank 1073 Dodd-Frank 1073 is part of the wider Dodd Frank Wall Street Reform and Consumer Protection Act; and applies to providers of payment services to consumers. Dodd Frank 1073 applies to any international wire transfers of $15 or more whether handled by a bank, credit union - or for that matter any other type of company that offers a wire transfer service more than 100 times a year. The Consumer Financial Protection Bureau has updated Regulation E (subpart B) to implement the statutory requirements in Dodd-Frank Act and this change came into force from October Essentially, anyone providing a remittance transfer service is now required to disclose the costs before any transaction is made, followed by a proof of payment and offer a way to resolve disputes. The likely timescale for arrival of the funds at their destination must also be given. In most cases, US customers will have around 30 minutes to cancel a live transaction, while scheduled payments can be cancelled up to three working days beforehand. Retail customers also have up to six months to dispute an error. The implication for payment service providers making remittance payments on behalf of consumers is that they should check all the information they can with their client prior to initiating the transaction. What is the impact for US payment service providers? In addition to the criteria around transparency of cost and service levels outlined above, the payment service provider will need to provide information on the receiving bank account in a certain format for example for wire transfers into Europe data will need to be in the IBAN (International Bank Account Number) format and provide the BIC (Bank Identifier Code). While the service provider is not liable if a payment fails due to incorrect bank account data being given by the service user, collecting IBANs and BICs from consumers wishing to send transfers is not a simple matter because: consumers are not familiar with IBANs or BICs, being more aware of the domestic formats of the individual countries into which they wish to make a transfer. although an IBAN is a standardized format it varies from country to country in exact format and length and can be as long as 32 characters (in the case of Malta). while a payment service provider cannot be held responsible for payment failure due to them being given poor data, failure of wire-transfers because of poor data could become a customer service issue. 4.3 International ACH Transaction (IAT) Since September 2009, NACHA has supported international payments to exit or enter the US. This new International ACH Transaction takes account of the US Government s Office of Foreign Asset Control s need to align NACHA rules with OFAC compliance requirements. The IAT is an ACH entry related to a payment transaction involving a financial institution s office that is not within US jurisdiction. 13

14 In the IAT format for sending payments from the US, it is mandatory to provide the Receiving Deposit Financial Institution (RDFI) Identification Number to identify the receiving bank; this can be in three different formats: 1) National Clearing Code 2) BIC 3) IBAN This information must be correct prior to initiation of the transaction or the IAT will be returned, either by the originating bank or by the payment system in the remote country. Validating the domestic bank code, the International Bank Account Number of the account or the Bank Identifier Code (BIC) is therefore essential to avoid additional cost and delay. 4.4 Payment Services Directive 2 and SEPA Rules The Single Euro Payments Area refers to the European initiative driven by the European Commission, architected by the European Payments Council and regulated by the European Central Bank that aims to drive down the barriers between EU countries for payments in euro. It relates to the Payment Services Directive, enacted into the legislation of each SEPAzone country and the SEPA Regulation which provides a technical basis and applies to both corporates and banks. SEPA encompasses all Euro payments including ACH, card payments and cash, however in practical terms the most impact and the need for action is for payments made by credit transfer or direct debit. The final deadline for Eurozone countries such as Germany, France and Spain passed on 1 August 2014 although there are allowances for some provisions until 1 February 2016, including some niche payment mechanisms, such as TIP and Télérèglement in France, For countries which do not use the Euro as their primary currency, such as the United Kingdom, Sweden and Switzerland the deadline is 1 October 2016 for their euro payments although most have already migrated their euro transactions to SEPA instruments. SEPA is underpinned by the Directive on Payment Services 2007/64/EC which established a common legal framework for payments within and between EU countries for the first time. This was transposed into national laws in most EU countries in 2009 to support the processing of SEPA Direct Debits. The European Union is further extending the scope and rules of the Directive on Payment Services (PSD) as part of a review of the regulation. The so-called PSD2 proposes to extend rules around transactions to those international credits coming into and going out of European banking institutions and also to non-european currencies within Europe. This means that rules around how payments fees are levied will extend to those transactions in addition to extending the data requirements. PSD2 also establishes accountability for error with the sender for payments which fail for reasons of data accuracy. This could therefore see an increase to repair charges levied against non-european payers. Within Europe it is mandatory for crossborder transactions to use IBAN and BIC between banks and it will be assumed that this will apply to transactions coming from outside the EU, such as from the US, as well. 14

15 Businesses outside the EU making payments into Europe should therefore start collecting and maintaining bank account numbers in IBAN format and undertaking data cleansing exercises to ensure payments information is as correct as possible. 4.5 ISO20022 The payments industry has been developing a new format to exchange payment, securities trade and FX data with their corporates. This provides the ability for businesses to harmonize all of their payments, both domestic and international, on one standard encompassing the vast majority of needs. ISO20022 is described as a Universal financial industry message scheme. The standard has been developed by a number of bodies, including SWIFT and ISO, under a UN/CEFACT mandate and implementations have been undertaken to support SEPA. Following a number of local interpretations which have hampered interoperability, a group called CGI (Common Global Implementation) has been formed to cope with variations between banks and countries. ISO20022 is designed to describe all the components necessary for financial messaging both between corporates and their bank(s) and between banks. Coupled with the XML standard, it allows additional information to be added where required and information to be interpreted easily. This richer data improves reconciliation, exception handling and general efficiency and has been considered for a number of non-payments applications, such as exchange of tax information in real time in the UK 14. What is ISO common language for financial transactions 2. foreign Exchange messaging 3. file format used by SEPA 4. data dictionary of commonly-used items 5. means of getting statement data from bank in a standard layout 6. securities industry standard 7. data interchange for Trade Services 8. interface supporting Cards and Retail There are two components which, working together, define everything necessary: ISO20022 the US/ISO/CEFACT/SWIFT data dictionary which defines fields such as account number, banking codes and name. XML the extensible format meaning that any field is tagged with what it contains. 14HMRC s PAYE RTI project - 15

16 There are many early-adopters: SEPA has used ISO20022 since its go-live in It is now mandated by the European Parliament as the only SEPA format for bulk payment both interbank and corporate-bank SWIFT is migrating its formatted, text-based payment format (MTxxx) to XML format (MX) over the next 10 years. international businesses such as Microsoft 15, are switching to ISO20022 format payments in order to standardize their treasury processes ISO20022 assumes XML delivery but does not specify the detail of the messages such as which are mandatory and which are optional fields. This detailed specification is done on a case-by-case basis and, as such, there are SEPA definitions of ISO20022 XML messages which support its SCT and SDD payments. There are a number of different types of message which include payment/security transaction initiation and account management Corporate Payments Credit Transfer pain Direct Debit pain Status Report pain Clearing and Settlement Status Report pacs Customer Direct Debit pacs Customer Credit Transfer pacs Payment Reversal pacs Payment Cancellation camt Payment Return pacs Cash Management Account Report camt Customer Statement camt Credit/Debit Notification camt New payment systems worldwide are being developed using ISO20022 as a basis. Some of these are already live such as SEPA which has had implications for businesses, banking institutions and automated clearinghouses. Whilst SEPA is largest in volume, the use in India of XML for their Real-Time Gross-settlement System (RTGS) will certainly contribute significantly to the value being transacted using ISO20022 XML. 15Microsoft Case Study, AFP Conference ISO20022_ pdf 16

17 LIVE IN DEVELOPMENT PROPOSED EU: SEPA SWIFT MX Qatar: ACH Denmark: Same day Global Securities India: RTGS UK: Faster Payments EU: TARGETS2 Switzerland: RTGS Canada: ACH Egypt: ACH Singapore Faster Payments Japan: Low/High Value Australia: Faster Payments Malaysia: RTGS Brunei: RTGS UK: Bacs US: FedACH US: FedWire US: NACHA Maintaining a payment file format for each country in which they operate is costly and harmonizing can allow standardization of processes as well as data format. The Microsoft case study 16, where a number of local formats were retired in order to use ISO20022 XML to send payment instructions to its banks, is a good example of the harmonization and cost-saving which can be achieved across an international business. Finally, the US payments industry is considering the opportunities offered by supporting ISO20022 payment files for US ACH transactions. US businesses would be well-advised to learn about ISO2002 and consider the implications for their applications. 16Microsoft Case Study, AFP Conference

18 5. What can be done? Businesses want confidence that their payments and collections will be successful in order to reduce cost, improve efficiency and raise levels of customer satisfaction. By checking data at the point of entry or at very least before the point of submission it is possible to increase rates of straight-through processing and reduce handling of exceptions to a minimum. 5.1 What needs to be checked Ideally all the information used to initiate a payment should be verified. In some countries, it is mandatory to check certain data before a transaction can be initiated, such as the UK where, for paperless Direct Debit transactions, the account number must be checked and a link with the owner of the account confirmed. Solutions to verify the identity of an individual exist, such as Experian s PreciseID product and so this section will focus on the elements of the bank account number and ancillary routing information. Bank details can be incorrect in a number of ways. We group them into four distinct categories: Format: Content Integrity Standardization Errors related to the format of bank and/or branch codes, the format of account numbers. These typically relate to the number and length of the fields, whether alphabetic or numeric characters are expected. Errors where a bank code or account field does not relate to a current entity. These occur when bank codes do not exist in the directory and can come about by lack of maintenance of the data. Errors in bank or branch rules on account formation. Many banks use modulus rules to detect transposed or incorrect digits but simple rules may also improve data accuracy such as the account must start with 07. These errors occur where data is converted incorrectly, is not input in a standard form or a transcription fault, mis-hearing or mis-keying occurs. Cases where bank account information is presented in a standard, non-domestic format, but that standard is incorrect. This typically occurs in International Bank Account Number data and relates to invalid IBAN check digits, incorrect country codes or not meeting the national standard for the IBAN in either length or character. In many cases this is due to poor quality conversion and can normally be identified by simple algorithmic checks. 5.2 Overview of solutions available The following table summarizes the options to validate bank details and supplement with additional routing information for international or in some cases domestic payments. Each potential solution may identify different types of error, as discussed earlier (Standardization, Format, Content, Integrity) but may also confirm the existence of an account and provide supplementary payment data such as a Bank Identifier Code (BIC). 18

19 Type Standardization Format Content Integrity Confirm Existence Supplementary data Directories of branches Yes Yes Rules on account structures Yes Yes International Account validation and conversion Pre-notification ( pre-note ) in US ACH Yes Yes Yes Yes Yes N/A Yes* Yes* Yes* Yes* Account verification Yes Yes Yes Yes Yes Yes * Subject to the recipient bank responding within an appropriate time, which is not reliable Directories of branches In general, each country publishes a list of branches, for example the Bundesbank, the German central bank, publishes a list of bank codes, Bankleitzahlen, on a quarterly basis. Checking that a code still exists in these directories is simple and can identify errors where data is mis-keyed or where the branch closes. For businesses dealing with many countries, directories which are regional or worldwide can be purchased, such as Swift s SwiftRef bank directory; these typically incorporate data from local directories or directly from banks. These worldwide sources have to standardize the information provided and generally exclude data required by local clearing such as routing codes for specific payment mechanisms which may be included in the local directory. Both solutions rely on organizations writing code to interrogate these tables and are as good as the source of the data and typically pick up only errors where the bank code is invalid. The cost of this solution which is overlooked is maintenance of the different data sources required and any changes made necessary by variations in ACH or banking rules. In some cases it is necessary to undergo a complex process to integrate updates into a business application where it maintains its own database of branch codes Rules on account structures Another approach is to use structural rules and integrity checks on account numbers. These can identify where an account number could exist for a given, valid branch code. In many cases these rely on formatting rules, such as where alphabetic characters are acceptable, and on modulus rules which perform mathematical operations to identify such errors as mis-keying, mis-hearing or mis-translation. These rules generally change infrequently but since each bank typically has more than one set of rules, it can be difficult to keep up to date, especially for businesses operating in more than one country. In the UK a table of modulus rules is published which covers around 80% of the UK branches this figure has not increased significantly in the last ten years. In France, for example, there is a single integrity check, the Clé RIB, which is standard across all banks and interestingly, makes the check digits of the related IBAN always 76 for numeric account numbers. In Germany, these rules vary branch by branch, resulting in over 130 separate rules, each of which may change on a 3 monthly basis. In the US these rules on account structure are not generally available. 19

20 On their own, account rules cannot completely eradicate error and do not, in general, remove the possibility that a bank code is incorrect Full account validation and conversion When coupled with branch directories, account structure rules can give a good probability that the account information is correct. This is typically termed full account validation and may also include issues around non-standard presentation and truncation. In Germany, for example, many accounts have a sub-account number within their structure which can be used to identify a particular aspect of that account; where this number is 0 or 00 it is almost always omitted, presenting the business with a problem: did they omit it or not. In some cases, account rules also cover short-code account numbers typically used by charities and there may be ways of identifying whether or not the account is in domestic or foreign currency. This sort of service may also be provided to convert old format data to new, as used by many corporates for migration to SEPA. This can also be used to periodically validate customer, staff and supplier databases to ensure continued accuracy. Short of a solution listing every account worldwide, which has not yet been achieved, full account validation gives the highest probability of payment success. To register for a free trial of Experian s Global bank account validation solution Bank Wizard please click here Pre-notification check ( pre-note ) in US ACH To help improve data quality, the NACHA rules encourage an organization to send a test transaction before making a credit or debit to check that the data is valid. In principle the organization then waits for up to 5 days for the response before going ahead with a live transaction In terms of data error, the NACHA Operating rules, Article 3, Section 3.5 covers prenotification entries: An RDFI that receives a Prenotification Entry must verify that the account number contained in the Prenotification is for a valid account. If the Prenotification does not contain a valid account number or is otherwise erroneous or unprocessable, then the RDFI must Transmit either (a) a Return Entry, or (b) a Notification of Change. This means that originating organizations or FIs receive notification only if there is a problem, not confirmation that the account is processable, however from comments of US businesses, it is common practice not to receive a response in any case. In practice not every receiving bank (Receiving Depository Financial Institution or RDFI as defined by NACHA) responds to every pre-note and generally not as quickly as the sending organization wishes. Anecdotally, businesses now either do not send the pre-note or send the live transaction almost immediately thereafter; in the latter case, the return transaction for failures is likely to arrive before the response to the pre-note. 20

21 So while this could be a mechanism of ensuring good data quality, it is undermined by operational difficulties and not relied upon widely. In a forthcoming request for comment NACHA is also proposing to reduce the prenotification response time to three banking days. NACHA is also looking to improve this position by helping to promote Account Validation services to ACH users Account verification In a few countries it is possible to check not only the correctness of the format of the account number and bank codes, but to verify the existence and the ownership. In the UK a commercial service was launched in 2008 to confirm both the ownership and address associated. In the US remittance providers use this service to avoid costs of failure or mis-directed payments and to guarantee good customer service for UK payments This service gives the highest level of confidence in the bank details supplied but is available in very few countries worldwide and tends to be used for mediumhigh risk transactions or parts of a business where exceptions are costly, such as sign-up for debits or high-value payments. To find out more about Experian s UK bank account verification solution Bank Wizard Absolute please click here 5.3 Where to check In addition to how and what to check, there are three logical locations to verify bank account information in a business system: when the data is captured, when the data is used to make a payment and periodically to ensure data hygiene At point of capture This requires a real-time check on information supplied by the counterparty. By checking while the potential customer is online, on the telephone or in a face to face environment time is saved, and payment failure and the associated remediation costs are avoided and customer satisfaction increased Before usage or periodically Many transactions, such as salary payments and debits to settle bills, recur for a number of years. Over time branches close and accounts are transferred and data becomes out-of-date. To avoid failed transactions from previously good data and the associated cost and annoyance, it is best practice to periodically check the contents of payments databases or validate batches of payments before initiation to ensure good data hygiene. In some countries, volume of changes in branches and rules annually approaches 1% of the total branch population. So merely checking data on entry will not eradicate data errors in payments. In some cases, changes happen wholesale. As an example, three years after the acquisition by RBS of ABN Amro in the Netherlands the Bank Identifier Codes (BICs) for payments were transferred from ABNANL2L to RBOSNL2A. Corporate experience was that very few customers called in to update their bank account details although they were required for domestic transactions. In similar cases, banks have been acquired, resulting in changes of branch codes and in some countries, this happens frequently. 21

22 6. Case study Microsoft Global computer giant opted for Bank Wizard to support accurate and timely cross-border commission payments. Founded in 1975, Microsoft is regarded as the global leader in software, services and solutions for people and businesses. It employs 94,000 people in over 64 subsidiaries, delivering products and services in more than 130 countries. Microsoft s global network of resellers and supply partners provides customers with everything from software components, windows products, to hugely popular gaming consoles like the Xbox. With such a complex supply chain, one of the key challenges Microsoft faced was ensuring the smooth, timely and successful delivery of commission payments to these partners across hundreds of international territories, in numerous currencies using multiple payment mechanisms through various banking partners and payment service providers. Background In common with many international brands, the company needed to ensure that all re-seller and supply partner commission payments were managed successfully and on time, with minimal rejections. As a result, it opted to use one common platform in the shape of Bank Wizard Global, which accurately validates and converts bank account data across 228 international territories, ensuring that all payment data is accurately validated and converted to the appropriate format at the point of collection / payment initiation. At the time, Microsoft was also mindful of the demands of pan-european payments regime SEPA and the adoption of the IBAN standard. With the introduction of Bank Wizard, it was able to underpin its on-going compliance ahead of the SEPA deadline ensuring that all euro payments used the necessary IBAN format. Solution Microsoft opted for Experian s Bank Wizard, as it was a complete validation and conversion platform which could be easily embedded within its own pre-existing applications. As a result of implementing Bank Wizard, Microsoft has virtually eliminated international transaction queries, ensuring its re-sellers and supply partners enjoy fast and seamless commission payments. Results Achieved returns from the outset by providing service improvements to Microsoft and its customers and partners alike. Ensured accuracy and validity of payments. Cut the risk of errors and improved overall efficiency. Provided full compliance with SEPA schemes 22

23 7. Eight-step guide to validating account data Businesses are frequently unaware how to approach the issue of data quality. In essence the two rules are separate good data from bad as early as possible; correct the errors and submit good data and get it right; keep it right. The following 8 steps help an organization to scope and implement a data quality project. 1. Establish scope Identify countries to which making payments and specify whether domestic or international payments to understand where best to invest, it is important to document all of the operations to understand to which countries payments are frequently made. Businesses frequently consider customer collections and supplier payments but occasionally forget salary transactions. 2. Leverage management information Monitor returns to identify areas for improvement or no fix necessary. Not every country will have high volumes or high rates of error. By monitoring the returns and exceptions and assessing repair costs, it is simple to focus on the most important areas. 3. Clarify format required for account number Identify whether domestic or IBAN format is required, for the problems prioritized in step 2, determine if you need to record domestic account numbers, IBANs or both. Identify where you store this information. 4. Identify points of capture One critical point is the application into which payments data is captured. This can include telephone call centers, web forms and paper processes. By identifying how data is received it can suggest sensible validation and error handling procedures. 5. Implement data validation up-front Consider how data validation can be embedded in the processes identified in step 4. By allowing only good quality information into databases, data hygiene can be established and preserved. 6. Identify points of initiation The other critical juncture is when payment data is used within a payment file. Identify where batches of payments (or in some cases individual wire payments) are created. By validating and providing correct supplementary data at this point, changes can be identified before they cause rejections. 7. Implement data validation as a recurring process or prior to initiation Consider whether to identify errors caused by bank code or account number change: either as a recurring data cleanse or systematically prior to payment batch creation. 8. Monitor rate of returns Finally, monitor the rates of exception to identify further areas for development and to prove the business case for work already undertaken. 23

24 8. Conclusion Issues of data error are endemic in all payment systems whether domestic or international. Use of data validation to avoid these errors is not common but can identify administrative returns or prevent costly international repairs. Estimates of the cost to businesses can be an average $3.50 for every debit authorization or even more for international payments. By failing to check data before initiating payments, businesses are wasting money and time and putting customer satisfaction at risk. The payments industry in the US and globally has recognized these problems and is working to establish rules and standards to encourage better data hygiene, but this will come only with investment from originators of credits and debits. Businesses are therefore best advised to look at the efficiency of their payment and acquisition processes and to consider whether data validation could significantly improve their cash management, efficiency and customer satisfaction. 17Estimated total end-to-end cost of $50, 7% error rate of first transaction. 24

25 9. About Experian s bank account validation and verification solutions Bank Wizard Global Capturing the correct beneficiary bank account and payment routing information for processing cross-border and international payments can be time-consuming and costly. Yet, these are vital steps to ensuring your payments reach the right destination quickly and efficiently. Bank Wizard Global is the international payment validation solution that enables you to maximze the Straight- Through-Processing (STP) of your international payments. Providing bank account number validation across 46 countries. Using the most comprehensive payment data, financial institution information and validation capabilities available for over 228 countries worldwide, Bank Wizard Global will help ensure your payments reach the correct beneficiaries with minimal risk of failure. Bank Wizard Global allows you to; collect correct and relevant bank account details based upon specific country requirements (IBAN, BBAN or BIC and Account Number) enter and convert between different account standards (BBAN and IBAN+BIC) validate IBANs and BBANs (where available) for increased confidence in account and bank accuracy. fully decompose IBAN information to ensure that the underlying BBAN is valid confirm the existence of bank or branch check BIC codes globally for international payment routing For a free trial of Bank Wizard Global please click here Experian s bank account data cleansing service For organizations with existing databases of bank account numbers Experian offers a service to validate the data already held and to make sure that it is cleansed and in the format required. Yet, with initiatives such as SEPA (Single Euro Payments Area) mandating the use of a standardised format for bank accounts using IBAN (International Bank Account Number) Experian s data conversion service can take the data in your systems to; validate the bank account data is correct convert the data into IBAN provide routing information such as BIC (Bank Identifier Code) ensure your payments data is ready to meet SEPA requirements Bank Wizard Absolute For UK current accounts Bank Wizard Absolute is the only verification service that enables you to make the connection between a consumer or a company and their bank account details in real-time from a single interface. 25

26 Bank Wizard Absolute (Consumer Data) Implementing Bank Wizard Absolute, can help you to dramatically improve profitability and customer service by reducing failed transactions and improving straight-through-processing rates. Bank Wizard Absolute minimises the potential for payment fraud by confirming in real-time that the bank account details provided actually belong to your customer. Best practice guidelines (such as the Bacs guidelines for Automated Direct Debit Instruction Service (AUDDIS) and Paperless Direct Debit) advise you to take measures to know your customer to reduce payment failure and fraud. By making the connection between your customer and their bank account details in near real-time at the point of sign-up, Bank Wizard Absolute helps you to comply with increasing regulatory requirements, legislation and best practice. Bank Wizard Absolute (Business Data) Error free B to B payments reduces cost, improves reputation and helps ensure that you do not fall victim to fraud. Bank Wizard Absolute holds the details of commercial bank accounts enabling you to make a hard link between a business you wish to pay and the ownership of the bank account you will be making a remittance to. Bank Wizard Absolute helps you to make error free payments by: confirming that a business current account exists and is open providing confidence scores allowing you to make risk based decisions linking a company name, address, proprietor and company registration number to a bank account Please click here to download our payment solutions brochure 26

27 10. Glossary ACCOUNT NUMBER The numeric or alphanumeric identifier which specifies a client account at a specific branch ACH Automated Clearinghouse A central system which accepts and distributes payment and information between banks BANK CODE BIC BRANCH CODE A code, typically numeric, assigned to a clearing In the US these are also called Transit Routing Numbers (TRN) Bank Identifier Code Essential a zip code for payments it is an ISO9366-format code issued and managed by SWIFT which specifies a destination bank worldwide. A code, typically numeric, identifying a specific branch. For some countries such, as the Bankleitzahl in Germany, the Bank Code and Branch Code are the same COMMON GLOBAL IMPLEMENTATION An initiative to standardize the implementation of ISO20022 across all banks, clearinghouses and businesses. COUNTERPARTY Either the originator or recipient of a payment. DODD-FRANK 1073 IBAN ISO20022 A section of the Dodd-Frank Wall Street Reform and Consumer Protection Act related to international remittance payments. International Bank Account Number An ISO13616-format for a domestic account number in many but not all countries. In addition to the account number it contains a bank code and the country in which the account is domiciled An international standard for payments, securities and trade-related data. ISO20022 is used in conjunction with XML by the Signle Euro Payments Area (SEPA) NACHA The Electronic Payments Association which administers the US ACH network and is a trade body for the US payments industry PRENOTIFICATION A Prenotification entry is a request to a receiving bank (RDFI) to check the accuracy of an account number. RDFI Receiving Depository Financial Institution The banking institution which receives a payment instruction ORIGINATOR The initiator of a credit or debit payment instruction. 27

28 ODFI Originating Depository Financial Institution The banking institution which receives a payment instruction SEPA SWIFT Single Euro Payments Area SEPA is an initiative of the European Commission which drives down barriers between countries for payments. SEPA established a new legal framework for payments and collections, regulations for the payment services and a set of technical standards and payment schemes including SEPA Direct Debit and SEPA Credit Transfer Society for Worldwide Interbank Financial Telecommunication SWIFT operates the international network for messaging between banks and manages the associated message standards. SWIFT helped to develop ISO20022 TRANSIT ROUTING NUMBER The US code which identifies a bank branch. The TRN is used in all US ACH payments instruction. WIRE TRANSFER XML An electronic credit payment, typically in near-real time. In the US FedWire and CHIPS are two common wire transfer schemes. extensible Markup Language XML is a general purpose carrier of data which is tagged, field-by-field so that it is easy to interpret. XML is used in conjunction with ISO20022 to define payment file format, including those used by the Single Euro Payments Area 28

29 Experian Limited Riverleen House Electric Avenue Nottingham NG80 1RH Experian The word EXPERIAN and the graphical device are trade marks of Experian and/or its associated companies and may be registered in the EU, USA and other countries. The graphical device is a registered Community design in the EU. All rights reserved.