FRIM: Foundation for Finance and Risk Data Management challenges
Creating a common language between Finance and Risk
Banks are increasingly required to deliver more frequent, in shorter lead times and containing much more granular data to Regulators, in addition to the traditional reports. Understanding the link of the reported data back to the source is therefore key. The foundation lies in a Finance and Risk Information Model with harmonized and standardized Finance & Risk data definitions.
The need for change in Finance and Risk
The ‘world of data’ will have an enormous and lasting impact on Finance and Risk. More in particular, departments like Finance and Risk policies, Risk modeling and Finance business controls will have to cope with the fact that Bank regulators are requiring more frequent and more detailed information (e.g. AnaCredit, PERDARR and AQR),in addition to the traditional CRDIV reporting. One could say, that regulators are passing by the traditional data aggregation and reporting functions and require the underlying granular data sets in order to analyze them themselves. Additionally, these new requirements are coming at a faster pace, with ever decreasing lead times for the required changes to be made.
Does this development signify the beginning of the end for the financial reporting functions? We think not in the short run, as aggregated reports are the basis for both internal and external analysis and validation. Often aggregated reports are the entry point for analysis, by breaking down through the constituting dimensions. However, reporting granular contract level data instead of synthesized reports, will require Finance and Risk to rethink the way they organize their aggregation and reporting processes.
The necessity of a common language for finance and risk
As the reconciliation of reported information is under increased scrutiny by the regulators and accounting standards and regulations between Finance and Risk are converging (i.e. IFRS9 and CRR/CRD-IV), alignment between Finance and Risk becomes increasingly necessary. This reconciliation can only be achieved if Finance and Risk base their reporting on a common set of granular data, often sourced from (legacy) core banking systems.
Many banks have established programs to deal with the required changes in data sourcing. Often this is done by collecting the granular data in a central data store and connecting this data store to the Finance and Risk reporting chains. Starting point for these programs is to create an unambiguous understanding of the data requirements by developing a common Finance and Risk language.
The overall objective of establishing such a common Finance and Risk language is to standardize and harmonize data and definitions required for reporting purposes and hence to lay the foundation for a more simplified and integrated Finance and Risk (data) architecture.
This common language also serves other purposes. For one, Finance and Risk will have a better mutual understanding of the (underlying) reporting data, exchanged between Finance and Risk to produce the (externally required) reports.
Furthermore, the common language will serve as the set of business requirements, in turn enabling better servicing, faster and higher quality data towards IT in establishing the data store. And finally, the common language is used in the communication towards the business and reporting entities, in understanding the requirements of what data has to be sourced by the local business to that data store.
This common language will not replace all local languages in Finance and Risk. These local languages (in local reporting entities and/or local source systems) will remain, and may serve their own purpose (e.g. local reporting requirements).
The relevance of a Finance & Risk Information Model
In creating a common language, a data dictionary might be an useful mechanism to capture a list of business terms and definitions. However, a data dictionary or taxonomy is only half of it. Putting these business terms in context with each other, through establishing relationships, will form the basis of what is often called a Business Information Model (BIM). For example the business term ‘Obligor’ is related to the term ‘Counterparty’. The relevance of a BIM is that these relations help to understand the impact of a changing definition(s) on related business terms and hence on the impact of the change on the sourcing of data and/or reports.
Relevant to mention is, that the BIM provides the business user’s view of the data with clear and unambiguous definitions for the business concepts which the data represents. As such, no data normalization or technical identifiers will reside in the BIM, as these are considered to be elements of technical data models (like a Data warehouse).
Taking on the abovementioned regulatory challenges, many banks are struggling to actually implement a BIM for the functional domain of Finance and Risk, a Finance and Risk Information Model (FRIM).
In Deloitte’s vision, a BIM is placed at the core of the (Enterprise) Data Management Framework. It is the glue that binds all the Data Management aspects, like meta-data, data governance, data quality and data architecture together, see figure 2.
Establishing a Finance and Risk Information Model (FRIM)
When starting to build a FRIM, relevant Subject Areas representing a logical grouping of a set of crucial data elements are to be defined. Resulting in Subject Areas like for example ‘Product’, ‘Counterparty’, and ‘Arrangement’, as depicted in figure 3.
All business terms harvested from regulatory reports and datasets, are subsequently placed in those Subject Areas, in order to facilitate consistent drafting of definitions and placing them into context within that Subject Area. The defined definitions from these datasets are “future proof” and may be used for other data requests. As such, the conceptual information model starts to evolve where relevant business concepts like ‘Organisation’ and “Individual’ are defined and belonging to the ‘Counterparty’ Subject Area.
Further detailing the conceptual level to a logical model is done by maintaining characteristics of the key data elements on a more granular level, i.e. ‘Legal name’ is a characteristic of an ‘Organisation’ (figure 3). Expert knowledge of core business processes (i.e. lending, provisioning) and what data elements are included in these processes is essential in order to decompose the aggregated data further.
FRIM and the future of Finance and Risk
The creation of the FRIM is a first step on a long journey. The data driven approach requires a change in mind-set for both Finance and Risk. Viewing a report no longer as a set of aggregate data (e.g. based on Chart of Accounts), but rather as a combination of attributes resulting from a set of business rules, requires understanding the lineage of the reported data back to the underlying granular data elements. This data lineage approach requires reflecting on some core values regarding internal control systems.
When looking at the consequences of the regulatory requirements to provide insight in the underlying granular data elements, it could very well be that this is actually a blessing in disguise for Finance and Risk. Instead of correcting the figures at the end of the aggregation and reporting chain, Finance and Risk demand data to be delivered first time right by the businesses. Making corrections in the large sets of data to be delivered to the regulator every period is not an option. And with the data store created by Finance and Risk, they can add value by providing data analytics services and become more impactful in the business decision making process.
Another impact is on the change process. Every change will be expressed as a change in either data attributes or business rules. Changes in attributes will potentially require additional sourcing, whereas changes in business rules ‘only’ require a change in calculations and / or formatting.
Thus, Data Management can very well be the catalyst for the next generation of Finance and Risk organizations, with a further improved cooperation between Finance and Risk or even a Finance-Risk reporting chain within a bank. Of course, this will fuel hefty debates on where and by whom key functions like information management, data modelling and validation rules maintenance have to be performed….
1. E.g. like a normalised Data warehouse
2. A BIM is referred to as an Enterprise Data Model in the DAMA standards