Data Governance Playbook

CDO 3.
0 – DG Playbook
Table Of Contents
Section Slide
I. Introduction to Data Governance 7
A. Executive Summary
B. Key Contacts
C. Why Data Matters
D. Industry Trends
II. Understand business drivers 12
A. Introduction
B. Foundational Concepts
C. Sample Approach
D. Example Business Drivers
III. Assess current state 22
A. Introduction
B. Sample Approach
C. Assessment Model Inventory
D. Detailed DMM Approach
E. Key Outputs
IV. Develop Roadmap 34
A. Identify gaps (e.g., leverage target state and current state)
B. Determine projects to close gaps
C. Prioritize and sequence
Page 2
Table Of Contents
Section Slide
V. Define scope of key data 45
A. Select approach
B. Define key data by supply chains
C. Define key data by domain
D. Define key data by a scoping methodology
E. Use a modified version of an existing bank’s structure
VI. Define and establish governance models 53
A. Define CDO office roles and responsibilities
B. Develop a RACI
C. Define an interaction model
D. Identify committees
E. Define escalation channels
F. Identify level of centralization / federation for DG
G. Define and implement roll-out strategy
VII. Define data policies and standards 76
A. Define a data policies and standards framework
B. Select data policies and standards specific to the bank’s needs
C. Write data policies and standards
VIII. Establish key processes and procedures 117
A. Establish issue management
B. Integrate SDLC (software development lifecycle)
C. Identify and develop other key processes and procedures
Page 3
Table Of Contents
Section Slide
IX. Execute Data Quality 136
A. Introduction
B. Link to DQ Playbook
X. Source Data & Activate Domains 138
A. Introduction
B. Link to Data Sourcing Playbook
XI. Capture & Test Metadata 141
A. Introduction
B. Link to Metadata Execution Playbook
XII. Next Gen industry trends and market demands
A. The evolution of Data
B. Next Gen Data Architecture and Use Cases
Page 4
Executive summary
Data Governance is the need to effectively manage and integrate vast and often disparate volumes of business data in order to be able to extract
competitive information from such – and in a timely manner – is a challenge faced by most financial services institutions today. Coupled with this
need is the wave after wave of regulatory requirements that such institutions need to comply with. To successfully address these needs, financial
services institutions must actively manage their data assets through programs that go beyond traditional systems development, and focus more on
the practice and discipline of Data Governance (DG).
This document serves as a playbook for implementing data governance end-to-end across enterprise data offices, lines of businesses, risk types, or
control functions. It can be implemented in segments to achieve targeted data governance capabilities, or used to implement a large-scale data
governance program. The concepts and frameworks contained within this playbook should be used as a starting point, but may need to be tailored
to meet the needs of the business. Using this playbook will help our clients achieve the following targeted data governance capabilities:
• Understand drivers
• Assess current state
• Develop roadmap
• Define scope of key data
• Define and establish governance models
• Define data policies and standards
• Establish key processes and procedures
• Execute Data Quality
• Activate domains and authoritative data sources
• Capture and test metadata
Page 5
Introduction to Data Governance
Page 6
Why Data Matters
Today, every company is a data company
▶ Increased regulatory scrutiny and intervention has presented financial institutions with the difficult challenge of
understanding, analyzing and providing ownership over data. Every financial institution has had to transform into a
‘data company’ that uses it’s data as the foundation to make informed decisions, better serve clients, and provide
accurate information to regulators and investors.
Everyone within a company is responsible for data management and data governance
▶ The amount of data being created, transformed, and used is growing exponentially and is becoming omnipresent
within all aspects of organizations. The key to accurate, consistent data is an effective governing operating model
around the input, use, and protection of the data in which the entire organization is responsible.
All companies want to create, use, and maintain high quality data
▶ Strong and effective data governance is essential for long lasting data quality, which includes confidence in the data
and the effectiveness, utility, and accuracy of the data
Data Governance
Data Domains
Data Standards Capabilities Adoption Sustainability

Elements
Data Quality
Page 7
What is Data Governance (DG)?
You can’t manage what you don’t name. And then there’s its corollary: you can’t manage
well what you don’t define explicitly.
Data Governance is:

► Overall management of the availability, usability, integrity and security of the data
employed in an enterprise
► Practice of organizing and implementing policies, procedures, and standards for the
effective use of an organization’s structured/unstructured information assets
► Execution and enforcement of authority over the management of data assets and the
performance of data functions
► Decision-making process that prioritizes investments, allocates resources and
measures results to ensure that data is managed and deployed to support business
Page 8
Benefits of data governance
There are widespread benefits across a financial services organization to establishing data governance capabilities.
Hallmarks of a strong DG organization include the establishment of clear accountability for data management through
data governance roles and responsibilities.
Benefits of having a DG program include:
Addressing and minimizing operational risks

► Increases transparency into data management
► Builds confidence in data management practices
► Reduces issue remediation
► Bolsters accountability for data policies and standards
► Enhances business processes (i.e. accuracy, completeness, and timeliness)
Sustaining the benefits of regulatory programs (e.g., Basel, Dodd-Frank, CCAR, Solvency II)
► Institutionalizing data governance enhances all areas of the business (e.g., risk models may be developed with
high quality data, MIS and regulatory reporting being done with greater confidence and in shorter cycles)
Establishing a foundation for meeting future regulatory mandates

► Makes an organization better prepared to respond to future regulatory mandates that require robust data
management functions (e.g., BIS’s Principles for Effective Risk Data Aggregation and Risk Reporting)
Page 9
Industry Trends
▶ Firms are reengineering their traditional data management approaches due to regulatory demands such as Dodd Frank,
CCAR, and BCBS 239
▶ Efficiency programs are now focused on lowering the cost of operating the data management and controls environment
▶ Streamlining process capabilities across key functions such as risk and finance
2015 & beyond
▶ Leveraging data management investments to enable analytics and drive better decision making
Sustainability
2013 – 2015
• Manage end to end data supply chains
BCBS 239 and CCAR from report to data
• Integrate control environments
2009 – 2013 • Formalizing and establish CDO
across model risk, spread sheet
functions
2005 – 2009 Data Quality controls, SOX
• Initiate metadata factory to collect • Consolidate firm wide policies and
Accountability and integrate metadata
• Deploying and executing data standards
• Establishing formal data roles and policies and standards • Building enterprise architecture • Automate the capture of metadata
responsibilities • Formalizing local data governance standards for data sourcing, • Build capability to independently test
structures and roles aggregation, analytics and
• Drafting and deploying policies and • Strengthening data architectures
reporting
standards • Establishing enterprise data through the use of new technologies
quality approaches and standards • Consolidate and build common • Building formal job families and
• Establishing formal data taxonomies training to build & retain talent
governance structures • Establish metadata approaches
and standards • Evaluate end user data
• Focus on centralized enterprise requirements and thresholds
data warehouse approaches
Page 10
Understand business drivers
Page 11
Section Introduction
► The objective of this activity is to declare an overall objective of the client’s data governance program by establishing clear measurable
goals, linking to business drivers, drilling down to the data management concepts that will enable achievement of that goal.
Definition ► Executing this step will help the client understand the options for their future state and evaluate and select the most suitable future
state based on the client’s vision and strategic objectives.
► Understanding your client’s drivers will allow you to deliver a high quality offering and align the target state to their overall vision.
► Determining what capabilities will help the client achieve their objectives.
Business Benefits
► Data Management/Governance Organizations Have different structure and focus on establishing different capabilities based on the
business objectives they are trying to achieve
► The primary business driver for the majority of data management functions has been demonstrating control to regulators, specifically in
the context of BCBS 239 and CCAR. This has emphasized the need for data governance capabilities within organizations.
Industry Trends ► The secondary benefit that drives data governance organizations is providing value to their business partners through analytics and
reporting that the business desires but has not been able to achieve.
► Mike Butterworth
► Mark Carson
Key Contacts ► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
► The primary business drivers will vary by the institution’s specific size, area of expertise, location in the global marketplace, and
Chapter Guidance standing with regulators. The business drivers contained within this section can be used as a starting point.
Page 12
Identifying Key Business Drivers
Key take-away: Firms need to have clear agreement on key business drivers before investing in technology and data capabilities
Information Strategy Framework Key business drivers

► Need for products to leverage good quality and
An information strategy harnesses the vast amounts of data available to
any company and turns that into useful knowledge. In addition it well managed data
establishes the foundation for data management. ► Efficiencies
in operating model creating greater
speed to market
Profit
► Data consistency requirements across customer
data sets
► Complex product design based on efficient and
intelligent data use
► Proliferation of data
► Enhance operational control and customer
satisfaction
Cost
► Reduce data storage costs
► Increased demands by customers for reporting
(e.g., Solvency II, UCITS IV, Form PF)
► Ability
to respond to change or integrate new
products, regions, or companies
Efficiency
► Business operational metrics
► Decrease process cycle times
► Heightened
regulatory scrutiny (e.g., Dodd-Frank,
CCAR, RDA)
► Concentration risk and correlations across LOBs
Risk and
regulatory ► Ad hoc stress scenarios
► Anticipate emerging risks
► Optimize capital allocation
► Vulnerability threats
Page 13
Foundational Concepts
Key take-away: Representative business questions often help illustrate how investment in information capabilities support key
business drivers
Key Business Drivers Key Questions Information Management Capability
Offensive
“What customer segments do I want to Quantitative Analysis and
focus on or exit?” Advanced Analytics
Profit
"What tools are available so my quants can focus on

analysis not data sourcing?"
Business Intelligence and
Cost Reporting
"How can I reduce my overhead costs related to
quarterly reporting"
“How accessible is my data?”

Efficiency "Where is the best source to get customer Data Architecture
exposures?"
“How good is my data?”

Data Quality
“Who’s accountable for my data?”

Risk &
Regulatory
“Does the existing governance structure meet Data Governance
regulatory requirements
Defensive
Page 14
Example Business Driver: BCBS-239
Regulatory Actions
► The Basel Committee on Banking Supervision (BCBS) released the Principles for effective risk data aggregation and risk reporting (The Principles) on in January 2013 and a self assessment
questionnaire for G-SIBs in March of 2013.
► The FRB and OCC required the US G-SIBs to complete and submit the self assessment questionnaire by July 2013.
► Both the BCBS and the US regulators have set expectations that the G-SIBs comply with The Principles by January 2016.
The Principles:
► There are 14 principles which heighten expectations for effective risk reporting to the board, internal management and regulators in order to facilitate Senior Management and Board accountability
for risk management during stress/crisis conditions during and business as usual.
► The Principles raise expectations for risk data and reporting process and controls to be similar in nature to those of financial data.
Banks Regulators
I. Governance & Infrastructure II. Risk data aggregation III. Risk reporting practices IV. Supervisory review & tools
1. Governance 3. Accuracy and integrity 7. Accuracy 12. Review

2. Data architecture and IT infrastructure 4. Completeness 8. Comprehensiveness 13. Remedial actions & supervisory
5. Timeliness 9. Clarity measures
6. Adaptability 10. Frequency 14. Home / host cooperation
11. Distribution
Timeline
Submit BCBS questionnaire Full compliance required

Regulatory deadlines:
(July 2013) (January 2016)
Part 1: Perform BCBS self- Part 2: Conduct detailed

Part 3: Implement Part 4: Sustain
assessment planning
Page 15
Sample Approach
Key take-away: Business drivers must be identified and established by reviewing in-flight data management programs, existing
initiatives and establishing the data management priorities.
Inputs Process Outputs
Global banking and financial services

WP01: Kick-off Deck
company Organizational Structure Step 1: Kick off project Mobilize project team and identify key Global
banking and financial services company stakeholders from the Refined Approach
enterprise office, lines of business IT as well as owners of key
systems, data owners, process owners as needed
Step 2: Draft approach and schedule workshops Establish the

sequence of activities and set expectations for engagement for the
subsequent steps. Schedule workshops with key stakeholders Initial workshop schedule
Step 3: Review in-flight programs that are designated to support the

target and obtain confirmation on high level data management
priorities
The Business Drivers
Example Business Drivers*
Step 4: Hold workshops Propose and agree on business drivers for data
management with key stakeholders. Identify initiatives that could
be used to test and support the case for data management
Page 16
Target State Capabilities Summary
The team used the stated business drivers and current state assessment output to determine key capabilities that are part of a mature Data Quality and
Assurance framework. The capabilities listed below are categorized into five target state areas.
1 Business Drivers 2 Current State Challenges 3 Key Capability Recommendations

Perfect client experience
► Full scope of policies and Target Area Actions
► Improve client interaction standards not promulgated 1. Establish Data Management roles and responsibilities (e.g.,
360 view of client, enterprise wide Business Process Owner, Data Steward, Data Custodian)
Know client preferences A Organization
► Inconsistent measurement 2. Establish and formalize data domains
► Integrated relationship
and monitoring of
management compliance
Single version of truth 1. Establish policies to define all key accountabilities, starting with
► Client segmentation ► Individuals not identified for
full range of roles and Policies, Data Quality and Assurance
Optimize product mix
and pricing responsibilities Standards 2. Establish measurable enterprise wide data governance standards
B and that define minimum compliance requirements
► Consistent execution of data
quality assessment not in Processes 3. Develop consistent, integrated data processes for use across the
Reporting and analytics place enterprise
► Data remediation and
► Financial, management
change management
and regulatory reporting 1. Establish data management metrics
processes not C Governance
Accurate, timely and standardized/well defined 2. Setup data governance committee structures and formalize
consistent data, expectations for local (e.g., LOB) data governance
Self-service reporting ► Lack of maintained,
► Business insights enterprise wide business
Cross-LOB analysis, glossary 1. Prioritize data domains (master / reference data, transactional data,
Forecasting, ► Full range of authoritative and derived data)
New revenue streams sources of data not identified 2. Identify certified data sources by domain
and defined Data
3. Develop plan for transitioning to certified data sources
► Immature, non-integrated D sourcing and
Risk management application of usage 4. Develop plan to enhance analytics and reporting infrastructure using
master/reference data (e.g., additional authorized sources
client, product, location) 5. Develop plan to adopt enterprise wide Business Intelligence
► Manage client exposure
Share risk profiles, ► Inconsistent, inflexible framework
Monitor client behavior reporting and analytics
► Manage risk capability 1. Incorporate defined and approved data management requirements
Monitor capital adequacy, ► Data management not Process gathering process into the SDLC process
Regulatory compliance, integrated within Software E integration
Reduce operational risk 2. Incorporate data governance approvals (e.g., BRD sign-off) into
Development Life Cycle
existing delivery tollgates
Page 17
Example Business Driver
Perfect Client Experience
Make client interactions more productive for CONSULTANT COMPANY and engaging
Improve client interaction
for the client
Communication channel
► Identify the communication channel most preferable for clients to reduce communication fatigue
► Enhance client self-service experience
Client experience
► Generate 360º view of the client
► Define the type of interactions with the client that deliver most value in the eyes of the client
► Track client product preferences from past experiences
► Resolve issues with quick turnaround by performing faster root cause analysis
Identify products in different lines of business that can be sold to existing

Integrated relationship mgmt.
CONSULTANT COMPANY clients
Single version of truth
► Create a comprehensive view of the client across all LOBs consisting of attributes like risk, exposure, profitability and price sensitivity to
optimize offers
Product effectiveness
► Understand product bundling and value propositions from the client’s point of view (additional revenue potential)
► Determine effectiveness of sold products to tweak future product offerings
► Optimize how funding should be allocated across LOBs to achieve the ideal mix of products for increased profitability
Identify client characteristics to match them to the right product offerings and increase
Segment clients efficiently
profitability
Product mix
► Segment the market intelligently by defining the ideal mix of product offerings for each segment (additional revenue potential)
► Identify the most valuable clients and allocate additional funds for products, marketing and client service for them
► Rebalance client segments regularly to reflect changing client preferences and demographics
Pricing
► Determine optimal pricing for each client segment and target by branding products appropriately (additional revenue potential)
Page 18
Reporting and Analytics
Financial, management and
Create accurate reports with quick turnaround for internal and external consumption
regulatory reporting1
Accuracy and timeliness
► Deliver financial and regulatory reports to government authorities on time using data that is accurate, certified, trusted and authorized; and cut costs by
avoiding rework
► Reduce manual processing while generating reports to reduce the probability of errors; provide consistent and common business terminology so that
business requirements can be translated to technical requirements accurately
Usage
► Enable self-service report creation capabilities by publishing specifications for data providers that are certified, trusted and authorized
► Create business friendly querying and reporting platform to enable self-service for all users
► Provide capabilities able to report out in the form of charts, graphs, scorecards, metrics and dashboards, and create the ability to aggregate, drill down or
drill through these reports
Consistency across reports
► Ensure different reports are consistent with others e.g., regulatory reports like FR Y-9C with CCAR and FFIEC 101, financial reports like 10-K with the GL
Fit for purpose
► Optimize data infrastructure to align with business needs e.g., data for monthly reports doesn’t need to be refreshed daily; focus areas could be accuracy,
timeliness, availability
Requirement changes
► Enable quick adaptability to changing business requirements by adopting more flexible development methodologies
Answer questions about business performance after analyzing data from multiple
Business insights2
sources
Business insight (sample questions)

► Perform analysis of products across LOBs to determine profitability (additional revenue potential)
► Analyze patterns to identify fraud
► Utilize complaints information to effective identify root causes of dissatisfaction
► Perform loss forecasting at a corporate level − balancing interactions between LOBs
► Compare business KPI trends with forecasts and analyze root cause for differences
1Helps reduce compliance risk 2Helps mitigate strategic risk
Page 19
Risk Management
Manage client exposure Consistently measure and manage client exposure across all LOBs in a unified manner
Share3 client profile

► Develop and maintain a consistent view of client credit profile and risk that can be used for all products across different LOBs
► Share3 client risk profiles across different LOBs
Continuous monitoring
► Continuously monitor internal and external data to minimize exposure
► Monitor client profiles to detect potential fraud
► Monitor client payment behavior over time and update risk profile
Manage risk Measure market, credit and liquidity risk across all LOBs
Share3 risk data

► Leveraging common or complementary risk variables across product lines or LOBs (e.g., consumer borrowing in country and out of country) to capture full
risk exposure
Mitigate risk
► Align capital adequacy reserves to legal and tolerated exposures
► Balance potential losses according to regulatory requirements, market conditions, risk tolerance and bank strategies
► Diversify assets in the balance sheet to reduce risk and align risks and reserves
Reduce risk from operations in the bank by automating business processes and thus
Reduce operational risk
reducing errors
Business processes
► Develop ways to measure errors in existing business processes and enable LOBs to proactively mitigate risk
► Assign appropriate SLA’s to business processes
► Automate business processes and develop contingency plans
Data life cycle
► Develop controls over production, transmission and consumption of data across the enterprise
3Share taking into account relevant privacy laws
Page 20
Assess Current State
Page 21
► The objective of this activity is to understand and document the current state of the institution’s data management capabilities. This is
Definition done in order to identify gaps between current state and the desired target state.
► Its helpful to know where a client is - in order to help them determine what they need to do - to get where they want to be.
Business Benefits ► Understanding your client’s drivers and their current state will allow you to deliver a high quality offering and align the target state to
their overall vision.
► Many organizations perform an assessment to baseline the capabilities and some conduct follow-up assessments to highlight progress
and compare against industry averages.
Industry Trends ► An assessment doesn’t need to be done against an industry benchmark, but it helps. Using a benchmark, like CMMI’s Data
Management Maturity Model (DMM) or EDMCs DCAM, allows the client to benchmark themselves against peers and provides a
standard set of questions to improve the thoroughness and quality of the assessment.
► Rob Perkins
► George Suskalo
► Sri Santhanam
Key Contacts ► Michael Krause
► Milena Gacheva
► Christopher Miliffe
► John Gantner
► Several assessment models are highlighted in this chapter and clients may be inclined to use one over another. The same approach can
Chapter Guidance be used regardless of the model chosen.
Page 22
Sample Approach
Key take-away: Holding a workshop based assessment of selected data maturity model components will determine the current
maturity level, establish the guiding principles and set target maturity levels for data management
WP: Assessment Results

Our Assessment methodology *
and Target State
Step 1: Select components to assess based on the business drivers

Current data maturity score results
Step 2: Conduct assessment workshops with key stakeholders to determine

current state maturity depth and perform a skills assessment to answer
questions and assign a maturity score
Business Drivers Step 3: Develop guiding principles and target state maturity based on the
business drivers and the current state, develop guiding principles of how Target state maturity score
firm wide data management will operate. Determine the desired firm with guiding principles
target maturity score for each component assessed.
Step 4: Validate targets with stakeholders Hold final workshops to validate

guiding principles and target maturity scores
* See appendix for more detail on this accelerator
Page 23
Define assessment model
When to perform a DMM assessment
An assessment is beneficial at specific events in an organization’s maturity lifecycle
Initial Data Management BCBS 239

Data Management Strategy Merger or Acquisition Data Management
Strategy Check up Assessment
Regulatory Newly hired

response Chief Data Officer
1 2 3 4 5 6 7 8 9 10 11
CDO Performance Measurement EDM Audit

Strategic Audit
Audit Appraisal
Assessment
Events when performing a DMM assessment provides beneficial insight:
1. Strategic Audit – when the Audit function has identified a need to develop a data will introduce its data into the enterprise information supply chain
management strategy
8. CDO Performance 2 – when the Board of Directors objectively measures CDO performance;
2. MRA/MRIA/Consent Order – when the organization has significant data management comparing results to step 1
issues to be prioritized
9. BCBS 239 – when the Board of Directors or CDO require a third party data management
3. Initial Data Management Strategy – when the organization recognizes the need to develop assessment to support BCBS 239 Principle 1
a data management strategy
10. EDM Audit – when the Audit function plans to conduct an audit of the enterprise data
4. CDO Performance 1 – when the Board of Directors plans to objectively measure management (EDM) function
performance of the Chief Data Officer (CDO); step 1 is establish the baseline
11. Maturity Progress Report – when it is appropriate for the organization to evaluate its data
5. CDO hired – when a Chief Data Officer (CDO) has been hired and is charged with developing management maturity progress
a data management strategy
6. Data Management Strategy check up – when the current data management strategy
progress is evaluated as an input to a revised data management strategy.
7. Merger or Acquisition – understanding data management maturity of an organization that
Page 24
Define assessment model
Assessment model inventory
The primary data standards are developed by these organizations. CONSULTANT COMPANY has built a relationship with CMMI and leverages this assessment model for client current state assessments.
The other assessment models may be used by financial services clients.
Assessment (Present) Appraisal (Emerging) Certification (Future)

• Data management strategy • Data management performance • Data management audit
Projects • Data governance strategy • Data management audit • Data management certification
• Less mature organization starting its data • More mature organization already • Mature organization seeking quantifiable
Audience management journey practicing structured data management certification of maturity
• Key stakeholders start a serious discussion • Identify data management strengths and • Establish organizational maturity rating
about data weaknesses • Identify data management strengths and
• Develop a common language and • Identify risks to achieve specific data weaknesses
understanding about data management management objectives • Identify risks to achieve specific data
• Identify data management strengths and • Evaluate progress toward specific data management objectives
Benefits and
weaknesses management objectives • Evaluate progress toward specific data
Objectives • Establish a baseline to measure growth • Update a roadmap for future state data management objectives
• Envision a future state capability management capabilities • Update a roadmap for future state data
• Develop a roadmap to achieve that future • Establish remediation plans to manage management capabilities
state risks or identified data management issues • Establish remediation plans to manage
risks or identified data management issues
• Workshops and interviews • Detailed self assessment questionnaires • Detailed self assessment questionnaires
Method and • Summary self assessment questionnaire • Inspection of physical evidence and • Inspection of physical evidence and
Evidence • Anecdotal evidence and affirmations functional performance functional performance
• Group consensus • Process performance affirmations • Process performance affirmations
• Pain points, practice gaps, good practices, • Pain points, function and artifact gaps, • Pain points, function and artifact gaps,
findings good practices, findings good practices, findings
Output • Process capability scores • Function and Process capability scores • Function and Process capability scores
• Self-assessment of organization-wide • Evidence based organization-wide process • Evidence based organization-wide process
process capability scores / Maturity Rating capability scores / Maturity Rating capability scores / Maturity Rating
• CDO, LOB Data Leads, Risk, Finance, • CDO, LOB Data Leads, Risk, Finance, • CDO, LOB Data Leads, Risk, Finance,
Compliance, and other Data Leads, Compliance, and other Data Leads, Compliance, and other Data Leads,
Participants Information architect, IT Lead Information architect, IT Lead Information architect, IT Lead
• Stewards, architects, developers, users, • Stewards, architects, developers, users,
project managers project managers
Page 25
Select data management assessment model
CONSULTANT COMPANY preferred

methodology
An industry standard Leading DM practices gear
capability framework of toward data governance,
leading data management data management
practices with an implementation, and
assessment and operations within specific
benchmarking capability architectural and technical
DMM 1.0 (2014) geared toward strategy DM BOK 1st Ed. (2009) contexts
development, governance
design, and operational
maturity
A capability framework of The models provide the big

leading practices with basic picture of analytics and big
self assessment questions data programs, where they
geared toward data need to go, and where you
DCAM 1.1 (2015) management strategy Analytics Maturity Model (2014) should focus attention to
development and operation Big Data Maturity Model (2013) create value
Page 26
Select data management assessment model
CMMI EDM Council DAMA BCBS 239

Category
DMM 1.0 2014 DCAM 1.1 2015 DM BOK 1st Ed. 2009 Principles for RDA 2013
Summary The DMM is an industry The DCAM is a capability Leading data management The BCBS 239 Principles for risk data
standard capability framework of leading practices practices geared toward data aggregation is not a framework but is listed here
framework of leading data with basic self assessment governance, data management due to industry interest. It contains many
management practices with questions geared toward data implementation, and operations principles for data management. The alignment
an assessment and management strategy within specific architectural and below is high level; actual overlap is broader
benchmarking capability development and operation. technical contexts. Note: DAMA and more complex. (est. 2013)
geared toward strategy (est. 2013) is collaborating with CMMI on
development, governance DM BOK 2nd Ed. (est. 2004)
design, and operational
maturity. (est. 2009)
Measurement Objective behavior oriented Artifact oriented measurement Measurement capability is Measurement capability is subjective and open
capability measurement capability for capability; performance, scope proprietary per consultant to interpretation in scope, meaning, and
performance, scope, and and meaning are open to performance
meaning based on 30+ year interpretation. Measurement
history of maturity rating model is in beta test
Depth Pages: ~232 Pages: 56 Pages: 430+ Pages: 28

Categories: 6 Core Components: 8 Functions: 10 Principles: 11 + 3 for supervisors
Process Areas: 25 Capability Objectives: 15 Environmental Elements: 7 Questions 2013: 87
Infrastructure Support: 15 Capabilities: 37 Concepts and Activities: 113 Questions 2014: 35
Measured Statements: 414 Sub capabilities: 115 Artifacts: 80+ Requirements (CONSULTANT COMPANY
Considered Artifacts: 500+ Measured Statements:110 Identified): 108
Support Practitioner training and Training and certification in Practitioner training and N/A
multi-level certification: development certification: CDMP
EDME
Rating mechanism CMMI sanctioned rating Element 22 / Pellustro provides No standardized rating Proprietary rating systems exist, leveraging
mechanism available a commercial rating solution mechanism BCBS 268
DMM and DCAM enable/align with BCBS 235
Page 27
The Data Management Maturity (DMM) Model
The DMM is the industry standard tool for benchmarking data management capability
What is it?
► The DMM is a cross sector peer reviewed
industry standard framework that describes
leading data management practices that
includes a diagnostic tool to identify gaps in a
firm’s practices and a benchmark measurement
that shows how firms compare to their peers
How does it work?

► The model measures two dimensions to
determine actual maturity.
► First is the organization’s level of capability in 25
Process Areas depicted top right.
► Next is the repeatability and sustainability for
each of those process areas based on the level
of practice maturity and scope as depicted
bottom right.
► For example: Data Quality Strategy contains 5
levels of capability, each of which may be
performed at one of the 5 levels of maturity; the
intersection defines organizational maturity, as
shown to the right.
Organizational Maturity Level Process Area Maturity Levels
What are the benefits of assessment? Level Data Management Maturity Definition
► Establish a common understanding and Reactive or partial data management performed
language about data management
5 3 4 5 1 Performed
informally (inconsistent) at the local/business unit level
Capability
► Stimulate conversations about the condition of 4 3 4 4 2 Managed

Processes are defined and documented but performed
at the business unit level on a sporadic basis
data quality and data management 3 2 3 3 3 Processes are defined, managed and orderly with
► Quantify data management strengths and 3 Defined implementation consistently applied at the
weaknesses to be managed and organizational 2 1 2 2 organizational level
Processes are structured, aligned, adopted and
change themes to champion 1 1 1 4 Measured traceable with consistent measurement analytics at the
► Alignment of data management initiatives that 1 2 3 4 5 organizational level
enhance performance toward critical 5 Optimized

Processes are managed on a continuous basis and
business objectives Scope advocated at the executive management level
Page 28 Content excerpted from the Data Management Maturity Model version 1.0, CMMI Institute © 2014
Conduct DMM Assessment
Approach for DMM
The DMM Assessment approach is comprised of three stages including the initial start-up, requiring understanding of the DMM Framework industry standard; application of the framework to client
specific capabilities through workshops and assessment; and lastly, the scorecard to visually represent industry vs. current state vs. future state If requested by the client.
A maturity model provides an objective view of the current state of data practices:
► Used to measure the maturity of the data management discipline within an organization
► Identifies the gaps against a leading practices for the data
► Helps identify where the an organization is relative to it’s peers or competitors
► Used as input to form a roadmap to a target state
It is comprised of three major components and is based upon the CMMI DMM
The DMM is widely adopted by the financial services industry
1 DMM Framework 2 DMM Assessment 3 DMM Scorecard
Page 29
Key Outputs
The objective of the execution steps is to determine and analyze the current maturity level for the organization based on assessment of selected
data management capability model components.
Input Process Output

Assessment kick off materials Data management capability
1 Deliver assessment introduction / education assessment
Step 1.1: Conduct walkthrough of the assessment
components, how to use the scoring template
Step 1.2: Educate participants on how to apply the
business drivers and scope to the scoring template
2 Execute assessment questionnaires
Refined assessment questionnaire Step 2.1: Distribute assessment questionnaires to
participants and request self-scoring In-flight initiatives aligned to data
management capabilities
3 Execute assessment workshops (review questionnaires)
Step 3.1: In workshops, conduct a walkthrough of each
assessment area and discuss the current score, evidence
that supports it and a target score
Assessment report template Step 3.2: Identify with the core team and stakeholders
common themes and pain-points emerging to develop
initial prioritization areas
Preliminary current state assessment for

4 Identify practice strengths and gaps and other current each process area
state findings*
Step 4.1: Identify areas where existing practices can be
adopted and those where capabilities are lagging
peers/expectations
In-flight initiatives
5 Analyze results and prepare assessment report
Step 5.1: Collect, compile and consolidate assessment
scores into final scoring template to formulate preliminary
results
Step 5.2: Produce preliminary results for reviewing and
validation with core team and key stakeholders
Page 30
* The scope may include a current state evaluation of information architecture, data usage, master data, analytics,
data integration or other specific implementations over and above governance and management practices.
Supporting EDM Programs
The DMM provides guidance defining program components
► The DMM can be used as a check list to make sure a data management program is complete
► The DMM can be used to help establish and prioritize a data management or data governance roadmap
► The DMM can be used as a tool to measure data management capability development and organizational maturity
Industry Standard Firm Specific

Maturity model Implementation
DMM Model
Data Management
Program
Guidance Business
Trustworthy, Reliable and Fit For Purpose

Glossary
Authoritative
Sources
Quality Data
Control
Data Lineage
DMM Assessment
Data Quality
Rules
Measure
Platform
Architecture
Internal Audit
measures compliance to the DG
Program.
Page 31
Continued assessment to track progress
Data Management Strategy Data Management Strategy
Supporting Process Supporting Process

Data Data
Governance Governance
Data Quality Data Quality
Platform and Platform and

Architecture Architecture
Data Operation Data Operation
Data Management Strategy

Data Management Strategy
Supporting Process
Supporting Process Data
Data
Governance
Governance
Data Quality
Data Quality
Platform and
Platform and Architecture
Architecture
Data Operation Data Operation
Page 32
Develop Roadmap
Page 33
Develop Roadmap
► A roadmap is a structured plan with multiple layers and milestones that defines the path forward on an initiative, project, or program for
moving the organization’s activities from a current state to an agreed-upon future state.
Definition ► A roadmap prioritizes and sequences a set of required initiatives (projects) into a larger program.
► A roadmap clearly states the objectivism, activities, timelines and success criteria for achieving the target state in a way that can be
easily tracked against. This is beneficial for communicating progress upward or enforcing responsibility downward.
Business Benefits ► The communication plan typically accompanies a roadmap and provides a step by step guide for achieving acceptance by the
organization and adoption of the program.
► A roadmap has become standard practice for data management activities and is the next logical step after receiving maturity
assessment results. This provides the ‘next steps’ that make a program actionable.
Industry Trends ► Communication early and often of the program’s status will provide transparency and drive adoption through the organization.
Standardized progress monitoring will keep involved parties accountable and drive the project forward.
► Mark Carson
► Lisa Cook
► Ryan Duffy
► Once an organization performs an assessment and understands the current state and target state, the capabilities to achieve the target
Chapter Guidance state are mapped out and assigned. This chapter provides guidance and an example of a 30-60-90 day plan, but additional detailed
roadmaps that have been developed for other clients can be found in the KCONSULTANT COMPANY.
Page 34
Develop roadmap to target state
Sample Approach
A client roadmap will assist in strategically structuring the roll out of enterprise data management (e.g., critical data, data quality, data sourcing, metadata, etc.) that align with short term and long term
objectives. In some cases, an associated communication strategy will be developed to socialize the plan to support the business strategy of the bank to stakeholders.
Duration: 2 - 5 weeks
Resources: Assessment & stakeholder team of 3-5 resources
Current data maturity score results
Step 1: Prioritize capability gaps based on logical sequencing, risk management and business High-level roadmap and project plan
priorities, and after discussing with project leadership for subsequent phases of the project
Step 2: Develop high level roadmap that includes assigning roles for each domain, establishing the
policies and standards, establishing the governance committees, and operationalizing the data
quality. data sourcing and metadata capabilities.
Target state maturity score
with guiding principles Executive level presentation
Step 3: Develop a communication plan and create the stakeholder socialization package that
describes the approach and supporting operating models aligned to the foundational
capabilities, and the high-level roadmap
Step 4: Socialize roadmap with stakeholders for alignment of efforts and messaging
Page 35
Assess current state and define target state
roadmap
► The objective of this activity is to establish a baseline of current state and identify dimensions that may
require change. The change required in each of the current state assessments vary but often include a
Current State desire to improve business performance, gain competitive advantage, or meet regulatory requirements
► A defined criteria and rating scale is used to evaluate a client's current state based on various
dimensions/assessment topics. This activity typically takes 3-4 weeks, but may vary.
► The objective of this activity is to help the client understand the options for their future state and
evaluate and select the most suitable future state based on the client’s vision and strategic objectives.
► This activity typically takes 1-3 weeks but could take longer depending number of future state options
Target State and whether recommended future state will be provide based on the scope of the project
► Managing the scope and considering the future state options that are in alignment with client
expectations are two key things that are important in this stage.
► A roadmap is a structured plan with multiple layers and milestones that defines the path forward on an
initiative, project, or program for moving the organization’s activities from a current state to an agreed-
upon future state.
► Depending on the duration of this stage, the roadmap could be a light version or detailed version
Roadmap roadmap.
► For short term assessment projects, a lighter version of the roadmap template is more suitable. For
medium to long term assessment projects where the client could consider CONSULTANT COMPANY for
future state implementation, a detailed version of the roadmap template should be used.
Page 36
Key Outputs
A key component of successful roadmap rollout is communication and transparency. Socialization and customization of messaging is imperative. Depending on the level of complexity and integration,
clients may request corresponding resource and interaction models.
(A) Identify initiatives that will achieve (B) Prioritize and sequence projects (C) Recommend monitoring
target state capabilities into a remediation plan with steps progress against functional
• Existing projects needed to achieve business benefits principles by tracking project status
• New projects
Sample outputs
Page 37
Example roadmap
A key component of successful roadmap rollout is communication and transparency. Socialization and customization of messaging is imperative. Depending on the level of complexity and integration,
clients may request corresponding resource and interaction models.
Page 38
Roadmap & Communication Plan
Example 30-60-90 day plan
Due to regulatory mandates and internal goals, CONSULTANT COMPANY should begin to implement the EDO and robust Data Management practices across
domains and the enterprise as soon as possible. To initiate this process, CONSULTANT COMPANY must execute on key activities in 30-, 60- and 90-day
timeframes and carry out a robust Communication Plan to accomplish the organization's Data Management goals. The information below describes how to
interpret the 30-60-90 Day Plan and Communication Plan.
Overview
► The 30-60-90 Day Plan and Communication Plan should be used as a “checklist”/guidelines and key activities to be carried out and the communication strategy
required to enable successful execution of EDO goals and objectives, respectively.
► As both plans will involve constant coordination with executives and domain stakeholders, the plans will serve as high-level frameworks that will need to be
tailored specifically to domains depending on the stakeholders, data involved, etc.
► The 30-60-90 Day Plan includes iterative activities based on identification of domain roles and responsibilities. These activities are noted on subsequent slides.
► Example: as stakeholders/groups continue to be identified, domain roles and responsibilities will continue to be assigned and the EDO will continue to
host meetings and execute the Communication Plan.
► The 30-60-90 Day Plan will be updated to include the next steps toward implementing the high-level roadmap until roles and responsibilities are assigned for all
domains.
► Based on the current high-level roadmap, domains will begin reporting on EDO compliance metrics to track progress on alignment with the EDO strategy
beginning in Q3 2014.
► Regulator checkpoints are currently scheduled quarterly.
30-60-90 Day Plan − Initial Phases
► 30-day plan − activities mainly include identification of and communication with executives, as well as, development of policies, standards, processes and
compliance metrics. EDO communication will be ongoing.
► 60-day plan − activities mainly include EDO-domain coordination and planning, as well as, ongoing communication and continued development of
policies, standards, processes and compliance metrics.
► 90-day plan − activities mainly include ongoing communication and planning, as well as, the beginning of execution of initiatives and development and
implementation of process and standards.
Communication Plan
► The Communication Plan will be leveraged throughout the 30-, 60- and 90-day timeframes and implementation of the high-level roadmap to communicate roles
and responsibilities, goals and objectives, expectations, progress, changes and more to key stakeholders.
► The Communication Plan includes a sequence of communications types (e.g., email, executive meetings) in a logical order by audience, with associated
frequencies, to kick-start the 30-60-90 Day Plan and high-level roadmap. The Communication Plan will need to be tailored to different domains while supporting
materials will need to be tailored to the appropriate audience (e.g., executives, Data Stewards).
Page 39
Example 30 day plan
Identify & Communicate
# Key Activities Description Enablers
Continue identifying Continue the process of identifying and creating a list of key stakeholders/groups across the ► List of domains
1*
stakeholders/ impacted groups domains/enterprise that will help execute EDO goals and objectives. ► LOB organizational structures
Continue Utilizing the inventory of key executives/groups, continue to assign stakeholders to important ► List of stakeholders/groups
2* determining/assigning roles & roles and responsibilities (e.g., Business Process Owner, Data Steward, Data Custodian) ► List of domain roles &
responsibilities considering current roles and alignment. responsibilities
Finalize DQA, change & issue Seek approval of the Policy team to finalize the Data Quality & Assurance, Change
3 ► Policy team input/approval
management policies Management, Issue Management, EDWE policies and standards.
Begin development of Begin development of additional EDO policies and standards documents, including Master
► Policies and standards (for
4 additional policies & standards Data, Metadata and SLAs, consistent with existing policies and standards that apply to the
consistency)
(master data, metadata, SLA) EDO’s goals and objectives.
Develop Communication Plan Develop strategy to approach impacted executives/groups, create timeline of important ► List of stakeholders/groups
5* strategy and schedule meetings/communications and schedule meetings with executives/stakeholders (see ► List of domain roles &
meetings Communication Plan guidelines/milestones). responsibilities
Develop materials for Communication Plan meetings with executives, Business Process
Develop Communication Plan ► Communication Plan
6* Owners, Data Stewards, etc. with appropriate content explaining the goals, responsibilities and
materials ► Communication calendar
expectations, tailored appropriately to the target audience.
Execute Communication Plan Conduct meetings with executives/stakeholders across the enterprise to understand goals and ► Communication Plan
7 with Executives (will continue objectives, roles and responsibilities, timeline and expectations (see Communication Plan ► Communication calendar
into other periods) guidelines/milestones). ► Communication materials
Schedule/develop materials for Schedule meetings with and develop materials for updates with regulators and executives with ► List of stakeholders/groups
8 regulatory/executive updates (if the objectives of communicating progress, the final design and capabilities of the EDO and its with assigned responsibilities
applicable) scope, relevant policies and standards, and more. ► Policies and standards
Provide regulators and CONSULTANT COMPANY executives with updates on the initial design ► Regulator/executive meeting
Meet with
and capabilities of the EDO, as well as, its scope, progress to date and relevant policies and schedule
9 regulators/executives (if
standards. Adjust/update accordingly, per regulatory and internal feedback, and communicate ► Regulatory/executive update
applicable)
outcomes across the enterprise, as needed. materials
With initial identification and communication activities completed, conduct comprehensive
► Minutes/summaries from
Update EDO leadership/ update meetings with the CDO, Enterprise Risk Manager and CRO (if necessary) to
10 regulator/executive meetings
executives communicate progress, any issues, updated estimates (e.g., time, budget, resources), and
► Progress/estimate updates
more.
* Iterative activities based on identification of domain roles and responsibilities
Page 40
Example 60 day plan
Coordinate & Plan
Execute Communication Continue to conduct meetings with executives/stakeholders across the enterprise to understand goals and ► Communication Plan
1 Plan with executives objectives, roles and responsibilities, timeline and expectations (see Communication Plan ► Communication calendar
(continued throughout) guidelines/milestones). ► Communication materials
Business Process Owners begin to identify team members related to their domain data. Domains begin to ► Communication Plan/other
Begin to develop
digest information conveyed in the Communication Plan and start the process of developing EDO materials
2* implementation/ execution
implementation/execution plans that align with the goals, objectives and timelines of the EDO, including ► Policies and standards
plans (domains)
roles and responsibilities, which will be carried out over the next several quarters. ► Domain roles/resp.
Create comprehensive calendar with executive checkpoints with the objectives of coordinating efforts,
Schedule checkpoints with ► List of stakeholders/groups
3* monitoring progress, managing change and maintaining an open dialogue. Determine which EDO resources
stakeholders/groups ► EDO program plan
will cover which meetings, as well as, the type of documentation needed by the EDO and stakeholders.
Prepare materials for Prepare materials and relevant documentation appropriate for the meetings, including updates on other ► Executive update schedule
4*
checkpoints efforts underway (e.g., in-flight initiatives, progress by other domains). ► Coverage by EDO
Conduct executive update meetings on the initiative as a whole and solicit information on progress of the
Conduct checkpoints with relevant domains. Review and provide initial feedback on implementation plans presented by stakeholders/ ► Executive update schedule
5
executives groups and finalize plans for coordination of work effort. Address issues and remediation activities, as ► Executive update materials
needed.
Review materials, progress updates, and implementation plans provided by executives and provide
Communicate follow ► Executive update materials/
6* feedback/solicit action, as necessary. As they are resolved, close out any EDO-responsible action items and
ups/execute takeaways minutes/action items
communicate the results of the meetings to EDO and Risk leadership.
Incorporate relevant Based on the executive update meetings, incorporate feedback/updates into overall program plan to track ► Executive progress updates
7*
information into plans progress/information. ► Program plan
Internally finalize additional
Finalize Master Data, Metadata and SLA policies and standards and seek approval of the documents from ► Policies and standards (for
8 policies & standards (master
Policy team. consistency)
data, metadata, SLA)
Begin to promulgate approved policies and standards to relevant stakeholders. ► List of stakeholders/groups
Begin to promulgate policies
9* ** This should be done before execution of the Communication Plan such that stakeholders have ample time with assigned responsibilities
& standards**
to read and understand the policies and formulate strategies to comply. ► Policies and standards
Begin DQA, change & issue
Begin to develop the standards and processes for Data Quality & Assurance, change management and ► List of KDEs/EDAs/CDSs
10 management process
issue management, as appropriate. ► Policies and standards
development (appl. domains)
► Minutes/summaries from
Update EDO leadership/ Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if necessary)
11 executive meetings
executives to communicate progress, any issues, updated estimates (e.g., time, budget, resources), and more.
► Progress/estimate updates
Page 41
Example 90 day plan
Begin to Execute/Implement
Prepare materials and relevant documentation appropriate for the meetings, including updates on ► Executive update schedule
1* Prepare materials for checkpoints
other efforts underway (e.g., in-flight initiatives, progress by other domains). ► Coverage by EDO
Continue checkpoints with Continue to facilitate adoption of the EDO strategy by conducting meetings with stakeholders from ► List of stakeholders/groups
2*
stakeholders/groups LOBs/domains. ► EDO program plan
Business Process Owners continue to identify team members related to the domain data. Domains ► Communication Plan/other
Continue to develop implementation/ continue to develop implementation/execution plans that align with the goals, objectives and EDO materials
3*
execution plans (domains) timelines of the EDO, including roles and responsibilities, which will be carried out over the next ► Policies and standards
several quarters. ► Domain roles/resp.
Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if ► Summaries from exec
4 Update EDO leadership/ executives necessary) to communicate progress, any issues, updated estimates (e.g., time, budget, resources), meetings
and more. ► Progress/estimate updates
Disseminate/integrate lessons Based on progress to date, aggregate and communicate any lessons learned to applicable
5 ► Program progress updates
learned stakeholders to ensure consistency of implementation and avoid repeat issues.
Begin identifying KDEs, EDAs and For domains that have adopted policies and standards, identify KDEs, tier 2 and 3 data elements, ► List of data elements
CDSs; defining business rules EDAs and CDSs critical to each domain (e.g., master data, metadata) collaboratively between the ► List of systems/data
6* requirements and thresholds; and EDO and stakeholders/domains. Develop rules to meet the needs of the business and ensure DQ; sources
registering data attributes (domains define requirements for data (e.g., master data and metadata requirements). Define thresholds for ► List of KDEs/EDAs/CDSs
that have adopted policies) DQ. Register the various attributes and characteristics of data elements. ► Policies and standards
Continue DQA, change & issue

Continue to develop the standards and processes for Data Quality & Assurance, change ► List of KDEs/EDAs/CDSs
7 management process development
management and issue management, as appropriate. ► Policies and standards
(domains that have adopted policies)
Begin data sourcing and provisioning

Begin to develop the standards and processes for EDWE, master data, metadata, and SLAs, as ► List of KDEs/EDAs/CDSs
8 standard and process development
appropriate. ► Policies and standards
(domains) that have adopted policies
Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if
► Progress by domains/
9 Update EDO leadership/ executives necessary) to communicate progress, any issues, updated estimates (e.g., time, budget, resources),
estimate updates
and more.
Update and adjust the 30-69-90 Day Plan monthly and create a new 90-day plan based on progress to date. As 30-, 60- and 90-day plans are executed,
continue executing/implementing the roadmap with a high-level of coordination between the EDO and domains/stakeholders. Refer to the roadmap for more
information of future activities.
* Iterative activities based on identification of domain roles and responsibilities with target completion before Q4 2014.
Page 42
Example Communication Plan
Below is a high-level framework that can be leveraged by the EDO to create more detailed/domain-specific Communication Plans.
Communicati Frequency of
# Audience Description Communication Items / Agenda
on Method Communication
Schedule and conduct meetings with the ► EDO objectives

1 Executives Meetings Enterprise Risk Manager, CRO and other ► Prioritization As needed
executives (as appropriate) ► Buy-in
► Goals and objectives of the EDO, as well as, the catalyst(s) for its creation (e.g., CCAR, data management requirements, EDMC
assessment)
Send mass-communication to all ► EDO leadership, alignment and where it fits within the organization and contacts, as well as, details on prior executive meetings/buy-
All
2 Email stakeholders/groups (request that they forward in and priorities (see above) Once
stakeholders
to members of their teams, as necessary)
► Overall timeline for implementation across the enterprise
► Next steps, including the timeframe in which the EDO will schedule initial meetings with individual stakeholders/groups
All Provide all stakeholders/groups with the links to

3 Email ► Policies / standards Once
stakeholders relevant policy and standards documents
► EDO goals, objectives and timelines, as well as, business drivers and summary of prior executive meetings/buy-in and priorities
Business Schedule and conduct meeting with Business ► Overview of the data domain (e.g., business processes and requirements, in-flight initiatives, roles and responsibilities) and business
Process Meetings (by Process Owners by domain (include multiple process/data management pain points Bi-weekly to
4
Owners domain) Business Process Owners in meetings, when monthly
(BPOs) possible) ► Initial thoughts on implementation/steps to be taken to comply with policies (requires future communication/meetings)
► Next steps (e.g., communication with other stakeholders, communication with Business Process Owners going forward)
► EDO goals, objectives and timelines

► Summary of discussion with executives and Business Process Owner and relevant information (e.g., responsibilities, data
Data Schedule and conduct meeting with Data management areas of focus)
Stewards / Meetings (by Stewards and Data Custodians by domain Bi-weekly to
5 ► Further discussion of data domain (e.g., processes, in-flight initiatives, roles and responsibilities) and data management pain points
Data domain) (include multiple stakeholders in meetings, when monthly
with respect to overall data quality
Custodians possible)
► Implementation plans and path to compliance with policies (e.g., ETL, SDLC, metrics)
► Next steps (e.g., communication with Data Steward(s) and Data Custodian(s) going forward)
► EDO goals, objectives and timelines
Data ► Summary of discussion with executive and Business Process Owner(s), Data Steward(s) and Data Custodian(s), relevant information
Architects/ Schedule and conduct meeting with Data (e.g., responsibilities, data management areas of focus)
Source Meetings (by Architects and Source System Application Bi-weekly to
6 ► Further discussion of data domain specific to architecture and source systems involved, as well as, data design/usage/sourcing and
System domain) Owners by domain (include multiple monthly
existing data management pain points
Application stakeholders in meetings, when possible)
Owners ► Implementation plans and path to compliance with policies (e.g., system/infrastructure build out, SLAs)
► Next steps (e.g., communication with Data Architect(s) and Source System Application Owner(s) going forward)
After conducting meetings with stakeholders and ► Meeting minutes/notes and action items
All
7 Email groups, send summary communications with the ► Overview of expectations and next steps As needed
stakeholders
following information ► EDO points of contact
Schedule and conduct checkpoints with
All stakeholders/groups throughout the 30-60-90 ► Encourage open dialogue and conduct ad hoc meetings to discuss progress and resolve any issues arising during planning and
8 Meetings As needed
stakeholders day plans and through full implementation, as implementation.
agreed to in previous meetings
Schedule and conduct updates with regulators to ► Approach, progress to date (e.g., execution of communication plan and notable items arising from those discussions)
9 Regulators Meetings Quarterly
provide information on the ► Communicate assessment of timelines for compliance with regulatory requirements and resolution of outstanding MRA/MRIAs.
Page 43
Define Scope of Key Data
Page 44
► Creating a standardized data taxonomy via data domains organizes the data by shared characteristics and context that facilitates
management governance.
Definition ► Executing this step will help the clients understand the existing data that lives across the enterprise and logical way of organizing the
data to drive accountability and governance.
► Defining the key data provides a more focused scope of data priorities and business drivers.
► Establishing data domains creates an accountability structure over the key data and clarity on what business truly ‘owns’ the data being
Business Benefits used across the enterprise.
► Domains can be used as a top level structure to achieve a ‘common taxonomy’ as described in BCBS 239
► The domain concept has been adopted by a large number of financial services institutions. Many institutions begin by aligning domains
to current organization models. However the benefits of domains are realized when they cross LOB and group boundaries. So that
Industry Trends similar data is grouped and managed together regardless of which LOB it is in. This can better enable efficacy of data sourcing and
authorized data sources.
► Mark Carson
► Lisa Cook
► Ryan Duffy
► An organization contains a vast array of data, not all of which must be governed in the highest capacity. This chapter allows businesses
Chapter Guidance to establish data domains and identify the key data to their business which will be governed under the operating model.
► The data domains playbook can be found here: LINK
Page 45
Define Scope of Key Data: Data Domains
Key take-away: Conducting multiple workshops with leadership to define and agree upon an initial set of prioritized data domains
and assign ownership for each domain
WP02: Data Domains

Our Domain Approach*
Executive Presentation
Step 1: Review Industry domain models and current state systems and
data flows usage patterns to propose a draft set of domains for Domains
Global banking and financial services company
Step 2: Conduct a series of domain workshops to socialize the concept,

Industry Domain models* share the draft and validate and revise Global banking and financial
services company’s domain structure with key data providers and
consumers
Step 3: Finalize domains and approve domain inventory. Perform

analysis of provider and consumer domains and create a domain Data Domain Ownership
interaction matrix matrix
Step 4: Assign domain ownership Establish roles and responsibilities for

domain ownership as well as the roles of data producers and data
consumers
* See appendix for more detail on this accelerator
Page 46
Define Scope of Key Data: Data Domains
The operational model uses data domains to classify data into a common subject area based on shared characteristics independent of business
usage (e.g. Industry, Compliance etc.) A data domain taxonomy is used to assign accountability for data and business processes through LOBs.
► A data domain groups data elements into a common subject area

based on shared characteristics. This facilitates common
What is a data domain?
understanding and usage of data elements across LOB’s, business
processes and systems
► Today, accountability for data is inconsistently applied at LOB’s,

business processes and systems
Why do we need data
domains?
► Since multiple LOB’s share the same data (e.g. client reference data),
accountability for shared data is unclear and/or fragmented
► Critical roles and responsibilities will be assigned at the data domain

level
How do we manage
data domains?
► These roles will have oversight of data across LOB’s, business
processes and systems
Page 47
Guiding Principles for Data Domains
► The organization will have a common and consistently applied data domain taxonomy
► A data element will be owned, defined, and maintained in only one data domain. It can be used by
multiple business processes and stored in multiple systems
► Each data domain will have a Domain Owner assigned who will be empowered and accountable
to make governance decisions with input from impacted business processes and stakeholders
► Domain Owners govern the definition and rules for the data consumed or provided by a business
process and do not govern the business process itself
Page 48
Data Domains
Example Domains 1
Reference and Master Data Domains Transactional Data Domains Risk. Finance and Treasury Data Domains
Data Types Definition Data Types Definition Data Types Definition
1 Linking & • Data that identifies or is used to categorize 8 Deposits & • The individual events associated with the
General Ledger • The combination of reference, master and
Classifications other types of data, along with the set of Payments movement of currency (cash assets) into 16 Data transactional data summarizing all of a
possible values for a given attribute and between Accounts
company's financial transactions, through
• Includes calendar, currency, geographic
Invoices & • The individual events associated with the offsetting debit and credit accounts.
locations, industry, identifiers, roles, 9
relationships Billing list of the services rendered, with an
account of all costs (such as an itemized
bill.) Customer • The calculated Profit and Loss data (PnL)
2 Party & Legal • An entity that is registered, certified & approved 17 Profitability Data such as the revenues earned and the costs
Entities by a government authority 10 Trading • The individual events associated with the associated with a customer over time
• Any participant that may have contact with the buying or selling of assets and securities.
Bank or that is of interest to the Bank and about
which the Bank wishes to maintain information Liquidity Data • The subset of assets and securities that
11 Clearing & 18 can be easily traded without affecting
(e.g. legal ownership / hierarchy, financials) • The lifecycle of an instruction from
Settlement customers to counterparties or other legal the price of that asset or security
entities for trade order events
3 Customers & • A state that a party or legal entity can be
Counterparties transitioned into when that entity is a potential Regulatory • Data that are determined as critical to
12 Borrowing & • The transactional events within or between 19 Reporting Data meet regulatory reporting requirements
or existing recipient of services, products or
Lending party’s & legal entities in which assets &
transactions
securities are exchanged under an
agreement that specifies the terms and • Calculation of the Bank’s financial
Assets & Securities
• Descriptive information about any form of conditions of repayment Capital Data performance (e.g. Income Statements,
4 20
ownership (asset) that can be easily traded in Cash Flow Statements & Balance
markets, such as stocks, bonds, loans, deals, Sheets).
and indices. 13 Financial • A group of activities customers or
Operational Risk • Data and criteria used to calculate losses
Planning counterparties need or to accomplish a 21 Data arising from an organizations internal
Prices & Rates • The value or cost and quantity at which assets financial goal
5 activities (e.g. people, process &
Include aspects of budgetary activities
& securities are traded or converted (e.g. systems)
exchange price, currency rate conversion,
Market Risk Data • Data and criteria used to calculate the
interest or inflationary rates
14 Fees & • A fee charged for facilitating a transaction, 22 probability of losses in positions arising
Commissions such as the buying or selling of assets, from movements in market prices
Products & • An item to satisfy the want or need of a securities, products or services offered to a
6
Accounts customer and has an economic utility and are customer or a counterparty to the Bank
Credit Risk Data • The amount of principle or financial
typically a grouping of various assets & 23 value that is at risk should a party fail
securities to meet their obligations
15 Business Events • The various types of events that can take
7 Ratings • An evaluation of the financial status of a party place across an organization including
or an asset to indicate the possibility of financial transactions, customer management Allowance for Loan • The financial value associated with the
default or credit risk 24 Losses Data estimated credit losses within a bank’s
and marketing events and business process
• (e.g. Moody’s, S&P, Fitch, Experian, Equifax, activities portfolio of loans and leases.
Transunion and internal)
Page 49
Data Domains
Example Domains 2
Reference & Master Domains Functional Domains Transactional Domains
1 External Parties
Data and criteria used to identify entities that lay outside of the
12 Credit Risk
The risk of loss from obligor or counterparty default. Includes
22 Product Transactions
Data elements and events supporting trade order and
ownership structure of the firm (external legal entities, Wholesale and Consumer credit risk transaction management, clearing and settlement, asset
prospects, clients, issuers, exchanges) transfers, cash movement, borrowing and lending transactions
Internal Parties 13 Market Risk 23 Customer & Client Servicing
2 Data and criteria used to identify entities that fall inside the
The potential for adverse changes in the value of the Firm’s assets
Data associated with client/customer transactions used in
and liabilities resulting from changes in market variables such as
ownership structure of the firm (internal legal entities, servicing them including fraud, default management, and
interest rates, foreign exchange rates, equity prices, commodity
subsidiaries, joint ventures, holding companies) originations transactions
prices, implied volatilities or credit spreads
3 Workforce 14 Operational Risk 24 Sales & Marketing
Includes employees and contractors and the core attributes that Relationship management activity, product management
The risk of losses arising from an organization’s internal activities
uniquely describes them strategy, sales activity including marketing, campaign
(e.g. people, process & systems)
management, commissions, fees and prospect management
4 Accounts
Accounts of JPMorgan customers in which holdings and
15 Principal Risk
The risk that the investment will decline in value below the initial
transactions get recorded. Contains account identifiers, legal
amount invested .
agreements, descriptors, key account attributes, etc.
16 Country Risk
5 Product & Product Classes The risk that a sovereign event or action alters the value or terms
Data used to categorize products or services (inclusive of asset
of contractual obligations of obligors, counterparties and issuers,
and asset classifications, securities and other financial
or adversely impacts markets related to a country
instruments)
17 Liquidity Risk
6 Instrument & Instrument Classes Data and criteria used to manage and categorize the
Data defining the means by which a tradable asset or
marketability of investment
negotiable item such as a security, commodity, derivative or
index, or any item that underlies a derivative is transferred 18 Capital & Liquidity
Data associated with an organization’s monetary assets (e.g.
7 Prices & Rates balance sheet) and a type of asset that can be traded in market
Data associated with values or costs at which assets &
without affecting the price of the asset. Assists with improving
securities are traded or converted (exchange rates, interest
the banking sector’s ability to absorb losses arising from financial
rates, equity prices, etc.)
and economic stress (CCAR stress testing, leverage and risk-based
8 Geography requirements); ensuring banks hold sufficient liquid assets to
Data that describes the geographic location or related survive acute liquidity stress; and preventing overreliance on
attributes of a party, transaction, collateral, etc., including short-term wholesale funding
addresses, geo codes, currencies, etc.
19 GL and External Financial Regulatory Reporting
9 Industry Data associated with financial transaction of the organization for
Data that describes the nature of a Customer or Other Party, or its entire life cycle, including SEC disclosures & MIS Reporting
risk exposure and data used to define requirements around individual regional
regulatory reports
10 Business Unit
Data that is used to represent a logical segment of a company 20 Compliance
representing a specific business function, separate from a legal Data used to asses and monitor anti-money laundering and non-
entity anti-money laundering activities including; transaction monitoring,
risk assessment, KYC, CDD/EDD, CLS (client list screening), look-
Financial Account / UCOA
11 The smallest unit at which financial transactions are classified
backs
within general ledger or sub-ledger (e.g. asset, liability, revenue, 21 Profitability & Cross-Sell
expense, etc.). This data also includes the banking book, trading Data and criteria used to support measurement of customer
Page 50
book and their respective hierarchies profitability, cross-sell and referrals
Data Domains
Operationalizing with Roles
Key Takeaway: Data domains become operationalized once aligned to business processes and roles are assigned.
► Business processes (e.g. Credit Risk, Regulatory Reporting, KYC, Sales and Marketing) must be mapped to data
domains to understand specific data usage patterns. Doing so:
► Identifies priority business processes for each data domain
► Assigns accountability for data requirements
► Provides business context for data
► Drives root cause analysis of Data Quality issues
► This mapping establishes the basis of accountabilities across data domains, business processes at each
intersection requires roles and responsibilities*
Role A: have broad understanding of data across Role B: have a detailed understanding of how the business
all business processes process functions and operates
Denotes the domain which the data is read (consumed) from Business Processes
Ownership
Regulatory Tracking
Know Your Credit Client
Data Domain Business Capital Regulatory Market Credit Risk System (to
Customer Portfolio Onboarding/ …
Process  Management Reporting Risk Reporting be replaced
(KYC)
Office (RCMO)
Group
with GEMS
Origination
Role C: have a
1Q 2015)
detailed
Wholesale Credit Risk x x x
Consumer Credit Risk x x x
understanding of
Consumer Market Risk x x processes and
Data Capital & Liquidity x associated data
Domains GL and External Financial Regulatory Reporting x x x X x
Compliance x x requirements
…
Reference & External Parties x x x x x x x x
Master Data Industry x x x x x x x x
Domains …
Page 51
Define and Establish Governance Model
Page 52
Define and Establish Governance Model
► The objective of creating an enforceable Data Governance operating model is to provide a clear structure of the roles and
Definition responsibilities required to have accountability over critical data.
► The operating model has roles, routines, metrics and monitoring.
► Attaching names to data governance makes the operating model ‘real’ and enforceable.
Business Benefits ► Establishing routines and effective governance to become part of the BAU process of data management within the organization.
► Most organizations have established a CDO (Chief Data Officer) but have not fully expanded their governance roles down to the lowest
possible levels.
Industry Trends ► The centralized and federated operating models of data governance has been most widely adopted, however, multiple methods are
available for use.
► Mark Carson
► Lisa Cook
► Ryan Duffy
► Until this point, data governance was seen as an initiative at the enterprise level without names or faces. Now roles and
Chapter Guidance accountabilities are aligned to carry out the key capabilities defined earlier in the roadmap and data domains.
► This chapter provides clear examples of roles and escalation structures that a business can use to set up their governance organization.
Page 53
Stand-up Governance and Oversight
► An often times overlooked key business function is the quality and consistency of data. Governance is
Governance the act of defining data ownership, policies, standards and procedures to effectively govern, control,
assess, monitor, and independently test to ensure data is accurate, complete, and timely.
► The oversight functionality exists to secure accountability and functionality. Fundamental principles
Oversight include ensuring standards exist and are followed, committees and groups are fit for purpose, and the
bank is functioning as intended.
Page 54
Define CDO office governance model
Review the descriptions, advantages, and disadvantages of each of the types of organization models with your client to identify which will meet their needs. Based on the need and the existing
organization structure of the firm, any of the following Data Governance organizations can be established.
Org model type Description Advantages Disadvantages
Committee A committee based approach is mush easier • Relatively flat organization • Consensus discussions tend to take
to establish, however sometimes • Informal governance bodies longer than hierarchical edicts
decisions/consensus may take longer to • Relatively quick to establish and • Many participants comprise governance
obtain due to lack of hierarchical edicts. implement bodies
• May be quick to loose organizational
impact
• May be difficult to sustain over time
Hierarchical A formal hierarchical approach to data • Formal Data Governance executive • Large organizational impact
governance, decisions are made at the top position • New roles may require Human
and then trickled down for execution. This • Council reports directly to executives Resources approval
data governance organizational structure can • Formal separation of business and
be easily aligned to the existing reporting technical architectural roles
lines.
Hybrid A hybrid approach provides the “tone at the • Hierarchical structure for establishing • Data Executive position may need to be
top” and wider range of committee members appropriate direction and ‘tone at the top’ at a higher level in the organization
provide subject matter advise. • Formal Data Executive role serving as a • Group dynamics may require
single point of contact and accountability prioritization of conflicting business
• Groups with broad membership for requirements and specifications
facilitating collaboration and consensus
building
• Potentially an easier model to implement
initially and sustain over time
Page 55
The diagram below depicts a generic, high level data governance model. The CONSULTANT COMPANY team will use the current state assessment and conduct review meetings to build a tailored
governance model for the organization.
Target State Governance Model
1st Line: Local groups / LOBs / 2nd Line: Oversight Functions 3rd Line: Audit
Domains
Business Process Owner (BPO) Audit

Executive Committees (May need additional data
Data Custodian (DC) management skills)
Data Steward (DS) Data Governance Committees

Chief data officer
Data Architect (DA) Controls data officer
Program executive sponsors (including BCBS)
Source System App. Owner
(SSAO)
Data Governance and QA1
Data User
Central Enablement Activities1

Data Strategy & Architecture
Data Management
Centre of excellence, Shared services
Data Advisory
Data Administration
EDO shared
Legend: EDO governance Domain specific Escalation/oversight path
services/enable External to EDO
roles
ment
1Refer to appendix 1 for further information on EDO functions

Page 56
Domains1 are a way to logically organize data around core business concepts. This enables establishing accountability and ownership of data, its quality, integrity, and usage. The domain model has been
established at two G-SIBs and 1 D-SIB. Domains allow for governance models to establish accountability in a realistic and actionable forum that typically exists informally.
EDO Functional Organization Enterprise wide data management roles at a business group / data domain level
Executive Owner Customer Domain #2 Domain #3 Domain #4

(Non IT)* (Illustrative) (e.g., GL data) (e.g., mortgages) (e.g., credit risk)
Data Governance Committees
Chief Data Officer Business Process Business Process Business Process Business Process
(Head of EDO) Owner(s)2 Owner(s) Owner(s) Owner(s)
Data Data Data Data Data Data Data

Data Steward Data Steward Data Steward
Management Architecture Steward2 Architect(s) 2 Architect(s) Architect(s) Architect(s)
Center of Source Source Source Source

Data
Excellence, Data System Data System Data System Data System
Governance
Shared Custodian2 Application Custodian Application Custodian Application Custodian Application
and QA
Services Owner2 Owner Owner Owner
Data
Data Advisory
Administration
Data User(s)2 Data User(s) Data User(s)
EDO works closely with business groups / domains to execute the data management strategy.
* Typically this is an executive who has an enterprise perspective, has strong influence and is also seen as a collaborator to help develop the partnership approach with the domain
owners. In the financial services industry, we have observed this being the COO/ CIO/ CMO
1Refer to appendix 3 for further information on data domains 2Refer to appendix 2 for additional information on specific roles
Page 57
Identify level of centralization / federation
Example Approach
The level of centralization / federation within a bank is a key indicator of bank culture and working environment. The highest dependency / consideration for this topic is existing bank culture. Significant
buy in and executive support is required for change.
Increasing EDO Authority
Independent Locally distributed Balanced Central + distributed Centralized
EDO EDO EDO EDO
Functional areas operate with Functional areas control a Responsibility and ownership are Data Governance provides a point Data Governance provides a
complete autonomy, while majority of their business and shared equally among the of control and decision making but single point of control and decision
maintaining global standards to technology operations, with different functional areas and the functional areas own selective making, with functional areas
meet specific enterprise limited coordination from the enterprise. decisions and activities. having little or no responsibility.
requirements. enterprise. • There is an advisory • There is an advisory and • All data management roles
• There is no oversight of data • There is some EDO assistance relationship between data oversight relationship between report into the EDO
management roles from the in setting up roles management roles and EDO data management roles and EDO • EDO sets forth policies,
Enterprise Data Office (EDO) • EDO sets forth policies and (provides services) (provides services) standards1 and processes for
• The EDO sets forth policies and standards1, but not processes • EDO sets forth policies, • EDO sets forth policies, business groups / data domains
standards1, but not procedures • There is minimal enforcement standards1and some processes standards1 and some processes to follow
• There is no enforcement of of standards for business groups / data for business groups / data • Business groups / data domains
standards • Data priorities are defined domains to follow domains to follow self-assess their performance,
• Data priorities are defined within within the lines of businesses / • Business groups / data • Business groups / data domains with the EDO frequently
the lines of businesses / data data domains, but after domains self-assess their self-assess their performance, overseeing results
domains discussions with the EDO performance and report to the with the EDO frequently • Most data priorities are defined
EDO overseeing results by the EDO
• Strategic data priorities are • Strategic data priorities are
defined by the EDO defined by the EDO
Page 58
Example Approach
Certain levels of EDO Authority correspond to both advantages and disadvantages pending capacity for cultural shift, resource capability and volume, and budget availability.
Increasing EDO Authority
EDO EDO EDO EDO
 Minimal disruption during program rollout  Integrated approach to fulfilling business  Most consistent data
 Easier business case for initiatives drivers management
Advantages
 Ability to leverage localized initiatives

 Ability to influence enterprise data maturity
 Ability to synthesize enterprise wide data
assets for strategic decision making
 Enhanced ability to meet regulatory
requirements
× No integrated approach to fulfilling business × Moderate disruption during program rollout × Disruptive cultural
Disadvantages
drivers × Additional resources required shift needed

× Different priorities across the enterprise × Speed of execution (initially, not long term)
× Increased cost from overlapping initiatives
× Increased risk due to disparate data
definitions
Page 59
Example Approach
Depending on the specifics of the centralization / federation model, accountability will be spread across the responsible groups accordingly. The RACI below is a starting point for assigning and placing
role specifics by standard area.
Standard Area Balanced Central + Distributed

R A C I R A C I
Data Quality Strategy Development EDO EDO LOB LOB EDO EDO LOB LOB
CDE Definitions LOB LOB EDO EDO LOB EDO EDO EDO
CDE Identification LOB LOB EDO EDO LOB LOB EDO EDO
Defining, Registering and Cataloguing CDEs LOB LOB EDO EDO LOB EDO EDO EDO
Business Rules Definition LOB LOB EDO EDO LOB LOB EDO EDO
DQ Threshold Definitions LOB LOB EDO EDO LOB LOB EDO EDO
Data Profiling LOB LOB EDO EDO LOB LOB EDO EDO
DQ Remediation LOB LOB EDO EDO LOB LOB EDO EDO
DQ Measurement LOB LOB EDO EDO LOB LOB EDO EDO
DQ Scorecards LOB LOB EDO EDO LOB EDO EDO EDO
DQ Maturity Assessment LOB LOB EDO EDO EDO EDO LOB LOB
DQ Maturity Remediation LOB LOB EDO EDO LOB EDO LOB LOB
R Responsible- Who is assigned to do the work
A Accountable- Who has ownership of delivery
C Consulted- Who must consulted before work is completed
I Informed- Who must be notified after work completion
Page 60
Identify organizational model
Example Interaction model 1
An interaction model is key for clearly defining accountability and expectations across the bank. Escalation procedures is one example of an at risk function without an effective interaction model. Plan
for significant stakeholder engagement for sign off.
Guiding Principles
Start simple (Crawl-Walk-Run) Avoid duplication of roles Maximize autonomy Enable early execution
Key Accountabilities
Data Office Chief Data Officer (CDO):
Establish, support, and monitor data management capabilities across Bank
Establishes and monitors data management function for Wholesale. Primary point
• Ultimate point of accountability to Enterprise for Data Mgmt. within the data office
of accountability to Enterprise.
• Define, implement and monitor data governance structures
• Establish cross-functional priorities for the data office
Chief Data Officer • Manage shared data assets (ex: customer/client); drive resolution of cross-functional issues
• Define Wholesale Data Mgmt. Standards and monitor adherence
Structures, supports, and monitors • Represent data office Bank at Enterprise governance routines
Data Officers Data Officers:

Ensure data quality and control for his/her assigned area of responsibility
Single point of accountability for establishing and delivering the data management • Identify and/or resolve data risks and issues (whether identified internally or by data consumers) for data within their custody
function for each Wholesale LOB and each functional area • Establish local data governance structures and resources
• Ensure compliance to Enterprise and Wholesale data standards / requirements
Data officers are • Ensure data provided meets user/consumer requirements
data providers
Line of Business Data and/or consumers
Data Custodians
System DataCustodians
for one another, Control Owners*:

Officers
Owners
driving significant Operate and manage key data controls

Various interaction, • Provide and maintain control metadata
negotiation and • Operate / manage to the control to specification agreed to by applicable Data Officer(s); provide action plans for out of threshold conditions
Various
Various
Various
CBG, CmBG, CRE, GIB, International, coordination and notify Data Officer of any material changes or risks impacting prioritized data
etc. between Data *A System Manager may also be the Control Owner for technical controls
SystemData
Officer functions to System Managers*:

manage data
System
Manage technical aspect of the data within application

Functional Data Officers
Various
effectively end-to-
Provide and maintain technical metadata (data flows / mapping, transformations, technical controls, etc.)
end. •
Various •
•
Provide support (analysis, enhancements, etc.) as requested by Data Officer
Identify and notify Data Officer of any material changes or risks impacting prioritized data
*Data Mgmt. accountabilities only; these are in addition to other policy requirements
Credit Risk, Finance,, etc.
System Data Custodian
Responsible for understanding the data quality of data within their assigned system; This is the “Data Owner” from G&O
Supports Monitors Supports
• Collaborate with the necessary Data Officers, System Managers, and Control Owners to understand the integrity and quality of data consumed for
System
SystemManagers Control
ControlOwners
their assigned system(s)
Page 61 SystemManagers
Managers Owners
Control Owners • Monitor the system to ensure data changes are communicated and consistent across Data Officers
Various
Various
Various Various
Various
Various
• Understand and provide visibility to action plans to resolve data issues related to the system
*The System Data Custodian will be the LOB Data Officers in cases where alignment between SOR and LOB is clear
Identify organizational model
Example Interaction model 2
An interaction model is key for clearly defining accountability and expectations across the bank. Escalation procedures is one example of an at risk function without an effective interaction model. Plan
for significant stakeholder engagement for sign off.
Chief Data Officer

Reference & Master Data*
Corporate
CB, CCB, CIB, CTC, AM
Business Partners Data Management Partners
1
LOB CDOs
4
Information
2
Data Architects
5 Domain
Business Executives
Process Owners
3
Data Stewards Technology
Managers
•1 CDOs – accountable and responsible for establishing the enterprise/LOB data strategy and governance program; roles and responsibilities of the enterprise and Corporate/LOB CDOs are
similar with different scope of data under their purview
•2 Data Domain Executives – accountable for compliance with the enterprise data management strategy, governance policies and requirements for the data domain(s); accountable for
rationalizing and unifying business rules across multiple providing and consuming business processes
3
• Data Stewards – accountable to the Data Domain Lead and responsible for understanding, disseminating and adopting applicable policies, standards and processes corresponding to the
data domain(s)
• 4 Information Architects – responsible for coordinating with Consumer, Reference & Master and Transactional Data Domain Lead(s) to link business metadata content (data definitions, data
lineage, data quality) to technical metadata content (data element, data model) in order to document data lineage
• 5 Business Process Owners – accountable to the Corporate or LOB business area officers (e.g. CRO); responsible for articulating business requirements, associated rules, business process
workflows, procedures and training materials; responsible for approval of requirements documented in the applicable templates
Page 62
Roles & Responsibilities
Example Committee Structure 1
Data Governance Structure and Escalation Levels Objectives, Agenda and Cadence
1 Executive Steering Committee 1
Executive Steering Committee – meets bi-monthly and as needed to
provide executive and business engagement in information management
Provides input on priority and drivers
Issues resolutions & process improvements escalation flow
►
Risk, Finance and Technology and
► Approves and funds strategies
Business Leadership Compliance Operations
Leadership Leadership ► Enforces compliance
Data management implementation & execution

e.g. KPIs: # Consent orders, # MRIAs
2 Data Management Council – CDO (chair) 2

Data Management Council (DMC) – meets monthly and as needed
to resolve common issues between lines of business data leads
► Develops data strategies (policies, standards, processes & procedures)
► Sets funding strategies
Enterprise CDO
LOB Data Office
Program Office & ► Sets initiative priority
Leads
Execution Leads ► Approves and implements policies, standards, processes & procedures
Data Domain
Executives ► Approves changes to list of data domains
Technology and
LOB/Corporate ► Measures LOB and Enterprise compliance
Operations Support
Report Owners
Partners e.g. KPIs: DQ defect materiality trend, # Faulty CDEs trend
3 Data Domain Working Groups – Data Domain Executives (chair) 3 Data Domain Working Groups – meets at least monthly to define,
prioritize and manage requirements and interactions between business
process teams
Consumer, Transactional and Reference & Master Data Domain Teams ► Defines shared data and resolves shared data issues
Technology and ► Prioritizes and manages requirements within the SDLC
Data Stewards Operations
Managers ► Ensures data is appropriately sourced and performs lineage
► Applies policies, standards and processes
Chief Information Business Process
Architects Owners e.g. KPIs: # Data issues
Page 63
Example Committee Structure 2
Role Description Responsibilities
Executive The group of executive • Sets appropriate “tone at the top”
Committee stakeholders who develop the • Provides funding and resources
vision and define goals of the • Provides strong sponsorship and leadership
governance body within the
strategic goals of the
enterprise
Data Governance A team of management • Develops policies and standards, and processes and procedures
Committee/Board personnel that is accountable for enterprise information management
for the execution of • Executes and monitors an overall strategic plan for enterprise data
governance functions. management improvement
• Provides channels for data issue resolution and performs
The team works closely with
business, operations and IT oversight of the resolution
• Monitors adherence to data policies, procedures, and standards
community in executing its
• Develops guidelines for classifying data stores by the type of
functions.
service they provide and the quality of data they provide
• Define data security principles, standards and sharing policies.
Data Governance Management personnel who • Leads the efforts to distill the data management goals of the
Lead heads the Data Governance enterprise as articulated by the Executive Committee Information
Program Office Management Council and Data Governance Collaborative Group
into executable and manageable processes.
• Leads the development of policies and standards, and processes
and procedures to ensure the continuous improvement of the
quality of the data assets
Page 64
RACI Definition
RACI models provide context for the participation by various roles in completing tasks or deliverables for a specific process or functions. It is especially useful in clarifying roles and responsibilities in
cross-functional/departmental projects and processes.
RACI Designations Definition

A group that is responsible for doing the work required to complete the task. The work required can
Responsible (R) be split across several responsible groups.
A group that is ultimately accountable for timely, accurate and thorough completion of the task. This
group can delegate tasks to other parties but the accountable party must sign-off or approve the work
Accountable (A)
that the responsible group completes.
A group that is consulted as part of the completion of a task, and serves as a subject matter advisor.
There is two-way communication in which the responsible or accountable parties seek the consulted
Consulted (C) groups' opinions, as they can provide input and subject matter expertise.
A group that is informed of progress and/or completion of a task. There is one-way communication in
which the responsible or accountable parties provide status updates or information to the informed
Informed (I)
group(s).
The vertical axis (left-hand column) specifies high-level tasks or deliverables while the horizontal axis specifies
roles or organizations.
Page 65
RACI Diagram
The RACI below is a standard format for visually depicting accountability and responsibility for data quality and governance. Role names may be customized or specific by bank but the foundational
context of roles should hold the integrity.
Data
Data Enterprise
Executive Governance Data Data
Function Governance Data Owner Data Comments
Committee Committee/ Steward Custodian
Lead Architect
Board
Identify KDEs for DQ

1 I A R R R R R
monitoring
Develop DQ validation
2 I C R A, R C C C
rules
Define profiling metrics

3 I A R C C C
and thresholds
Determine profiling
4 I I C C C A, R
point(s) in the dataflow
5 Profile data (History) I I I R A, R I A one-time exercise
Review/monitor results,
6 and tweak validation I A, R R R R R C
rules and thresholds
Initiate Issue
7 C A, R C C C C
Resolution
A recurring activity
performed each
8 Profile data (Current) I I I R A, R I
time data transfers
take place
Page 66
Organization model – Role Inventory
CONSULTANT COMPANY works with our clients to identify the key role sand responsibilities to enable accountability within enterprise data offices. The roles below are common roles across the industry.
Inventory of Chief Data Office Roles

► Chief Data Officer (CDO)
► Data Owner - Domain Owner
► Data Governance Lead
► Data Steward
► Data Custodian
► Information Architect
► Business Process Owner
► Executive Steering Committee
► Data Governance Committee - Data Management Council
Page 67
Chief Data Officer
Accountabilities & Responsibilities Example Skills Requirements
▶ Accountable and responsible for establishing the enterprise/LOB data ▶ Strong knowledge of industry and business data domains and
strategy and governance program processes
▶ Defines the organization's vision and sets objectives, priorities and ▶ Experience with business financial management, compliance and
scope for the data management program regulatory requirements, program management, change
▶ Defines policies, standards and processes to cover all areas of data management and risk management
management ▶ Experience in negotiation and conflict management
▶ Prepares and presents materials in support of Executive Steering ▶ Demonstrates thought leadership, diplomacy and strategic thinking
Committee and Board ▶ Knowledge of data management disciplines such as data
▶ Accountable and responsible for ensuring that all relevant governance and quality, business intelligence, data architecture and
stakeholders endorse and adopt the principles and objectives of the strategy, data security and privacy, data integration, master data
data management strategy management and metadata management
▶ Defines the data domains included in the data management program ▶ Background and career in data management or architecture,
of the organization business intelligence or data governance/data quality
▶ Defines the method by which the governance model is supervised by ▶ Ability to coordinate and lead Data Domain Executives and other
the organization stakeholders to adopt business processes and systems supporting
▶ Establishes the mechanism by which data management is funded and governance requirements
executed within the organization
▶ Defines the mechanism for measuring data management against
defined objectives including how progress is tracked and
benchmarked
▶ Works with human resources to organize job families and skills
required for enterprise data governance roles
▶ Defines and assigns the people and related skill sets to support
sustainable and effective data management
▶ Resolves prioritization and assignment conflicts and approves
decisions involving shared or critical data
▶ Responsible for validating the level of specification, business driver
alignment and prioritization of data requirements against data
domains
Page 68
Domain Executive (Domain Owner)
▶ Accountable for compliance with the enterprise data management ▶ Has breadth of knowledge of data in the data domain(s) based on
strategy, governance policies and requirements for the data usage
domain(s) ▶ Ability to coordinate and lead Data Domain Leads and others to
▶ Accountable for rationalizing and unifying business rules across collectively support the responsibilities
multiple providing and consuming business processes ▶ Required to have knowledge of the business processes and
▶ Responsible for assignment and delegating to the appropriate Data industry experience related to the data domain(s)
Domain Lead(s)
▶ Accountable for ensuring that data management standards have
been applied to data requirements, data quality validation rules,
service level agreements and data profiling
▶ Accountable for conducting QA/validation checks for integrity,
validity, completeness and timeliness of all data in the data domain(s)
by reviewing data management standards, data requirements and
associated rules
▶ Accountable for prioritizing, tracking status and obtaining resolution
on data quality issues for the data domain(s)
▶ Accountable for certification of authoritative data sources of the
attributes/elements for the data domain(s)
▶ Accountable for ensuring the critical data elements (CDEs) criteria is
applied within their data domain(s)
▶ Accountable for ensuring that data management standards have
been applied to data change management and release management
▶ Responsible for oversight of business process training materials
documentation
▶ Reference and Master data Domain Executives for common reference

data are responsible for governance and oversight of data
management operational processes
Page 69
Domain Lead (not always required)
▶ Accountable to the Data Domain Executive ▶ Understands how data is used within business processes and its
▶ Responsible for collaborating with Business Process Owners and Data impact on desired business process outcomes
Domain Executives to translate business requirements into the ▶ Experience with data analysis and data quality assessment
appropriate data requirements techniques
▶ Responsible for understanding, disseminating and adopting ▶ Ability to manage a complex workload that includes multiple tasks
applicable policies, standards and processes corresponding to the and conflicting priorities with minimal supervision
data domain(s) ▶ Capable of examining data trends to determine the root cause of
▶ Responsible for working with the Chief Information Architect to variations
review data profiling results and recommend authoritative data ▶ Skilled in conceptualizing, documenting and presenting creative
source(s) for the attributes/elements within the data domain(s) solutions
▶ Responsible for providing inputs (e.g. data impact analysis) to Data ▶ Education and training related to business process improvement
Domain Executive(s) for data quality issue prioritization and its desired business outcomes, and quality-assurance methods
▶ Responsible for monitoring changes to business data requirements (for example, popular quality-oriented methodologies such as Six
and ensuring that change and release management activities are Sigma), are preferred
executed for the data domain(s) ▶ Possesses knowledge of data lifecycle activities such as data
▶ Responsible for working in partnership with Chief Information definitions, data lineage and data quality
Architect(s) to provide subject matter advise in support of solution
design for optimal integration with existing business processes
▶ Responsible for facilitating User Acceptance Testing (UAT) by
Business Process Owner(s)
▶ Responsible for providing inputs to business process training
materials to Business Process Owner(s)
Page 70
Data Steward
▶ Accountable to the Data Domain Lead for compliance with the ▶ Understands how data is used within business processes and its
enterprise data management strategy impact on desired business process outcomes
▶ Responsible for understanding, disseminating and adopting ▶ Experience with data analysis and data quality assessment
applicable policies, standards and processes corresponding to the techniques
data domain(s) ▶ Capable of examining data trends to determine the root cause of
▶ Responsible for identifying critical data elements (CDEs) and variations
decomposing attributes ▶ Possesses knowledge of data lifecycle activities such as data
▶ Responsible for defining the data quality validation rules, thresholds definitions, data lineage and data quality
and service level agreements for CDEs (e.g. data quality issue
dashboards and metrics)
▶ Responsible for managing critical data attribute/element by applying
standards and data quality rules to ensure consistency across all
systems for the data domain(s)
▶ Responsible for logging, categorizing and performing root cause
analysis for data quality issues for the data domain(s)
▶ Responsible for providing inputs (e.g. data impact analysis) to Data
Domain Lead for data quality issue prioritization
Page 71
Data Custodian
▶ Data Custodians should be responsible for the implementation of all ▶ Understands how data is used within business processes and its
aspects of data governance and data quality for their assigned impact on desired business process outcomes
application or technology process that includes: ▶ Experience with data analysis and data quality assessment
▶ The technical definition and metadata of Key Data Elements(KDEs) techniques
including data lineage ▶ Capable of examining data trends to determine the root cause of
▶ The design and implementation of Data Quality Key Performance variations
Indicators (DQ KPIs) to measure the data quality of KDEs. ▶ Possesses knowledge of data lifecycle activities such as data
▶ The design and implementation of assessment, management, definitions, data lineage and data quality
monitoring and reporting of the data quality of KDEs
▶ The design, development, and implementation of data quality
remediation efforts
▶ Representing their application or technology process in all aspects of
Data Governance
▶ Supporting all data management activities as the Subject matter
Expert (SME) for their application or technology process
▶ Data Consumers
▶ Need to map each of these roles to the actuarial functional roles (e.g.
BUVAs may take on the responsibilities of Data Stewards as part of
their responsibilities)
▶ Support Data Owners and Data Stewards in their data oversight
responsibilities by managing the structure and integrity of the data
within their application or technology process, and designing and
implementing appropriate data management controls
▶ Coordinate across all impacted Data Stewards for those data
governance and data quality issues that arise within their application
or technology process
▶ Ensure that customer data is processed fairly and complies to
applicable regulations
Page 72
Chief Information Architect
▶ Responsible for coordinating with Consumer, Reference & Master ▶ Ability to coordinate with all levels of the organization to design
and Transactional Data Domain Lead(s) to link business metadata and deliver technical solutions to business problems
content (data definitions, data lineage, data quality) to technical ▶ Understands use of architecture principles through database, data
metadata content (data element, data model) in order to document warehouse, or business intelligence concepts and technologies
data lineage ▶ Experience with enterprise architecture modeling tools as well as
▶ Accountable for defining the approach for data profiling, supervising data modeling, mapping and profiling tools
data profiling process and providing support to personnel performing ▶ Proven ability to develop, document, and communicate information
data profiling (e.g. advising data profiling tools/training, interpreting (data) models
requirements and rules) ▶ Possesses knowledge of project management, process
▶ Responsible for recommending authoritative data source for the improvement, data modeling, and change management
attributes/elements of the data domain(s) ▶ Education and training in application development (data
▶ Responsible for working with Technology & Operations to gain manufacturing, data warehouse, data marts, information delivery),
authoritative data sources certification and contract agreement are preferred
▶ Accountable for supporting root cause analysis and data remediation
issues
▶ Responsible for designing end-to-end data Chief Information
Architecture (e.g. data flows, taxonomies, data models, design
patterns) by coordinating with Data Domain Executive(s) and
Technology and Operational Manager(s)
▶ Responsible for providing guidance on the required infrastructure
(e.g. tools, software, hardware etc.) to Technology & Operations
▶ Responsible for monitoring technical implementation to ensure
compliance with data management policy and standards
▶ Responsible for translating narrative business rules to technical rules
(algorithms)
▶ Responsible for design of business rules automation and functional
solution by working in partnership with Data Domain Lead
Page 73
Business Process Owner
▶ Accountable to the Corporate or LOB business area officers (e.g. ▶ Ability to interpret and define complex reporting requirements and
CRO) provide appropriate information to Data Domain Executives and
▶ Responsible for articulating business requirements, associated rules, Data Domain Leads to collectively support responsibilities
business process workflows, procedures and training materials
▶ Responsible for approval of requirements documented in the ▶ Strong knowledge of the finance, risk and analytic reporting rules
applicable templates and processes associated with:
▶ Accountable for understanding the data usage in the context of a • Accounting & General Ledger
business process • Profitability & Cross-sell
▶ Responsible for working with Data Domain Lead(s) to define data • Regulatory & Other Disclosure
requirements, data quality validation rules, thresholds and service • Capital & Liquidity
level agreements for CDEs • Operational Risk, Market Risk, Credit Risk,
▶ Responsible for assessing resources (systems and workforce) ability to Counterparty Risk
meet business requirements and communicating concerns to
Executive Management and applicable data office(s)
▶ Accountable for accuracy of data in the context of business process
▶ Responsible for raising/reporting data issues to the relevant Data
Domain Lead(s)
▶ Responsible for testing the processes against business requirements
and associated rules
▶ Responsible for ensuring timely and accurate report filings and has
an understanding of variances in the reports (e.g. Outstanding
Balance)
▶ Accountable for execution of operational procedures training for
Operations by leveraging capabilities (e.g. Training Organizations)
▶ Responsible for User Acceptance Testing (UAT) and approving the
implemented solution
Page 74
Define Data Policies and Standards
Page 75
Define Data Policies and Standards
► The objective of this activity is to declare the scope of governance and expectations for governance activities through policies and
Definition standards that are establish clear requirements for practitioners.
► Good policies and standards are specific an measurable.
► Understanding your client’s drivers will allow you to deliver a high quality offering and align the target state to their overall vision.
Business Benefits ► Determining what capabilities a client needs will help determine the policies and standards required
► Well written policies and standards are an enforcement tool.
the context of BCBS 239 and CCAR. This has emphasized the need for data governance policies and standards within organizations.
Industry Trends ► There has been a recent trend to streamline and consolidate policies across an institution, So that data standards are baked into
existing policies and standards
► Mark Carson
► Lisa Cook
► Ryan Duffy
► The standards required by a given institution will depend in the problems it is trying to solve, not all policies are appropriate for a DG
Chapter Guidance orgs. Focus on the policies and starts that are needed to enforce the desired behavior and activates
Page 76
Data Policies and Standards Framework
The following framework covers the following seven components of data governance. Policies, standards, and procedures will be defined by the Enterprise Data Office to ensure the program is
implemented consistently across business functions.
Policy A statement of intent in which people can be held accountable.
A collection of approved processes, procedures, roles, responsibilities, controls, metrics, reporting, templates and entry/exit criteria used to prescribe consistent and
Standard required behaviors in the definition and usage of data.
Actions performed to operate business functions in a consistent manner. Designed as sustainable data management processes with well-defined and measureable
Process and
performance criteria. Assessed for proper execution and ability to evidence adherence to standards. A well-formed procedure includes roles, responsibilities,
Procedure controls, reporting metrics and templates.
Data Change Data Issue Data Service Level

Data Quality Master Data Metadata
Management Management Provisioning Agreement
Maximize business outcomes, Provide a standard process for Provide a standard process for Provide an environment to Provide an approved, Provide clarity to data consumers Provide a standard process for
improve usability and reduce efficiently documenting, efficiently documenting, manage data, support business standardized system in which data into what each Key Data Element defining, monitoring,
Objective
time/expenses from excessive escalating and addressing data- escalating and addressing data- data reqs and move from an LOB consumers can access quality- specifically means and how it is enforcing, and maintaining
data reconciliation related change requests related issues to remediation approach to an enterprise-wide controlled reference data recorded SLAs between consumers and
data environment
providers
1. KDE Identification 1. Data Change Type 1. Data Issue Identification and 1. Authoritative source 1. Standardization and 1. Requirements definition 1. Define required SLAs
2. Source Identification Identification Capture registration representation 2. Define KDE metadata 2. Individual SLA definitions
3. Business Rule Development 2. Change Implementation Plan 2. Issue Remediation Plan 2. Provisioning point creation 2. Authoritative source 3. Metadata access 3. SLA monitoring enforcements
Creation Creation and registration registration
4. Data Quality Threshold 4. Metadata maintenance 4. SLA maintenance
Definition 3. Change Management Process 3. Issue Management Process 3. Provision point monitoring 3. Provisioning point definition
Implementation Implementation 4. Data sourcing and access and maintenance
5. Data Quality Attribute
Registration 4. Change Request Tracking and 4. Issue Tracking and Metrics 5. Data persistence 4. Master data persistence
Metrics 5. Master data access
6. Data Profiling 6. Provisioning point
Standards
7. Data Quality Issue maintenance

Management
8. Data Quality Remediation
1. Defining, registering and 1. Data Change Management 1. Non-compliance to policies 1. Upstream/downstream 1. Creating new golden sources 1. Metadata definition 1. Defining scope of services /
cataloguing KDEs process and standards/provisioning identification/ depends 2. Define source hierarchies and 2. Metadata capture/update partners
2. Data Quality measuring and 2. Data change request tracking 2. Discrepancies to data 2. Data sourcing/extraction survivorship rules 3. Data lineage capture/update 2. Establishing SLAs
(illustrative)
monitoring process definitions assessment 3. Master data change 3. Exception/escalation

Processes
4. Metadata change
3. Root cause identification 3. Escalation process 3. Issue tracking process 3. Data provisioning assessment management management processes
4. Data Quality remediation 4. Escalation process
Page 77
Data Policies and Standards Objectives
Developing appropriate, effective, and comprehensive policy, standards, and procedures for a variety of capabilities is imperative for successful data governance. The following policy framework below
is a comprehensive starting point.
The objective of Reference Data Policy

The objective of Data Quality Policy is is to provide and approved,
to maximize business outcomes, standardized system where data
improve usability and reduce time consumers can access quality-
and expenses associated with controlled reference data.
excessive data reconciliation.
The objective of Issue Management

Policy is to provide a standard process
for efficiently documenting, escalating,
and remediating data-related issues.
The objective of Metadata Policy is
to provide clarity to data consumers
into what each Key Data Element
specifically means and how it is The objective of Change Management
recorded. Policy is to provide a standard process
for efficiently documenting, escalating,
and addressing data-related change
requests.
The objective of Data Provisioning

Policy is to provide clarity to data The objective of SLA Management Policy is to
consumers on the required provide a standard process for defining,
locations for accessing quality- monitoring, enforcing, and maintaining
controlled data. Service Level Agreements between Data
Consumers and Data Providers.
Page 78
Policies and Standards Inventory
DQ01 – KDE identification

DQ02 – Business rule development RD01 – Standardization and representation
DQ03 – Business rule development (target depth) RD02 – Authoritative source registration
DQ04 – Quality threshold determination RD03 – Provisioning point definition and maintenance
DQ05 – Data profiling (testing points) RD04 – Reference data persistence
DQ06 – Data quality Attribute Registration RD05 – Reference data access
DQ07 – Data profiling (test execution)
DQ08 – Data profiling (enterprise scorecards)
DQ09 – Data quality issue management (capability)
DQ10 – Data quality issue management (prioritization)
DQ11 – Data quality remediation IM01 – Issue management process implementation
IM02 – Issue remediation plan and timeline
IM03 – Issue tracking and metrics
MD01 – Requirements definition

MD02 – Define KDE Metadata
MD04 – Metadata access
MD03 – Metadata maintenance CM01 – Change management process implementation
CM02 – Change implementation plan and timeline
CM03 – Change request tracking and metrics
DP01 – Authoritative source registration

DP02 – Provisioning point creation and registration SLA01 – Define required SLA’s
DP03 – Provisioning point monitoring SLA02 – Individual SLA definitions
DP04 – Data sourcing and access SLA03 – SLA monitoring enforcements
DP05 – Data persistence SLA04 – SLA maintenance
DP06 – Provisioning point maintenance
Page 79
Policies and Standards Framework
Data Quality
Page 80
Data Quality Policies and Standards
Scope The Data Quality policies and standards is applicable to all Key Data Elements
The objective of Data Quality Policy is to maximize business outcomes, improve usability and reduce time and expenses associated
Objective with excessive data reconciliation.
Critical Data Key business processes where Customer data is a critical component
Enterprise Data Quality Policy & Standards Requirements
Data Quality across will be compliant with the data quality policies and standards across the following components of data quality:
•(DQ-01) KDE Identification - Identification of the Key Data Elements for Lines of Business which need to be profiled.
•(DQ-02) Business Rule Development - Development of rules to validate the quality of data based on specific business criteria.
•(DQ-03) Business Rule Development (Target depth) – Defining the level of Business Rule sophistication (and complexity) required to monitor Data Quality.
•(DQ-04) Quality Threshold Determination – The minimum threshold for data quality that can be tolerated by each Business Process.
•(DQ-05) Data Profiling (Testing Points) - Testing points for profiling data at different stages of the data flow.
•(DQ-06) Data Quality Attribute Registration - Storage and sharing of KDE attributes across Lines of Business.
•(DQ-07) Data Profiling (Test Execution) - Execution of the data profiling tests (including tool guidance and testing frequency).
•(DQ-08) Data Profiling (Enterprise Scorecards) - Scorecards used for data quality reporting to capture and understand the data quality ‘health’ of data.
•(DQ-09) Data Quality Issue Management (Capability) - Process and capabilities required to capture and resolve enterprise data quality issues.
•(DQ-10) Data Quality Issue Management (Prioritization) - Criteria used to prioritize data quality issues to be addressed by the data quality program.
• (DQ-11) Data Quality Remediation - Remediation of issues based on their priority severity (e.g., Level 1- Level 5) guidelines.
Page 81
ID Policy (Principle) Standard (Criteria)
DQ-01 KDE Identification- The The general definition of a KDE is: ‘Data elements that is critical to the successful creation of reports, where data quality issues
Customer Focus Group is with these elements could potentially impact the business.’
responsible for identifying the
Key Data Elements (KDEs) for Alternatively, KDEs can be: ‘those data elements that drive capital or are used by executive management to make significant
their respective business business decisions’.
functions / processes.
Key Data Elements(KDEs) are identified by the LOB’s and then prioritized for business importance / impact. Data elements
should be identified across the following areas to determine if they are in fact ‘key’ to business operations. Typically KDEs meet
one or more of the following criteria.
•Metric Calculation - The data element is utilized in a key metric calculation within a business process and feeds a key report or
analytic.
•Context Definition - The data element is used to group or filter data to ensure key metrics are stratified as required by the
business or regulatory body (e.g. FATCA requires identification of income generated by US citizens abroad. Monitoring the
quality of the data elements that identify someone as a US citizen would aid in compliance).
•Critical Unique Identifier - The data element is critical to uniquely identifying an individual customer or transaction.
Page 82
DQ-02 Data Quality Business Rule Business rules are business-specific verifiable statements that are identified for each Key Data Element (KDE) . Rules are
Development- The Lines of developed using a data quality business rule/dimension framework. A rule can be created for 1 or more data quality dimension
Business must develop and (e.g., completeness, accuracy, and timeliness).
maintain data quality
business rules for the Key
•Completeness Rules: The degree to which data is required to be populated with a value (e.g., A policy ID is required for all
Data Elements (KDEs) within
customers but not prospects) - Metric = % Failure, Failure Count
respective data domain(s).
•Uniqueness: The degree to which data can be duplicated (e.g., Two non-related customers cannot have the same Policy ID.).
Metric = % Duplicated, Duplicate Count
•Validity: The degree to which data conforms to defined business rules for acceptable content (e.g., Policy ID must be 10
characters long). Metric = % Failure, Failure Count
•Logic / Reasonableness: The degree to which data confirms to tests of reasonableness based on real-world scenarios (e.g., A
policy holder’s birth date must prove that they are at least 13 years old). Metric = % Failure, Failure Count
•Accuracy: The degree to which data is consistent with authoritative sources of the truth (e.g. Policy ID must conform to an
authorized government-issued document or database). Metric = % Accuracy, Failure Count
•Integrity: The degree to which data retains consistent content across data stores (e.g. Policy ID contains the same value for a
Customer across databases). Metric = % Different, Count of Differences
•Timeliness: The degree to which data is consistent with the most recent business event (e.g., Policy ID must be updated within all
systems within XX hours of a change made to a Customer record). Metric = % Failure, Failure Count
•Coverage: The degree to which data is inclusive of all supported business functions required to produce a comprehensive view for
a specific business purpose (e.g., Average Revenue per User reporting for the enterprise should include revenue data from all
LOB’s where revenue is generated). Metric = % Data Sources Available
•Comprehensiveness: The degree to which all expected records are contained in a data store (e.g., All AFORE Policy ID’s must be
stored in the AFORE Customer database). Metric = Comprehensiveness Ratio (records found vs. records expected)
Page 83
DQ-03 Business Rule Development Target Depth of the required data quality checks for each KDE must be agreed to by all impacted stakeholders prior to
(Target depth) – The Lines of implementation. The minimum level of depth should be applied for all LOB’s which is typically the maximum need of any one
Business are responsible for LOB.
establishing the target depth
required for business rules that Target depth refers to the appropriate level of details and complexity required for the business rules that are developed.
are being developed.
The typical levels of Dimensions Testing Depth
business rule depth
include (from low to Completeness Level 1 – Single field validation
• Null/ allowable values Low
high complexity):
Uniqueness • Valid values
Data Quality Testing Depth

• In – domain
Validity • In Range
Level 2 – Validation within an entry / table
Logic/ Reasonableness • Enforced key rules
• Sequencing
• Cross validation
Accuracy • Data Obsolescence
Integrity Level 3 – Validation across entities / tables / systems

• Key relationships
• Logical relationships
Timeliness • Date relationships
• Temporal relationships
Coverage
Level 4 – Reconciliation
Comprehensiveness High
• Population completeness
Page 84
DQ-04 Quality threshold determination – Data Stewards must develop a minimum quality threshold for each KDE / Business process combination.
The LOB’s must establish and
record data quality thresholds for Data Quality thresholds must be recorded in a centralized repository for future reference and maintenance.
each KDE.
DQ-05 Data Profiling (Testing Points)- The KDEs must be profiled as close to their original source as possible to ensure that downstream consumers are receiving the
Data Governance Organization is highest quality data.
responsible for identifying the
appropriate testing points where Examples of testing points of where data can be profiled are: (sources of data (recommended), points of aggregation, areas
data will be profiled. where data is enriched).
Data Profiling is the activity of processing KDEs through the business rules and capturing the results to be assessed.
DQ-06 Data Quality Attribute Registration Data Governance Organization must confirm that the following attributes have been recorded:
– The data Governance
Organization must confirm •Business Process
successful recording of KDE •KDE Name • Measurement Metric
attributes. •KDE Reason • KDE Threshold
•Target Depth • Profiling Points
•Business Rules • Profiling Frequency
Access to KDE attribute data must be controlled to protect attributes of sensitive KDEs.
Page 85
DQ-07 Data Profiling (Test Execution)- Tests Test execution must be performed using approved tools as defined by the Enterprise Data Governance organization. A
must be performed/executed by the standard minimum test execution frequency (typically monthly) must be defined to ensure that test results can be
Data Governance Organization using aggregated and reported.
approved tools, on the Key Data
Elements(KDEs). Test execution is the shared responsibility of both the business and IT and is facilitated by the Data Stewards.
DQ-08 Data Profiling (Enterprise Results of profiling to be recorded using enterprise data quality metrics and established thresholds. Enterprise data
Scorecards)- The Data Governance quality metrics include (see appendix for additional descriptions):
Organization is responsible for
aggregating and publishing the • Data Quality Materiality - Index representing the amount of materiality that is NOT at risk due to poor data quality
results of their data quality profiling within a business process.
efforts in a consistent manner and on
a monthly basis. • Data Quality Defect - Index representing the defect count across transactions or records that supply data to a
business process.
• Data Quality Test Coverage - Index representing percentage of critical KDEs that are currently being reported on data
quality for a particular business process
• Data Quality Testing Depth - Indicates the depth of testing, on a scale of (1 -4), that any given KDE is tested against
(e.g. 1- Single Field Validation; 2- Validation within an entity / table; 3- Validation across entities / systems; 4-
Reconciliation).
• Total # of Data Quality Issues - The number of data quality issues that are entered into the tracking system (e.g.
Quality Center) for a given profiling period.
• Total # of Data Quality Issues (Past Due) - The number of data quality issues that are past due based on a SLA. (SLAs
must be defined at the Business Process Level).
Page 86
DQ-09 Data Quality Issue Management The standard data quality issue management process must be established to ensure data quality issues are effectively
(Capability) must establish a capability prioritized and remediated (please refer to the Issue Management policies and standards for more information on
to capture, manage and escalate high setting up a standard process)
priority data quality issues across
Lines of Business. The capability must include dedicated resources to manage and track and escalate issues.
DQ-10 Data Quality Issue Management Will work with Lines of Business to identify high priority issues using a prioritization framework/criteria. An example of
(Prioritization) must prioritize data high priority issues are data quality issues which have an impact across Lines of Business and/or have significant
quality issues to determine the scope business impact (e.g., reputational risk, regulatory).
of their responsibility.
DQ-11 Data Quality Remediation- Lines of Data Stewards are responsible for partnering with the Data Custodians and System Owners on the necessary steps and
Business must remediate data quality timeline for remediating a Data Quality Issue.
in a timely manner.
Remediation time will be determined by the severity of the issue. The severity level depends on the impact to the
business (e.g., risk, reputational, operational, legal).
The proposed remediation end-date will be monitored by the issue management process for on time implementation
(See Issue Management Policies and Standards for more detail)
Page 87
Policy and Standards Framework
Metadata
Page 88
Metadata Policies and Standards
Scope The Metadata policies and standards is applicable to all Key Data Elements
The objective of Metadata Policy is to provide clarity to data consumers into what each Key Data Element specifically means and how it
Objective is recorded.
Critical Data Customer Key Data Elements

Metadata across will be compliant with the metadata policies and standards across the following components of metadata:
• (MD-01) Requirements Definition – Defining the requirements for specifically what metadata must be captured per Key Data Element.
• (MD-02) Define KDE Metadata - Defining the actual metadata required for each Key Data Element.
• (MD-03) Metadata Maintenance - Maintaining metadata over time to ensure continued accuracy and usability.
• (MD-04) Metadata Access – Ensuring metadata is made available for data consumer reference.
Page 89
MD-01 Requirements definition – Metadata metrics that are common candidates to be captured include:
The Data Governance •Business definition
Organization must define the •Regulatory restrictions
required metadata values to be •Data Recording standards (business and IT)
defined for each KDE. •Data authoritative source (Data lineage)
•Key Security restrictions (e.g., regulatory or internal)
•Key data business relationships (e.g., All Customers with Policy ID’s must have a registered legal Name)
•Technical Metadata (Table Name, Foreign key constraints, Indexes, Partitions etc.)
MD-02 Define KDE Metadata - The Line of All Line of Business's should agree on shared Metadata specifications. Exceptions should be registered depending on the
Business's must work together to business need.
define the required metadata
values for each KDE. Shared metadata specifications typically include:
•Business definition
•Data recording standards (e.g., field length)
When there is a shared ownership of Metadata, a common definition must be defined and agreed to.
Metadata definitions must be recorded in a single location (ideally in a metadata tool) and made available to users for
reference.
MD-03 Metadata Maintenance - There must be a standard Issue management process responsible for recording and escalating issues pertaining to
Impacted Line of Business's must metadata.
approve all metadata updates,
deletions, or new KDE additions. There must be a standard change request process responsible for addressing updates to metadata.
When new metadata requirements (or new KDEs) are established, the required metadata must be created and
implemented within the standard repository within a defined timeframe (typically 30 days).
Page 90
MD-04 Metadata Access - All Lines of Business must define and implement the correct level of access and control, for sensitive metadata within its
Metadata must be made available control.
to data consumers while managing
access to restricted metadata Access to metadata values may be restricted if it divulges information that is not for enterprise consumption (e.g., Metadata
information. may describe the employee salary data to a level of detail that should not be viewed outside of the HR department).
Access to certain restricted or proprietary metadata should be restricted in the same fashion as all other data is controlled
and restricted.
Access to non-secured metadata should be made easily available and encouraged.
Accountability for appropriate usage of data by the Lines of Business falls to their respective Data Stewards.
Page 91
Data Provisioning
Page 92
Data Provisioning Policies and Standards
Scope The Data Provisioning policies and standards will be applicable to all data assets within the organization.
The objective of Data Provisioning Policy is to provide clarity to data consumers on the required locations for accessing quality-
Objective controlled data.
Critical Data All Customer data
Data Provisioning across the client will be compliant with the data provisioning policies and standards across the following components:
•(DP-01) Authoritative Source Registration – Assigning each LOB system as whether it is an authoritative source for a Key Data Elements.
•(DP-02) Provisioning Point Creation and Registration - Creating and registering provisioning points where data consumers can come to access Key Data Elements.
•(DP-03) Provisioning Point Monitoring - Monitoring provisioning points for KDE usage and ensuring timeliness of data availability.
•(DP-04) Data Sourcing and Access – Managing data consumer access and usage.
•(DP-05) Data Persistence – Ensuring data remains available at the provisioning point for as long as necessary.
•(DP-06) Provisioning Point Maintenance – Maintaining provisioning points over time to ensure long term usability.
Page 93
DP-01 Authoritative Source Registration: Each Line of Business must adhere to the definition and register all owned systems that contain KDEs as to whether they are an
Lines of business must define an Authoritative Source an End User Computing System (EUC).
authoritative source status for all
systems that store Key Data •Authoritative Source Definition – An authoritative source of Key Data Elements is a system (or systems) that contain
Elements. registered Key Data Elements and is authorized to share that data with other systems in accordance with data provisioning
policies.
•End User Computing System (EUC) - An EUC is a system that consumes Key Data Elements and will generate some reporting
based on it such as regulatory reports, financial statements, etc, but is not allowed to share the data with other systems
directly (i.e. is NOT an Authoritative source nor a Provisioning Point).
New systems must be registered before going into production. Existing applications must be registered within the timeframe
specified by the Data Management Governance Organization. (All systems must be registered within 12 months from
ratification of this standard requirement).
Each system must be registered in the Enterprise System of record for application identification identifying each Key Data
Elements that is shared.
Registration must be updated to reflect any additional Information needed regarding Key Data Elements.
KCONSULTANT COMPANY NOTES:

•All Provisioning Points (as described in DP-02) are also classified as Authoritative Sources of data as they are authorized to
share KDE data.
•Please refer to the appendix for an illustrative example of the difference between Authoritative Sources vs. EUC Systems vs.
Provisioning Points.
Page 94
DP-02 Provisioning Point Creation and Data Stewards are responsible for providing their usage requirements for Key Data Elements so that Data Custodians can
Registration: Standard create the appropriate data provisioning point. These usage requirements include:
Provisioning points must be
created and registered. •Data Availability (timing)
•Data persistence (how long the data will remain available)
•Data controls / restrictions
Data Custodians will analyze the KDE access requirements supplied by the Data Stewards and create a Provisioning Point
for KDE access. All provisioning points should be registered in an Enterprise Registration System so they can be referenced
by data consumers looking for data.
Provisioning Point Definition - A data provisioning point is a location (system) that is authorized to share specific KDEs with
Data Consumers (individuals and systems).
•Provisioning points are typically created by subject areas (e.g. Customer, Risk, Finance etc.) and must be defined and
maintained by the Data Custodians.
•Provisioning points are specifically designed to provide the data to consumers when they need it
•The provisioning point for a particular data domain will rarely change once created but registration is appropriate to
ensure any changes that are made are known and communicated.
KCONSULTANT COMPANY NOTES:
•All Provisioning Points are by definition classified as Authoritative Sources of data as they are authorized to share KDE
data. However, all authoritative sources are not necessarily authorized provisioning points.
•Please refer to the appendix for an illustrative example of the difference between Authoritative Sources vs. EUC Systems
vs. Provisioning Points.
Page 95
DP-03 Provisioning Point Monitoring: Registered provisioning points that distribute Key Data Elements must be reviewed and assigned a provisioning status by the
Provisioning points must be LOB owner and Data Custodian to designate the system's readiness and appropriateness to share data.
monitored for availability and Key
Data Element usage. The Data Governance Organization must oversee the data provisioning assessment process.
Key Data Element usage must be monitored to understand frequency of data usage and effectiveness of controls. Metrics
include:
•Frequency of KDE Access by security profile - Metric = # Requests by Profile by Date

•Performance (e.g., CPU Utilization) of provisioning point during peak usage- Metric = CPU Utilization by Date
Access to shared data assets will be reviewed by the Data Governance Organization on annual basis.
DP-04 Data Sourcing and Access: All users Key Data Elements must only be sourced from registered Provisioning Points.
must obtain their data from an
approved provisioning point.
The Key Data Elements created are a corporate asset and must only be used for a defined business purpose.
DP-05 Data Persistence: Lines of Business Data Stewards are responsible for developing, maintaining, and communicating persistency requirements.
are responsible for developing
persistence requirements for the The typical persistence requirements vary by system type:
data they use.
•Authoritative Sources – Store complete KDE history
•Provisioning Points – Store complete KDE history
•EUC Systems – Storage history is defined by the system owner is only required to store the level of history required for its
business purpose.
Data Custodians are responsible for ensuring that persistence is maintained for all systems in their control.
Page 96
DP-06 Provisioning Point Maintenance: All data sourcing requests for new KDEs must be submitted to the Data Stewards for review and ratification.
All new KDEs must have an
approved provisioning point
The sourcing requests must contain the following requirements:
defined and registered.
• What data is required
• How the data will be used
• Anticipated duration of the need
Data Custodians will be responsible for making the new data available via an approved provisioning point.
The Data Custodian must record which authoritative source and associated approved provisioning point is providing the
data.
Page 97
Reference Data
Page 98
Reference Data Policies and Standards
Scope The reference data policies and standards will be applicable to reference data assets within the organization. Reference data is data
that should have only one representation for use across the organization
The objective of Reference Data Policy is to provide and approved, standardized system where data consumers can access quality-
Objective controlled reference data.
Critical Data External data that enhances Customer
Reference Data across the client will be compliant with the Reference Data policies and standards across the following components:
•(RD-01) Standardization and Representation – Standardizing on what reference data the enterprise should commit to using and how that data will be represented.
•(RD-02) Authoritative Source Registration – Assigning each reference data system as whether it is an authoritative source for Key Data Elements.
•(RD-03) Provisioning Point Definition and Maintenance - Creating and maintaining provisioning points for reference data consumer access.
•(RD-04) Reference Data Persistence – Defining how long reference data should remain available for access via a provisioning point.
•(RD-05) Reference Data Access – Controlling access to reference data available for consumption.
Page 99
RD-01 Standardization and Data stewards for reference data domains and attributes will be accountable for defining the structure and representation of
Representation: Sources of reference data.
reference data must be defined,
standardized and shared. Industry standards must be used to represent reference data where applicable (e.g., currency standards, industry coding
standards etc.).
Reference data unique to the client must comply with internal representation standards approved by the Data Governance
Committee.
RD-02 Authoritative Source Authoritative sources will be defined for reference data and will be registered in the enterprise system of record for
Registration: Lines of business application identification.
are responsible for defining and
registering systems that Refer to the data provisioning Policies and Standards for additional information on declaring Authoritative Sources.
produce Reference Data as
authoritative sources.
RD-03 Provisioning Point Definition Data Custodians must provide standard provisioning points for reference data. Please refer to the data provisioning policies
and Maintenance: Reference and standards for details of provisioning point registration and maintenance.
Data Provisioning Points must
be defined and created.
Page 100
RD-04 Reference Data Persistence: Lines Data Stewards are responsible for developing, maintaining, and communicating persistency requirements.
of Business are responsible for
developing persistence Please refer to the Data Provisioning Policies and Standards for additional detail on implementing data persistence
requirements for the reference requirements for all data domains.
data they use.
RD-05 Reference Data Access: Reference All access requirements (incl. controls) must conform to the data provisioning Policies and standards.
Data must only be accessed from
an approved provisioning point.
Page 101
Issue Management
Page 102
Issue Mgmt Policies and Standards
Scope The centralized Issue Management policies and standards will manage all data related issues including those related to Data Quality,
Data Provisioning, Reference Data, and Metadata.
The objective of Issue Management Policy is to provide a standard process for efficiently documenting, escalating, and remediating
Objective data-related issues.
Issue Management will be compliant with the Issue Management policies and standards across the following components:
•(IM-01) Issue Management Process Implementation – Adhering to a standard issue management process to ensure comprehensiveness of issue management and remediation.
•(IM-02) Issue Remediation Plan and Timeliness – Assuring issue remediation is thorough, complete, and timely.
•(IM-03) Issue Tracking and Metrics - Monitoring the issue management process and detail to ensure efficiency while spotting potential trends in issue identification and
escalation.
Page 103
IM-01 Issues Management Process There must be a standardized, centralized, and clear issue management process, this process must be agreed upon by the Data
Implementation: A standard, Governance Organization and adopted by all participating LOBs. The process must include the following key activities:
centralized issue
•Standardized Issue Description – All issues should be logged describing the issue, the exact circumstance or scenario that lead
management process must
to the issue and the perceived impact of the issue (e.g., a Data Quality Issue should describe exactly what KDE was being analyzed
be created and enforced.
and for what reason).
•Issue Routing – Issues should be routed to the appropriate support audience based upon the initial problem description . This
routing will ensure that issues get to the correct owners for each issue type including:
- Data Quality,
- Data Provisioning
- Metadata
- Reference Data
•Issue Prioritization – The responsible support team will place the issue into the queue based on its perceived prioritization (e.g.,
a Data Quality issue impacting an upcoming regulatory report will likely take precedence over a non-material issue).
•Issue Diagnostic – The responsible support team will perform the research to determine the cause of the issue and formulate and
remediation plan (see IM-02).
IM-02 Issue Remediation Plan and Each time there is an issue to be addressed a remediation plan must be created and followed.
Timelines: All issues require
Data Stewards must define the corrective actions if they are the sole owners of the data, or in coordination with the Data
a plan for remediation to
Governance Organization if it affects more than one Line of Business.
ensure a comprehensive fix
is completed. Data Custodians will be responsible for any IT remediation in their respective domains.
There will be an established remediation plan depending on the severity, if remediation is expected to take significant time, there
must be periodic reporting on the progress to the Data Governance Organization.
Page 104
IM- 03 Issue Tracking and Metrics: There should be a scorecard with metrics to monitor new and in-process issues.
Standard issue monitoring and
reporting must be in place for Detailed Metrics should include:
effective issue management
• Type of Issue e.g., (Data Quality, Data Provisioning, Metadata, Reference Data)
• Issue owner
• Severity
• Prioritization
• Target resolution date
Summary Metrics should include:

• # Issues per Line of Business
• # Issues per system
• # Issues outstanding (In process vs. in queue)
• # of issue remediation's past due
• Frequency of occurrence of the type of Issue
Page 105
Change Management
Page 106
Change Mgmt Policies and Standards
Scope The Change Management policies and standards will define a centralized approach for managing, sustaining, and maintaining
changes to data including Policy and Standards updates, new KDE sources, data quality and metadata rules updates.
The objective of Change Management Policy is to provide a standard process for efficiently documenting, escalating, and addressing
Objective data-related change requests.
Change Management will be compliant with the Change Management policies and standards across the following components:
•(CM-01) Change Management Process Implementation – Centralized change request process to manage all types of data-related changes.
•(CM-02) Change Implementation Plan and Timeline – Thorough implementation plans and estimated target dates to allow for strategic implementation planning and
execution.
•(CM-03) Change Request Tracking and Metrics - Monitoring the status of change management activities underway while providing insight into upcoming data change requests
for strategic planning purposes.
Page 107
CM-01 Change Management Process There must be a centralized, standardized and clear data change management process, this process must be agreed upon by
Implementation: A centralized the Data Governance Organization and adopted by all participating LOBs. The process must include the following key
standard change management activities:
process must be created and
•Standardized Change Request Description – All change requests should be logged describing the requested change, the
enforced.
business reason for the change and all known impacts of the change. (e.g., Mexico requires phone numbers to have an
additional digit which is a regulatory requirement and impacts all systems and users of telephone numbers).
•Change Prioritization – The Data Governance Organization will place the change request into the queue based on its
perceived prioritization (e.g., Phone number digit addition is not required for implementation for 3 years, therefore, existing
high priority short term change requests can be processed first).
•Change Routing and Impact Assessment – All change requests must be routed to the appropriate organization who will
perform an impact assessment to determine the scale and complexity of the change (e.g., Phone number digit addition is
routed to IT to determine the scale of the system updates required to accommodate the change). The routing will include the
following types of change requests:
- Policy and Standards updates
- New KDE sources
- Data quality and metadata rules updates
CM-02 Change Implementation Plan and Each time there is a change to be addressed an implementation plan must be created and followed.
Timeline: All change requests
Change implementation plan should include:
require a plan for implementation
to ensure the right resources are • Budget, Estimate, and Resource Requirements
available to implement the
• Implementation Timeline
change.
•Testing Plan
• Deployment Plan
Page 108
CM- 03 Change Request Tracking and There must be a status report with metrics to monitor new and in-process change requests .Detailed Change Metrics should
Metrics: Standard change request include:
monitoring and reporting must be
• Change request type (e.g., Policy / Standards Update, new KDE request etc.)
in place to effectively manage and
sustain ongoing change efforts. • Change request owner
• Severity / Prioritization
• Impacted LOBs
• Target implementation date
To plan for and sustain ongoing data change request initiatives, an executive scorecard must be created to provide insight
into the following metrics:
• Prioritized change requests by type
• Projected budget requirements for prioritized change requests
• Prioritized change requests LOB / Operations dependencies
Page 109
Service Level Agreement
Page 110
SLA Policies and Standards
Scope The SLA Management policies standards will be applicable to the data used by any critical business process.
The objective of SLA Management Policy is to provide a standard process for defining, monitoring, enforcing, and maintaining Service
Objective Level Agreements between Data Consumers and Data Providers.
Critical Data Customer Key Data Elements (specifically pertaining to data quality, provisioning, metadata, and reference data)
SLA Management will be compliant with the SLA Management policies and standards across the following components:
• (SLA-01) Declare Required SLAs – Centralized list of SLAs to be executed and monitored for adherence.
• (SLA -02) Individual SLA Definitions– Agreed to detailed SLA terms for each individual SLA.
• (SLA-03) SLA Monitoring and Enforcement - Monitoring and enforcing SLA adherence to ensure effective business operations.
• (SLA-04) SLA Maintenance - Creating new SLAs or maintaining existing SLA terms to ensure they meet current requirements and remain feasible to achieve.
Page 111
SLA-01 Declare Required SLAs: SLAs must SLAs must govern data related agreements between impacted parties for all critical business processes where timeliness
be established to govern all critical is required. Key SLA candidates include:
business processes.
•Data Quality Agreements – Agreeing on the level of quality to be maintained for Key Data Elements.
•Data Sharing (provisioning) Agreements – Agreeing on when data will be available for data provisioning.
•Metadata Management Agreements – Agreeing on the timing for when existing metadata should be revised or new
metadata be created and made available.
•Reference Data Agreements – Establishing agreements with 3rd party vendors on when reference data will be available
and how it will be maintained.
SLA- 02 Individual SLA Definitions: SLA Minimum SLAs must be established between impacted parties (e.g., Data Stewards, Data Custodians, Operations,
terms must be negotiated and Support) including SLA violation impacts.
agreed to between impacted parties
prior to ratification. Situations where the impacted parties cannot agree to terms for the SLA will be escalated to the Data Governance
Organization for resolution.
SLA-03 SLA Monitoring and Enforcement: SLA adherence is monitored by the business process owners and issues are escalated via the issue management process.
SLAs must be actively monitored
and enforced to ensure effective An SLA scorecard will monitor SLA adherence over time and be communicated to the Data Governance Organization. This
business processes. scorecard typically includes the following metrics:
•SLA Owners (e.g., data provider and data consumer)
•# violations per SLA over time
•Degree of SLA violation (e.g., <5 mins = minor, 5-20 mins = moderate, 21+ mins = severe)
The Data Governance Organization will monitor SLA adherence and address any reoccurring violations when necessary.
Page 112
SLA- 04 SLA Maintenance: SLAs SLAs must be revisited periodically to ensure they reflect current business process needs and priorities.
agreements must be
maintained to ensure SLAs no longer required should be terminated to eliminate confusion and simplify processes (e.g., a report previously
relevance and feasibility of required for regulatory reasons is no longer needed).
adherence
All new business processes should be analyzed for any required new SLAs.
Page 113
Policies and Standards
Roll Out Strategy
The roll out strategy will be customized to by client and client priorities. Differing in flight initiatives will be the key drivers used to determine the roll out strategy..
Function Name Activities Input Output/ Deliverables* Comments
Establish a DG • Assign individuals to roles in the DG organization • Organization model • Organization model The goals/vision of the
body • Conduct kickoff meetings for WGs and (with roles and (with individuals DG organization should
Committees, and establish long term agenda responsibilities) assigned to the roles) reiterated in the kickoff
• DG Charter • Meeting agenda and meetings.
minutes
Rollout DG policy • Ratify DG policy, and publish compliance • DG Policy Document policy
and standards schedule for stakeholders under policy’s purview • Set of DG standards exceptions. For the non-
• Publish set of standards for adoption compliant, develop
• Assign accountability to requisite stakeholders timeline for compliance.
for standards adoption
Execute DG • Provide training on the formal DG processes to • Process flows • Various (e.g., DQ As the DG processes get
Processes and impacted stakeholders • RACI charts dashboards) deployed, modifications/
Procedures • Perform functions defined in the DG processes • Procedure documents enhancements may be
(e.g., for Issue Resolution, collate issues into a required to address
central issue log, assign owners to issues, specific nuances of the
manage issues through resolution). processes. Such
• Monitor process for improvement opportunities modifications will reduce
over time with the maturity
of the program.
Conduct training • Provide requisite training to DG organization • Training materials • Training Include success stories in
and spread DG members • Communiqués the communiqués
awareness • Recommend DG-related training for other
stakeholders
• Publish periodic messages informing the
business, technology and operations about its
value, benefits and impact to project/initiatives
Page 114
Policies and Standards
Example Pilot Program
Goals and Objectives: Roles and Participants In-Scope Data Domains
• Use a practical approach to test & prove the key data governance components that are in Role Name
Workstream:
development: Policy & Standards, Roles & Responsibilities, Key data elements processes. Data Domain Source
Chief Data Officer
• Prove out key interactions between the business process owners, data custodian, data stewards, Customer Data TBD
data users and source system application owners. Data Governance Committee (EDO Core Team)
Finance Data N/A
• Determine which governance routines will be effective.
Risk Data N/A
CRM Project Manager
Operations Data N/A
Approach: Key data governance roles by area
• Conduct workshops to execute use cases specific to the selected pilot program Area Data User App Owner Custodian Steward
• Use of simplified processes and tools as opposed to formalities TBD TBD TBD TBD Keith Gaydica
• Capture learning from pilot and establish next steps for expanding governance
Pilot Activities (Use Cases)
Description Status Templates (Docs)
Scope & Assumptions: 1. Update project plan and scope statements with data management activities Not started
• Eight week pilot consisting of (3) workshops within the following scope 2. Finalize role assignments Not started
• Maximum of 2 systems, 15 data elements and 30 business rules

3. Identify key data elements (define critical data) Not started
• Platform to profile data and execute DQ business rules
4. Register source and target enterprise data assets (define critical data) Not started
• Will need project resources to fully participate
5. Define Data Quality business rules Not started
6. Execute business rules and create Data Quality metrics Not started
Measuring Success G
7. Review pilot and update policies, standards and processes as applicable Not started
Description Value Trend
% of Roles Assigned ▲ Timeline:
% of KDEs documented and registered ▲ Prepare Workshops & Participants Workshop #1 Debrief Workshop #2 Debrief Workshop #3 Debrief Final touchpoint
% of EDAs identified and registered ► Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
% of Enterprise EDAs used ▼ Pilot Project-Plan & Participants, ownership assignment KDE and EDA identification and DQ Business Rules creation DQ Metrics and scorecards, data issues
registration logging, pilot debrief
% of Use Cases Completed ►
Additional work product: Updated project plan / scope statements with data management
Page 115
Establish Key Processes and Procedures
Page 116
Establish Key Processes and Procedures
Section Introduction –
► There are key processes that need to be set up to enable governance to be ‘real’. These processes include the processes to declare and
Definition prioritize scope of data under governance, (e.g. declare KBEs or Critical elements) manage change and to solve identified problems
(e.g. through issue escalation and management.) this chapter is focused on establishing these key foundational processes.
► The foundational processes of change management and issue management are what make data governance actually be able to solve
business problems.
Business Benefits ► Integration of data governance into the SDLC enables it to occur at time of development and not as an after the fact control.
Implementing DG principles at time of build is cheaper, easier and faster than doing after the fact.
► Firms are beginning to integrate the DG processes into a wider framework of other processes as part of an integrated internal control
environment for data.
Industry Trends ► Clients looking for a more sustainable and cost effective approach to data governance are beginning to build it into their SDLC
processes and tollgates.
► Mark Carson
► Lisa Cook
► Ryan Duffy
Chapter Guidance ► Where possible use existing processes at the client to handle data governance activities
Page 117
Implement issue management and change
management
Issue and change management are key components for program capabilities to maintain up to date procedures, policies, and compliance with dynamic regulator expectations.
► Issue Management process controls the timing, impact, and method by which issues are managed and
remediated
► Captures information regarding the issue and categorizes the identified issue based on
Issue criticality and sensitivity
Management ► Monitors progress of remediation efforts and tracks results for strategic planning purposes by
recording attributes
► Provides key metrics around issue management for the CCAR reporting program
► Ensuring that all changes to data follow a set methodology, including a change control process with
change request, review, prioritization, escalation and implementation. Changes should not be
implemented on an ad hoc basis, but rather, implemented in a controlled manner.
Change ► Corporate leaders are seeking to leverage their firm’s data resources and regulators are pursuing
Management consumer protection through regulation. In order for banks to attain a strategic advantage over its
competitors and to comply with government mandates, it is imperative to establish and enforce
enterprise-wide Data Change Management Standards. Such Standards will help ensure data integrity,
reliability and quality by maintaining controls around data located within the enterprise.
Page 118
Implement issue management
Implement an issue management process to manage issues as they are identified through metadata and controls testing, and remediate with data owners.
What is Data Issues Management?

Issues management is the proactive approach to monitoring, controlling and resolving issues as they are identified. This includes managing the issue from the point of identification, to submission,
prioritization, resolution and tracking through to the implementation of the final solution. It is also the monitoring of issues to determine repeat occurrences of issues, to determine the success of
resolutions implemented.
What is the value of Issues Management?

• Allows for the creation of management reporting views to monitor and track progress
• Meets requirements for SOR Data Owners Certification
• Future policy will state that DOs must oversee the data for their areas, which includes having a common process to monitor and track data issues
• Provides evidence to the regulators that data issues are being monitored, managed and resolved
• Provides rationale and evidence regarding issues that are not being resolved
• Defines impacts and severities across the organization
• Outlines agreed upon status definitions and escalation paths
What is a Data Issue?
Issues are not easily defined.

An issue is any significant failure relating to data in production that directly impacts the business. This could include, but is not limited to issues DGS will use reviews and engage different teams to
with data quality, data movement controls, data lineage, metadata, data integrity, regulatory and risk reporting, data reconciliation, etc. ensure that issues are validated and assigned to the
What is NOT a Data Issue? right teams to remediate
• Individual Data defects
• Business processes issues
• Data base performance issues
• System issues/defects that do not impact data, data quality or data movement controls
Page 119
Implement issue management
Define, document, and implement a process to handle issues that are identified through metadata and controls testing. This process can be integrated into existing issue management procedures, or
established separately. Impacted stakeholders and leadership should be reviewed to determine the best approach for each client.
• A “Change” is a new or changing requirement Requestor • An “Issue” is a material problem with an existing (“production” process, platform, or data set
• Changes will be structured into initiatives that must be sponsored, funded, (Corporate or otherwise) • Data Issues will be centrally logged, prioritized and tracked
prioritized and tracked by stakeholders • Requestors and stakeholders will have visibility to action plans, priorities, and accountable parties
New / Change Issue

Request Type
• Requestor will engage with appropriate Data Officer to • Issue will be reviewed for clarity, completeness, appropriateness
create a “Start Request” Issues Log • Priority and severity will be established
• Request documents problem statement, impact, scope Structure Initiative Request • Initial Ownership will be established
assumptions, dependencies, funding, and impacted groups Action Plans,
Mgmt.
across Wholesale Status, Ownership
Reporting
Updates
• Owner will define action plan and dates
• Data Officer will shepherd the request through applicable • Ownership will shift as needed based on research and validation
committees for prioritization and approvals Committee Review and Establish Action Plan • Action plan changes will be reviewed with stakeholders
• SLAs will be developed for establishing action plans (but not for issue
Prioritization Escalation as needed resolution) , and will be based on priorities
• Project lead (identified within “Start Request”) is

accountable to execute the work • Efforts will be structured and monitored in priority order
• Wholesale routines (Committees and supporting Program Structure and Execute Material work efforts • Data Officers / Committees will prioritize and act as stakeholder
routines) will monitor progress; stakeholder groups will Initiative Resolve Issue groups
manage the initiative • Portfolio mgmt. routines will monitor and report progress
• Resolution may become a project and require a start request
Page 120
Implement issue management and change
management
Issue Management process controls the timing, impact, and method by which issues are managed and remediated. The framework below is a comprehensive issue
management framework consisting of 4 components:
• Identification and Categorization

• Issue Remediation
• Issue Tracking
• Issue Reporting
Below is an overarching target Issue Management Framework to track and manage issues through remediation.
Issue Management Framework
Identification and Categorization Issue Remediation Issue Tracking Issue Reporting
The issue identification and categorization The issue remediation planning phase involves The issue tracking enables the team to track Issue Reporting enables the team to monitor
process captures information regarding the coordinating the management and remediation key attributes of issues including (but not progress of remediation efforts and tracks
issue and categorizes the identified issue of issues. limited to): results for strategic planning purposes
based on criticality and sensitivity.
The Phases include: • Issue type
Key Components include (but are not limited • Validate initial findings and perform deep dive • Owner
to): analysis • Severity
• Issue Entry – Potential inputs to the Issue • Develop remediation strategy • Escalation level
Management process • Perform source system analysis • BU/data mart/data warehouse
• Mandate / scope of issues • Cleanse dating • Expected resolution
• Prioritization • Validation fixes & monitor results
• Issue Escalation process
• Roles and responsibilities
• Controls
Page 121
Identification and Categorization – High Level Summary
Captures information regarding the issue and categorizes the identified issue based on criticality and sensitivity
Issue Entry: Potential Inputs to the Issue Management Process:

• Upstream / downstream application issues identified
• Process / business rule violation
• End user defined
• Internally identified issues
Mandate/Scope of Issues: Definition of types of issues that will be handled by the Team (i.e. there may be issues that would be more appropriate for functional
areas, etc.)
Prioritization: The task to perform a preliminary root cause analysis to asses the impact and criticality of the issue, and assigning a certain level or urgency for
resolution
Issue Escalation Process: The following information enables an effective issue escalation process by facilitating the process to notify appropriate stakeholders
and remediate issues effectively and by magnitude. Some considerations to define Governance Structure/escalation path; Severity/Appropriateness; Timeliness;
Independent Review
Roles and Responsibilities:

• Identify, assign roles & responsibility
• Central point of contact for the Issue Management Process
• Escalation considerations
• Remediation partners
Controls: Process includes the appropriate level of controls (i.e. who can view and update entries)
Page 122
Issue Remediation – High Level Summary
Coordinates the management and remediation of issues
Remediation Framework illustrated below:
Remediation Framework
1 2 3 4 5
Validate Initial
Develop
Findings and Perform Source Validate Fixes &
Remediation Fix Issue
Perform Deep Dive System Analysis Monitor Results
Strategy
Analysis
• Validate initial findings with • Identify a strategy to tackle • Analyze the source system • Based on the analysis, • Validate completion of the
business unit / functional the issue. for similar issues. perform remediation remediation actions.
area SMEs. • Determine the short term • Analyze the source systems actions per the remediation • Confirm results with
• Perform deep dive analysis and long term remediation and other toll-gates for plan. business unit / functional
and root cause analysis to plan based on the issue viability of remediation • Determine the effectiveness area SMEs. Socialize the
identify cause of the issues impact. action implementation. of the remediation through results to the users and the
Key Activities
and location of the issue. • Socialize plan with users • Incorporate additional close monitoring and executive oversight team.
and the executive oversight checks and controls to revalidation of the checks • Monitor issues at toll-gates
team capture similar exceptions. and controls. to validate fixes.
Page 123
Issue Tracking – High Level Summary
Monitors progress of remediation efforts and tracks results for strategic planning purposes by recording attributes
Issue Tracking: The Issue Management activities in-progress and upcoming remediation efforts are monitored and tracked for strategic planning purposes.
The Issue Management activities in-progress and upcoming remediation efforts are monitored and tracked for strategic planning purposes using the following
information (but not limited to):
• Issue type (activity 1 above) – allows stakeholders to investigate similar initiatives and corresponding Issue Management processes, and creates a lineage
to trace a given issue, through to remediation.
• Owner – allows stakeholders visibility to how issues roll-up to sponsors/domains and identifies the ultimate owner of the issue remediation responsible for
providing and/or overseeing the change implementation.
• Severity/impact/prioritization – allows stakeholders visibility to which issues have the highest/lowest impacts to existing systems and processes for
classification by importance and remediation prioritization.
• Escalation level – based on the severity/impact/prioritization, allows stakeholders visibility to the level to which a issue has been escalated.
• BU/domain – allows stakeholders to track the impact to BU/domains of remediation of issues.
• Age – allows stakeholders to visibility to the duration of time which issue remediation has been in-flight, or suspended
• Target resolution date – allows stakeholders to track the original planned date for the resolution to be implemented
Page 124
Issue Reporting – High Level Summary
Provides key metrics around issue management for the CCAR reporting program
Issue Reporting (Potential Types):

1. Executive Report – This report will be used to provide a consolidated view of high priority issues being addressed by the CCAR reporting team, along with a high
level summary, remediation impact summary, and escalation summary for items that require a decision by the Governance Team and/or Senior Leadership.
2. Weekly Issue Report – This report will be used to provide leadership with an aggregated view of the issues being tracked on a weekly basis (subset of the issue
tracker).
Issue Reporting (Purpose):

• Engage Senior Leadership
• Engage Governance Committee
• Monitor Progress & Report
• Identify Process Changes
Potential Metrics:
Other “summary” metrics which are enabled by the collection of issues above includes, but is not limited to:
• Number of issues per BU
• Number of issues per system
• Number of issues outstanding (in process vs. in queue)
• Number of issue remediation(s) past due
• Frequency of occurrence of issues (per type of issue)
Page 125
Integration with SDLC
Objective and benefits

Businesses have been spending significant amount of time an energy applying the principles of effective data governance to their data already in
Production
This enabler provides a methodology for integrating key Data Governance activities into a solution development lifecycle (SDLC) so that any
engagement that creates, modifies, or consumes data will proactively apply the principles of DG will deploy their solution to Production with Data
Governance principles already in place.
The contents herein is not intended to be exhaustive, so use judgment to determine an appropriate approach.
How to use this tool/enabler
Refer to the guidance in the subsequent processes.
When to use this tool/enabler
Use throughout all phases of Identify, Diagnose, Design, Deliver and Sustain, when a project plan is to be presented.
Document details
Last Updated Date 20-Feb-2015
Document Version V10
Point of Contact M. Carson / K. Cardoso
Page 126
Methodology
The following pages provide details on steps and artifacts for each SDLC Phase.
• Data impact is measured and

Investments are prioritized
• Governance Engagement
Questionnaire, Prioritization Charts,
High Level Roadmap
• Governance activities are performed, Sustain
certified and improved
• Post-implementation Reviews, Change Identify
Control, Improvement Plans • Level of governance involvement is
assessed and estimated
• Impact Assessment, Scope of work,
Agreed issues, Roadmap, Initial Cost
Deliver estimates
Diagnose
• Implementation aspects are planned,
tested and executed
• Technical Design Document, • Governance standards documented as
Deployment Plan, Testing Results, Design requirements and specifications
Delivery Artifacts
• Business Requirements Document,
Functional Requirements Document,
System Requirements Specifications
Page 127
Identify
During the Identify Phase, the data impact is measured and investments are
Sustain
prioritized
Identify
• The Line-of-Business Leads assess the needs driving the project and the data impact it can have,
identifying the domains and processes affected by the it
Deliver
Diagnose • These results must be presented to the Executive Committee who selected which projects get tentative
funding and are approved to proceed
Design
• The Line-of-Business Leads foresee and document pre-engagement planning activities associated with
data governance that must be reflected in Prioritization Charts, High Level Roadmap, and Client
Engagement Charter
Governance Engagement Questionnaire
Page 128
Diagnose
During the Diagnose Phase, the level of data governance involvement is
Sustain
assessed and estimated
Identify
• The Project Manager completes a detailed assessment questionnaire to determine whether or not the Data
Governance Organization involvement is needed, and at what level
Deliver
Diagnose
• If involvement is deemed necessary, the Data Governance Organization educates others on efforts needed
to achieve compliance, and becomes a mandatory approver for all SDLC toll gates along with other
Design
stakeholders
• Data Governance aspects are then incorporated into initial artifacts such as summary of the Impact Assessment,
Scope of work, Agreed issues, Roadmap and Initial Cost estimates
Impact Assessment Document
Page 129
Design Phase (1 / 3)
During the Design Phase, data governance standards are documented as

Sustain
considerations to requirements/specifications
Identify
• The Business Analyst works with the Data Governance Organization to documentthe list of data governance
standards that the project must comply with, across various data management disciplines
Deliver
Diagnose • The compliance with those standards may be prioritized on the basis of its business impact
Design • The list of applicable standards is documented at the Business Requirements Document, as part of an
additional ‘Governance Business Requirements’ section that includes various data management disciplines
Business Requirements Document Continues on next page
Page 130

Sustain
Identify
• The Business Analyst translates the list of data governance standards into the effects to be achieved by the
system, or the required features for achieving those effects
Deliver
Diagnose
• Features are documented as high-level descriptions of what is needed for an optimum feasible solution,
omitting any design or implementation details on how is to do it
Design
• The list of features is generally documented at the Functional Requirements Document, as part of additional
‘Governance Functional Requirements’ section, but can be incorporated by the Business Requirements
Document or System Requirements Specification
Functional Requirements Document Continues on next page
Page 131

Sustain
Identify
• The Lead Developer or Architect translates the governance functional requirements into formal design
notations on how the system is to do it
Deliver
Diagnose
• Features are defined as use casesand include screen mock-ups for conceptualization of each functionality, and
non-functional requirements are also incorporated
Design
• Both are documented at the System Requirements Specifications, and can also be reflected at Updated Costs
estimates and Release Plan schedules
System Requirements Specifications Continues on next page
Page 132
Delivery Phase
During the Delivery Phase, implementation aspects of the data governance

Sustain
standards are planned, tested and executed
Identify
• The Architect and Developers translates the design notations into formal implementation specifications, while
the Delivery Manager translates it into a implementation strategy
Deliver
• Governance-related data is incorporated into conceptual and logical representations of entities and relationship,
Diagnose along with governance-driven implementation details which are documented at the Technical Design
Document, sometimes called Technical Design Specifications
Design
• The Delivery teams to plan and execute the project, including test and integration activities, assessment of
expected vs. realized objectives, escalation & resolution of deployment issues, and exit criteria as part of
Deployment Plan, Testing Results and Delivery Artifacts
Technical Design Document
Page 133
Iintegration with SDLC
Sustain Phase
During the Sustain Phase, the planned governance activities are performed,
Sustain
certified and possibly improved
The Line-of-Business team executes day-to-day governance related activities in the production
Identify
•
environment, ensuring that the implemented design operates as intended
• Performance gaps are identified through on-going monitoring, and addressed through remediation and
Deliver
Diagnose production-support activities, as part of Post-implementation Reviews, Change Control and Improvement
Plans
Design
• The Data Governance Organization is responsible for post-release certification activities, while the Line-of-
Business team is responsible for training activities and artifacts
Final Operational Document
Page 134
Execute Data Quality
Page 135
Execute Data Quality
► The objective of a Data Quality (DQ) playbook is to provide an end-to-end process for improving confidence in a client’s data quality
health. This is done by creating and executing fit-for-purpose data quality rules, measuring the “DQ Health” of the data through concise
Definition metrics and remediating data quality issues (e.g. establishing controls) to achieve complete, consistent, accurate, and timely data for
critical business functions within the client’s organization.
To address at a minimum the following common issues:

► Poor business decisions based on data duplication and inaccuracies
Business Benefits ► Loss of investor confidence due to misleading data, raising questions on the validity of financial and business reports
► Missed revenue (cross-sell / up-sell) opportunities and increased costs attributed to compromised data
► Increased workloads, process times, resource requirements to address data issues
Industry Trends the context of BCBS 239 and CCAR. This has emphasized the need for data governance capabilities including evidence of data quality
measurement routines.
► Bilal Khan
► Alexander Tsinman
► Kiet Pham
Key Contacts ► Srikaanth Santhanam
► Pradeep Karunanidhi
► Eric Fisher
► The effectiveness of the any data quality program will depend on the type of data quality program implemented, maturity of the data
governance and IT functions within the organization, and business drivers driving the implementation. Following the end-to-end
Chapter Guidance framework (described in the playbook) allows for clients to establish an repeatable process to measure data quality health that can be
applied across the enterprise.
Page 136
Source Data & Domain Activation
Page 137
Data Sourcing
► Systematic data sourcing is a planned approach for placement, delivery and consumption of shared information for specific business.
Definition ► Data sources are designated as authoritative data sources (ADS) through a comprehensive process of governance and approval.
► Enables accountability and transparent paths for locating data for specific business needs
► Configures a platform for unique sets of data by removing duplicate data from the data footprint
Business Benefits ► Influences all data sourcing decisions
► Prioritizes consistent and simple data governance including lineage, metadata, policies, and procedures
► Traditional data sourcing functions are being challenged by the regulatory expectations to establish overarching control environments
and end-to-end data supply chains that integrate data management.
Industry Trends ► Institutions have established clear processes and procedures in the identification, designation, and use of authoritative data sources to
provide understanding and accountability for the data used both internal and regulatory purposes.
► Saurabh Agarwal
► Mark Carson
► Jeff Harmon
► John Bell
► Lisa Cook
► Vamsi Illindala
► Ryan Duffy
► This playbook can be used to discuss the need and purpose of a governed ADS program as well as an accelerator for establishing and
Playbook Guidance deploying ADSs within an organization.
Page 138
Activate Domains
► A Data Domain is a logical grouping of data elements based on shared characteristics and context that facilitates management and
Definition governance.
► Data domains create a common understanding and usage of data across lines of business, business processes, and systems.
► Traditionally, data is managed at the LOB level, with shared data managed across multiple LOBs data domains enable accountability
and responsibility for shared data that is typically fragmented across multiple owners.
Business Benefits ► Data domains provide a structure for data elements that creates common definitions for business concepts and data elements,
preventing data elements from being defined differently across LOBs.
► The data domain concept has been widely adopted across financial institutions of all sizes. A common structure for data elements,
roles, and systems to align to has created transparency and accountability at an enterprise level.
Industry Trends ► Single data elements are governed and managed by a single Domain. Critical roles and responsibilities are assigned at the Domain
level, including a Domain Owner (Executive) to manage the domain.
► Mark Carson
► Lisa Cook
► Ryan Duffy
Chapter Guidance ► A detailed process for domain activation can be seen in the domain activation playbook.
Page 139
Capture & Test Metadata
Page 140
Capture Metadata – Factory Approach
► The objective of the Metadata Factory Playbook is to provide an operating model and set of core procedures and standards to facilitate
Definition the collection of metadata for a report, data domain, or data process.
► Using the metadata factory approach to collect metadata will result in the following benefits:
► Establish a repeatable and scalable process by using a standardized execution model and blended team of onsite and
offsite resources.
Business Benefits ► Maximize efficiency through standardized subject matter expert (SME) engagement, providing minimal disruption to
business as usual (BAU) activities.
► Standardize outputs which integrate seamlessly with any number of enabling technologies.
► The primary business driver for documenting and maintaining metadata has been demonstrating control to regulators, specifically in
the context of BCBS 239 and CCAR. Management must have confidence in the accuracy of information reported internally and to
Industry Trends regulators by understanding how data is sourced, transformed and reported.
► The secondary benefit will highlight opportunities to improve the quality of data, streamline sourcing, and reduce the number of manual
processes executed in the reporting supply chain.
► Mark Carson
Key Contacts ► Patrick Shannon
► Jesse Blue
► The metadata collection approach will vary by the institution’s size, level of maturity, and complexity of data environment and should be
tailored as appropriate.
Chapter Guidance ► The Metadata Factory Playbook will later be enhanced to include the testing of metadata accuracy and BAU maintenance processes.
► Please see Metadata Playbook for additional details.
Page 141
Test Metadata and Controls
► Testing is used to demonstrate quality of the metadata, validate controls for operational and design effectiveness, and perform data
Definition accuracy testing where inline accuracy controls are not evident. Testing provides a mechanism to verify data lineage from System of
Record/System of Origin to the end reports.
► Testing validates the data control environment and identifies defects within a sample population.
► Addresses regulatory requirements on accuracy and reliability of data used to create critical report.
Business Benefits ► Provides management with a point of view on the efficacy of the reporting control environment.
► Provide the firms with sustainable and repeatable testing approaches for design effectiveness and operational effectiveness of data
movement controls.
► Regulatory requirements tied to governance (BCBS 239, CCAR, Liquidity, etc.) have raised scrutiny on data control environments,
necessitating an ‘end-to-end’ testing solution for key data supply chains
Industry Trends ► Organizations are looking for ways to maximize coverage of testing, while optimizing the balance between tools/automation and more
costly, labor-intensive testing.
► Tripp Harris
Key Contacts ► Saurabh Agarwal
► John Bell
Chapter Guidance ► Reference the Data and Controls testing playbook for detailed approaches for testing design, execution, and reporting.
Page 142
Next Gen industry trends and
market demands
Page 143
Evolution Of Data Strategy
Next Gen – industry trends & disruptions
New Digital Volume and Need for Diverse Data

Channels velocity Automation Ability to store and process diverse data types that include
unstructured / semi-structured data and leverage
Business Challenges
Traditional batch processing and As volume and velocity of data Increased automation is replacing technologies like Optical Character Recognition (OCR)
reporting of data is inadequate in increases, the traditional methods manual data processes which are
meeting the real-time information of periodic data integration and still being assessed and optimized
requirements for the new digital prioritization becomes impractical across the enterprise
channels Data Lake Based Platform
Ability to scale infrastructure on-demand, while making it
Emerging Omni-channel Data External
Next Gen Solution Spectrum

cheaper in the long run (i.e., cloud)
Technologies Delivery Exposure
Data Management organizations Traditional ‘off-line’ data Current information access
are being restructured to include a management and data quality requirements may no longer be Next Gen Data Management
correct mix of resources in legacy processes are unable to keep sufficient or applicable due to
and emerging technologies pace with new demands of omni- increased exposure to external Ability to perform real time Data Management through AI /
channel instantaneous data delivery entities Machine Learning based technologies
Enterprise Wide Data Delivery

Ability to report out and analyze significantly more
 Expanding scope beyond Risk & Regulatory  Increasing pressure to reduce cost and eliminate
Industry Trends
historical data and additional types of data for better

agendas to include additional data types, which fatigue associated with traditional manual data
includes semi-structured and unstructured data management business insights through self-service platforms
High Speed Computation Engines

 Investing in skill development and talent  Embracing new technologies and architectural
acquisition to meet demand for new technologies patterns: cloud first mindset, move towards big Ability to perform real time change data capture and data
and capabilities data environments, focus on security, reduction transformation
in manual activities, introduction to Fintech
Page 144
What is Next Gen Data and Its Capabilities
Next Gen Data is a new Data Management approach that leverages advancements in technology, storage, cloud, and Machine Learning capabilities to
process more quantity and types of data, empowering more users with self-service, and yet maintaining transparency and auditability of data.
► Data lake based architecture is robust and AI / Machine

► AI enabled real time Data Management, in
Data Lake
scalable; ensures full fidelity of source Based Platform Learning Based line data quality, dynamic data mapping,
data in an immutable zone, and can be Data Management tagging, indexing, data cataloging, and
deployed on hybrid cloud/on-prem provisioning
infrastructure ► Support for Curated data sets and Enhanced
► Supports Multi speed data processing, audit trails and lineage
Microservices, and advanced data security
Next Gen
Data ► Provides support for structured and
Enterprise Diverse semi-structured, and unstructured data
Wide Data Data
Delivery (such as, signal, social media, voice /
speech, text, web logs, encrypted packets,
etc.)
► Data made available to the enterprise
through self-service analytics and High Speed
reporting, advanced visualization Computation
Engines
capabilities, virtualization, and context ► Connected streams (pushing data in real time
based data delivery and ensuring latest data being consumed in the
event of change in state of data); centralized
business rules ensures data transformations
are applied on the data in real time
Page 145
Legacy Architecture v/s Next Gen Architecture
While firms have desired an integrated risk and finance architecture for many years, legacy technology constraints have made this challenging to
achieve. Advances in new technologies like low cost cloud based infrastructure and machine learning have made such an architecture possible.
LEGACY ARCH. NEXT GEN. ARCH.

Traditional warehouse based architecture
Data lake based architecture with unified
with numerous hops, rigid data model, and
sourcing and consumption, flexible and
manual processes
iterative data model, supported by
automation
Implementation duration of ~24+ months with expensive and Reduced cost due to rapid development with quick iterations
lengthy future changes having duration of weeks to months
Data management is “offline” with many manual components Improved insights as data is processed (inline) with continuous
learning and improvement
Does not support semi and unstructured data increasingly relevant Support for all data types with potential to unlock data not yet
for data enrichment and analytics utilized (e.g., loan origination processes, call log transcripts, etc.)
Vertical scalability to enhance data processing capability has Ability to scale horizontally, relatively cheaply and without any
become cost prohibitive limit, and on demand
Primarily suited for batch-oriented use cases (i.e., reg. and

Supports multi-speed batch-oriented and real-time use cases
management reporting)
(e.g., fraud detection)
Page 146
Next Generation Data Value Proposition
Initial investments in infrastructure and foundational capabilities are more than offset by the decommissioning of warehouses and / or deceleration in
spend. Real value is unlocked by progressing from the bottom of the pyramid to the top where analytical capabilities are enabled to generate real
insights.
Value Proposition Enabling Capabilities

Value is unlocked from the investments by Discovery & Insights: Revenue Growth, Enhanced Client
developing analytical capabilities that derive Experiences, Product & Channel Evolution
insights to drive action
Machine learning, Cognitive Analytics, Advanced Modeling
VALUE
Executive Simulations
Insights
Cost savings are realized from Reports &

Dashboards
Business Intelligence: Reporting, historical trend
decommissioning / arresting the analysis & forecasting
Information
growth of legacy systems
consumption Ad-hoc queries, Dashboards and Scorecards
Analytics
Platform
Data Data Integration Data Provisioning Data

Storage Usage
Infrastructure & Foundational Capabilities: Scalable &

Data
Security , Secure Platforms, Managing Data as a Corporate Asset
Investment in the Next Gen Data
INVESTMENT
Quality,
Risk
platform establishes the foundation Robust Data Management & Governance, “Fit for Use”
Data Ecosystem
Data Management &
Data
Creation Governance Data
Retirement
Page 147
Next Generation Data Benefits
Unlock business value, increase adoption and lower cost
*
**
* Based on Industry Case Studies ** As per Gartner, Forrester and IDC reports
Page 148
Next Gen Data Architecture
and Use Cases
Page 149
What’s different about Next Generation Data
Traditional Enterprise Data Warehouse (EDW) Vs. Data Lake
Data Sources Data Integration Data Storage Data Integration EDW Targets
EDW ARCHITECTURE
Structured Data
Integrated
Batch | Near Real Time | Real Time

Batch | Near Real Time | Real Time
Sources Landing Staging Enterprise Data Warehouse
Data Hub
Reporting
Enterprise Data
Origination Systems Warehouse
Target Data Third Normal
File Type Form
Type
Transactional Platforms
XML 3 NF 2 NF Dimensions Dashboards
ETL
ETL
Cloud Platforms
TXT / DAT
MDM Platforms No Relationships Relationships
CSV Stage Enforced Enforced Data Warehouse

Augment
Data Marts
Operational Data Platforms Pre-Process
Other Master / Reference Data
Compute Offload
EDW / DW Archive Offload
Deep Exploration
Data Marts DQ Dashboard
Business Process Data Business Reporting Data

Data Mapping Modeling Modeling
Data Ingestion Governance

Data Sources Data Storage Semantic Layer (Optional) Targets
Framework
ARCHITECTURE
Enterprise Data Lake

DATA LAKE
CCAR Self Service Platforms

Meta Data Tagging
Structured Data
Sources
Customer … Legacy BI Platforms
Data
HDFS / Batch Analytics
Unstructured Data
Sources
Transactions
…
Snapshot HBase / Speed Visualization Platforms
Other
Granular Data Reporting
Page 150
Chandra
CFO Insights
Integrated dashboard enables users to analyze financial performance and resource constraints across enterprise hierarchies and planning scenarios and horizons
Scenario Horizon
Actuals Monitoring Short-Term Long-Term
Daily/Monthly 1-5 Days 30-90 Days 12-24 Months

Financial Measurement
Scenario Analysis
• Net Income • ROE / ROA
Profitability
• RaROC / EVA • EPS
Performance
• Efficiency Ratio • Net Interest

Efficiency
Scenario Condition
• Operating Margin Margin Trend Analysis Comparative Analysis Scenario Analysis
Baseline Scenario
Stress Scenario
• Revenue Growth • RWA
Growth Growth
• Earnings Volatility
• RWA Sensitivity Analysis What-if Analysis Anomaly Detection

Capital • Leverage Exposure
Constraint
• CET1 Ratio
• HQLA • LCR Ratio

Funding
• Unfunded Commitments
Early Warning Predictive Modeling Pattern Recognition
Customer Product Business
Channel Geography Investment
Dimension
Page 151
CFO insights
Design a consolidated platform strategy integrating internal and external data sources to enable fluid diagnostics and actionable business insights
• Executive dashboard collates analysis of firm’s

current and projected performance, resource
allocation, and competitive landscape
• User employs filtering and click-through

capabilities to analyze comparative performance
of investments, products, and businesses
• Snapshots of market structure and growth predict

returns to engagement and distribution strategies
and diagnose emerging risks
• Data architecture supports consistent data sourcing

and enrichment across management, business, and
regulatory applications
Note: Dashboards are for illustrative purposes only and all figures presented are hypothetical
Page 152
Insurance FRAC Solution
An actuarial focused data management and reporting solution based on the EY FRAC architecture, showcases a end to end data management cycle to
support actuarial reporting on a next gen platform
Hardware/Software
What was the need ?
Platform :
► Life insurers typically use multiple modelling platforms such as Polysystems, Moses,
► Azure HD Insight ( 4 Node Cluster)
GGY AXIS and Prophet. An common reporting solution external to these modelling
systems is therefore a valuable solution
Components:
► However, due to distinct target operating models, and little experience with new ► Apache Spark (2.1.1) ► Scala 2.11
platforms, “end to end” implementations have been scarce and they will continue to ► Apache Sqoop ► Java 1.8.0
have disparate systems until they see viability in an “end to end” vendor solution ► Hive on Tez ► Python 2.7.12
► This would mean data would exist in different formats in different systems for some ► Tableau ► IntelliJ IDEA
time which calls for a solution that would help hold things together and create an ► MySQL ► Ambari
integrated environment for actuarial data and reporting
The Value Proposition:
How does LIRA help actuarial functions at life insurance companies
► Demonstrates the workings of an effective solution for actuarial

reporting
► Helps communicate actuarial system needs to key stakeholders
► Aides in the identification of gaps and weaknesses for targeted
improvement
► Provides a significant jump start for implementation of an actuarial
environment
► Components are plug-n-play allowing for customization and alignment
with company’s toolset
LIRA an effective solution framework for Life Actuarial data and reporting needs
Page 153
Chandra
Next Gen Data Applications
Artificial Intelligence and Advanced Analytics
► Big Data is the foundation of Next Gen Data and enables Next Gen data applications such as AI, Machine Learning and forms of Advanced Analytics (e.g. Predictive Analytics) – technologies that
were once inaccessible using traditional data architecture
Overview of AI, Machine Learning and Predictive Analytics
Predictive Analytics is a form of Advanced

Artificial Intelligence (AI) is defined as the science
Machine Learning (component of AI) is the ability Analytics that leverages data mining, statistics,
of making computers do things that require
of computers to self-learn using statistical and modeling, and artificial intelligence to analyze
intelligence or reasoning when performed by
optimization techniques current and/or historical data to predict future
humans
events
How Big Data Enables AI, Machine Learning and Predictive Analytics
AI & Machine Learning Platform Advanced Analytics

Data Sources Big Data capabilities such as high volume storage and
Big Data supports new data types that were once schema-on-read data access allows AI platforms to flexibly Big Data allows the storage, processing, and
inaccessible, which allows AI and Advanced access massive data sets in real-time. access to large volumes of unstructured data,
Analytics to leverage more sources of data to
which is required by Predictive Analytics to
drive business value.
analyze data to predict future events.
Big Data Platform
Page 154
EY’s Strategic Capability Development
Artificial Intelligence and Advanced Analytics
Page 155
Sampling of Case Studies
Page 156
Assisted a large global bank in creating their global credit risk modeling
capabilities using a big data ecosystem on the cloud
Chandra
1 Client opportunity / challenge

The client need to simplify and enhance credit risk modeling capabilities in reaction to the increased need of a controlled data environment to perform analysis across four prioritized geographies. The client’s current approach involved sourcing data from various
sources and performing analysis on this data with limited controls. EY assisted the client with standing up a GCP/AWS cloud environment that included integrated, model ready data with data quality enforcement along with other controls.
2 Illustrative artifacts
Business Methodology Cloud DevOps Model Data Classification Process Semantic Layer Approach and MVP and Sprint Framework
Metadata Framework
3 EY approach / innovation 4 Outcome and benefits

EY took the following approach to implement a GCP/AWS cloud environment: ► Provided an optimized data cloud experience through a commercially viable solution
► Extended the current batch use cases by adding additional functional and non-functional features through building user stories for use cases that is scalable for additional depth of data for prioritized geographical locations
► Assisted in defining an operating model to roll out the future releases of the architecture across priority use cases ► Provided data quality enforcement and metadata tagging
► Performed technology stack evaluation of the messaging systems, in-memory grids, etc.
► Assisted with the program delivery, change management support, architecture and data governance
► Defined and designed scalable platform architecture for priority geographical locations
► Created a training on MVP methodology for BAU and identification of talent for BAU teams
Page 157
Assisted a large mortgage GSE in modernizing their enterprise data platform by
architecting and implementing a big data lake based ecosystem
Chandra

The client was looking to update its manual accounting process for non-pooled assets, which lacked asset-level accounting details and created a labor-intensive process that was not auditable and prone to error. This resulted in a “disclaimed” audit opinion from
the Office of Inspector General (OIG) for four consecutive years. EY engaged with the client to automate and streamline accounting for non-pooled assets. The resulting solution was a data architecture that provided a sub-ledger at the business event level.
EDMC Maturity Model and Capabilities Framework Objectives Ent erprise dat a management
Support partners
oProgram management Program office oTraining and communications
Data Management Strategy Dat a gover nance Dat a management Dat a qualit y Dat a ar chit ect ur e Dat a usage Information security
Descr i bes how data wil l be col l ected, stor ed, Exami nes compl eteness, val idi ty, consi stency, Deter mines the over al l conceptual , l ogi cal and o Information security policy definition
Sol uti ons that i ncl ude defi niti ons ar ound data managed and di str i buted for al l sol utions i n the ti mel i ness and accur acy of enterpr ise data as it physi cal vi ew of the enter pr ise. Defi nes Under stands business obj ecti ves and goals to
DM Goals Corporate Culture Governance Model DM Funding Requirements Defining organization's vision and owner shi p, standar ds and pol i ci es. Al so ar chi tectur e. Includes defini ng str ategi es ar ound moves fr om sour ce to r eporti ng. Defi nes data standar ds and pol ici es on al l ar chi tectur e defi ne how data wi l l used for r epor ti ng and o Information security standards and
Lifecycle includes pr ocesses and pr ocedur es for the metadata, r efer ence and master data management enr i chment and enhancement str ategi es to components i ncl uding sol uti on suppor t anal ysi s acti viti es for al l functional ar eas governance
overall strategy for data cr eati on, movement, usage, stor age, and how best to ar chi tect the data consoli dation addr ess any issues with well defined contr ol r ecommendati ons, impl ementati on patter ns and including management, financial, oper ational and o Access and entitlements
Total Lifecycle Cost of Data Requi rements r etention and di sposal of infor mati on. poi nts. poi nts. common ser vi ci ng. r i sk.
Strategy & Obj ecti ves Al ignment Governance Structure Governance Implementation o Data protection system security operations
Ownership Defi niti on management, approved and
adopted by stakeholders. Organizational model Metadata management Data profiling and analysis Conceptual data model and design patterns Analytics and data mining
Data Management Pri oriti es Communi cation Strategy Organi zati on Model Human Capi tal Requi rements Business Case Operati onal Impact
o o o Data profiling strategy o o

Data Lifecycl e Organizational structure
o
Metadata strategy
o Data profiling design and o
Logical data modeling management
o
Analytics strategy
o
Conceptual data model management
Data Management Scope Oversight Measurement Fundi ng Model
Management
o
Roles and responsibilities o
Metadata design and development
Metadata operations
o
development o Data-sharing patterns
o
Analytics design and development
Infrastructure
o
Governance routines o Metadata vendor management
o
Data profiling operations
o
Analytics operations
Enterprise architecture governance
o
o
Logical data model Analytics vendor management
Regulatory control and monitoring
Data lineage services
o
Data profiling vendor management
Data profiling tool evaluation
o o Tool evaluation o Data retention services
Data Management Operations Determining organization Standards and policies Reference and master data management
o Rule validation services
o
Logical data model management
Relationship management
o Physical and logical design standards and
services
structures, and managing the Cleansing Reporting and scorecarding o Hardware and infrastructure development
Standards and Procedures Data Sourcing components associated with the
o o Reference data definition
o
Physical data model
o and deployment and support
Accountability policy o Customer and client data services
o
Root cause analysis services
o o
Reporting strategy
implementation of data
o Data quality standards o External data acquisition
o
Issue management services Physical data model management
o
Reporting design and development
Areas Promulgati on
Busi ness Process and Data Data Dependenci es Ontol ogy and Busi ness Data Change Data Sourcing Procurement & management. o Metadata standards
Data cleansing tools and methods Services
o
Reporting operations
Fl ows Li fecycle Semantics Management Requirements Provi der Process
o Data provisioning standards Controls o
Reporting vendor management
o Data movement standards
Data movement and protection
o o
Tool evaluation Change management
o Reference data standards
o o Data management control definition
o
Data modeling services Management reporting services o Data requirements in software development
Platform & Architecture o Unstructured data standards
o
Application/information integration/services
o Data management standard services life cycle
o
Software delivery life cycle
Defining the technical Data transformation services (framework, maturity model) Quantitative analysis
Key data elements standards
o Security assessments & services
integration
o Data source certification services
o Data requirements in project management
life cycle
Platform and Integration Architectural Framework requirements and architectural o Unstructured data services o
framework for integrating data into Data warehouse and data marts
Enrichment and enhancement
o Business process modeling service o
Cross business analysis services
Processes and procedures
o Data quality monitoring strategy
o
(standards and governance)
Predictive and trend analysis services
Data Management Platform Appl icati on Integrati on Release Management Historical Data Archi tectural Archi tectural business processes.
o o Data quality scorecard design and Data logical modeling services Risk management
Standards Approach o Change management and
o
Data warehouse strategy development
Alerts and notifications o Risk appetite
communication processes
o
Data warehouse design and development o Data quality scorecard operations o Regulatory standards
o Planning and budgeting processes
o
Data warehouse operations
o Standards o Data monitoring services
Data Quality Data Management Support Process Areas o Resource allocation process Data warehouse vendor management
Data quality incident management
o o Exception triggering process
o Issue management process Standardize design, development and
Data Quality Assurance Data Quality Framework

Determining the approach and o Remediation process Operational data stores and
implementation of data architectures Audit
Data management audit strategy, planning,
measuring the effectiveness of systems of record o
execution and reporting
processes that ensure timely o Design and development o System of record for data audit issues
Data Profil ing
Data Qual i ty
Data Qual ity Strategy Devel opment Confi gurati on Requirements
Ri sk Management delivery of accurate, consistent, o Operations
Assessment Management Management
complete data. o System of record services
Data Quality for Business act ivit ies
Data Cl eansi ng Data Quality Measurement and Analysis
Integration
o Provide oversight of local governance of o Operate and maintains local data platforms (e.g., o Identify key business metrics o Implement and design local platforms o Consume data and drive reports and Compliance
key data systems of records, data marts) o Measure and remediate data quality o Provide interoperability of the local analytics o Data privacy policy and standards
o Execute enterprise policies and o Provide local metadata platforms o Manage local reporting and analytics o Data retention policy
standards platforms
Business Event Level Data Architecture Data Quality and Governance Framework Enterprise Data Management Target Operating Model

EY assisted the customer with a multiyear, multi-phased implementation — deploying a multidiscipline, diversified team (on-site, near shore): ► Completed loan-level forensic analysis, accounting policies and procedures
► Defined the data strategy and implemented the future state road map for non-pooled asset data ► Established a “single source of truth ” for all non-pooled assets data serving all
► Designed and implemented canonical data store for standardizing and rationalizing mortgage servicing data from multiple sub servicers, including the forensic downstream applications
reconstruction of historical positions and business events ► Enabled the client to get the consistent view of data across different functional areas
► Designed and implemented centralized rules driven accounting event generation and subledger application that supports multi-basis accounting ► Provided a sub-ledger self-serving reporting option that helped business users quickly
► Designed a financial data mart and enabled self-service reporting visualize data and generate actionable business insights
► Assisted with account reconciliations, financial statement analysis and acted in an audit liaison role
► Supported financial platform modernization
► Supported loan-level forensic analysis
Page 158
Assisted a global insurer in building a global data analytics platform to
achieve strategic goals

The client has embarked on an ambitious multiyear global program to deploy a Global Data Analytics Platform (GDAP) to allow the divisions across the globe to deliver on the promise of their Strategic Agenda for growth, optimization and excellence . In the past,
the client has struggled to gain valuable insights from their data and analytics due to fragmented and inconsistent platforms, tools and lack of governance . GDAP will deliver a consistent pattern of platform, tools and capabilities on the Cloud to power Analytics,
Exploration and Discovery by Data Scientists to help achieve their strategic goals.

Developed a templated design to enable a “develop once, deploy multiple times” approach enabling a platform in each division with several components to support ► “Minimum viable product” for global teams to access a standardized development
infrastructure, network, information security and governance. The key requirements were: environment
► Delivered a basic (foundational) analytics platform to enable analysts to develop models ► Standard set of templates that package together analytics and data tools in a “data
► Produced an analytics platform design that enables a longer term future-proofed, consistent solution globally to support the Hub and Spoke model container”
► Streamlined analytics model deployment and the generation of insights ► Analytics team gained ability to manage and productionize models using a
“deployment factory,” reusable frameworks
► Created a global governance framework and operating processes to allow a consistent approach to analytics across divisions
► “Data container” for analytics development, deployment, and other enterprise
► Designed a target state data container to support the analytics platform; the reference design can then be used by the divisions to setup data platforms and
initiatives
maintain global consistency
Page 159
Assisted a large US life insurance company in building its data and
analytics organization to help the company achieve strategic data goals

The client has embarked on an ambitious multi-year global program to set up their Business Intelligence Center Of Excellence (COE) to provide enterprise BI solutions. The client was not certain of the best approach to build a large volume of reports all of which
were critically needed and there was heavy reliance on business domain specific reports and excessive time was spent on rework and repetitive tasks for BI. The client asked for EY to provide BI and reporting capabilities to the client. This included deploying a
cloud BI solution using Birst, Exasol — in-memory database and Amazon Web Services (AWS), gathering reporting requirements, performing reporting rationalization, building a sematic layer, and building reports across lines of business
Building Semantic Layer in Birst Business Requirements Document Kanban Method of Prioritization Report/Dashboard Creation

EY assisted in the BI COE implementation with the following approach: ► Better collaboration between Business and IT helped lower capex and opex costs
► Developed a COE operating, governance, rationalization, and prioritization framework to drive synergies across business functions ► Promoted increased client adoption of agile and adaptive platforms with an ability to
► Prioritized reports from 14 business functions and conducted report rationalization connect to data for streamlined communications, collaborations and decisions
► Built a report inventory comprising approximately 1000 reports ► Enabled client to rationalize and re-evaluate reporting needs
► Defined tactical and strategic business and functional requirements to generate reports ► Created enterprise data solution and enabled single source of truth across business
► Defined Implementation framework for each of the Agile teams and created Agile PODs functions operating in siloes
► Created a robust and scalable star schema data model and developed a semantic layer design in Birst, encompassing all the in-scope business function ► Unified semantic layer allowed client to leverage existing data models for self-service
BI capabilities
Page 160
Advised a retail brokerage firm in creating their next generation data
architecture and platform for regulatory reporting
Chandra

EY was engaged to establish a foundational Next Gen Data architecture platform to support report filing (i.e., FR Y9C and FR2052a) that were previously filed manually and to support future risk and reporting functions in the future.
End to end data lineage
Data architecture Tool-based development End-to-end lineage

EY assisted the client to develop a supporting architecture providing end-to-end delivery from strategy to implementation including full SDLC: ► Comprehensive common data platform to support all regulatory reporting needs
► Designed strategy to develop foundational data architecture with the following: ► Foundational platform for finance and risk reporting and analytics
► Metadata and governance-based ingestion layer ► Enhanced data quality and insights value
► Semantic-based data distribution/vending layer ► Flexible extendible data lake capable of integrating with action based applications
► Designed and built Hadoop data platform on Cloudera distribution ► Ability for easy integration of additional sources
► Implemented architecture for client and assisted in updates as needed ► Ability to leverage machine learning in data integration/ingestion to create metadata
► Assisted in planned test filing and parallel run for one quarter and cutover and data mapping
Page 161
Appendix:
Next Generation Data
Reference Architecture & Tools Landscape
Page 162
Next Generation Data Reference Architecture
Solution Building Blocks
1
Data Enterprise Data Architecture Access
Source /
5 Data Management
Deliver
DG Standards and API Gateway & Metadata Common Exception y
Data Quality Audit and Balance Control Framework Security and Privacy
Policies Orchestration Management Handling
Structured Collaboration
Streaming Data Distribution Analytic &
Data
Supports data transfer and processing at a steady, high-speed rate and Provisioning Operational
Applications
2 Data Ingestion 3 4 Standard Reporting
Data Transformation and Storage Semantic Layer
Ad-Hoc Analysis
Data Lake Visualization
Virtualization & Web
Data Repository Data Wrangling Services /
Calculation Engine Federation
Modeling / Data Portals
Data Data Exploration / Data
Acquisition Ingestion Harmonized Conformed Analytical Data Delivery
Semi- Data Discovery
Raw Layer Layer Layer Layer
Structured Warehouse In Memory Computing
Data Self Service Enterprise Search
Discovery and Exploration
Data Marts Virtualization
Cataloging | Integration | Transformation | Curation |
Data Tagging | Data as a Service
Preparation Appliances Search Mobile
Indexing Artificial Intelligence
6 Shared Operational Data

Operational Control
Master Data Reference Data Integrated Rules Metadata Learning Patterns
Metrics
Unstructure
d Data
7 Data Transfer
Applications
Asynchronous Batch Control Common Exception

API Gateway Synchronous Services Event Management
Pub/Sub Services Management Handling
Key Data Data Store Processing Engine Function Machine Learning Capable
Page 163
Data Management Framework & Architecture – Data Lake
Data Management
Data Quality | Integrated Rules Service | Meta Data | Security & Privacy | Data Governance | Administrative Services
Common Exception Handling and Logging (CEHL)
Data Sources Data Production Layer Data Virtualization Layer Data Consumption Layer
Enterprise Data Lake Advance Analytics Applications
Structured Data Sources Composite Views (CV)
Ingestion Certified Data Stores
Customer Segmentation Business Banking Campaign Management
Landing In Memory

Operational Data Certified Data Store Single Subject Areas
Raw Data 
Credit Payment Proxy Digital Analytics Risk Profiling
 Customer
Product Profitability Risk Analytics Fraud Analytics
Data Quality (Technical & Business) | Matching | Metadata Tagging | Catalog | Certification
Master Data

Product

Events/ Message
Data Services (Format, Transfer Protocol, Frequency, Terms)
Customer, Account, Consuming Applications

Event Product, Transactions,
Reference Data  GL, Loans, Channels,  Front-Office Systems Accounting & Finance Systems Data Warehouse
Data Services (SOA / ESB / Vending Patterns)

 Sales, Credit 
Insurance,

Middle-Office Systems HR / Audit / Compliance Systems External

IB, etc.

Staging
Back-Office Systems BI / Analytics Others
Content Data Other4

Uncertified Data  Enterprise Data Warehouse (EDW) Analysis & Models Development
Documents
 Multi Subject Areas 
Cust + Prdct

Web & Social Media Data Warehouse
Customer Risk
Cust + Prdct + Crdt
Metadata & Governance Other
Data Services


Multimedia Archive


• Canonical Data Model Use Case View Digital Product
 • Metadata Tags Data Marts (Fit-For-Purpose/Persisted)
• Data Mapping Cross-LOB View
• Search
System Data Finance Risk Credit
Enterprise Archive Risk View

• Time Series
• Decision Tree
CRM View
IB Insurance • Regression
Machine Generate
Master • Machine Learning
• Clustering
Data Services
Page 164
Data Lake Architecture Guiding Principles
# Best practices Category Description
It is recommended that a staging layer is created by ingesting all raw data at the atomic level. This is encouraged
as Hadoop can be deployed on cheap commodity hardware/storage, where the staging layer can be deployed as
1 Ingest all – use as needed Data Management
a data lake. An integration layer should be created for data rationalization and standardization by extracting only
required data elements from the staging layer.
Ingesting data at the most granular level ensures consistent data at various aggregate level that reconciles
Data Management, Data
2 Ingest most granular data appropriately. It is recommended that most granular data is captured at the ingestion stage in the Hadoop data
Architecture
lake.
Hadoop eliminates the need of expensive data lineage efforts by integrating metadata with the data elements at
Tag metadata during
3 Data Governance the time of ingestion. Hence it’s recommended that business and/or technical metadata are associated with the
ingestion
data elements at the time of ingestion enabling stronger and consistent data lineage and governance.
Data structure or schema must be kept simple and flat as Hadoop is designed for storing large volume of data in
de-normalized format. It is encouraged that de-normalized star schema with smaller dimensions are used instead
4 Flat schema and simple joins Data Architecture
of complex third normal form or snowflake models. This will enable efficient use of memory and maximize data
retrieval performance.
Hadoop supports “schema on read”, in which a schema is applied on data as it is pulled out of the semantic layer,
5 Leverage schema on read Data Architecture instead of when data is ingested in the lake. Hence a schema can be applied on the data only in the semantic
layer (on the way out).
Storage format for optimum Data Management, Data Appropriate data storage formats, such as ORC and Parquet, should be used for most efficient storage and
6
data retrieval Architecture performance.
Partitioning in Hadoop is synonymous to creating indexes on the datasets, hence is extremely important for
7 Partitioning Data Architecture
efficient data access or retrieval.
Page 165
Landscape of Next Gen Tools
Traditional v/s Next Generation tools
1
Data Enterprise Data Architecture Access
Source /
5 Data Management
DG Standards and Policies API Gateway, Orchestration Metadata Management Data Quality Control Framework Common Exception Handling Security and Privacy Deliver
SQL
Controls
Atlas
Kylo
Web
HTML
REST
XML
MDM
Custom
Integrated
Atlas
Web
HTML
REST
XML
Code
SQL
ML
AI/RPA
Java
Trigger
Zookeeper
NiFi
Kerberos
LDAP
SAM
Ranger y
MDG Spark Script JSON Separate Ranger Script JSON Script Atlas SQL XML Kerberos KNOX
Code Vendor VB OS Kylo VB OS MDG Ranger Custom JavaScript
Structured Collaboration
Streaming Data Distribution Analytic &
Data
Supports data transfer and processing at a steady, high-speed rate and Provisioning Operational
Applications
2 Data Ingestion 3 Semantic Layer, Virtualization
& Federation, Data Delivery,
4 Standard Reporting,
Visualization, Ad-hoc Analysis,
Data Transformation and Storage Self Service, Search Data Wrangling, ..., Data as
Data Acquisition Data Ingestion
Service
Server Informatica Actuate Elastic Power BI D3
copies ETL Data Lake
DB Links SQL Excel GraphQL Excel Tableau Web
Platform Data Data Store Platform – On- Data Data Store REST
SFTP DataStage
Processing Premise Processing PDF PDF Qlik Services /
Informatica SSIS Watson Spotfire Portals
Ab Intio Ab Intio Oracle PL/SQL RDBMS MAPR Hive Avro Tableau Tableau
Datastage Replication Lucene Birst
SSIS File Upload Access Shell Flat File Hortonworks Python Parquet Cognos Cognos
Solr
Semi- Goldengate Traditional Paradox Scripts Cloudera Java ORC
Neo4j
SAS Docker BI Reports
Structured IBM CDC Map Teradata Progress Mongo DB Spark
GraphDB
Python Viz
NiFi NiFi Canned
Data Flume BigQL
DB2 ETL Cassandra Storm R
Consul Reports
Sqoop Kafka Netezza Scala SAS
Streaming Samza Platform – Python
SQL Server Kudu
Golden Spark Cloud Spark HUE
SpringXD SpringXD AWS HBase
ETL Storm R Kibana
Custom Zeppelin Azure Tez
Zeppelin Zeppelin
Mobile
ELT Impala
6 Shared Operational Data

Master Data, Reference Data Integrated Rules, Metadata, Learning Patterns
MDG MDM Collibra Ranger Kylo IGC Custom Excel ETL SQL Atlas NiFi Kylo IGC Custom
Unstructure
d Data 7 Applications
Data Transfer
Web Driver API Gateway, Synchronous Services, Asynchronous Pub/Sub Services, Event Management, Batch Control Management, Common Exception Handling
HTML Script SOAP REST SAM MiniFi XML JSON Python
Key Legacy Next Gen “Apache - Open Source” Next Gen “Third Party” vendor
Page 166
Landscape of Next Gen Tools
Big Data Technology Stack – Hortonworks “Apache” Distribution
Data Source HORTONWORKS Distribution Delivery

Governance and Security
Ranger KNOX
Data Ingestion, Integration, and Access
Data Ingestion Batch NoSQL Stream Search
Script SQL
In-Memory Other
ISV Engine
NFS Web HDFS
Data Operating System, Operations, System administration, and Scheduling
YARN Apache Ambari Apache Cloudbreak
Hadoop Distributed File System
Page 167
Landscape of “Third Party” Vendor Tools
Third Party Vendor Tools - Capabilities
Category Vendor Description Key Capabilities
► Datameer is an end-to-end big data discovery and Hadoop analytics application which uses machine-learning ► Web-based end-to-end big data discovery platform
Analytics & Visualization and advanced algorithms for data discovery ► Text, behavior, and sentiment analytics
► Supports unstructured data
► Tamr is a data discovery, unification, and integration platform that combines machine learning with human ► Data unification platform
expertise ► Provides the ability to automatically discover, catalog, and manage all the enterprise metadata
► Talend is an open-source software vendor that provides data integration, data management, enterprise
application integration, and Big Data software and solutions ► 450+ connectors, it integrates almost any data source
► Open source tools to execute data quality
Data Integration
► Accur8 Integration Engine (Accur8 Integrate) provides a flexible, agile way to unify data across processes and
applications. Accur8 Insights provides a robust self-serve reporting and analytics platform ► Data unification / virtualization platform
► PodiumData is a data integrations as well as a metadata and governance tool on a Data Lake environment ► Data ingestion from variety of sources and formats, DQ validation, automatic profiling, data
discovery & exploration
► Profiling, usability and scalability/performance
► MIOsoft’s provides contextual data quality technology and big data analytics using graph analytics and ► Profiling, visualization, usability and scalability/performance
unsupervised machine learning cluster algorithms
Data Quality
► Ataccama specializes in solutions for data quality, master data management, and data governance. ► Comprehensive DQ suite
► Snowflake operates a cloud-based data warehouse service. It offers a platform to store, transform and analyze ► Automated infrastructure management through cloud services
business data
Architecture and ► Dataguise is a leading provider of Big Data security intelligence and protection services. ► Cloud migration, masking and encryption capabilities at the data element level
Governance
► BigID’s platform aims at transforming enterprise protection and privacy of personal data by utilizing patent- ► Advanced data discovery
pending machine learning & identity intelligence technology ► “Living” data maps of all PII data
Page 168

Data Governance Playbook

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Data Governance Playbook

Caricato da

Copyright:

Formati disponibili

CDO 3.

Data Standards Capabilities Adoption Sustainability

Data Governance is:

Benefits of having a DG program include:

Addressing and minimizing operational risks

Establishing a foundation for meeting future regulatory mandates

Information Strategy Framework Key business drivers

Key Business Drivers Key Questions Information Management Capability

"What tools are available so my quants can focus on

“How accessible is my data?”

“How good is my data?”

“Who’s accountable for my data?”

1. Governance 3. Accuracy and integrity 7. Accuracy 12. Review

Submit BCBS questionnaire Full compliance required

Part 1: Perform BCBS self- Part 2: Conduct detailed

Inputs Process Outputs

Global banking and financial services

Step 2: Draft approach and schedule workshops Establish the

Step 3: Review in-flight programs that are designated to support the

1 Business Drivers 2 Current State Challenges 3 Key Capability Recommendations

Identify products in different lines of business that can be sold to existing

Business insight (sample questions)

1Helps reduce compliance risk 2Helps mitigate strategic risk

Share3 client profile

Share3 risk data

3Share taking into account relevant privacy laws

Inputs Process Outputs

WP: Assessment Results

Step 1: Select components to assess based on the business drivers

Step 2: Conduct assessment workshops with key stakeholders to determine

Step 4: Validate targets with stakeholders Hold final workshops to validate

* See appendix for more detail on this accelerator

Initial Data Management BCBS 239

Regulatory Newly hired

CDO Performance Measurement EDM Audit

Assessment (Present) Appraisal (Emerging) Certification (Future)

CONSULTANT COMPANY preferred

A capability framework of The models provide the big

CMMI EDM Council DAMA BCBS 239

Depth Pages: ~232 Pages: 56 Pages: 430+ Pages: 28

How does it work?

► Stimulate conversations about the condition of 4 3 4 4 2 Managed

enhance performance toward critical 5 Optimized

business objectives Scope advocated at the executive management level

1 DMM Framework 2 DMM Assessment 3 DMM Scorecard

Input Process Output

Preliminary current state assessment for

Industry Standard Firm Specific

Trustworthy, Reliable and Fit For Purpose

Supporting Process Supporting Process

Data Quality Data Quality

Platform and Platform and

Data Management Strategy

Inputs Process Outputs

Current data maturity score results

Continue DQA, change & issue

Begin data sourcing and provisioning

Schedule and conduct meetings with the ► EDO objectives

All Provide all stakeholders/groups with the links to

► EDO goals, objectives and timelines

Inputs Process Outputs

WP02: Data Domains

Step 2: Conduct a series of domain workshops to socialize the concept,

Step 3: Finalize domains and approve domain inventory. Perform