Certain features are essential for handling the soaring amounts and types of data demanded by regulators, but others depend on each firm’s particular circumstances. That’s according to Jeroen Van Doorsselaere, VP, global risk and finance, for Wolters Kluwer’s finance, risk and reporting business.
The financial services industry has gotten used to the idea that regulators will require more granular and better data submissions, from a greater diversity of sources, faster than ever. The new supervisory backdrop, serving an overarching goal of enhancing integration of key operations, has defined the task that institutions face in optimising their finance, risk and regulatory reporting (FRR) capabilities.
If that was the “what” question, the more challenging “how” question is just being asked as firms set about reconfiguring their data management architecture, or overhauling it completely, to give the authorities what they want and, in an ideal world, to give firms themselves what they need, whether they realise it or not.
Certain features are essential to an effective FRR solution – a central data repository, strong data lineage and a modular design – but an assortment of other factors will determine the ideal architecture for any given firm. These include its mix of activities, the number and locations of the jurisdictions it operates in, and the relevant regulatory, legal and political environments. Another critical aspect is the history of the business, and of its systems in particular, for it is those systems that new technology will have to be integrated into or replace.
Perhaps the most vital factors are an entity’s organizational structure and corporate culture, and the extent to which they foster operational integration. BCBS 239, introduced in 2013, amounted to a regulators’ manifesto explicitly linking a bank’s ability to gauge and manage risk with its ability to function as an integrated, cooperative unit rather than a collection of silos.
Many of these factors are related to the size and age of an institution. The bigger it is, the more places it’s likely to do business and the more regulatory authorities will be making demands on it. A large, global bank may have to contend with everything from EMIR and AnaCredit in Europe to the U.S. Dodd-Frank act, along with a variety of national requirements, such as MAS 610 in Singapore and Becris in Belgium. With their complex stress testing procedures and/or nonstop, real-time submissions, these frameworks are data intensive to a degree that was unknown just a few years ago, and they feature a hitherto unknown complexity.
As for age, well, we have a tendency to pick up bad habits as we get older, even as we may also become richer, more confident and more highly regarded, and the same goes for financial institutions. The semiautonomous niches that may form as time goes by, often through mergers and acquisitions or the establishment of new subsidiaries or business lines, can be mirrored in a bank’s technology. There may be separate systems for different functions, none of which communicate well with the others.
A smaller or younger firm that has less technical debt – fewer unwieldy, expensive, error-prone legacy systems – may be better suited by implementing fully integrated architecture from the ground up, helping it serve as a bulwark against new or entrenched silos, and permitting it to handle the new generation of regulatory frameworks effectively. Such a root-and-branch overhaul may be impractical for more established businesses, even if their systems are more likely to be riddled with flaws. A piecemeal approach may work better, merging new technology with old, often to solve particular issues that have limited the ability to meet regulatory or commercial needs.
When pondering the particulars, it’s important not to lose sight of the big picture, which is that there is indeed a big picture. Whether an FRR solution is implemented in stages in a limited way, or everywhere and all at once, certain characteristics will be necessary for a firm to achieve the primary objectives of integrating operations and reporting more and better data:
- Centralised storage
A single source of clean, verified data with common definitions fosters consistency and transparency across an organization by creating a single version of the truth that can be used in all analytical and reporting processes. This helps break down silos by eliminating distinctions between “our data” and “their data.”
Perhaps paradoxically, by having only “the data”, different parts of the bank have more freedom to perform idiosyncratic bits of analysis, safe in the knowledge that the data, and therefore the results, can be trusted and applied elsewhere.
- Data lineage
Centralised storage is not enough. As data from disparate sources is aggregated, cleansed and verified in the repository, and as it then travels out and back in for different purposes, a trail of its movements must be established to ensure accuracy, consistency and transparency.
- Modular design
Components should fit anywhere within the technological architecture and be compatible with other equipment, especially legacy systems. This can save implementation time and expense.
- Minimal duplication
The use of standardised integrated data, common analytics and calculation engines with access to an FRR data warehouse limits the need to repeat work.
Beyond providing the scaffolding for institutional integration, these features help make FRR architecture adaptable, flexible and scalable. These traits will be vital for the next phase of the great supervisory project, the finalization of Basel III, also known in the industry as Basel IV.
Basel IV promises to require even greater amounts of data collection, analysis and reporting, as will such rubrics as CRD V in Europe, and whatever comes after them. As supervisors pose new “what” and “how” questions, institutions with the most flexible, integrated FRR architecture will be in the best position to answer them.
All credits to source blow :