A story of data quality and reporting
Banks need to implement BCBS 239 standard when reporting to the European Banking Authority, EBA. This means, that when they submit their reporting packages to EBA, the numbers must be compiled from the underlying transactions, instead of merely posting untethered balances.
That sounds easy enough. Except when you have over 21 separate administrations in separate countries, each with local (legal) variations. And when these are each comprised of several more-or-less integrated sub-administrations for accounts receivables, general ledger and assets.
You have your work cut-out for you.
Leaseplan
Leaseplan is a Dutch car-leasing company. It’s been a European market leader since its founding in the late 1960’s. It has grown into a multi-national company through organic growth and ambitious acquisition strategies.
The company has been successful by giving local branches P&L and balance sheet responsibility, granting them freedom to develop local practices, tactics and processes, but holding local management accountable for the results.
Leaseplan bank
By the end of the first decade of the 2000’s, Leaseplan had acquired a banking license. This provided a strategic advantage. Not only could it draw money from private consumers by creating savings accounts, they could also acquire cash at lower interest rates on the capital markets.
This improved access to capital allows for increased growth.
But being a bank comes with responsibilities for external reporting. Which brings us back to BCBS 239.
Enter the External Reporting Data Quality program: ERDQ.
The ERDQ program
The ERDQ program was set-up by the Leaseplan leadership to comply with the BCBS 239 standards.
It entailed pulling the underlying transactions from all 21 local (sub) administrations, verify the integrity (execute the DQ part), and compile the reporting balances for the relevant positions based on them (the ER part). The initial scope of the program was FinRep reporting. It was to be extended with CoRep and Asset encumbrance reporting after.
Acquiring the data
The acquired data comprises customer data, accounts receivables data and dunning data. And, most importantly, assets data, in the form of lease contract data and, of course the collateral, the cars.
Content, format and timeliness have been agreed with all 21 subsidiaries, and in each of them, a project is started to supply the data.
Collecting and processing
The data is processed in a layered architecture, with a raw data layer, a propagation layer and a reporting layer.
The raw data stores the data as received, the propagation layer contains the curated data, ready for reporting, and the (results of the) quality controls.
The reported data is accumulated in the reporting layer, on transaction level, with all attributes required for the FinRep drilldowns.
Data Quality
Data quality, in this project, has a number of levels. It’s easy to get bogged in checking attribute-values, such as branch codes and DUNS-number. These are relevant, but not key.
The key is being able to support the reported FinRep balances by all underlying transactions.
Data quality is the measure of integrity between sub administrations: the contract-, the billing (accounts receivables)-, the customer-and the vehicle administration, and the general ledger administration.
The fact that in the operating companies, most of these administrations exist in separate systems, with limited integration, guarantees that there will be data quality issues to uncover.
Data Quality ambition
The result of the Data Quality part of the ERDQ program, therefor, is not providing 100% quality, but identifying quality issues to be addressed by the operating companies. This will consistently improve processes and systems to the point that, in the future, data quality issues will not have material impact on the reported data.
Administrative backlog
Most data quality issues are due to administrative backlog. This means that contracts that have been physically signed, have not been entered or updated in the contract administration system in time. Similarly, invoice payments are only being processed 2 days after payment, due to the delay of payment information from the banks.
How to correctly report
Statutory reporting requires timely reporting, and correct reporting. After a month is complete, finance departments hurry to update the financial administration and produce correct output in time.
For this, a detailed process, the month-end-close, is followed. It includes retroactive payment updates, based on the delayed banking information, and other steps to compile the financial balances correctly. However, what it cannot do, is update all sub administrations. There just is no time.
This forces the entry of manual postings, to reflect the value of the administrative backlog in the various financial accounts it may hit. These postings are in fact substantiated by transactions, but these are not recorded in the system yet. They create data quality issues in the context of the BCBS 239 standard.
Report to record
The EBA knows what it’s doing. By requiring transaction-based reporting through BCBS 239, they drive banks to improve the completeness and timeliness of their administrations. Better administrations suggest better control, and less surprises. And with the financial crisis of 2008 in mind, less surprises from banks is a good thing.
This is an approach that can work really well: using reporting to drive interest in accurate recording.
