AnaCredit: Time for a Reality Check
By FF Newsroom · 29 January 2016

FinTech Finance recently asked Nicos Kynicos, Senior Regulatory Reporting Specialist for Wolters Kluwer’s Finance, Risk and Reporting business for an overview of AnaCredit and what banks can expect from a tech perspective.
First off, can you provide an overview of the regulation?
The AnaCredit project started in 2011 to form a core set of low level and harmonized data on credit granted by euro area financial institutions. On the 18 May 2016, The European System of Central Banks (ESCB) settled plans for stage one of its Analytical Credit Dataset (AnaCredit). The purpose is to enable the work of the Single Supervisory Mechanism (SSM) by providing a full, true and up-to- date view of Eurozone credit data.
So what has changed?
Firstly, the ESCB delayed AnaCredit by six months and now goes live on the 1st September 2018. By no means is the delay reason enough to lean back, instead, the delay gives banks the chance to evaluate the gaps they have to fill and find the right solution. The threshold to report past due loans has also been raised from €100 to €25,000 – so that it is now the same as non-past due. The final rules also add three new data items and removed nine; please see Table 2 for more details. Five data items have also had either their name or definition updated.
What are the key challenges for banks?
From our conversations with banks that are in scope for AnaCredit, we see a number of challenges and concerns;
- Data quality, completeness and availability: front office and back office systems, particularly older ones do not capture the data that needs reporting. Therefore system enhancements, their lead times, training staff all add extra work and complexity.
- Overlap with IRFS9 project(s): outputs from IFRS9 projects need to feed into AnaCredit reporting e.g. Stage Assessments, Accumulated impairment amounts etc. Can firms resolve this dependency in an operationally efficient way?
- Risk system dependencies: For example, stage 1 of AnaCredit requires the counterparty PD of eligible debtors (as per the CRDIV definition), but the final text does not clarify if this is only required only where the reporting firm has IRB approval.
- Reconciliation: Stage 1 only focuses on a subset of instruments, so how easy is it for firms to filter their balance sheets to have a sensible benchmark to reconcile? This is required to ensure that all applicable exposures are reported and the challenge is where and how will this be done, especially if another tactical solution is implemented? It would make more sense to leverage an existing regulatory reporting solution that can cater for this. In addition, firms will have to consider reconciliation to their COREP and FINREP submissions to which many of the data items will relate.
- Vendor risks: Some vendors are using AnaCredit as a platform to launch new products, this is the certainly the case in Germany. What risks and challenges does this present to firms e.g. un-tested technology, an additional platform means another silo and consequently reconciliation and data consistency challenges as well as new skills to be learnt to implement and support the solution.
- National discretions; the risk here is that local regulators will extend the scope of AnaCredit to meet local objectives, but in the same ECB time-line. For example, local regulators are discussing integration with local credit registers in Germany and Spain.
- Capacity and centralization vs localization: Many (larger) institutions who have numerous subsidiaries and branches in Euro member states are already in the midst of large transformation programs to replace tactical reporting solutions with more holistic strategic ones. However, due to the timelines for AnaCredit, these programs cannot be leveraged. The sensible decision would be to implement a centralized solution to AnaCredit for these firms, but the reality is more likely to be local solutions, which do not deliver economies of scale.
- data sources and owners
- your level of compliance
- changes to processes and systems
- business needs
- target architecture
- target operating model
- implementation scope, planning and deliverables