Achieving a single customer view for the banking sector
The next era of regulatory reporting
Regulators are mandating banks to provide more and more insight into their master data. The Deposits Guarantee Scheme is exemplary for such a new data request by the Dutch central bank (DNB). What are the main implementation challenges banks should address?
- Traditional templates & generic datasets
- Single Customer View
- Key implementation challenges
- Concluding thoughts
Both traditional templates and generic datasets
Regulatory reports by banks manifest itself in many forms. Traditional templates are still distributed, but regulators are pushing to gradually replace the templates with harmonized, generic datasets that enable data-driven supervision. These datasets contain granular, very detailed information that often goes back to the original details of the contract and customer. AnaCredit and Residential Real Estate are two recent examples of the start of a new era of regulatory reporting, with more to come. So what are the challenges for banks who are implementing the new (Dutch) Deposit Guarantee Scheme?
Single Customer View – ‘Integraal klant beeld’
As of January 2019, the existing Deposit Guarantee Scheme (DGS) requirements will be extended to include a more detailed dataset called the “Single Customer View” (Dutch: Integraal Klantbeeld). The testing phase starts in September 2018. Until now, DNB requested banks to submit a quarterly report. This was used to calculate the amounts guaranteed by the DGS, based on the amount per account. However, the Deposit Guarantee Scheme Directive (2014/49/EU) states that the amount should be calculated based on the amount of deposits per accountholder instead of per account. A change to DGS reporting was inevitable: banks must offer an overview of the amount covered per client.
Key implementation challenges
Achieving a Single Customer View is far from easy. Most banks have a widely dispersed IT system landscape, with a variety of (legacy) systems to process and store payment and deposit data. The interpretation of DNB’s complex regulatory guidelines adds to the complexity. For instance, implementing EBA DPM 2.7, IFRS 9 and AnaCredit revealed some very important challenges to cope with during any next implementation. These are listed below.
1. Interpreting requirements
DNB’s (data) requirements come in various ways: legislation, handbooks, and data delivery agreements complemented with technical data model specifications. It can be hard to translate those to the bank’s context in a unified way and even harder when for instance data definitions are not aligned within the bank.
2. Data quality and availability
Once the (data) requirements are defined, the source location(s) of data should be determined and data availability and quality in those systems should be assessed. Very often these systems are used in operational processes and not for reporting, so they lack necessary data attributes. In addition these operational systems often contain aggregated group level data (e.g. general ledger), whereas contractual data is required.
3. Obtaining the “single customer” view
The available data should be collected and integrated to obtain a single customer view. This implies that data from different systems must be integrated and properly linked. Very often, important keys (identifiers) to connect customers are missing or data is not of the same granular level - Client A in system X could be Client B in system Y – or not.
4. Reconciliation differences
The DGS dataset should reconcile to other regulatory reports, such as the FinRep and Resolution planning templates. The source location(s) of data for those reports should therefore be aligned. In addition, data should be reconciled with external sources (e.g. Chamber of Commerce).
5. Technology & tooling
The extraction, transformation and loading of data requires specific tooling and technology such as data modelling and data migration tools. These must meet the strict demands of DNB and must create an encrypted reliable dataset. End-user computing tools are not recommended.
6. Reporting timeliness
The reporting process, including data collection and transformation, should be designed in such a way that the bank is able to report the DGS within 72 hours’ notice.
Data availability and quality have proven to be the most prominent challenge in conjunction with obtaining the single customer view. Changing granularity of data, amending source systems and developing data integration processes is time consuming, and is, without proper (data) requirements and analysis, an underestimated issue which is around the corner, affecting the project’s timelines. Having a single data repository for storage of unified customer information across source systems is a prerequisite for obtaining the single customer view. Therefore it is crucial to always start a (new) data and reporting project with a focus on (data) requirements and availability analysis, so issues are raised at the beginning of an implementation and sufficient time will be left to design and build solutions.
The Future of Banking
Since the beginning of 2018 we have been sharing a range of articles with you on the future of banking, based on the ‘seven wicked problems’ we have identified. Embrace digital is one of these ‘problems’. Our research skills and day-to-day experience in working with banks have allowed us to dive into these challenges more deeply. By sharing our insights, we strive to help you with the choices you face in your day-to-day work and with aligning your leadership, culture and organizational structure to a fully digital mindset, optimizing the use of proprietary and external data. Sign up for the email alerts to make sure you won't miss any of the articles about the latest insights and solutions on the future of banking.