Veda Advisory Services. Submitting High Quality Comprehensive Credit Reporting Data to Credit Bureaus

Transcription

1 Veda Advisory Services Submitting High Quality Comprehensive Credit Reporting Data to Credit Bureaus Authors: Chris Slater and Eric Janssens Release Date: May 2014

2

3 Contents 02 About Veda Advisory Services 03 About the Authors 04 Executive Summary 05 Recommendations 06 Introduction 07 Decision 1: Should I Supply Negative, Partial or Full CCR Data? 08 Decision 2: When Should I Cut Over to the New Data Standard? 09 The Data Supply Process 12 Managing a Data Supply Project 15 Lessons and Tips from Veda s Experience in New Zealand 17 Three International Guiding Principles 18 Managing the Rectification Work Identified in the Response Files 19 Multi-Bureau Data Supply 20 Glossary Submitting high quality data to credit bureaus 01

4 About Veda Advisory Services Veda Advisory Services provides unrivalled expertise, advice and business value in retail credit risk management. Their services span a range of key credit risk management functions including risk appetite, credit policy, credit processes and systems, credit risk governance and credit portfolio management with a key focus on comprehensive credit reporting. Copyright Veda Group Ltd. The above information is general in nature and does not constitute legal or compliance advice to Veda s customers. We recommend that customers seek their own independent legal and/or compliance advice. 02

5 About the Authors Chris Slater Chris Slater is a partner in The International Risk Partnership (IRP) and was with Experian for 13 years before leaving to establish IRP. Chris is widely regarded as a data and analytics expert in the industry. He has worked with Experian and subsequently with a number of national credit bureaus to develop world class products and services. He has subsequently worked with a number of national credit bureaus to maximise the benefits they get from using credit bureau services. In the last five years, Chris has worked extensively in the Australian and New Zealand markets. He is very familiar with the challenges faced in these markets, as they migrate from a negative to comprehensive (or positive) reporting environment. Eric Janssens Eric Janssens is the General Manager, Comprehensive Credit Reporting Data Management at Veda. He has been with Veda for over 20 years working in a variety of areas, including Information Technology, Customer Services, Operations and most recently Data Management. Eric has extensive experience in developing technology solutions to meet business needs, data analytics, identity matching, implementing data quality improvement programmes, and setting of data standards, policies and procedures. He is regarded as the leading credit bureau data and identity matching expert in Australia and has been instrumental in establishing the Australian Credit Reporting Data Standard (ACRDS), which was issued in January Submitting high quality data to credit bureaus 03

6 Executive Summary The introduction of the new Australian Credit Reporting Data Standard (ACRDS) is a foundation stone for the exchange of Comprehensive Credit Reporting (CCR) data between credit providers and credit reporting businesses (credit bureaus). This document assesses the key decisions, processes, project structure and international learnings concerning the adoption of the new data standard. It is required reading for anyone in a role within a credit provider s project to establish data sharing with the new data structure. Internationally, projects to supply credit bureau data are notorious for significant (up to 100%) over-runs in project time as there is a hidden project tail of test and fix between credit providers and credit bureaus. The first submission of credit data to a bureau starts a discovery period during which the credit provider learns about the quality of the data that they hold on accounts and account holders. The process designed for the supply of data is two-way and is only a success once the second monthly submission is made correctly by the credit provider to a bureau. In addition, credit providers must have an ongoing process to manage any errors that are reported back by bureaus. This paper provides the authors best advice on how to minimise both the risk of significant time over-runs and the risk of customer complaints. This document assesses the key decisions, processes, project structure and international learnings concerning the adoption of the new ACRDS. 04

7 Recommendations Build your extract to supply full CCR data even if you do not intend to use full data initially. It is easier to suppress this data than to rewrite the extraction programs again at a later date. The project team will need to be cross-functional with IT resources that understand the source systems and business resources that understand the data and its use. Ensure resources that are close to the data and understand its intricacies are available through the early data supply process. Utilise a specialist extract, transform and load tool (ETL) to create the output file and maximise data quality before submitting to the bureau. You must supply three consecutive months of CCR data before you can access CCR data (as per the industry Principles of Reciprocity). There will also be a period of discovery when issues with the data need to be ironed out. You should plan to have your data supply developed six months in advance of when you need to access CCR data from the bureau. This is shortened dramatically by the use of a specialist ETL tool. Credit providers wishing to supply multiple credit bureaus should take the pragmatic option to do this sequentially. Bedding one bureau supply down before supplying the next one is recommended as each bureau will have different data validation processes. Submitting high quality data to credit bureaus 05

8 Introduction Amendments to the Privacy Act 1988 enabled the sharing of Comprehensive Credit Reporting (CCR) data with credit bureaus. Many credit providers are now assessing the business opportunities from the sharing of CCR data and are realising that early use of the data will deliver genuine competitive advantage. This whitepaper looks at the planning, approach and what can be learnt from international best practice to supply data and allow businesses to be early adopters of the new data. The Act requires credit providers to take ownership and full responsibility of the quality of their data. Credit providers must ensure that the data they supply is as accurate as they can make it and that they have policies and procedures to manage rectification and correction of data when issues are identified. The opportunity to improve lending quality and hence return is a significant benefit of getting the supply of data to credit bureaus right. The data standard is a technical document that specifies the business requirements for when and how data should be supplied as well as the technical aspects of that data supply. This paper aims to go beyond the data standard and explore the business decisions that every credit provider has to make. It also looks at what processes are needed to support these business decisions and the risks to such a project. Many credit providers are now assessing the business opportunities from the sharing of CCR data and are realising that early use of the data will deliver genuine competitive advantage. 06

9 Decision 1: Should I Supply Negative, Partial or Full CCR Data? The first strategic decision is the level of data that your business intends to supply. The industry has established three levels of data supply: Negative Data The supply of information about only those accounts where negative events have occurred such as being defaulted or written off. Partial Data The supply of the basic details of all accounts that are active. Comprehensive Data The supply of repayment history information* on all active accounts, identifying where accounts are in various stages of delinquency or up to date. The industry has set up a rigid reciprocity arrangement whereby access is related to supply. If a credit provider supplies negative data they will only be able to access negative data and similarly if they supply partial data they will only be able to access partial data and so on. Most credit providers will have a plan for the portfolios and level of data they wish to supply. In the long term, every business must make changes to the way negative data is supplied to the bureau. The authors recommended strategy for credit providers is to plan an IT project that delivers full CCR data and to execute it in a way that allows the business to switch on or off the level of data supply the business actually decides to contribute. This means only one investment is necessary for data supply. Even organisations that wish to remain negative for the foreseeable future should take this approach. While the investment to extract full CCR data is greater than the investment to extract negative data, the real costs are actually in identifying the customer, providing their data (current addresses, previous addresses etc.) and linking them to the correct accounts. The cost of providing the additional fields that constitute full CCR data are often very little. * Only licensed credit providers may use and disclose repayment history information. Submitting high quality data to credit bureaus 07

10 Decision 2: When Should I Cut Over to the New Data Standard? The second strategic decision is timing. For organisations looking to improve their business performance with the new CCR data, the benefits cannot arise until CCR data is being supplied. This means that the business will want to balance their ability to supply the data with their ability to consume the data. The authors recommend that companies target being able to supply data at least six months before they want to start accessing the new data. There are two reasons for this: 1. The Rules of Reciprocity require that a new subscriber provides three months of data before they can consume CCR data. Some credit providers may do this by accessing historic data to create this in one submission, but for those that are extracting just the current month this adds a three month delay between submission and access to the data. 2. The vast majority of credit bureau data supply projects over-run (a topic we will return to) and expose data issues that credit providers were not aware of. This is referred to as the discovery period. A reason for undertaking the project even earlier than this is that most organisations go through a 'period of discovery'. This is where they come to understand their data quality issues through externalising their data and having new data quality tests applied to it. In many instances, credit providers will want to understand the size of this issue and the task of mitigating the frequently occurring issues before they finally commit to supply to a credit bureau. The credit bureau should allow you to hold back your data from sharing with other financial institutions (referred to as 'set to private') so that you can time the sharing of your data to the wider credit bureau client base more accurately. This allows you to see your own data in credit reports, but you do not see the data of others and they do not see yours. This feature was used extensively by Veda s clients in New Zealand as CCR data built up to the agreed critical mass before formal data sharing commenced. For negative data supply, the key benefit of utilising the new data standard is the avoidance of non-compliance when credit providers must migrate to the new data standards. If your organisation chooses to adopt this approach, you should keep in contact with your chosen credit bureau(s) to understand when they will be migrating off existing arrangements. 08

11 The Data Supply Process The data supply process is in line with best practice from around the world, with data being extracted and supplied electronically and securely to a credit bureau. Credit bureaus then decrypt and validate the input, checking it against previously loaded data on the credit bureau. A response file is generated and returned to the credit provider to allow them to understand the data quality of their submission and to plan and manage the rectification of any errors. The diagram below outlines the process. Credit Provider Credit Bureau Operational System Data Warehouse File Validation Field Validation Operational System Operational System Data Extract SFTP Server Field Verification Cross Check Load Credit Bureau Response Analysis Create Response Submitting high quality data to credit bureaus 09

12 The Data Supply Process The credit provider extracts the data from their source systems. In many cases this will be a data warehouse that they have already built in their environment. However a number of credit providers will need to extract data from various sources such as the account processing platform, the collections platform for accounts in arrears, and even the CRM system where they may store their customer data independently of the accounts. The key task of the data submission project is the transformation of this data into the ACRDS standard and credit providers will need to determine whether they build this capability for each portfolio internally or whether they use third party tools to achieve the transformation, compression and encryption. Once the data is formatted correctly, compressed and encrypted it is submitted to the credit bureau s SFTP servers and from there the bureau takes over. The bureau starts by validating the integrity of the file and then unpacks it and sets about completing three key validation steps: 1. To validate that the contents of each field are in the right format and mandatory elements are present. 2. To validate that the relationships between the fields are correct, e.g. the account open date is earlier than the extraction date. 3. To cross check that the new data is consistent with the previously supplied data, e.g. that an account has not changed from a mortgage account to a credit card account. Only if the data meets these validation checks will the data be loaded to the live bureau. The credit bureau might reject the whole file for a number of reasons: The encrypted file cannot be de-encrypted The file is corrupted The file has an incorrect XML schema The file has a significant error rate on a specific data item The file has an unacceptable overall error rate The number of events compared to previous months events is inconsistent The account holder match rates are inconsistent with previous months There is a significant increase in information or warning message Once the data is formatted correctly, compressed and encrypted it is submitted to the credit bureau s SFTP servers and from there the bureau takes over. 10

13 The Data Supply Process Internationally, credit bureaus set initial tolerances on the number of errors in various elements of the data and then tighten these over time. In most countries the mature tolerances for the account data are above 95% accuracy, although they tend to be lower on the subject data. This reflects the fact that most credit providers know precisely the state of the account, but often have lower accuracy of data on the customer, especially longer term customers. The response file generated includes summary statistics about the processing, response records providing feedback on what happened to every record, information messages, warning messages and errors messages. The credit bureau will then generate a response file. This response file structure is standard for all credit bureaus, but each bureau will have differing content as they may have slightly different data validation checks that they apply. This may cause your business extra complexity if you supply your data to multiple credit bureaus. Most credit providers will action the response files in the following way, although others may exceed these basic requirements: The data load statistics Check that the statistics match the supply, e.g. the number of records supplied were the same as the number received. The response records, information and warning records Store these for up to six months for future problem solving. Review warning messages when workload on error messages is low. Error messages Prioritise and fix the errors preferably on the source systems or if necessary, during the data transformation process. Submitting high quality data to credit bureaus 11

14 Managing a Data Supply Project When setting up a project there are three key things to be aware of: 1. Around the world, credit providers supply projects over-run because of the iterative data quality stages that occur after the data has been extracted. Too many projects fail to account for the fact that there will be issues in the data. This is the main risk to your project which is best mitigated by planning rapid iterations of test cycles. 2. The project finishes once the second monthly delivery of data to the bureau has been successfully made. We have seen in the last section how the bureau checks for consistency between submissions and this often flushes out a new set of data quality issues when the second submission is loaded. 3. Credit bureaus will have a number of credit providers working to supply data and it is essential to plan the first deliverables with them. The project team needs to be a cross-functional team in larger institutions, combining IT (project management, analysis and development) and the risk function (understanding of the data and business objectives). If the institution is developing its own solution rather than using an off the shelf one, then there is a requirement for strong XML skills as the ACRDS XML schema is a strict structure. It is not a simple task of selecting XML when exporting the data from Excel or SAS. The ACRDS is flexible to allow credit providers to provide data in a way that best suits their business and so the first steps in the project are to make a number of tactical business decisions on how to use the standard to best suit your business: 1. Which portfolios to supply and when to supply them? 2. How to supply the new data: a. What frequency to supply the data? b. Supply the bureau with a full extract or just the changes on the accounts? c. Which source systems to extract the data from? 12

15 Managing a Data Supply Project 3. Do you supply all events in one file: a. Can you extract up-to-date data on your collections accounts at the same time as the up to date accounts? b. How are sold accounts treated? Will you have to create separate extractions to capture them? 4. Are you going to supply all your portfolios in one file? 5. How will you manage sub brands, should they be all reported in the same file? 6. How do you plan to process the response files? Technically, the main decision is whether to build or buy. Traditionally credit providers have developed these data supply programs but there is a current trend across the world, especially in countries such as Australia, where there is a national data standard to use extract, transform and load (ETL) tools. The latest tools, such as SmartData, come built in with the ACRDS and also take care of a number of the details that add to the costs of an in-house developed system. This can include simple things like developing the code to create and maintain sequential batch identifiers to more complex things like response file handling and testing the output to confirm that the data format is correct. SmartData has demonstrated major benefits for project teams that have chosen to use it. It enabled a client to get through the first eight cycles of testing in just two hours, eliminating all systemic issues and allowing them to focus on the underlying and extraction issues immediately. This sort of benefit reduces projects that would typically take months down to weeks. As a project manager, the key phases that need to be planned are: 1. Data extraction 2. Data transformation 3. Internal verification (first load) 4. Verification supply with the bureau (first load) 5. Verification of supply with the bureau (second load) 6. Set up the access to the credit bureau (SFTP etc.) 7. Build and test the response handling software The interactions with the credit bureaus need to be scheduled. Many credit providers will be moving to CCR data supply with the new standard at once so there will be a need to schedule your work with the larger bureaus. During the testing phases, there will be a number of data anomalies that are exposed. This is referred to as the discovery period. In a successful project this will have been planned for, with the project team set up to run and re-run submission, clearing errors with every cycle. These cycles can take three to four days (extract, submit, bureau validation, bureau response, review and fix) and so a project that takes 8 to 10 cycles to deliver good quality data will have a discovery period of over a month. Very few projects achieve target quality in 8 cycles and 20 is quite common so this tail of the project can easily run to three months elapsed time if every issue has to be fixed in code or source systems. Submitting high quality data to credit bureaus 13

16 Managing a Data Supply Project There are two ways to minimise this loss of elapsed time: Use a specialist tool like SmartData to ensure that the cycles can be completed quickly internally, in minutes rather than days, without sending the data to the credit bureaus. This is particularly strong at eliminating systemic issues quickly. Take a data cleanse from the credit bureaus in advance of CCR data supply testing and validation. This will highlight many of the data errors, and is particularly good at eliminating the record level of issues that lurk in many operational systems, especially among your older accounts. There are a number of ways to fix the problems that arise from your data quality discovery period: Fix in source system The credit provider can allow the extract program to update as part of the monthly updates, or force their system to deliver the rectification. Fix in the extract program Some problems are easier to fix in the extract program, e.g. a sub-set of records have historical coded fields so a quick transformation can be applied. Fix via the credit bureau (typically historical data) The credit bureaus will offer clients either direct access to update their data on the bureau or will provide a service to do so. Typically this would be used where the error has occurred in the past and is easier to fix directly as long as the update programs will not overwrite the change. Fix in future cycles There will be errors that do not justify remedial action or simply cannot be fixed before the second load. Credit providers will need a process that plans and manages their correction priorities. In addition to the extraction work, there are two key data tasks that each credit provider will have to undertake with each credit bureau: First credit providers will need to reconcile the default accounts that they have already supplied to the credit bureau to check that they are up to date (especially where the debt has been subsequently sold) and that they are compliant with the new regulation. Secondly they will need to take steps to ensure that they will be correctly updated by the new data feeds that are being provided under CCR. There are a number of ways to fix the problems that arise from your data quality discovery period. 14

17 Lessons and Tips from Veda s Experience in New Zealand Veda has already led the introduction of CCR into New Zealand and has gained a great deal of insight into the potential issues that can arise with data supply. These are a few of the key insights: The new data standard is untested in practice or against industry wide business practice so early adopters must allow contingency for new issues that may arise throughout the move from test to live CCR provision. Getting SFTP and encryption methods established and testing connectivity early is vital. Veda suggests establishing a coordinated transition plan with phases, responsibilities and timings. It is important to discuss production options early in the supply as this can impact the nature and scale of testing for some customers. Remember that three months worth of data must be loaded before a credit provider can access the shared data under the rules of reciprocity. Plan for resources that have both a working knowledge of the operational systems and the data they hold to work on data quality in the verification process. All credit providers will have data errors that this process exposes and will need manual intervention. Often this will be in the source systems. Don t assume you can get all the data from a data warehouse or that it will be fresh enough to supply to bureaus. It will often be easier in the long run to use the operational systems. If you are sourcing the data from multiple data sources, make sure the sources are synchronised. Many credit providers have problems with the closed accounts where there were payment issues. You may need to reconcile the collections and account systems before extraction. Be aware of grace periods and tolerances already in your operational systems. There are clear guidelines on these in the ACRDS, but take care not to add these to any that exist already. Use the same logic to determine allocation of partial and over repayments in your data supply as the operational system. Submitting high quality data to credit bureaus 15

18 Lessons and Tips Guarantor information is often problematic to extract and often needs substantial work by business analysts to determine how to best retrieve. Many participants store deceased status at the account level; this is often problematic for reporting joint accounts. Older accounts tend to be the ones that are missing CCR information such as open date. While open dates do influence credit experience metrics in scorecards, it is better to have a logical estimate rather than miss the field. In some credit providers, account numbers are created sequentially so good estimates can be made for the open date. Following the initial release of a data standard, review and refinements will occur over time. Review/ refinement of a data standard is common to all markets and is a key reason for using flexible ETL tools, if available, rather than hard-coding the extraction and transformation. Review/refinement of a data standard is common to all markets and is a key reason for using flexible ETL tools. 16

19 Three International Guiding Principles There are always questions that arise on how to interpret the data standard with a credit provider s working practices and system limitations. IRP recommends that you always use the following principles to avoid customer complaints and confusion down the line: 1 Always try to supply data as close to the way the customer would see it on a statement that you would send them. This is the leading reason for noise, wasted time and costs in the customer complaints process. 2 Always try to use existing data on the operational systems rather than try to recalculate data for the CCR feed. Time and time again we have seen the new calculations introduce problems into the data feed (often on older accounts) that had been solved in the operational systems in previous years. 3 Involve the bureau early on in your project dealing with data quality issues is a core capability of a mature bureau. They can advise and guide you on the data standard and help expedite your quality of data supply, reducing project cost and time. Submitting high quality data to credit bureaus 17

20 Managing the Rectification Work Identified in the Response Files Every credit provider needs to have a procedure for rectifying data errors returned from credit bureaus to comply with the regulation concerning data quality. There are two key considerations that apply: 1. Timing of corrections Standalone rectification and correction files can be submitted before the next submission. Rectifications and corrections can be delivered in the next submission file. If the next submission file deadline is missed, then the rectifications cannot be performed and must become part of the following cycle. 2. Multi-bureau You must ensure that each rectification is delivered to each credit bureau. This will naturally limit the use of a direct interface if you are supplying multiple bureaus. Each bureau will not be working to the same standard set of error codes. Each bureau will implement these checks separately and so you may get different errors on the same account from each bureau. If you rectify the data on one bureau in response to its error message then we recommend you make the same correction on all bureaus in the same cycle to avoid confusion. 18

21 Multi-Bureau Data Supply The question of whether to supply to multiple credit bureaus is one of cost versus benefit. The industry would like to see all credit providers providing their data to all credit bureaus to ensure that there is a competitive credit bureau market. Naturally this comes at a cost to credit providers, the main ones being: The need to manage multiple data supply programs, administer passwords etc. The fact that each credit bureau will have subtle variations in the data validation rules they apply and these will increase the cost of compliance as you will need to understand these differences. Identity matching will vary based on the sophistication of each bureau s matching process and the breadth and depth of information on their database. This will mean variation in the errors that are generated which may be outside your control. The response files will not be consistent (see above) and so there will be an increased cost in maintaining them. The authors recommend that for those credit providers wishing to supply multiple credit bureaus, they take the pragmatic choice to do this sequentially, bedding one bureau supply down before you supply the next one. Submitting high quality data to credit bureaus 19

22 Glossary Rectification This is the remedial work to update errors in supplied data as identified during the load process. The credit bureaus will provide a response file identifying the error records that need rectification. Corrections This is the remedial work to update disputed records that a consumer, a bureau or another credit provider has identified as a result of a consumer enquiry. The supplying credit provider may themselves discover a data issue within their own systems that will in turn require correction of previously supplied data. These can be made either directly on the bureau, submitted as corrections in standalone files or updated in the next data supply. Updates Updates are the incremental data required for full CCR data or changes to the payment status of defaults. Today for example, Veda provides an update mechanism to update default data records. Validation Checking that the data supplied is according to the technical specification, e.g. numeric fields contain numbers, date fields contain dates. Verification Checking that the data is acceptable in the business context and aligned to previous supply, e.g. the date an account was opened was before the date it went into default and an account that was up to date last month is not 90 days delinquent this month. 20

23

24 To find out more visit veda.com.au MAY 2014 PV1