This blog is an introduction to Regulatory Reporting. Regulatory reporting is mandatory activity banks have to perform with the coordination of Treasury, Group Finance, IT, and business lines. Regulators across the globe depend on the accurate and timely submission of various Risk and non-risk reports by banks to measure the overall health of the banking sector.
Regulatory reporting in the banking sector is reporting its business numbers to local regulators like RBI for India and FED for the US. This includes the Balance Sheet, Profit & Loss statement, also Capital adequacy, and Liquidity Coverage numbers.
Banks generate and collect data from various business lines. Collecting information from disparate sources is not only cumbersome but also, at times, inefficient; the difference in reporting formats governed by multiple regulators adds to the troubles. Data inaccuracy, the dearth of skilled resources, need for constant reconciliation to recheck the accuracy of the content are some of the other challenges. Regulatory reporting needs to address the problem of legacy mainframes, lack of granular data, and intricate data mapping.
The regulatory reporting end-to-end process is not a straightforward task. It has its own complex dynamics. The process followed by various banks does differ to some extent but the crust of reporting remains the same. Let us discuss the abstract view of current regulatory reporting all the way from data sourcing to submission to external or internal supervisors.
During the subprime crisis of 2007, when Lehman Brothers failed, Regulators thought of more stringent rules to apply for financial institutions. The Basel committee came up with the recommendations for Basel rules which as of now implemented as Basel III. There are strict guidelines for Capital requirements and Liquidity Profiles to be reported with a certain frequency and non-compliance with them has its own repercussions.
It’s been quite an improvement with what Globally Important and Systemic Banks are reporting but Regulators across the globe are expecting more than just sending business numbers before deadlines. They want automation and improved process with minimal adjustments by human interventions. They want Banks to devote 80% time to the analysis of data and 20% time to production. Regulators are satisfied with the numbers that Banks are reporting but they also want to see how those numbers are derived.
Let us see what existing abstract structure Banks have:
The above flow diagram shows how data flows from upstream to downstream reporting. Disparate data coming from trade desks, consumer transactions, loan contracts, etc. are extracted using batch processes on a daily basis and it needs to be transformed so as to make data meaningful and sometimes need to fill the blank spaces kept by traders :).Overnight data gets batch processed and further dumped in a data warehouse that works as a single point of source for downstream reporting. This data can be further spitted into different Subject Areas called Data marts.
Finally, this data gets picked up by BI tools which can be used for Trend Analysis, Day on Day Delta exposure against different dimensions. The same data can be used for regulatory filings by populating numbers in the template as per Business Rules using AxiomSL® ControllerView®, OneSumX®, or any in-house strategic tool Bank has created.
Today Global Banks have to be flexible with ever-changing regulatory requirements. The regulators are looking for more than just reporting templates but automating and streamlining the entire process till the last mile of reporting. There is still a larger gap when it comes to BCBS 239 recommendations implementation regarding data lineage and manual intervention and reporting in silos where reconciliation becomes a tedious job.
There is a long way to go for financial institutions in the Regulatory Reporting area from data sourcing to Report generation. The Regulators have come up with solutions in the recent past of creating reusable business concepts that can have certain dimensions and measures. It can be used in different permutations and combinations to create the view required for analysis and reporting which is called hypercubes. This structure is quite flexible when it comes to any regulatory change which can be seen in template-based reports where we need to revamp each time there is a regulatory change required. Please refer Stages of Regulatory Reporting blog to know more about the various stages of regulatory reporting.
Amlgo Labs is an advanced data analytics and decision sciences company based out in Gurgaon and Bangalore, India. We help our clients in different areas of data solutions including the design/development of end-to-end solutions (Cloud, Big Data, UI/UX, Data Engineering, Advanced Analytics, and Data Sciences) with a focus on improving businesses and providing insights to make intelligent data-driven decisions across verticals. We have another vertical of business that we call – Financial Regulatory Reporting for (MAS, APRA, HKMA, EBA, FED, RBI, etc) all major regulators in the world and our team is specialized in commonly used regulatory tools across the globe (AxiomSL Controller View, OneSumX Development, Moody’s Risk, IBM Open Pages, etc). We build innovative concepts and then solutions to give an extra edge to the business outcomes and help to visualize and execute effective decision strategies. We are among the top 10 Data Analytics Start-ups in India, in 2019 and 2020.