What does a risk or governance function need to understand about its business requirements before initiating a strategic data enablement program?
This article is the second of a series of five articles. The first article can be read here.
Risk and governance functions are investing heavily in strategic data enablement programs that promise to transform financial institutions’ risk and governance capabilities through deployment of big data capabilities, advanced data integration platforms and the rich data visualization capabilities of business intelligence toolsets. However, the improvements in analytical insight and reporting efficiency from investments in the deployment of toolsets have tended to be marginal rather than transformational. Implementing new tools alone creates reporting that is more visually attractive, but the new reports rarely say much more than their predecessors.
This series discusses the valid reasons for the risk or governance function to invest in a strategic data enablement program to deliver these capabilities and explain what needs to be done by the risk or governance function before anything is spent on the implementation of new toolsets.
What does a strategic data enablement program need to achieve to succeed?
The first article in this series examined the need for data analysis capabilities to understand aggregate exposures across an institution. The creation of these analyses from data sourced from separate business-aligned data silos typically involves time-consuming manual data cleansing and consolidation activities. The implementation of current data engineering, dashboarding and visualization tools alone are insufficient to unlock the required analytical insights.
In order to unlock new insights and remove the reporting rigidities encountered when assembling analyses of data from across sources it is necessary to establish a 360° view of the necessary data: a single, consistent version of truth of the institution’s risk exposures and the financial obligations and activities that they arise from.
Consistent, was defined in the previous article, as meaning that the organization of data in this authoritative source is the same regardless of the source systems, businesses, organizations, locations, jurisdictions, entities or geographies that those data have been sourced from.
The previous article identified that one of the major obstacles to achieving this is the lack of foundational analysis prior to the commencement of a strategic data enablement program to identify and articulate the business requirements for this 360° view of exposure.
Why isn’t the foundational analysis performed?
Major technology implementation programs normally start with the articulation of the business requirements that the solution is supposed to satisfy. However, programs to implement strategic data solutions often use as starting points data models that are marginal refinements on, and consolidations of, existing models.
If there is a formal business requirement exercise it normally focuses on removing the current known pain points within existing reporting. Existing reporting does not however answer questions to respond to scenarios that have not yet been encountered. A requirements exercise focused on existing reporting will not identify requirements to answer these questions. It also is unlikely to show how to combine and analyze data that are currently maintained in rigidly separate data silos other than identify how to combine aggregate measures calculated from data within those separate silos.
One reason why data integration business requirements are not formally captured at the beginning of the data enablement program is that articulating business requirements for the integration of data is quite different from articulating business requirements for processing capabilities.
Business requirements for processing are described in terms of observable behaviors i.e. the interactions that result in the achievement of valuable observable outcomes [See Endnote 1]. The functional requirements for data transformation and data governance capabilities / toolsets can be expressed in this way. However, the requirements for organizing and integrating data to enable analytical questions to be asked and obtain meaningful answers need to be expressed differently.
Understanding the Risk Conversation
The first step to understanding how to express these data integration requirements is to understand precisely what the business problem is that needs solving.
Analyses of exposure, whether delivered as reports, dashboards or any other format are not created for their own sake. They are created to enable decision-making. The aim of a decision-making conversation about risk and governance is always to answer essentially the same question:
Should we accept or manage a specific risk exposure or issue?
[See Endnote 2]
These decisions are made through debate and discussion amongst the key stakeholders responsible for the governance of the business. Deciding what to do about a specific exposure requires specific information about the exposure. The conversation therefore includes the asking and answering of analytical questions that enable the decision-makers:
- To understand the nature and extent of the discussed exposure;
- To understand what can and must be done; and
- To contextualize the exposure amongst other exposures, possible threats, the business’s risk appetite and its obligations under internal policy or regulatory mandates.
Risk dashboards support this debate amongst stakeholders by answering the specific analytical questions raised in each risk conversation.
The exact questions that need to be answered in each risk conversation are specific to the type and nature of the exposures being discussed. The following generic questions are however representative of the types of questions that need to be answered:
What are our risk exposures?
- What type of events can happen?
- What are their causes?
- What impacts may arise?
Where are our exposures?
- What type of events can happen?
- What are their causes?
- What impacts may arise?
How large are our exposures?
- What is the expected loss?
- What is the worst-case possible loss?
What CAN be done about our risks?
- What are the possible mitigations / actions?
- Should the risk be avoided? (e.g. exit business / region, withdraw a product etc.?
What MUST be done about our risks?
- What regulatory / internal polices requirements mandate action?
- What are the regulatory compliance implications if an exposure changes?
What ARE we going to do / doing about our exposures?
- Which exposures will we accept?
- Which exposures will we manage?
- How effective have we been at managing our exposures?
What are our possible exposures (threats)?
- What will happen to our existing exposures if the business environment changes?
What exactly is the business problem that needs to be solved?
The goal of a risk or governance data enablement program is the creation of a capability to create analyses to answer the questions decision-makers need answered to take part in informed decision-making in each of the possible risk and governance conversations.
The solution therefore needs to:
- Enable asking of each of the analytical questions raised in each risk conversation; and
- Provide answers in the form of analyses of data representing the business concepts that were asked about combined in valid and meaningful ways.
[There are a limited number of valid ways to combine real world concepts. Although it is possible to ask the question “How many wings do African elephants have? This is not a valid question because it violates the business rule “Elephants do not have wings.”]
Not everyone discusses the same thing the same way
Discussions within specific business disciplines use specialized terminology which is specialized further in individual institutions.
Conversations amongst human beings are expressed in human languages. Business and technical dialects of human languages are used for conversations amongst specialists in the same business / technical domain. These consist of specialized terms that have specific meanings understood by those specialists. Words in common usage can have specific meanings in a business or technical dialect. Within even a single business line within a single institution words can have more specific meanings that are different from how practitioners within the institution or in the same business in another institution may understand them.
So what does the technical solution need to do?
The implemented solution needs to:
- Enable data to be organized so that it can be used to represent the distinct real-world things that may be asked about.
- Support a vocabulary of terms that represent those real-world things so that questions can be expressed in those terms.
- Enable combining the terms into each of the possible specific questions.
- Follow a set of rules (business rules) for combining the terms of the vocabulary into valid questions and combining data representing those terms in valid ways to provide valid answers.
Business Intelligence tools and data query languages provide the means to express questions in terms of any the available data elements of physically accessible data sources. Tools do not however ensure that those queries represent business meaningful questions or return results that represent business meaningful answers. The gap needs to be addressed in the data integration business requirements that need to capture and articulate:
A vocabulary that identifies and defines the unique key information concepts needed to answer analytical questions.
An information concept is a real world “thing” that we need to hold data about.
e.g. a person, a geographic address, an account, a calculation.
The information concepts define unique real-world things that only need describing once.e.g. a record identifying each person in the real world (e.g. current legal name and date of birth) only needs to be recorded once and does not need to be duplicated each time a new address is identified for that person [See Endnote 3].
Grammar that defines the valid ways for combining information concepts to express meaningful questions and obtain meaningful answers.
i.e. set of business rules for combining the concepts in valid ways to obtain meaningful answers e.g.
- “a party has one or more addresses”
- “a person is included in a marketing campaign”
- “an address is within a state or province”
Institution and business-specific definitions and rules
The solution needs to be able to organize data in ways that are specific to how decision-makers within the institution discuss, conceptualize and understand exposures as well as the specific ways they do that businesses within the institution.
The requirements therefore need to:
- Identify and define information concepts as they are understood and discussed within the institution rather than define them in the generic ways that they are understood and discussed across the industry.
- Identify specialized versions of information concepts that are specific to the understanding of business and exposure within specific businesses within the institution or in the context of specific product types or for ensuring compliance within specific jurisdictions.
- Identify specialized versions of business rules that define how information concepts may be combined in valid ways in the context of specific businesses or products.
What does it all look like in the end?
The next article in this series will explain how these requirements should be expressed in a single business authored, owned and maintained artifact that can be used by data architects to form the creation of logical and physical data models of the solution. The fourth article in the series will discuss do’s and don’ts for creating the artifact and the final one will describe an approach for leveraging existing expertise of the subject matter experts of the risk and governance function and business lines to author these requirements.
Endnotes
Endnote 1
Best practice is to express functional requirements as use cases i.e. a series of interactions between one or more actors in order to achieve a result of observable value.
Endnote 2
Accepting a risk exposure or issue is a decision to not take steps to mitigate the risk. A decision to accept a risk can be made when an exposure is within the institution’s risk appetite and the business is not mandated by internal policy or an external regulatory requirement to take steps to remove the exposure. A decision to accept an exposure may be made because it is not cost effective to manage the exposure or because the exposure represents a business opportunity. Accepted risk exposures should be monitored so that the decision to accept them can be re-assessed at an appropriate time interval in the future in case the extent of the exposure has changed, the business’s risk appetite has changed, or other circumstances have changed.
Managing an exposure involves taking steps to end the business’s exposure to the risk. This can include taking active steps to mitigate the risk i.e. withdrawing credit, tearing-up or hedging a market position, or implementing / remediating a control or contingency plan; transforming the risk e.g. changing the nature of an underlying financial obligation; or transferring the risk e.g. selling underlying financial obligations to another institution, purchasing insurance or outsourcing the operation of underlying processes or infrastructure to a vendor.
Endnote 3
This has important data governance implications for those data represented in the solution: holding multiple versions of the same piece of information can lead to inaccuracies e.g. A rating is only updated in one record and not in the other records for that person. Formally defining data integration requirements in this way can provide major benefits for a formal data governance program. The definitions can be used as the basis for creating data standards and for identifying types of reference and master data that authoritative sources need to be identified / established for.
Dan Shalev is an Information Architect and Governance, Risk and Compliance (GRC) professional focused on enabling data-driven business decision-making. His key focus and passion is the enablement of business decision-making using consistently organized data irrespective of the systems, businesses or geography those data have been sourced from. Dan can be contacted at dan.shalev@bifrostanalytics.com.
© 2013 – 2020 Dan J Shalev. All rights reserved.
Bifrost Analytics 
1 comment