Future-Ready Reporting
Loren C. Farmer
Reporting requirements in the banking, financial services and insurance (BFSI) sector are continuously evolving and creating unprecedented demands on the technical and functional infrastructure of all organizations. This has demanded a paradigm shift in envisaging and creating solutions and underlying enabling technology for the BFSI sector.
Regulators are demanding more granular data and additional data elements on an ongoing basis, driving computations from massive amounts of structured and unstructured data with inbuilt controls, accuracy and lineage challenges on a continuous basis. Typically, According to estimates, about 20% of data elements change and are redefined every year1. To support the systemic risk computation at the economy level, we believe regulators have plans to increase regulatory reporting requirement by 5-10X times by 20252 and . To enable this, regulators have plans to introduce machine-readable regulatory reporting instructions; and globally, regulators are likely to adopt the existing semantic definition standards. Figure 1 lists the upcoming regulatory expectations.
The need for a new approach to regulatory reporting
These changing regulatory reporting environment factors will compel a change to the technology infrastructure requirements for regulatory reporting in terms of volumes to handle, low latency to complete the reporting cycle, intelligence to ensure lineage, accuracy, completeness, audit trail and semantics to support the quantum of changes in the definitions. Currently, the BFSI organizations are weighed down by data-related challenges and manual processes in regulatory reporting. Figure 2 lists the multiple challenges financial institutions face in regulatory reporting technology.
An overall transformation is achievable by creating a domain-driven microservices architecture for various business requirements independently as specific instances. This architecture can be based on the business requirements’ dependence on various functional domains from the front end, mid office, back end and databases wherever feasible, and containerize the same. It is also important to create a set of common services to support the domain-based microservices. This will help avoid duplicating major enabling-functionalities like data input, extraction, validation and calculations and at the same time, keep it nimble to associate appropriate computing resources. These instances can be leveraged to increase and decrease the computing capacity as demanded by the domain, based on the period end /monthly/daily peaks and troughs, which can be dynamically adjusted to make the optimal use of cloud resources.
Major domains are then categorized into functional areas supported by a microservice to achieve the business objective (See Figure 3). For example, in regulatory reporting, in the past few years CCAR (Comprehensive Capital Analysis and Review) has taken a prime stage for major BFSI organizations. Clearing the regulatory stress tests was not only a financial issue addressed by appropriate balance sheet management but also a technical demand laying tremendous strain on the infrastructure to provide the computations through various risk, liquidity and stress scenarios. Optimizing the operating costs is the next challenge. Investing in additional infrastructure to support these models is never-ending with additional scenarios, data sets and granular requirements becoming the norm from the regulators.
Financial organizations are re-architecting their solutions with cloud as the underlying support infrastructure and microservices-based domain architecture to innovatively support these demands associated with data management and running the stress test models simulating capital requirement under various stress scenarios. This would mean utilizing the resources of the cloud for increased processing power dynamically as needed when these models run and not investing in data centers, hardware and licenses permanently for the same.
In addition, the cloud provides an opportunity to use open source technologies and is designed for big data, which allows organizations to move out of license-based products for software and data management at a fraction of the costs. All this is possible as applications move towards domain-based microservices, which need to be well-defined right from the data sources, aggregations and computations to provide the right outputs as demanded by businesses and regulators.
Conclusion
The ever-changing business and regulatory environment with demands for additional data and reporting requirements can be supported by a domain-based microservices architecture on the cloud leveraging its flexible infrastructure support, open source technology and design for big data
