TOP_407070357-Data-Governance-Playbook.pptx

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

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

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

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

Introduction to Data Governance

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
Elements
Data Quality
Standards Capabilities Adoption Sustainability

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
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.

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)

▶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
▶Leveraging data management investments to enable analytics and drive better
decision making
Industry Trends
2005 – 2009
Accountability
2013 – 2015
BCBS 239 and CCAR
2009 – 2013
Data Quality
2015 & beyond
Sustainability
• Manage end to end data
supply chains from
report to data
• Integrate control
environments across
model risk, spread sheet
controls, SOX
• Consolidate firm wide
policies and standards
• Automate the capture of
metadata
• Build capability to
independently test
• Strengthening data
architectures through the
use of new technologies
• Building formal job
families and training to
build & retain talent
• Formalizing and
establish CDO
functions
• Initiate metadata
factory to collect and
integrate metadata
• Building enterprise
architecture standards
for data sourcing,
aggregation, analytics
and reporting
• Consolidate and build
common taxonomies
• Evaluate end user data
requirements and
thresholds
• Deploying and
executing data policies
and standards
• Formalizing local data
governance structures
and roles
• Establishing enterprise
data quality
approaches and
standards
• Establish metadata
approaches and
standards
• Establishing formal
data roles and
responsibilities
• Drafting and
deploying policies and
standards
• Establishing formal
data governance
structures
• Focus on centralized
enterprise data
warehouse approaches

Understand business drivers

Section Introduction
► 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.
► Data Management/Governance Organizations Have different structure and focus on establishing different capabilities based on the
business objectives they are trying to achieve
Business Benefits
► The primary business drivers will vary by the institution’s specific size, area of expertise, location in the global marketplace, and
standing with regulators. The business drivers contained within this section can be used as a starting point.
Chapter Guidance
► 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.
► 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.
Industry Trends
► Mike Butterworth
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► 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.
► 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.
Definition

An information strategy harnesses the vast amounts of data available to
any company and turns that into useful knowledge. In addition it
establishes the foundation for data management.
Key business drivers
Profit
► Need for products to leverage good quality and
well managed data
► Efficiencies in operating model creating greater
speed to market
► Data consistency requirements across customer
data sets
► Complex product design based on efficient and
intelligent data use
Cost
► Proliferation of data
► Enhance operational control and customer
satisfaction
► Reduce data storage costs
► Increased demands by customers for reporting
(e.g., Solvency II, UCITS IV, Form PF)
Efficiency
► Ability to respond to change or integrate new
products, regions, or companies
► Business operational metrics
► Decrease process cycle times
Risk and
regulatory
► Heightened regulatory scrutiny (e.g., Dodd-Frank,
CCAR, RDA)
► Concentration risk and correlations across LOBs
► Ad hoc stress scenarios
► Anticipate emerging risks
► Optimize capital allocation
► Vulnerability threats
Information Strategy Framework
Key take-away: Firms need to have clear agreement on key business drivers before investing in technology and data capabilities
Identifying Key Business Drivers

Risk &
Regulatory
Cost
Profit
“Who’s accountable for my data?”
“How good is my data?”
“What customer segments do I want to
focus on or exit?”
Data Governance
Data Architecture
Business Intelligence and
Reporting
Quantitative Analysis and
Advanced Analytics
Data Quality
“How accessible is my data?”
Efficiency
“Does the existing governance structure meet
regulatory requirements
Key Questions Information Management Capability
"Where is the best source to get customer
exposures?"
"How can I reduce my overhead costs related to
quarterly reporting"
"What tools are available so my quants can focus on
analysis not data sourcing?"
Key Business Drivers
Defensive
Offensive
Key take-away: Representative business questions often help illustrate how investment in information capabilities support key
business drivers
Foundational Concepts

Example Business Driver: BCBS-239
► 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.
Part 3:
Implement
Full compliance
required
(January 2016)
Submit BCBS questionnaire
(July 2013)
Regulatory deadlines:
Part 2: Conduct
detailed planning
Part 1: Perform
BCBS self-
assessment
Part 4: Sustain
Timeline
Regulators
Banks
1. Governance
2. Data architecture and IT
infrastructure
II. Risk data aggregation
3. Accuracy and integrity
4. Completeness
5. Timeliness
6. Adaptability
III. Risk reporting practices
7. Accuracy
8. Comprehensiveness
9. Clarity
10. Frequency
11. Distribution
IV. Supervisory review &
tools
12. Review
13. Remedial actions &
supervisory measures
14. Home / host cooperation
Regulatory
Actions
I. Governance & Infrastructure

Sample Approach
Inputs Process Outputs
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
Step 3: Review in-flight programs that are designated to support the
target and obtain confirmation on high level data management
priorities
Step 1: Kick off project Mobilize project team and identify key Global
banking and financial services company stakeholders from the
enterprise office, lines of business IT as well as owners of key
systems, data owners, process owners as needed
Example Business Drivers*
Refined Approach
Global banking and financial services
company Organizational Structure
Initial workshop schedule
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
The Business Drivers
WP01: Kick-off Deck
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.

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.
► Full scope of policies and
standards not promulgated
enterprise wide
► Inconsistent measurement
and monitoring of
compliance
► Individuals not identified for
full range of roles and
responsibilities
► Consistent execution of data
quality assessment not in
place
► Data remediation and
change management
processes not
standardized/well defined
► Lack of maintained,
enterprise wide business
glossary
► Full range of authoritative
sources of data not identified
and defined
► Immature, non-integrated
application of
master/reference data (e.g.,
client, product, location)
► Inconsistent, inflexible
reporting and analytics
capability
► Data management not
integrated within Software
Development Life Cycle
Data
sourcing and
usage
Governance
Process
integration
1. Prioritize data domains (master / reference data, transactional data,
and derived data)
2. Identify certified data sources by domain
3. Develop plan for transitioning to certified data sources
4. Develop plan to enhance analytics and reporting infrastructure using
additional authorized sources
5. Develop plan to adopt enterprise wide Business Intelligence
framework
Target Area Actions
Key Capability Recommendations
Current State Challenges
1. Establish data management metrics
2. Setup data governance committee structures and formalize
expectations for local (e.g., LOB) data governance
1. Incorporate defined and approved data management requirements
gathering process into the SDLC process
2. Incorporate data governance approvals (e.g., BRD sign-off) into
existing delivery tollgates
Organization
1. Establish Data Management roles and responsibilities (e.g.,
Business Process Owner, Data Steward, Data Custodian)
2. Establish and formalize data domains
Business Drivers
► Improve client interaction
360 view of client,
Know client preferences
► Integrated relationship
management
Single version of truth
► Client segmentation
Optimize product mix
and pricing
► Financial, management
and regulatory reporting
Accurate, timely and
consistent data,
Self-service reporting
► Business insights
Cross-LOB analysis,
Forecasting,
New revenue streams
► Manage client exposure
Share risk profiles,
Monitor client behavior
► Manage risk
Monitor capital adequacy,
Regulatory compliance,
Reduce operational risk
Perfect client experience
Reporting and analytics
Risk management
Policies,
Standards
and
Processes
1. Establish policies to define all key accountabilities, starting with
Data Quality and Assurance
2. Establish measurable enterprise wide data governance standards
that define minimum compliance requirements
3. Develop consistent, integrated data processes for use across the
enterprise
A
C
B
D
E
Target State Capabilities Summary
1 2 3

Improve client interaction
Make client interactions more productive for CONSULTANT COMPANY and engaging
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
Integrated relationship mgmt.
Identify products in different lines of business that can be sold to existing
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
Segment clients efficiently
Identify client characteristics to match them to the right product offerings and increase
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)
Example Business Driver
Perfect Client Experience

Financial, management and
regulatory reporting1
Create accurate reports with quick turnaround for internal and external consumption
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
Business insights2
Answer questions about business performance after analyzing data from multiple
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
Reporting and Analytics

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 operational risk
Reduce risk from operations in the bank by automating business processes and thus
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
Risk Management

Assess Current 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.
► 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.
Business Benefits
► Several assessment models are highlighted in this chapter and clients may be inclined to use one over another. The same approach
can be used regardless of the model chosen.
Chapter Guidance
► Many organizations perform an assessment to baseline the capabilities and some conduct follow-up assessments to highlight
progress and compare against industry averages.
► 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.
Industry Trends
► George Suskalo
► Michael Krause
► Christopher Miliffe
Key Contacts
► The objective of this activity is to understand and document the current state of the institution’s data management capabilities. This is
done in order to identify gaps between current state and the desired target state.
Definition
► Rob Perkins
► Sri Santhanam
► Milena Gacheva
► John Gantner

Assess Current State
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
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
Step 3: Develop guiding principles and target state maturity based on the
business drivers and the current state, develop guiding principles of how
firm wide data management will operate. Determine the desired firm
target maturity score for each component assessed.
Step 1: Select components to assess based on the business drivers
Current data maturity score results
Target state maturity score
with guiding principles
Step 4: Validate targets with stakeholders Hold final workshops to validate
guiding principles and target maturity scores
Our Assessment methodology *
Business Drivers
* See appendix for more detail on this accelerator
WP: Assessment Results
and Target State

Define assessment model
When to perform a DMM assessment
1. Strategic Audit – when the Audit function has identified a need to develop
a data management strategy
2. MRA/MRIA/Consent Order – when the organization has significant data
management issues to be prioritized
3. Initial Data Management Strategy – when the organization recognizes the
need to develop a data management strategy
4. CDO Performance 1 – when the Board of Directors plans to objectively
measure performance of the Chief Data Officer (CDO); step 1 is establish
is establish the baseline
5. CDO hired – when a Chief Data Officer (CDO) has been hired and is
charged with developing 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
revised data management strategy.
7. Merger or Acquisition – understanding data management maturity of an
organization that will introduce its data into the enterprise information
information supply chain
8. CDO Performance 2 – when the Board of Directors objectively measures
CDO performance; comparing results to step 1
9. BCBS 239 – when the Board of Directors or CDO require a third party data
management assessment to support BCBS 239 Principle 1
10. EDM Audit – when the Audit function plans to conduct an audit of the
enterprise data management (EDM) function
11. Maturity Progress Report – when it is appropriate for the organization to
evaluate its data management maturity progress
Events when performing a DMM assessment provides beneficial insight:
Audit
Appraisal
Assessment
3 9
1 2 4 5 6 8 11
Strategic
Audit
CDO Performance Measurement
Initial
Data Management
Strategy
Regulatory
response
BCBS 239
Data Management
Assessment
Data Management
Strategy
Check up
EDM
Audit
Newly hired
Chief Data Officer
10
7
Merger or Acquisition
An assessment is beneficial at specific events in an organization’s maturity lifecycle

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

Select data management assessment model
clients.
DMM 1.0 (2014) DM BOK 1st Ed. (2009)
DCAM 1.1 (2015) Analytics Maturity Model (2014)
Big Data Maturity Model (2013)
CONSULTANT COMPANY preferred
methodology
An industry standard
capability framework of
leading data management
practices with an
assessment and
benchmarking capability
geared toward strategy
development, governance
design, and operational
maturity
Leading DM practices gear
toward data governance,
data management
implementation, and
operations within specific
architectural and technical
contexts
A capability framework of
leading practices with basic
self assessment questions
geared toward data
management strategy
development and operation
The models provide the big
picture of analytics and big
data programs, where they
need to go, and where you
should focus attention to
create value

Select data management assessment model
clients.
Category
CMMI
DMM 1.0 2014
EDM Council
DCAM 1.1 2015
DAMA
DM BOK 1st Ed. 2009
BCBS 239
Principles for RDA 2013
Summary The DMM is an industry
standard capability
framework of leading data
management practices with
an assessment and
benchmarking capability
geared toward strategy
development, governance
design, and operational
maturity. (est. 2009)
The DCAM is a capability
framework of leading practices
with basic self assessment
questions geared toward data
management strategy
development and operation.
(est. 2013)
Leading data management
practices geared toward data
governance, data management
implementation, and operations
within specific architectural and
technical contexts. Note: DAMA
is collaborating with CMMI on
DM BOK 2nd Ed. (est. 2004)
The BCBS 239 Principles for risk data
aggregation is not a framework but is listed here
due to industry interest. It contains many
principles for data management. The alignment
below is high level; actual overlap is broader
and more complex. (est. 2013)
Measurement
capability
Objective behavior oriented
measurement capability for
performance, scope, and
meaning based on 30+ year
history of maturity rating
Artifact oriented measurement
capability; performance, scope
and meaning are open to
interpretation. Measurement
model is in beta test
Measurement capability is
proprietary per consultant
Measurement capability is subjective and open
to interpretation in scope, meaning, and
performance
Depth Pages: ~232
Categories: 6
Process Areas: 25
Infrastructure Support: 15
Measured Statements: 414
Considered Artifacts: 500+
Pages: 56
Core Components: 8
Capability Objectives: 15
Capabilities: 37
Sub capabilities: 115
Measured Statements:110
Pages: 430+
Functions: 10
Environmental Elements: 7
Concepts and Activities: 113
Artifacts: 80+
Pages: 28
Principles: 11 + 3 for supervisors
Questions 2013: 87
Questions 2014: 35
Requirements (CONSULTANT COMPANY
Identified): 108
Support Practitioner training and
multi-level certification:
EDME
Training and certification in
development
Practitioner training and
certification: CDMP
N/A
Rating mechanism CMMI sanctioned rating
mechanism available
Element 22 / Pellustro provides
a commercial rating solution
No standardized rating
mechanism
Proprietary rating systems exist, leveraging
BCBS 268
DMM and DCAM enable/align with BCBS 235

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.
What are the benefits of assessment?
► Establish a common understanding and
language about data management
► Stimulate conversations about the condition of
data quality and data management
► Quantify data management strengths and
weaknesses to be managed and organizational
change themes to champion
► Alignment of data management initiatives that
enhance performance toward critical
business objectives
The Data Management Maturity (DMM) Model
The DMM is the industry standard tool for benchmarking data management capability
Content excerpted from the Data Management Maturity Model version 1.0, CMMI Institute © 2014
Capability
5 3 4 5
4 3 4 4
3 2 3 3 3
2 1 2 2
1 1 1
1 2 3 4 5
Scope
Level Data Management Maturity Definition
1 Performed
Reactive or partial data management performed
informally (inconsistent) at the local/business unit level
2 Managed
Processes are defined and documented but performed
at the business unit level on a sporadic basis
3 Defined
Processes are defined, managed and orderly with
implementation consistently applied at the
organizational level
4 Measured
Processes are structured, aligned, adopted and
traceable with consistent measurement analytics at the
organizational level
5 Optimized
Processes are managed on a continuous basis and
advocated at the executive management level
Process Area Maturity Levels
Organizational Maturity Level

Conduct DMM Assessment
Approach for DMM
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
DMM Assessment
2 DMM Scorecard
3
DMM Framework
1
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.

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.
Deliver assessment introduction / education
Input Process Output
Step 1.1: Conduct walkthrough of the assessment
components, how to use the scoring template
Execute assessment questionnaires
Step 2.1: Distribute assessment questionnaires to
participants and request self-scoring
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
Step 3.2: Identify with the core team and stakeholders
common themes and pain-points emerging to develop
initial prioritization areas
Identify practice strengths and gaps and other current
state findings*
Step 4.1: Identify areas where existing practices can be
adopted and those where capabilities are lagging
peers/expectations
1
2
3
4
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
5
Data management capability
assessment
* 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.
Step 1.2: Educate participants on how to apply the
business drivers and scope to the scoring template
Assessment kick off materials
Refined assessment questionnaire
Assessment report template
Preliminary current state assessment for
each process area
In-flight initiatives
In-flight initiatives aligned to data

Industry Standard
Maturity model
Firm Specific
Implementation
► 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
Measure
DMM Model
Data Management
Program
Guidance
DMM Assessment
Platform
Architecture
Business
Glossary
Data Quality
Rules
Data Lineage
Authoritative
Sources
Control
Quality
Data
Trustworthy,
Reliable
and
Fit
For
Purpose
Internal Audit
measures compliance to the DG
Program.
Supporting EDM Programs
The DMM provides guidance defining program components

Continued assessment to track progress
Data Management Strategy
Data
Governance
Data Quality
Data Operation
Platform and
Architecture
Supporting Process
Data
Governance
Data Quality
Data Operation
Platform and
Architecture
Supporting Process
Data Operation
Data
Governance
Data Quality
Platform and
Architecture
Supporting Process
Data
Governance
Data Quality
Data Operation
Platform and
Architecture
Supporting Process

Develop Roadmap
► 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.
► 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.
Business Benefits
► Once an organization performs an assessment and understands the current state and target state, the capabilities to achieve the
target 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.
Chapter Guidance
► 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.
► 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.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► 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.
► A roadmap prioritizes and sequences a set of required initiatives (projects) into a larger program.
Definition

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.
Process Outputs
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.
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 1: Prioritize capability gaps based on logical sequencing, risk
management and business priorities, and after discussing
with project leadership for subsequent phases of the project
High-level roadmap and
project plan
Executive level
presentation
Duration: 2 - 5 weeks
Resources: Assessment & stakeholder team of 3-5 resources
Inputs
Current data maturity score results
Target state maturity score
with guiding principles
Step 4: Socialize roadmap with stakeholders for alignment of
efforts and messaging

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
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.
Current State
► 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
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.
Target State
► 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.
► 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.
Roadmap

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
target state capabilities
• Existing projects
• New projects
(B) Prioritize and sequence projects
into a remediation plan with steps
needed to achieve business benefits
(C) Recommend monitoring
progress against functional
principles by tracking project status
Sample
outputs

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.

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).

# Key Activities Description Enablers
1*
Continue identifying
stakeholders/ impacted groups
Continue the process of identifying and creating a list of key stakeholders/groups across the
domains/enterprise that will help execute EDO goals and objectives.
► List of domains
► LOB organizational structures
2*
Continue
determining/assigning roles &
responsibilities
Utilizing the inventory of key executives/groups, continue to assign stakeholders to important
roles and responsibilities (e.g., Business Process Owner, Data Steward, Data Custodian)
considering current roles and alignment.
► List of stakeholders/groups
► List of domain roles &
responsibilities
3
Finalize DQA, change & issue
management policies
Seek approval of the Policy team to finalize the Data Quality & Assurance, Change
Management, Issue Management, EDWE policies and standards.
► Policy team input/approval
4
Begin development of
additional policies & standards
(master data, metadata, SLA)
Begin development of additional EDO policies and standards documents, including Master
Data, Metadata and SLAs, consistent with existing policies and standards that apply to the
EDO’s goals and objectives.
► Policies and standards (for
consistency)
5*
Develop Communication Plan
strategy and schedule
meetings
Develop strategy to approach impacted executives/groups, create timeline of important
meetings/communications and schedule meetings with executives/stakeholders (see
Communication Plan guidelines/milestones).
► List of domain roles &
responsibilities
6*
Develop Communication Plan
materials
Develop materials for Communication Plan meetings with executives, Business Process
Owners, Data Stewards, etc. with appropriate content explaining the goals, responsibilities and
expectations, tailored appropriately to the target audience.
► Communication Plan
► Communication calendar
7
Execute Communication Plan
with Executives (will continue
into other periods)
Conduct meetings with executives/stakeholders across the enterprise to understand goals and
objectives, roles and responsibilities, timeline and expectations (see Communication Plan
guidelines/milestones).
► Communication materials
8
Schedule/develop materials for
regulatory/executive updates (if
applicable)
Schedule meetings with and develop materials for updates with regulators and executives with
the objectives of communicating progress, the final design and capabilities of the EDO and its
scope, relevant policies and standards, and more.
with assigned responsibilities
► Policies and standards
9
Meet with
regulators/executives (if
applicable)
Provide regulators and CONSULTANT COMPANY executives with updates on the initial design
and capabilities of the EDO, as well as, its scope, progress to date and relevant policies and
standards. Adjust/update accordingly, per regulatory and internal feedback, and communicate
outcomes across the enterprise, as needed.
► Regulator/executive meeting
schedule
► Regulatory/executive update
materials
10
Update EDO leadership/
executives
With initial identification and communication activities completed, conduct comprehensive
update meetings with the CDO, Enterprise Risk Manager and CRO (if necessary) to
communicate progress, any issues, updated estimates (e.g., time, budget, resources), and
more.
► Minutes/summaries from
regulator/executive meetings
► Progress/estimate updates
Identify & Communicate
* Iterative activities based on identification of domain roles and responsibilities
Example 30 day plan

Coordinate & Plan
1
Execute Communication
Plan with executives
(continued throughout)
Continue to conduct meetings with executives/stakeholders across the enterprise to understand goals and
objectives, roles and responsibilities, timeline and expectations (see Communication Plan
guidelines/milestones).
► Communication materials
2*
Begin to develop
implementation/ execution
plans (domains)
Business Process Owners begin to identify team members related to their domain data. Domains begin to
digest information conveyed in the Communication Plan and start the process of developing
implementation/execution plans that align with the goals, objectives and timelines of the EDO, including
roles and responsibilities, which will be carried out over the next several quarters.
► Communication Plan/other
EDO materials
► Domain roles/resp.
3*
Schedule checkpoints with
stakeholders/groups
Create comprehensive calendar with executive checkpoints with the objectives of coordinating efforts,
monitoring progress, managing change and maintaining an open dialogue. Determine which EDO resources
will cover which meetings, as well as, the type of documentation needed by the EDO and stakeholders.
► EDO program plan
4*
Prepare materials for
checkpoints
Prepare materials and relevant documentation appropriate for the meetings, including updates on other
efforts underway (e.g., in-flight initiatives, progress by other domains).
► Executive update schedule
► Coverage by EDO
5
Conduct checkpoints with
executives
Conduct executive update meetings on the initiative as a whole and solicit information on progress of the
relevant domains. Review and provide initial feedback on implementation plans presented by stakeholders/
groups and finalize plans for coordination of work effort. Address issues and remediation activities, as
needed.
► Executive update materials
6*
Communicate follow
ups/execute takeaways
Review materials, progress updates, and implementation plans provided by executives and provide
feedback/solicit action, as necessary. As they are resolved, close out any EDO-responsible action items and
communicate the results of the meetings to EDO and Risk leadership.
► Executive update materials/
minutes/action items
7*
Incorporate relevant
information into plans
Based on the executive update meetings, incorporate feedback/updates into overall program plan to track
progress/information.
► Executive progress updates
► Program plan
8
Internally finalize additional
policies & standards (master
data, metadata, SLA)
Finalize Master Data, Metadata and SLA policies and standards and seek approval of the documents from
Policy team.
► Policies and standards (for
consistency)
9*
Begin to promulgate policies
& standards**
Begin to promulgate approved policies and standards to relevant stakeholders.
** This should be done before execution of the Communication Plan such that stakeholders have ample time
to read and understand the policies and formulate strategies to comply.
with assigned responsibilities
10
Begin DQA, change & issue
management process
development (appl. domains)
Begin to develop the standards and processes for Data Quality & Assurance, change management and
issue management, as appropriate.
► List of KDEs/EDAs/CDSs
11
Update EDO leadership/
executives
Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if necessary)
to communicate progress, any issues, updated estimates (e.g., time, budget, resources), and more.
► Minutes/summaries from
executive meetings
Example 60 day plan

1* Prepare materials for checkpoints
Prepare materials and relevant documentation appropriate for the meetings, including updates on
other efforts underway (e.g., in-flight initiatives, progress by other domains).
► Coverage by EDO
2*
Continue checkpoints with
stakeholders/groups
Continue to facilitate adoption of the EDO strategy by conducting meetings with stakeholders from
LOBs/domains.
► EDO program plan
3*
Continue to develop implementation/
execution plans (domains)
Business Process Owners continue to identify team members related to the domain data. Domains
continue to develop implementation/execution plans that align with the goals, objectives and
timelines of the EDO, including roles and responsibilities, which will be carried out over the next
several quarters.
► Communication Plan/other
EDO materials
► Domain roles/resp.
4 Update EDO leadership/ executives
Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if
necessary) to communicate progress, any issues, updated estimates (e.g., time, budget, resources),
and more.
► Summaries from exec
meetings
5
Disseminate/integrate lessons
learned
Based on progress to date, aggregate and communicate any lessons learned to applicable
stakeholders to ensure consistency of implementation and avoid repeat issues.
► Program progress updates
6*
Begin identifying KDEs, EDAs and
CDSs; defining business rules
requirements and thresholds; and
registering data attributes (domains
that have adopted policies)
For domains that have adopted policies and standards, identify KDEs, tier 2 and 3 data elements,
EDAs and CDSs critical to each domain (e.g., master data, metadata) collaboratively between the
EDO and stakeholders/domains. Develop rules to meet the needs of the business and ensure DQ;
define requirements for data (e.g., master data and metadata requirements). Define thresholds for
DQ. Register the various attributes and characteristics of data elements.
► List of data elements
► List of systems/data
sources
7
Continue DQA, change & issue
management process development
(domains that have adopted policies)
Continue to develop the standards and processes for Data Quality & Assurance, change
management and issue management, as appropriate.
8
Begin data sourcing and provisioning
standard and process development
(domains) that have adopted policies
Begin to develop the standards and processes for EDWE, master data, metadata, and SLAs, as
appropriate.
9 Update EDO leadership/ executives
Conduct comprehensive update meetings with the CDO, Enterprise Risk Manager and CRO (if
necessary) to communicate progress, any issues, updated estimates (e.g., time, budget, resources),
and more.
► Progress by domains/
estimate updates
Begin to Execute/Implement
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.
Example 90 day plan

Below is a high-level framework that can be leveraged by the EDO to create more detailed/domain-specific Communication Plans.
# Audience
Communicati
on Method
Description Communication Items / Agenda
Frequency of
Communication
1 Executives Meetings
Schedule and conduct meetings with the
Enterprise Risk Manager, CRO and other
executives (as appropriate)
► EDO objectives
► Prioritization
► Buy-in
As needed
2
All
stakeholders
Email
Send mass-communication to all
stakeholders/groups (request that they forward
to members of their teams, as necessary)
► Goals and objectives of the EDO, as well as, the catalyst(s) for its creation (e.g., CCAR, data management requirements, EDMC
assessment)
► EDO leadership, alignment and where it fits within the organization and contacts, as well as, details on prior executive meetings/buy-
in and priorities (see above)
► Overall timeline for implementation across the enterprise
► Next steps, including the timeframe in which the EDO will schedule initial meetings with individual stakeholders/groups
Once
3
All
stakeholders
Email
Provide all stakeholders/groups with the links to
relevant policy and standards documents
► Policies / standards Once
4
Business
Process
Owners
(BPOs)
Meetings (by
domain)
Schedule and conduct meeting with Business
Process Owners by domain (include multiple
Business Process Owners in meetings, when
possible)
► EDO goals, objectives and timelines, as well as, business drivers and summary of prior executive meetings/buy-in and priorities
► Overview of the data domain (e.g., business processes and requirements, in-flight initiatives, roles and responsibilities) and business
process/data management pain points
► 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)
Bi-weekly to
monthly
5
Data
Stewards /
Data
Custodians
Meetings (by
domain)
Schedule and conduct meeting with Data
Stewards and Data Custodians by domain
(include multiple stakeholders in meetings, when
possible)
► EDO goals, objectives and timelines
► Summary of discussion with executives and Business Process Owner and relevant information (e.g., responsibilities, data
management areas of focus)
► Further discussion of data domain (e.g., processes, in-flight initiatives, roles and responsibilities) and data management pain points
with respect to overall data quality
► 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)
Bi-weekly to
monthly
6
Data
Architects/
Source
System
Application
Owners
Meetings (by
domain)
Schedule and conduct meeting with Data
Architects and Source System Application
Owners by domain (include multiple
stakeholders in meetings, when possible)
► EDO goals, objectives and timelines
► Summary of discussion with executive and Business Process Owner(s), Data Steward(s) and Data Custodian(s), relevant information
(e.g., responsibilities, data management areas of focus)
► Further discussion of data domain specific to architecture and source systems involved, as well as, data design/usage/sourcing and
existing data management pain points
► 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)
Bi-weekly to
monthly
7
All
stakeholders
Email
After conducting meetings with stakeholders and
groups, send summary communications with the
following information
► Meeting minutes/notes and action items
► Overview of expectations and next steps
► EDO points of contact
As needed
8
All
stakeholders
Meetings
Schedule and conduct checkpoints with
stakeholders/groups throughout the 30-60-90
day plans and through full implementation, as
agreed to in previous meetings
► Encourage open dialogue and conduct ad hoc meetings to discuss progress and resolve any issues arising during planning and
implementation.
As needed
9 Regulators Meetings
Schedule and conduct updates with regulators to
provide information on the
► Approach, progress to date (e.g., execution of communication plan and notable items arising from those discussions)
► Communicate assessment of timelines for compliance with regulatory requirements and resolution of outstanding MRA/MRIAs.
Quarterly
Example Communication Plan

Define Scope of Key Data

► 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 used across the enterprise.
► Domains can be used as a top level structure to achieve a ‘common taxonomy’ as described in BCBS 239
Business Benefits
► An organization contains a vast array of data, not all of which must be governed in the highest capacity. This chapter allows
businesses 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
Chapter Guidance
► 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
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.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► Creating a standardized data taxonomy via data domains organizes the data by shared characteristics and context that facilitates
management governance.
► 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.
Definition

Define Scope of Key Data: Data Domains
Step 2: Conduct a series of domain workshops to socialize the concept,
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
interaction matrix
Step 1: Review Industry domain models and current state systems and
data flows usage patterns to propose a draft set of domains for
Global banking and financial services company
Domains
Industry Domain models*
Step 4: Assign domain ownership Establish roles and responsibilities for
domain ownership as well as the roles of data producers and data
consumers
Our Domain Approach*
Data Domain Ownership
matrix
* See appendix for more detail on this accelerator
WP02: Data Domains
Executive Presentation
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

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
understanding and usage of data elements across LOB’s, business
processes and systems
What is a data domain?
► Critical roles and responsibilities will be assigned at the data domain
level
► These roles will have oversight of data across LOB’s, business
processes and systems
How do we manage
data domains?
► Today, accountability for data is inconsistently applied at LOB’s,
business processes and systems
► Since multiple LOB’s share the same data (e.g. client reference data),
accountability for shared data is unclear and/or fragmented
Why do we need data
domains?

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

Data Domains
Example Domains 1
General Ledger
Data
• The combination of reference, master and
transactional data summarizing all of a
company's financial transactions, through
offsetting debit and credit accounts.
Customer
Profitability Data
• The calculated Profit and Loss data (PnL)
such as the revenues earned and the
costs associated with a customer over
time
Liquidity Data • The subset of assets and securities that
can be easily traded without affecting
the price of that asset or security
Regulatory
Reporting Data
• Data that are determined as critical to
meet regulatory reporting requirements
Capital Data
• Calculation of the Bank’s financial
performance (e.g. Income Statements,
Cash Flow Statements & Balance
Sheets).
Operational Risk
Data
• Data and criteria used to calculate losses
arising from an organizations internal
activities (e.g. people, process &
systems)
Market Risk Data • Data and criteria used to calculate the
probability of losses in positions arising
from movements in market prices
Credit Risk Data • The amount of principle or financial
value that is at risk should a party fail
to meet their obligations
Allowance for Loan
Losses Data
• The financial value associated with the
estimated credit losses within a bank’s
portfolio of loans and leases.
Risk. Finance and Treasury Data Domains
16
17
18
19
21
22
23
24
20
Data Types Definition
• Data that identifies or is used to categorize
other types of data, along with the set of
possible values for a given attribute
• Includes calendar, currency, geographic
locations, industry, identifiers, roles,
relationships
Linking &
Classifications
Party & Legal
Entities
• An entity that is registered, certified & approved
by a government authority
• Any participant that may have contact with the
Bank or that is of interest to the Bank and about
which the Bank wishes to maintain information
(e.g. legal ownership / hierarchy, financials)
• Descriptive information about any form of
ownership (asset) that can be easily traded in
markets, such as stocks, bonds, loans, deals,
and indices.
Assets & Securities
Reference and Master Data Domains
1
4
2
Transactional Data Domains
8
9
10
11
• A state that a party or legal entity can be
transitioned into when that entity is a potential
or existing recipient of services, products or
transactions
Customers &
Counterparties
3
• The value or cost and quantity at which assets
& securities are traded or converted (e.g.
exchange price, currency rate conversion,
interest or inflationary rates
Prices & Rates
5
• An item to satisfy the want or need of a
customer and has an economic utility and are
typically a grouping of various assets &
securities
Products &
Accounts
• An evaluation of the financial status of a party
or an asset to indicate the possibility of
default or credit risk
• (e.g. Moody’s, S&P, Fitch, Experian, Equifax,
Transunion and internal)
Ratings
6
7
• The individual events associated with the
movement of currency (cash assets) into
and between Accounts
Deposits &
Payments
list of the services rendered, with an
account of all costs (such as an itemized
bill.)
Invoices &
Billing
buying or selling of assets and securities.
Trading
• The lifecycle of an instruction from
customers to counterparties or other legal
entities for trade order events
Clearing &
Settlement
12 • The transactional events within or between
party’s & legal entities in which assets &
securities are exchanged under an
agreement that specifies the terms and
conditions of repayment
Borrowing &
Lending
13 • A group of activities customers or
counterparties need or to accomplish a
financial goal
Include aspects of budgetary activities
Financial
Planning
14 • A fee charged for facilitating a transaction,
such as the buying or selling of assets,
securities, products or services offered to a
customer or a counterparty to the Bank
Fees &
Commissions
15 • The various types of events that can take
place across an organization including
financial transactions, customer management
and marketing events and business process
activities
Business Events

Transactional Domains
Credit Risk
The risk of loss from obligor or counterparty default. Includes
Wholesale and Consumer credit risk
Market Risk
The potential for adverse changes in the value of the Firm’s assets
and liabilities resulting from changes in market variables such as
interest rates, foreign exchange rates, equity prices, commodity
prices, implied volatilities or credit spreads
Operational Risk
The risk of losses arising from an organization’s internal activities
(e.g. people, process & systems)
Principal Risk
The risk that the investment will decline in value below the initial
amount invested
Country Risk
The risk that a sovereign event or action alters the value or terms
of contractual obligations of obligors, counterparties and issuers,
or adversely impacts markets related to a country
Liquidity Risk
Data and criteria used to manage and categorize the
marketability of investment
Capital & Liquidity
Data associated with an organization’s monetary assets (e.g.
balance sheet) and a type of asset that can be traded in market
without affecting the price of the asset. Assists with improving
the banking sector’s ability to absorb losses arising from financial
and economic stress (CCAR stress testing, leverage and risk-based
requirements); ensuring banks hold sufficient liquid assets to
survive acute liquidity stress; and preventing overreliance on
short-term wholesale funding
GL and External Financial Regulatory Reporting
Data associated with financial transaction of the organization for
its entire life cycle, including SEC disclosures & MIS Reporting
and data used to define requirements around individual regional
regulatory reports
Compliance
Data used to asses and monitor anti-money laundering and non-
anti-money laundering activities including; transaction monitoring,
risk assessment, KYC, CDD/EDD, CLS (client list screening), look-
backs
Profitability & Cross-Sell
Data and criteria used to support measurement of customer
profitability, cross-sell and referrals
Functional Domains
12
15
13
14
16
17
18
Reference & Master Domains
19
20
21
External Parties
Data and criteria used to identify entities that lay outside of the
ownership structure of the firm (external legal entities,
prospects, clients, issuers, exchanges)
Internal Parties
Data and criteria used to identify entities that fall inside the
ownership structure of the firm (internal legal entities,
subsidiaries, joint ventures, holding companies)
Workforce
Includes employees and contractors and the core attributes that
uniquely describes them
Accounts
Accounts of JPMorgan customers in which holdings and
transactions get recorded. Contains account identifiers, legal
agreements, descriptors, key account attributes, etc.
Product & Product Classes
Data used to categorize products or services (inclusive of asset
and asset classifications, securities and other financial
instruments)
Instrument & Instrument Classes
Data defining the means by which a tradable asset or
negotiable item such as a security, commodity, derivative or
index, or any item that underlies a derivative is transferred
Prices & Rates
Data associated with values or costs at which assets &
securities are traded or converted (exchange rates, interest
rates, equity prices, etc.)
Geography
Data that describes the geographic location or related
attributes of a party, transaction, collateral, etc., including
addresses, geo codes, currencies, etc.
Industry
Data that describes the nature of a Customer or Other Party, or
risk exposure
Business Unit
Data that is used to represent a logical segment of a company
representing a specific business function, separate from a legal
entity
Financial Account / UCOA
The smallest unit at which financial transactions are classified
within general ledger or sub-ledger (e.g. asset, liability, revenue,
expense, etc.). This data also includes the banking book, trading
book and their respective hierarchies
1
4
2
3
5
6
7
8
9
10
11
Product Transactions
Data elements and events supporting trade order and
transaction management, clearing and settlement, asset
transfers, cash movement, borrowing and lending transactions
Customer & Client Servicing
Data associated with client/customer transactions used in
servicing them including fraud, default management, and
originations transactions
Sales & Marketing
Relationship management activity, product management
strategy, sales activity including marketing, campaign
management, commissions, fees and prospect management
.
22
23
24
Data Domains
Example Domains 2

Key Takeaway: Data domains become operationalized once aligned to business processes and roles are assigned.
Data Domains
Operationalizing with Roles
Data Domain Business
Process 
Know Your
Customer
(KYC)
Regulatory
Capital
Management
Office (RCMO)
Regulatory
Reporting
Market
Risk
Credit
Portfolio
Group
Credit Risk
Reporting
Ownership
Tracking
System (to
be replaced
with GEMS
1Q 2015)
Client
Onboarding/
Origination
…
Wholesale Credit Risk x x x
Consumer Credit Risk x x x
Market Risk x x
Capital & Liquidity x
GL and External Financial Regulatory Reporting x x x X x
Compliance x x
…
External Parties x x x x x x x x
Industry x x x x x x x x
…
Denotes the domain which the data is read (consumed) from Business Processes
Consumer
Data
Domains
Reference &
Master Data
Domains
► 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
all business processes
Role B: have a detailed understanding of how the business
process functions and operates
Role C: have a
detailed
understanding of
processes and
associated data
requirements

Define and Establish Governance Model

Define and Establish Governance Model
► Attaching names to data governance makes the operating model ‘real’ and enforceable.
► Establishing routines and effective governance to become part of the BAU process of data management within the organization.
Business Benefits
► Until this point, data governance was seen as an initiative at the enterprise level without names or faces. Now roles and
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.
Chapter Guidance
► Most organizations have established a CDO (Chief Data Officer) but have not fully expanded their governance roles down to the
lowest possible levels.
► The centralized and federated operating models of data governance has been most widely adopted, however, multiple methods are
available for use.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► The objective of creating an enforceable Data Governance operating model is to provide a clear structure of the roles and
responsibilities required to have accountability over critical data.
► The operating model has roles, routines, metrics and monitoring.
Definition

Stand-up Governance and Oversight
► An often times overlooked key business function is the quality and consistency of data. Governance is
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.
Governance
► The oversight functionality exists to secure accountability and functionality. Fundamental principles
include ensuring standards exist and are followed, committees and groups are fit for purpose, and the
bank is functioning as intended.
Oversight

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
to establish, however sometimes
decisions/consensus may take longer to
obtain due to lack of hierarchical edicts.
• Relatively flat organization
• Informal governance bodies
• Relatively quick to establish and
implement
• Consensus discussions tend to take
longer than hierarchical edicts
• Many participants comprise governance
bodies
• May be quick to loose organizational
impact
• May be difficult to sustain over time
Hierarchical A formal hierarchical approach to data
governance, decisions are made at the top
and then trickled down for execution. This
data governance organizational structure can
be easily aligned to the existing reporting
lines.
• Formal Data Governance executive
position
• Council reports directly to executives
• Large organizational impact
• New roles may require Human
Resources approval
• Formal separation of business and
technical architectural roles
Hybrid A hybrid approach provides the “tone at the
top” and wider range of committee members
provide subject matter advise.
• Hierarchical structure for establishing
appropriate direction and ‘tone at the top’
• Formal Data Executive role serving as a
single point of contact and accountability
• Groups with broad membership for
facilitating collaboration and consensus
building
• Potentially an easier model to implement
initially and sustain over time
• Data Executive position may need to be
at a higher level in the organization
• Group dynamics may require
prioritization of conflicting business
requirements and specifications

1st Line: Local groups / LOBs /
Domains
2nd Line: Oversight Functions
Executive Committees
Data User
Data Steward (DS)
Business Process Owner (BPO)
Data Governance Committees
Data Custodian (DC)
Data Architect (DA)
Source System App. Owner
(SSAO)
Data Strategy & Architecture
Data Management
Centre of excellence, Shared services
Data Advisory
Central Enablement Activities1
Target State Governance Model
3rd Line: Audit
Audit
(May need additional data
management skills)
Chief data officer
Controls data officer
Program executive sponsors (including BCBS)
Data Governance and QA1
EDO governance
EDO shared
services/enable
ment
Legend: Domain specific
roles
External to EDO
Escalation/oversight path
Data Administration
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.
1Refer to appendix 1 for further information on EDO functions

Data
Architect(s)
Data Steward
Data
Custodian
Domain #4
(e.g., credit risk)
Data
Management
Chief Data Officer
(Head of EDO)
Data
Architecture
Data
Governance
and QA
Center of
Excellence,
Shared
Services
Data
Architect(s)
Source
System
Application
Owner
Domain #2
(e.g., GL data)
Data Steward
Data
Custodian
Data
Architect(s)
Data Steward
Data
Custodian
Domain #3
(e.g., mortgages)
Source
System
Application
Owner
Data
Architect(s) 2
Source
System
Application
Owner2
Customer
(Illustrative)
Data
Steward2
Data
Custodian2
Data Advisory
Data
Administration
Source
System
Application
Owner
Data Governance Committees
Executive Owner
(Non IT)*
Business Process
Owner(s)2
Business Process
Owner(s)
Business Process
Owner(s)
Business Process
Owner(s)
EDO Functional Organization Enterprise wide data management roles at a business group / data domain level
Data User(s)2 Data User(s) Data User(s)
2Refer to appendix 2 for additional information on specific roles
1Refer to appendix 3 for further information on data domains
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
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.

Identify level of centralization / federation
Example Approach
Independent Locally distributed Balanced Central + distributed Centralized
Functional areas operate with
complete autonomy, while
maintaining global standards to
meet specific enterprise
requirements.
• There is no oversight of data
management roles from the
Enterprise Data Office (EDO)
• The EDO sets forth policies and
standards1, but not procedures
• There is no enforcement of
standards
• Data priorities are defined within
the lines of businesses / data
domains
Functional areas control a
majority of their business and
technology operations, with
limited coordination from the
enterprise.
• There is some EDO assistance
in setting up roles
• EDO sets forth policies and
standards1, but not processes
• There is minimal enforcement
of standards
• Data priorities are defined
within the lines of businesses /
data domains, but after
discussions with the EDO
Responsibility and ownership are
shared equally among the
different functional areas and the
enterprise.
• There is an advisory
relationship between data
management roles and EDO
(provides services)
• EDO sets forth policies,
standards1and some processes
for business groups / data
domains to follow
• Business groups / data
domains self-assess their
performance and report to the
EDO
• Strategic data priorities are
defined by the EDO
Data Governance provides a point
of control and decision making but
functional areas own selective
decisions and activities.
• There is an advisory and
oversight relationship between
data management roles and EDO
(provides services)
standards1 and some processes
for business groups / data
domains to follow
• Business groups / data domains
self-assess their performance,
with the EDO frequently
overseeing results
• Strategic data priorities are
defined by the EDO
Data Governance provides a
single point of control and decision
making, with functional areas
having little or no responsibility.
• All data management roles
report into the EDO
standards1 and processes for
business groups / data domains
to follow
• Business groups / data domains
self-assess their performance,
with the EDO frequently
overseeing results
• Most data priorities are defined
by the EDO
EDO EDO EDO
EDO
Increasing EDO Authority
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.

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.
 Minimal disruption during program rollout
 Easier business case for initiatives
× No integrated approach to fulfilling business
drivers
× Different priorities across the enterprise
× Increased cost from overlapping initiatives
× Increased risk due to disparate data
definitions
 Integrated approach to fulfilling business
drivers
 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
× Moderate disruption during program rollout
× Additional resources required
× Speed of execution (initially, not long term)
 Most consistent data
management
× Disruptive cultural
shift needed
Advantages
Disadvantages
EDO EDO EDO
EDO
Increasing EDO Authority

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

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.
Identify organizational model
Example Interaction model 1
System Managers
Various
Control Owners
Various
System Managers
Various
System Managers
Various
Control Owners
Various
Control Owners
Various
Various
Data Officers
CBG, CmBG, CRE, GIB, International,
etc.
Credit Risk, Finance,, etc.
Line of Business Data
Officers
Various
Functional Data Officers
Various
Single point of accountability for establishing and delivering the data management
function for each Wholesale LOB and each functional area
Data Office
Establishes and monitors data management function for Wholesale. Primary point
of accountability to Enterprise.
Chief Data Officer
Structures, supports, and monitors
Supports Monitors Supports
Key Accountabilities
Guiding Principles
Start simple (Crawl-Walk-Run) Avoid duplication of roles Maximize autonomy Enable early execution
Data officers are
data providers
and/or consumers
for one another,
driving significant
interaction,
negotiation and
coordination
between Data
Officer functions to
manage data
effectively end-to-
end.
Chief Data Officer (CDO):
Establish, support, and monitor data management capabilities across Bank
• Ultimate point of accountability to Enterprise for Data Mgmt. within the data office
• Define, implement and monitor data governance structures
• Establish cross-functional priorities for the data office
• Manage shared data assets (ex: customer/client); drive resolution of cross-functional issues
• Define Wholesale Data Mgmt. Standards and monitor adherence
• Represent data office Bank at Enterprise governance routines
Data Officers:
Ensure data quality and control for his/her assigned area of responsibility
• Identify and/or resolve data risks and issues (whether identified internally or by data consumers) for data within their custody
• Establish local data governance structures and resources
• Ensure compliance to Enterprise and Wholesale data standards / requirements
• Ensure data provided meets user/consumer requirements
System Managers*:
Manage technical aspect of the data within application
• Provide and maintain technical metadata (data flows / mapping, transformations, technical controls, etc.)
• 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
Control Owners*:
Operate and manage key data controls
• Provide and maintain control metadata
• Operate / manage to the control to specification agreed to by applicable Data Officer(s); provide action plans for out of threshold conditions
and notify Data Officer of any material changes or risks impacting prioritized data
*A System Manager may also be the Control Owner for technical controls
System Data Custodian
Responsible for understanding the data quality of data within their assigned system; This is the “Data Owner” from G&O
• Collaborate with the necessary Data Officers, System Managers, and Control Owners to understand the integrity and quality of data consumed
for their assigned system(s)
• Monitor the system to ensure data changes are communicated and consistent across Data Officers
• 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
System
Data
Custodians
Various
System
Data
Custodians
Various
System
Data
Owners
Various

• 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
• 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
• 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)
• 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
• 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
1
2
3
Chief Data Officer
5
Business
Process Owners
5
Technology
Managers
Data
Domain
Executives
2
LOB CDOs
1
Information
Architects
CB, CCB, CIB, CTC, AM
Corporate
Reference & Master Data*
Data Stewards
Business Partners Data Management Partners
4
3
4
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.

Roles & Responsibilities
Example Committee Structure 1
Executive Steering Committee
Issues
resolutions
&
process
improvements
escalation
flow
Data Management Council – CDO (chair)
Executive Steering Committee – meets bi-monthly and as needed to
provide executive and business engagement in information management
► Provides input on priority and drivers
► Approves and funds strategies
► Enforces compliance
e.g. KPIs: # Consent orders, # MRIAs
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
► Sets initiative priority
► Approves and implements policies, standards, processes & procedures
► Approves changes to list of data domains
► Measures LOB and Enterprise compliance
e.g. KPIs: DQ defect materiality trend, # Faulty CDEs trend
Data Domain Working Groups – meets at least monthly to define,
prioritize and manage requirements and interactions between business
process teams
► Defines shared data and resolves shared data issues
► Prioritizes and manages requirements within the SDLC
► Ensures data is appropriately sourced and performs lineage
► Applies policies, standards and processes
e.g. KPIs: # Data issues
Data Domain Working Groups – Data Domain Executives (chair)
Data Governance Structure and Escalation Levels Objectives, Agenda and Cadence
Consumer, Transactional and Reference & Master Data Domain Teams
1
2
3
1
2
3
Data Domain
Executives
Enterprise CDO
Program Office &
Execution Leads
LOB Data Office
Leads
LOB/Corporate
Report Owners
Technology and
Operations Support
Partners
Business Leadership
Technology and
Operations
Leadership
Risk, Finance and
Compliance
Leadership
Data
management
implementation
&
execution
Technology and
Operations
Managers
Data Stewards
Chief Information
Architects
Business Process
Owners

Example Committee Structure 2
Role Description Responsibilities
Executive
Committee
The group of executive
stakeholders who develop the
vision and define goals of the
governance body within the
strategic goals of the
enterprise
• Sets appropriate “tone at the top”
• Provides funding and resources
• Provides strong sponsorship and leadership
Data Governance
Committee/Board
A team of management
personnel that is accountable
for the execution of
governance functions.
The team works closely with
business, operations and IT
community in executing its
functions.
• Develops policies and standards, and processes and procedures
for enterprise information management
• Executes and monitors an overall strategic plan for enterprise data
management improvement
• Provides channels for data issue resolution and performs
oversight of the resolution
• Monitors adherence to data policies, procedures, and standards
• Develops guidelines for classifying data stores by the type of
service they provide and the quality of data they provide
• Define data security principles, standards and sharing policies.
Data Governance
Lead
Management personnel who
heads the Data Governance
Program Office
• Leads the efforts to distill the data management goals of the
enterprise as articulated by the Executive Committee Information
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

RACI Definition
RACI Designations Definition
Responsible (R)
A group that is responsible for doing the work required to complete the task. The work required can
be split across several responsible groups.
Accountable (A)
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
that the responsible group completes.
Consulted (C)
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
groups' opinions, as they can provide input and subject matter expertise.
Informed (I)
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
group(s).
The vertical axis (left-hand column) specifies high-level tasks or deliverables while the horizontal axis specifies
roles or organizations.
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.

Function
Executive
Committee
Data
Governance
Committee/
Board
Data
Governance
Lead
Data Owner
Data
Steward
Data
Custodian
Enterprise
Data
Architect
Comments
1
Identify KDEs for DQ
monitoring
I A R R R R R
2
Develop DQ validation
rules
I C R A, R C C C
3
Define profiling metrics
and thresholds
I A R C C C
4
Determine profiling
point(s) in the dataflow
I I C C C A, R
5 Profile data (History) I I I R A, R I A one-time exercise
6
Review/monitor results,
and tweak validation
rules and thresholds
I A, R R R R R C
7
Initiate Issue
Resolution
C A, R C C C C
8 Profile data (Current) I I I R A, R I
A recurring activity
performed each
time data transfers
take place
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.
RACI Diagram

Organization model – Role Inventory
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
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.

Accountabilities & Responsibilities
▶ Strong knowledge of industry and business data domains and
processes
▶ Experience with business financial management, compliance and
regulatory requirements, program management, change
management and risk management
▶ Experience in negotiation and conflict management
▶ Demonstrates thought leadership, diplomacy and strategic thinking
▶ Knowledge of data management disciplines such as data
governance and quality, business intelligence, data architecture and
strategy, data security and privacy, data integration, master data
management and metadata management
▶ Background and career in data management or architecture,
business intelligence or data governance/data quality
▶ Ability to coordinate and lead Data Domain Executives and other
stakeholders to adopt business processes and systems supporting
governance requirements
Example Skills Requirements
▶ Accountable and responsible for establishing the enterprise/LOB data
strategy and governance program
▶ Defines the organization's vision and sets objectives, priorities and
scope for the data management program
▶ Defines policies, standards and processes to cover all areas of data
management
▶ Prepares and presents materials in support of Executive Steering
Committee and Board
▶ Accountable and responsible for ensuring that all relevant
stakeholders endorse and adopt the principles and objectives of the
data management strategy
▶ Defines the data domains included in the data management program
of the organization
▶ Defines the method by which the governance model is supervised by
the organization
▶ Establishes the mechanism by which data management is funded and
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
Chief Data Officer

▶ 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
▶ Responsible for assignment and delegating to the appropriate Data
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
▶ Has breadth of knowledge of data in the data domain(s) based on
usage
▶ Ability to coordinate and lead Data Domain Leads and others to
collectively support the responsibilities
▶ Required to have knowledge of the business processes and
industry experience related to the data domain(s)
Domain Executive (Domain Owner)

▶ Accountable to the Data Domain Executive
▶ Responsible for collaborating with Business Process Owners and Data
Domain Executives to translate business requirements into the
appropriate data requirements
▶ Responsible for understanding, disseminating and adopting
applicable policies, standards and processes corresponding to the
data domain(s)
▶ Responsible for working with the Chief Information Architect to
review data profiling results and recommend authoritative data
source(s) for the attributes/elements within the data domain(s)
▶ Responsible for providing inputs (e.g. data impact analysis) to Data
Domain Executive(s) for data quality issue prioritization
▶ Responsible for monitoring changes to business data requirements
and ensuring that change and release management activities are
executed for the data domain(s)
▶ Responsible for working in partnership with Chief Information
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)
▶ Understands how data is used within business processes and its
impact on desired business process outcomes
▶ Experience with data analysis and data quality assessment
techniques
▶ Ability to manage a complex workload that includes multiple tasks
and conflicting priorities with minimal supervision
▶ Capable of examining data trends to determine the root cause of
variations
▶ Skilled in conceptualizing, documenting and presenting creative
solutions
▶ Education and training related to business process improvement
and its desired business outcomes, and quality-assurance methods
(for example, popular quality-oriented methodologies such as Six
Sigma), are preferred
▶ Possesses knowledge of data lifecycle activities such as data
definitions, data lineage and data quality
Domain Lead (not always required)

▶ Accountable to the Data Domain Lead for compliance with the
enterprise data management strategy
▶ Responsible for understanding, disseminating and adopting
applicable policies, standards and processes corresponding to the
data domain(s)
▶ Responsible for identifying critical data elements (CDEs) and
decomposing attributes
▶ Responsible for defining the data quality validation rules, thresholds
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
techniques
variations
Data Steward

▶ Data Custodians should be responsible for the implementation of all
aspects of data governance and data quality for their assigned
application or technology process that includes:
▶ The technical definition and metadata of Key Data Elements(KDEs)
including data lineage
▶ The design and implementation of Data Quality Key Performance
Indicators (DQ KPIs) to measure the data quality of KDEs.
▶ The design and implementation of assessment, management,
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
techniques
variations
Data Custodian

▶ 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
▶ Accountable for defining the approach for data profiling, supervising
data profiling process and providing support to personnel performing
data profiling (e.g. advising data profiling tools/training, interpreting
requirements and rules)
▶ Responsible for recommending authoritative data source for the
attributes/elements of the data domain(s)
▶ Responsible for working with Technology & Operations to gain
authoritative data sources certification and contract agreement
▶ 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
▶ Ability to coordinate with all levels of the organization to design
and deliver technical solutions to business problems
▶ Understands use of architecture principles through database, data
warehouse, or business intelligence concepts and technologies
▶ Experience with enterprise architecture modeling tools as well as
data modeling, mapping and profiling tools
▶ Proven ability to develop, document, and communicate information
(data) models
▶ Possesses knowledge of project management, process
improvement, data modeling, and change management
▶ Education and training in application development (data
manufacturing, data warehouse, data marts, information delivery),
are preferred
Chief Information Architect

▶ 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
▶ Accountable for understanding the data usage in the context of a
business process
▶ Responsible for working with Data Domain Lead(s) to define data
requirements, data quality validation rules, thresholds and service
level agreements for CDEs
▶ Responsible for assessing resources (systems and workforce) ability to
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
▶ Ability to interpret and define complex reporting requirements and
provide appropriate information to Data Domain Executives and
Data Domain Leads to collectively support responsibilities
▶ Strong knowledge of the finance, risk and analytic reporting rules
and processes associated with:
• Accounting & General Ledger
• Profitability & Cross-sell
• Regulatory & Other Disclosure
• Capital & Liquidity
• Operational Risk, Market Risk, Credit Risk,
Counterparty Risk
Business Process Owner

Define Data Policies and Standards

Define Data Policies and Standards
► 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 a client needs will help determine the policies and standards required
► Well written policies and standards are an enforcement tool.
Business Benefits
► 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
orgs. Focus on the policies and starts that are needed to enforce the desired behavior and activates
Chapter Guidance
the context of BCBS 239 and CCAR. This has emphasized the need for data governance policies and standards within organizations.
► 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
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► The objective of this activity is to declare the scope of governance and expectations for governance activities through policies and
standards that are establish clear requirements for practitioners.
► Good policies and standards are specific an measurable.
Definition

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.
Standard
A collection of approved processes, procedures, roles, responsibilities, controls, metrics, reporting, templates and entry/exit criteria used to prescribe consistent and
required behaviors in the definition and usage of data.
Process and
Procedure
Actions performed to operate business functions in a consistent manner. Designed as sustainable data management processes with well-defined and measureable
performance criteria. Assessed for proper execution and ability to evidence adherence to standards. A well-formed procedure includes roles, responsibilities,
controls, reporting metrics and templates.
Objective
Standards
1. Data Change Type
Identification
2. Change Implementation Plan
Creation
3. Change Management Process
Implementation
4. Change Request Tracking and
Metrics
1. KDE Identification
2. Source Identification
3. Business Rule Development
4. Data Quality Threshold
Definition
5. Data Quality Attribute
Registration
6. Data Profiling
7. Data Quality Issue
Management
8. Data Quality Remediation
1. Data Issue Identification and
Capture
2. Issue Remediation Plan
Creation
3. Issue Management Process
Implementation
4. Issue Tracking and Metrics
1. Authoritative source
registration
2. Provisioning point creation
and registration
3. Provision point monitoring
4. Data sourcing and access
5. Data persistence
6. Provisioning point
maintenance
1. Standardization and
representation
2. Authoritative source
registration
3. Provisioning point definition
and maintenance
4. Master data persistence
5. Master data access
1. Requirements definition
2. Define KDE metadata
3. Metadata access
4. Metadata maintenance
1. Define required SLAs
2. Individual SLA definitions
3. SLA monitoring enforcements
4. SLA maintenance
Provide a standard process for
efficiently documenting,
escalating and addressing data-
related change requests
Maximize business outcomes,
improve usability and reduce
time/expenses from excessive
data reconciliation
efficiently documenting,
escalating and addressing data-
related issues to remediation
Provide an environment to
manage data, support business
data reqs and move from an LOB
approach to an enterprise-wide
data environment
Provide an approved,
standardized system in which data
consumers can access quality-
controlled reference data
Provide clarity to data consumers
into what each Key Data Element
specifically means and how it is
recorded
defining, monitoring,
enforcing, and maintaining
SLAs between consumers and
providers
Processes
(illustrative)
1. Data Change Management
process
2. Data change request tracking
process
3. Escalation process
1. Defining, registering and
cataloguing KDEs
2. Data Quality measuring and
monitoring
3. Root cause identification
4. Data Quality remediation
1. Non-compliance to policies
and standards/provisioning
2. Discrepancies to data
definitions
3. Issue tracking process
4. Escalation process
1. Upstream/downstream
identification/ depends
2. Data sourcing/extraction
assessment
3. Data provisioning assessment
1. Creating new golden sources
2. Define source hierarchies and
survivorshiprules
3. Master data change
management
1. Metadata definition
2. Metadata capture/update
3. Data lineage capture/update
4. Metadata change
management
1. Defining scope of services /
partners
2. Establishing SLAs
3. Exception/escalation
processes
Data Quality
Data Change
Management
Data Issue
Management
Data
Provisioning
Master Data Metadata
Service Level
Agreement

The objective of Data Quality Policy is
to maximize business outcomes,
improve usability and reduce time and
expenses associated with excessive
data reconciliation.
The objective of Metadata Policy is
to provide clarity to data consumers
into what each Key Data Element
specifically means and how it is
recorded.
The objective of Data Provisioning
Policy is to provide clarity to data
consumers on the required
locations for accessing quality-
controlled data.
The objective of Reference Data Policy
is to provide and approved,
standardized system where data
consumers can access quality-
controlled reference data.
The objective of Issue Management
Policy is to provide a standard process
for efficiently documenting, escalating,
and remediating data-related issues.
The objective of Change Management
Policy is to provide a standard process
for efficiently documenting, escalating,
and addressing data-related change
requests.
The objective of SLA Management Policy is to
provide a standard process for defining,
monitoring, enforcing, and maintaining Service
Level Agreements between Data Consumers
and Data Providers.
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.
Data Policies and Standards Objectives

DQ01 – KDE identification
DQ02 – Business rule development
DQ03 – Business rule development (target depth)
DQ04 – Quality threshold determination
DQ05 – Data profiling (testing points)
DQ06 – Data quality Attribute Registration
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
MD01 – Requirements definition
MD02 – Define KDE Metadata
MD04 – Metadata access
MD03 – Metadata maintenance
DP01 – Authoritative source registration
DP02 – Provisioning point creation and registration
DP03 – Provisioning point monitoring
DP04 – Data sourcing and access
DP05 – Data persistence
DP06 – Provisioning point maintenance
RD01 – Standardization and representation
RD02 – Authoritative source registration
RD03 – Provisioning point definition and maintenance
RD04 – Reference data persistence
RD05 – Reference data access
IM01 – Issue management process implementation
IM02 – Issue remediation plan and timeline
IM03 – Issue tracking and metrics
CM01 – Change management process implementation
CM02 – Change implementation plan and timeline
CM03 – Change request tracking and metrics
SLA01 – Define required SLA’s
SLA02 – Individual SLA definitions
SLA03 – SLA monitoring enforcements
SLA04 – SLA maintenance
Policies and Standards Inventory

Policies and Standards Framework
Data Quality

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.
Scope The Data Quality policies and standards is applicable to all Key Data Elements
Objective
The objective of Data Quality Policy is to maximize business outcomes, improve usability and reduce time and expenses associated
with excessive data reconciliation.
Critical Data Key business processes where Customer data is a critical component
Data Quality Policies and Standards

ID Policy (Principle) Standard (Criteria)
DQ-01 KDE Identification- The
Customer Focus Group is
responsible for identifying the
Key Data Elements (KDEs) for
their respective business
functions / processes.
The general definition of a KDE is: ‘Data elements that is critical to the successful creation of reports, where data quality issues
with these elements could potentially impact the business.’
Alternatively, KDEs can be: ‘those data elements that drive capital or are used by executive management to make significant
business decisions’.
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.

DQ-02 Data Quality Business Rule
Development- The Lines of
Business must develop and
maintain data quality
business rules for the Key
Data Elements (KDEs) within
respective data domain(s).
Business rules are business-specific verifiable statements that are identified for each Key Data Element (KDE) . Rules are
developed using a data quality business rule/dimension framework. A rule can be created for 1 or more data quality dimension
(e.g., completeness, accuracy, and timeliness).
•Completeness Rules: The degree to which data is required to be populated with a value (e.g., A policy ID is required for all
customers but not prospects) - Metric = % Failure, Failure Count
•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)

DQ-03 Business Rule Development
(Target depth) – The Lines of
Business are responsible for
establishing the target depth
required for business rules that
are being developed.
Target Depth of the required data quality checks for each KDE must be agreed to by all impacted stakeholders prior to
implementation. The minimum level of depth should be applied for all LOB’s which is typically the maximum need of any one
LOB.
Target depth refers to the appropriate level of details and complexity required for the business rules that are developed.
The typical levels of
business rule depth
include (from low to
high complexity):
Dimensions Testing Depth
Completeness Level 1 – Single field validation
• Null/ allowable values
• Valid values
• In – domain
• In Range
Uniqueness
Validity
Logic/ Reasonableness
Level 2 – Validation within an entry / table
• Enforced key rules
• Sequencing
• Cross validation
• Data Obsolescence
Accuracy
Integrity Level 3 – Validation across entities / tables / systems
• Key relationships
• Logical relationships
• Date relationships
• Temporal relationships
Timeliness
Coverage
Comprehensiveness
Level 4 – Reconciliation
• Population completeness
Low
High
Data
Quality
Testing
Depth

DQ-04 Quality threshold determination –
The LOB’s must establish and
record data quality thresholds for
each KDE.
Data Stewards must develop a minimum quality threshold for each KDE / Business process combination.
Data Quality thresholds must be recorded in a centralized repository for future reference and maintenance.
DQ-05 Data Profiling (Testing Points)-
The Data Governance
Organization is responsible for
identifying the appropriate testing
points where data will be profiled.
KDEs must be profiled as close to their original source as possible to ensure that downstream consumers are receiving the
highest quality data.
Examples of testing points of where data can be profiled are: (sources of data (recommended), points of aggregation, areas
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
– The data Governance
Organization must confirm
successful recording of KDE
attributes.
Data Governance Organization must confirm that the following attributes have been recorded:
•Business Process
•KDE Name
•KDE Reason
•Target Depth
•Business Rules
Access to KDE attribute data must be controlled to protect attributes of sensitive KDEs.
• Measurement Metric
• KDE Threshold
• Profiling Points
• Profiling Frequency

DQ-07 Data Profiling (Test Execution)- Tests
must be performed/executed by the
Data Governance Organization using
approved tools, on the Key Data
Elements(KDEs).
Test execution must be performed using approved tools as defined by the Enterprise Data Governance organization. A
standard minimum test execution frequency (typically monthly) must be defined to ensure that test results can be
aggregated and reported.
Test execution is the shared responsibility of both the business and IT and is facilitated by the Data Stewards.
DQ-08 Data Profiling (Enterprise
Scorecards)- The Data Governance
Organization is responsible for
aggregating and publishing the
results of their data quality profiling
efforts in a consistent manner and on
a monthly basis.
Results of profiling to be recorded using enterprise data quality metrics and established thresholds. Enterprise data quality
metrics include (see appendix for additional descriptions):
• Data Quality Materiality - Index representing the amount of materiality that is NOT at risk due to poor data quality
within a business process.
• 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).

DQ-09 Data Quality Issue Management
(Capability) must establish a capability
to capture, manage and escalate high
priority data quality issues across Lines
of Business.
The standard data quality issue management process must be established to ensure data quality issues are effectively
prioritized and remediated (please refer to the Issue Management policies and standards for more information on setting
up a standard process)
The capability must include dedicated resources to manage and track and escalate issues.
DQ-10 Data Quality Issue Management
(Prioritization) must prioritize data
quality issues to determine the scope
of their responsibility.
Will work with Lines of Business to identify high priority issues using a prioritization framework/criteria. An example of
high priority issues are data quality issues which have an impact across Lines of Business and/or have significant
business impact (e.g., reputational risk, regulatory).
DQ-11 Data Quality Remediation- Lines of
Business must remediate data quality
in a timely manner.
Data Stewards are responsible for partnering with the Data Custodians and System Owners on the necessary steps and
timeline for remediating a Data Quality Issue.
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)

Policy and Standards Framework
Metadata

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.
Scope The Metadata policies and standards is applicable to all Key Data Elements
Objective
The objective of Metadata Policy is to provide clarity to data consumers into what each Key Data Element specifically means and how it
is recorded.
Critical Data Customer Key Data Elements
Metadata Policies and Standards

MD-01 Requirements definition –
The Data Governance
Organization must define the
required metadata values to be
defined for each KDE.
Metadata metrics that are common candidates to be captured include:
•Business definition
•Regulatory restrictions
•Data Recording standards (business and IT)
•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 Business's must work together
to define the required metadata
values for each KDE.
All Line of Business's should agree on shared Metadata specifications. Exceptions should be registered depending on the
business need.
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 - Impacted
Line of Business's must approve
all metadata updates, deletions, or
new KDE additions.
There must be a standard Issue management process responsible for recording and escalating issues pertaining to
metadata.
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).

MD-04 Metadata Access -
Metadata must be made available
to data consumers while managing
access to restricted metadata
information.
All Lines of Business must define and implement the correct level of access and control, for sensitive metadata within its
control.
Access to metadata values may be restricted if it divulges information that is not for enterprise consumption (e.g., Metadata
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.

Data Provisioning

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.
Scope The Data Provisioning policies and standards will be applicable to all data assets within the organization.
Objective
The objective of Data Provisioning Policy is to provide clarity to data consumers on the required locations for accessing quality-
controlled data.
Critical Data All Customer data
Data Provisioning Policies and Standards

DP-01 Authoritative Source Registration:
Lines of business must define an
authoritative source status for all
systems that store Key Data
Elements.
Each Line of Business must adhere to the definition and register all owned systems that contain KDEs as to whether they are
an Authoritative Source an End User Computing System (EUC).
•Authoritative Source Definition – An authoritative source of Key Data Elements is a system (or systems) that contain
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.

DP-02 Provisioning Point Creation and
Registration: Standard
Provisioning points must be
created and registered.
Data Stewards are responsible for providing their usage requirements for Key Data Elements so that Data Custodians can
create the appropriate data provisioning point. These usage requirements include:
•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.

DP-03 Provisioning Point Monitoring:
Provisioning points must be
monitored for availability and Key
Data Element usage.
Registered provisioning points that distribute Key Data Elements must be reviewed and assigned a provisioning status by the
LOB owner and Data Custodian to designate the system's readiness and appropriateness to share data.
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
must obtain their data from an
approved provisioning point.
Key Data Elements must only be sourced from registered Provisioning Points.
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
are responsible for developing
persistence requirements for the
data they use.
Data Stewards are responsible for developing, maintaining, and communicating persistency requirements.
The typical persistence requirements vary by system type:
•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.

DP-06 Provisioning Point Maintenance:
All new KDEs must have an
approved provisioning point
defined and registered.
All data sourcing requests for new KDEs must be submitted to the Data Stewards for review and ratification.
The sourcing requests must contain the following requirements:
• 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.

Reference Data

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.
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
Objective
The objective of Reference Data Policy is to provide and approved, standardized system where data consumers can access quality-
controlled reference data.
Critical Data External data that enhances Customer
Reference Data Policies and Standards

RD-01 Standardization and
Representation: Sources of
reference data must be defined,
standardized and shared.
Data stewards for reference data domains and attributes will be accountable for defining the structure and representation of
reference data.
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
Registration: Lines of business
are responsible for defining and
registering systems that
produce Reference Data as
authoritative sources.
Authoritative sources will be defined for reference data and will be registered in the enterprise system of record for application
identification.
Refer to the data provisioning Policies and Standards for additional information on declaring Authoritative Sources.
RD-03 Provisioning Point Definition
and Maintenance: Reference
Data Provisioning Points must
be defined and created.
Data Custodians must provide standard provisioning points for reference data. Please refer to the data provisioning policies
and standards for details of provisioning point registration and maintenance.

RD-04 Reference Data Persistence: Lines
of Business are responsible for
developing persistence
requirements for the reference data
they use.
Data Stewards are responsible for developing, maintaining, and communicating persistency requirements.
Please refer to the Data Provisioning Policies and Standards for additional detail on implementing data persistence
requirements for all data domains.
RD-05 Reference Data Access: Reference
Data must only be accessed from
an approved provisioning point.
All access requirements (incl. controls) must conform to the data provisioning Policies and standards.

Issue Management

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.
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.
Objective
The objective of Issue Management Policy is to provide a standard process for efficiently documenting, escalating, and remediating
data-related issues.
Issue Mgmt Policies and Standards

IM-01 Issues Management Process
Implementation: A standard,
centralized issue
management process must
be created and enforced.
There must be a standardized, centralized, and clear issue management process, this process must be agreed upon by the Data
Governance Organization and adopted by all participating LOBs. The process must include the following key activities:
•Standardized Issue Description – All issues should be logged describing the issue, the exact circumstance or scenario that lead
to the issue and the perceived impact of the issue (e.g., a Data Quality Issue should describe exactly what KDE was being
analyzed 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
Timelines: All issues require
a plan for remediation to
ensure a comprehensive fix
is completed.
Each time there is an issue to be addressed a remediation plan must be created and followed.
Data Stewards must define the corrective actions if they are the sole owners of the data, or in coordination with the Data
Governance Organization if it affects more than one Line of Business.
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.

IM- 03 Issue Tracking and Metrics:
Standard issue monitoring and
reporting must be in place for
effective issue management
There should be a scorecard with metrics to monitor new and in-process issues.
Detailed Metrics should include:
• 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

Change Management

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.
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.
Objective
The objective of Change Management Policy is to provide a standard process for efficiently documenting, escalating, and addressing
data-related change requests.
Change Mgmt Policies and Standards

CM-01 Change Management Process
Implementation: A centralized
standard change management
process must be created and
enforced.
There must be a centralized, standardized and clear data change management process, this process must be agreed upon
by the Data Governance Organization and adopted by all participating LOBs. The process must include the following key
activities:
•Standardized Change Request Description – All change requests should be logged describing the requested change, the
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
Timeline: All change requests
require a plan for implementation
to ensure the right resources are
available to implement the change.
Each time there is a change to be addressed an implementation plan must be created and followed.
Change implementation plan should include:
• Budget, Estimate, and Resource Requirements
• Implementation Timeline
•Testing Plan
• Deployment Plan

CM- 03 Change Request Tracking and
Metrics: Standard change request
monitoring and reporting must be
in place to effectively manage and
sustain ongoing change efforts.
There must be a status report with metrics to monitor new and in-process change requests .Detailed Change Metrics should
include:
• Change request type (e.g., Policy / Standards Update, new KDE request etc.)
• 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

Service Level Agreement

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.
Scope The SLA Management policies standards will be applicable to the data used by any critical business process.
Objective
The objective of SLA Management Policy is to provide a standard process for defining, monitoring, enforcing, and maintaining Service
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 Policies and Standards

SLA-01 Declare Required SLAs: SLAs must
be established to govern all critical
business processes.
SLAs must govern data related agreements between impacted parties for all critical business processes where timeliness
is required. Key SLA candidates include:
•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
terms must be negotiated and
agreed to between impacted parties
prior to ratification.
Minimum SLAs must be established between impacted parties (e.g., Data Stewards, Data Custodians, Operations,
Support) including SLA violation impacts.
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:
SLAs must be actively monitored
and enforced to ensure effective
business processes.
SLA adherence is monitored by the business process owners and issues are escalated via the issue management
process.
An SLA scorecard will monitor SLA adherence over time and be communicated to the Data Governance Organization. This
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.

SLA- 04 SLA Maintenance: SLAs
agreements must be
maintained to ensure relevance
and feasibility of adherence
SLAs must be revisited periodically to ensure they reflect current business process needs and priorities.
SLAs no longer required should be terminated to eliminate confusion and simplify processes (e.g., a report previously
required for regulatory reasons is no longer needed).
All new business processes should be analyzed for any required new SLAs.

Policies and Standards
Roll Out Strategy
Function Name Activities Input Output/ Deliverables* Comments
Establish a DG
body
• Assign individuals to roles in the DG organization
• Conduct kickoff meetings for WGs and
Committees, and establish long term agenda
• Organization model
(with roles and
responsibilities)
• DG Charter
• Organization model
(with individuals
assigned to the roles)
• Meeting agenda and
minutes
The goals/vision of the
DG organization should
reiterated in the kickoff
meetings.
Rollout DG policy
and standards
• Ratify DG policy, and publish compliance
schedule for stakeholders under policy’s purview
• Publish set of standards for adoption
• Assign accountability to requisite stakeholders
for standards adoption
• DG Policy
• Set of DG standards
Document policy
exceptions. For the non-
compliant, develop
timeline for compliance.
Execute DG
Processes and
Procedures
• Provide training on the formal DG processes to
impacted stakeholders
• Perform functions defined in the DG processes
(e.g., for Issue Resolution, collate issues into a
central issue log, assign owners to issues,
manage issues through resolution).
• Monitor process for improvement opportunities
• Process flows
• RACI charts
• Procedure documents
• Various (e.g., DQ
dashboards)
As the DG processes get
deployed, modifications/
enhancements may be
required to address
specific nuances of the
processes. Such
modifications will reduce
over time with the maturity
of the program.
Conduct training
and spread DG
awareness
• Provide requisite training to DG organization
members
• 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
• Training materials • Training
• Communiqués
Include success stories in
the communiqués
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..

Goals and Objectives:
• Use a practical approach to test & prove the key data governance
components that are in development: Policy & Standards, Roles &
Responsibilities, Key data elements processes.
• Prove out key interactions between the business process owners,
data custodian, data stewards, data users and source system
application owners.
• Determine which governance routines will be effective.
Approach:
• Conduct workshops to execute use cases specific to the selected
pilot program
• Use of simplified processes and tools as opposed to formalities
• Capture learning from pilot and establish next steps for expanding
governance
Workshop #1 Workshop #2
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Debrief
Prepare Workshops & Participants Debrief Workshop #3 Debrief
Scope & Assumptions:
• Eight week pilot consisting of (3) workshops within the following
scope
• Maximum of 2 systems, 15 data elements and 30 business rules
• Platform to profile data and execute DQ business rules
• Will need project resources to fully participate
In-Scope Data Domains
Workstream:
Data Domain Source
Customer Data TBD
Finance Data N/A
Risk Data N/A
Operations Data N/A
Roles and Participants
Role Name
Chief Data Officer
Data Governance Committee (EDO Core Team)
CRM Project Manager
Key data governance roles by area
Area Data User App Owner Custodian Steward
TBD TBD TBD TBD Keith Gaydica
Pilot Activities (Use Cases)
Description Status Templates (Docs)
1. Update project plan and scope statements with data management activities Not started
2. Finalize role assignments Not started
3. Identify key data elements (define critical data) Not started
4. Register source and target enterprise data assets (define critical data) Not started
5. Define Data Quality business rules Not started
6. Execute business rules and create Data Quality metrics Not started
7. Review pilot and update policies, standards and processes as applicable Not started
KDE and EDA identification
and registration
Measuring Success G
Description Value Trend
% of Roles Assigned ▲
% of KDEs documented and registered ▲
% of EDAs identified and registered ►
% of Enterprise EDAs used ▼
% of Use Cases Completed ►
Timeline:
DQ Metrics and scorecards,
data issues logging, pilot
debrief
DQ Business Rules creation
Pilot Project-Plan & Participants,
ownership assignment
Final touchpoint
Additional work product: Updated project plan / scope statements with data management
Policies and Standards
Example Pilot Program

Establish Key Processes and Procedures

Establish Key Processes and Procedures
Section Introduction –
► The foundational processes of change management and issue management are what make data governance actually be able to solve
business problems.
► 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.
Business Benefits
► Where possible use existing processes at the client to handle data governance activities
Chapter Guidance
► 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.
► Clients looking for a more sustainable and cost effective approach to data governance are beginning to build it into their SDLC
processes and tollgates.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► There are key processes that need to be set up to enable governance to be ‘real’. These processes include the processes to declare
and 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.
Definition

Implement issue management and change
management
► 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
criticality and sensitivity
► 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
Issue
Management
► 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.
► Corporate leaders are seeking to leverage their firm’s data resources and regulators are pursuing
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.
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.

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?
What is NOT a Data Issue?
• Individual Data defects
• Business processes issues
• Data base performance issues
• System issues/defects that do not impact data, data quality or data movement controls
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 with data quality, data movement
controls, data lineage, metadata, data integrity, regulatory and risk reporting, data
reconciliation, etc.
Issues are not easily defined.
DGS will use reviews and engage
different teams to ensure that
issues are validated and assigned to
the right teams to remediate

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.
Request
Type
Requestor
(Corporate or otherwise)
Issues Log
Issue
• An “Issue” is a material problem with an existing (“production”
process, platform, or data set
• Data Issues will be centrally logged, prioritized and tracked
• Requestors and stakeholders will have visibility to action plans,
priorities, and accountable parties
• Issue will be reviewed for clarity,
completeness, appropriateness
• Priority and severity will be established
• Initial Ownership will be established
Establish Action
Plan
Resolve Issue
• Owner will define action plan and dates
• Ownership will shift as needed based on
research and validation
• Action plan changes will be reviewed with
stakeholders
• SLAs will be developed for establishing action
plans (but not for issue resolution) , and will
be based on priorities
Mgmt.
Reportin
g
Action
Plans,
Status,
Ownership
Updates
• Efforts will be structured and monitored in
priority order
• Data Officers / Committees will prioritize and
act as stakeholder groups
• Portfolio mgmt. routines will monitor and
report progress
• Resolution may become a project and require
a start request
Structure Initiative
Request
Committee Review
and Prioritization
Structure and
Execute Initiative
• Requestor will engage with
appropriate Data Officer to create a
“Start Request”
• Request documents problem
statement, impact, scope assumptions,
dependencies, funding, and impacted
groups across Wholesale
New /
Change
• A “Change” is a new or changing requirement
• Changes will be structured into initiatives that must
be sponsored, funded, prioritized and tracked by
stakeholders
• Data Officer will shepherd the request
through applicable committees for
prioritization and approvals
• Project lead (identified within “Start
Request”) is accountable to execute
the work
• Wholesale routines (Committees and
supporting Program routines) will
monitor progress; stakeholder groups
will manage the initiative
Escalation as
needed
Material work efforts
Implement issue 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.
Implement issue management and change
management
Identification and Categorization Issue Remediation Issue Tracking Issue Reporting
Issue Management Framework
The issue identification and
categorization process
captures information
regarding the issue and
categorizes the identified issue
based on criticality and
sensitivity.
Key Components include (but
are not limited to):
• Issue Entry – Potential inputs
to the Issue Management
process
• Mandate / scope of issues
• Prioritization
• Issue Escalation process
• Roles and responsibilities
• Controls
The issue remediation
planning phase involves
coordinating the management
and remediation of issues.
The Phases include:
• Validate initial findings and
perform deep dive analysis
• Develop remediation strategy
• Perform source system analysis
• Cleanse dating
• Validation fixes & monitor
results
The issue tracking enables the
team to track key attributes of
issues including (but not
limited to):
• Issue type
• Owner
• Severity
• Escalation level
• BU/data mart/data warehouse
• Expected resolution
Issue Reporting enables the
team to monitor progress of
remediation efforts and tracks
results for strategic planning
purposes

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)

Issue Remediation – High Level Summary
Coordinates the management and remediation of issues
Remediation Framework illustrated below:
Validate Initial
Findings and
Perform Deep Dive
Analysis
Develop
Remediation
Strategy
Perform Source
System Analysis
Fix Issue
Validate Fixes &
Monitor Results
Key
Activities
2 3 4 5
1
• Validate initial findings with
business unit / functional
area SMEs.
• Perform deep dive analysis
and root cause analysis to
identify cause of the issues
and location of the issue.
• Identify a strategy to tackle
the issue.
• Determine the short term
and long term remediation
plan based on the issue
impact.
• Socialize plan with users
and the executive oversight
team
• Analyze the source system
for similar issues.
• Analyze the source systems
and other toll-gates for
viability of remediation
action implementation.
• Incorporate additional
checks and controls to
capture similar exceptions.
• Based on the analysis,
perform remediation actions
per the remediation plan.
• Determine the effectiveness
of the remediation through
close monitoring and
revalidation of the checks
and controls.
• Validate completion of the
remediation actions.
• Confirm results with
business unit / functional
area SMEs. Socialize the
results to the users and the
executive oversight team.
• Monitor issues at toll-gates
to validate fixes.
Remediation Framework

IssueTracking – High Level Summary
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
Monitors progress of remediation efforts and tracks results for strategic planning purposes by recording attributes

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)

Integration with SDLC
Objective and benefits
Businesses have been spending significant amount of time an energy applying the principles of effective data governance to
Production
This enabler provides a methodology for integrating key Data Governance activities into a solution development lifecycle (SDLC)
engagement that creates, modifies, or consumes data will proactively apply the principles of DG will deploy their solution to
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

Methodology
Identify
Design
Diagnose
Deliver
Sustain
• Data impact is measured and
Investments are prioritized
• Governance Engagement
Questionnaire, Prioritization Charts,
High Level Roadmap
• Level of governance involvement is
assessed and estimated
• Impact Assessment, Scope of work,
Agreed issues, Roadmap, Initial
Cost estimates
• Governancestandardsdocumentedas
requirementsandspecifications
• BusinessRequirementsDocument,
FunctionalRequirementsDocument,
SystemRequirementsSpecifications
• Implementation aspects are
planned, tested and executed
• Technical Design Document,
Deployment Plan, Testing Results,
Delivery Artifacts
The following pages provide details on steps and artifacts for each SDLC Phase.
• Governance activities are performed,
certified and improved
• Post-implementation Reviews,
Change Control, Improvement Plans

Identify
Governance Engagement Questionnaire
During the Identify Phase, the data impact is measured and
investments are prioritized
• 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
• These results must be presented to the Executive Committee who selected which projects get tentative
funding and are approved to proceed
• 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
Identify
Design
Diagnose
Deliver
Sustain

Diagnose
Identify
Design
Diagnose
Deliver
Sustain
During the Diagnose Phase, the level of data governance involvement
is assessed and estimated
• The Project Manager completes a detailed assessment questionnaire to determine whether or not the
Data Governance Organization involvement is needed, and at what level
• 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
stakeholders
• Data Governanceaspectsare then incorporatedintoinitialartifactssuchas summaryof the Impact Assessment,
Scopeof work, Agreedissues,Roadmap and InitialCost estimates
Impact Assessment Document

Design Phase (1 / 3)
Business Requirements Document
Identify
Design
Diagnose
Deliver
Sustain
During the Design Phase, data governance standards are documented
as considerations to requirements/specifications
• The BusinessAnalystworkswith the Data GovernanceOrganizationto documentthe listof data governance
standardsthat the projectmust complywith,acrossvariousdata managementdisciplines
• The compliance with those standards may be prioritized on the basis of its business impact
• 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 managementdisciplines
Continues on next
page

Functional Requirements Document
Identify
Design
Diagnose
Deliver
Sustain
• 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
• Features are documentedashigh-leveldescriptionsof what isneededforan optimumfeasiblesolution,
omitting any design or implementation details on how is to do it
• 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
Continues on next
page

System Requirements Specifications
Identify
Design
Diagnose
Deliver
Sustain
• The Lead Developer or Architect translates the governance functional requirements into formal design
notations on how the system is to do it
• Featuresare definedas use casesand includescreenmock-upsfor conceptualizationof eachfunctionality,
and non-functional requirements are also incorporated
• Both are documented at the System Requirements Specifications, and can also be reflected at Updated
Costs estimates and Release Plan schedules
Continues on next
page

Delivery Phase
Identify
Design
Diagnose
Deliver
Sustain
Technical Design Document
During the Delivery Phase, implementation aspects of the data
governance standards are planned, tested and executed
• The Architectand Developerstranslatesthe designnotationsintoformalimplementationspecifications,while
the DeliveryManagertranslatesit into a implementationstrategy
• Governance-relateddataisincorporatedinto conceptualand logicalrepresentationsof entitiesand
relationship,alongwith governance-drivenimplementationdetailswhichare documented at the Technical
Design Document, sometimes called Technical Design Specifications
• 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

Iintegration with SDLC
Sustain Phase
Final Operational Document
Identify
Design
Diagnose
Deliver
Sustain
During the Sustain Phase, the planned governance activities are
performed, certified and possibly improved
• The Line-of-Business team executes day-to-day governance related activities in the production
environment, ensuring that the implemented design operates as intended
• Performance gaps are identified through on-going monitoring, and addressed through remediation and
production-support activities, as part of Post-implementation Reviews, Change Control and
Improvement Plans
• The Data Governance Organization is responsible for post-release certification activities, while the Line-of-
Business team is responsible for training activities and artifacts

Execute Data Quality
To address at a minimum the following common issues:
► Poor business decisions based on data duplication and inaccuracies
► 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
Business Benefits
► 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
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.
Chapter Guidance
the context of BCBS 239 and CCAR. This has emphasized the need for data governance capabilities including evidence of data
quality measurement routines.
Industry Trends
► Bilal Khan
► Alexander Tsinman
► Srikaanth Santhanam
► Pradeep Karunanidhi
► Eric Fisher
Key Contacts
► 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 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.
Definition
► Kiet Pham

Source Data & Domain Activation

Data Sourcing
► 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
► Influences all data sourcing decisions
► Prioritizes consistent and simple data governance including lineage, metadata, policies, and procedures
Business Benefits
► This playbook can be used to discuss the need and purpose of a governed ADS program as well as an accelerator for establishing
and deploying ADSs within an organization.
Playbook Guidance
► 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.
► 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.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► Systematic data sourcing is a planned approach for placement, delivery and consumption of shared information for specific business.
► Data sources are designated as authoritative data sources (ADS) through a comprehensive process of governance and approval.
Definition
► Saurabh Agarwal
► Jeff Harmon
► John Bell
► Vamsi Illindala

Activate Domains
► 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.
► 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.
Business Benefits
► A detailed process for domain activation can be seen in the domain activation playbook.
Chapter Guidance
► 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.
► 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.
Industry Trends
► Mark Carson
► Shobhan Dutta
► Lisa Cook
► Ryan Duffy
Key Contacts
► A Data Domain is a logical grouping of data elements based on shared characteristics and context that facilitates management and
governance.
► Data domains create a common understanding and usage of data across lines of business, business processes, and systems.
Definition

Capture & Test Metadata

Capture Metadata – Factory Approach
► 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.
► 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.
Business Benefits
► 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.
► 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.
Chapter Guidance
► 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
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.
Industry Trends
► Mark Carson
► Patrick Shannon
► Jesse Blue
Key Contacts
► The objective of the Metadata Factory Playbook is to provide an operating model and set of core procedures and standards to facilitate
the collection of metadata for a report, data domain, or data process.
Definition

Test Metadata and Controls
► 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.
► 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.
Business Benefits
► Reference the Data and Controls testing playbook for detailed approaches for testing design, execution, and reporting.
Chapter Guidance
► 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
► Organizations are looking for ways to maximize coverage of testing, while optimizing the balance between tools/automation and more
costly, labor-intensive testing.
Industry Trends
► Tripp Harris
► Saurabh Agarwal
► John Bell
Key Contacts
► Testing is used to demonstrate quality of the metadata, validate controls for operational and design effectiveness, and perform data
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.
Definition

Next Gen industry trends and
market demands

Evolution Of Data Strategy
Next Gen – industry trends & disruptions
Next
Gen
Solution
Spectrum
Diverse Data
Ability to store and process diverse data types that include
unstructured / semi-structured data and leverage
technologies like Optical Character Recognition (OCR)
Data Lake Based Platform
Ability to scale infrastructure on-demand, while making it
cheaper in the long run (i.e., cloud)
Next Gen Data Management
Ability to perform real time Data Management through AI /
Machine Learning based technologies
Enterprise Wide Data Delivery
Ability to report out and analyze significantly more
historical data and additional types of data for better
business insights through self-service platforms
New Digital
Channels
Traditional batch processing and
reporting of data is inadequate in
meeting the real-time information
requirements for the new digital
channels
Volume and
velocity
As volume and velocity of data
increases, the traditional methods
of periodic data integration and
prioritization becomes impractical
Need for
Automation
Increased automation is replacing
manual data processes which are
still being assessed and optimized
across the enterprise
External
Exposure
Current information access
requirements may no longer be
sufficient or applicable due to
increased exposure to external
entities
Emerging
Technologies
Data Management organizations
are being restructured to include a
correct mix of resources in legacy
and emerging technologies
Omni-channel Data
Delivery
Traditional ‘off-line’ data
management and data quality
processes are unable to keep
pace with new demands of omni-
channel instantaneous data delivery
 Expanding scope beyond Risk & Regulatory
agendas to include additional data types, which
includes semi-structured and unstructured data
 Increasing pressure to reduce cost and eliminate
fatigue associated with traditional manual data
management
 Investing in skill development and talent
acquisition to meet demand for new technologies
and capabilities
 Embracing new technologies and architectural
patterns: cloud first mindset, move towards big
data environments, focus on security, reduction
in manual activities, introduction to Fintech
Business
Challenges
Industry
Trends
High Speed Computation Engines
Ability to perform real time change data capture and data
transformation

► AI enabled real time Data Management, in
line data quality, dynamic data mapping,
tagging, indexing, data cataloging, and
provisioning
► Support for Curated data sets and Enhanced
audit trails and lineage
► Data lake based architecture is robust and
scalable; ensures full fidelity of source
data in an immutable zone, and can be
deployed on hybrid cloud/on-prem
infrastructure
► Supports Multi speed data processing,
Microservices, and advanced data security
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.
Next Gen
Data
AI / Machine
Learning Based
Data Management
Diverse
Data
High Speed
Computation
Engines
Enterprise
Wide Data
Delivery
Data Lake
Based Platform
► Provides support for structured and
semi-structured, and unstructured data
(such as, signal, social media, voice /
speech, text, web logs, encrypted packets,
etc.)
► Connected streams (pushing data in real time
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
► Data made available to the enterprise
through self-service analytics and
reporting, advanced visualization
capabilities, virtualization, and context
based data delivery

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

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.
Infrastructure& Foundational Capabilities: Scalable
& Secure Platforms, Managing Data as a Corporate
Asset
Robust Data Management & Governance, “Fit for Use”
Data Ecosystem
BusinessIntelligence: Reporting, historical trend
analysis & forecasting
Ad-hoc queries, Dashboards and Scorecards
Discovery & Insights: Revenue Growth, Enhanced Client
Experiences, Product & Channel Evolution
Machine learning, Cognitive Analytics, Advanced Modeling
Simulations
Executive
Insights
Information
consumption
Data Management &
Governance
Data
Creation
Data Integration Data Provisioning
Data
Storage
Data
Usage
Data
Retirement
Data
Security,
Quality,
Risk
Analytics
Platform
Reports &
Dashboards
Enabling Capabilities
Investmentin the Next Gen
Data platform establishes the
foundation
Valueis unlocked from the
investments by developing analytical
capabilities that derive insights to
drive action
INVESTMENT
VALUE
Cost savings are realized from
decommissioning / arresting the
growth of legacy systems
ValueProposition

Next Generation Data Benefits
Unlock business value, increase adoption and lower cost
*
* Based on Industry Case Studies
**
** As per Gartner, Forrester and IDC reports

Next Gen Data Architecture
and Use Cases

Structured Data
Sources
EDW
ARCHITECTURE
Data Sources
Origination Systems
Transactional Platforms
Cloud Platforms
MDM Platforms
Operational Data Platforms
EDW / DW
Data Marts
Landing Staging
XML
TXT / DAT
CSV
Other
Target Data
Type
Stage
File Type
Third Normal
Form
3 NF
No Relationships
Enforced
Relationships
Enforced
Master / Reference Data
Integrated
Data Hub
Data Integration
Enterprise Data Warehouse
2 NF Dimensions
Pre-Process
Compute Offload
Archive Offload
Deep Exploration
Targets
Reporting
Dashboards
Data Marts
DQ Dashboard
Enterprise Data
Warehouse
Data Warehouse
Augment
ETL
Batch
|
Near
Real
Time
|
Real
Time
Data Integration
ETL
Batch
|
Near
Real
Time
|
Real
Time
Data Sources
Structured Data
Sources
Unstructured Data
Sources
CCAR
Customer
Transactions
Other
Data Storage
Enterprise Data Lake
Meta
Data
Tagging
…
HDFS / Batch
HBase / Speed
…
Snapshot
Granular Data
Targets
Self Service Platforms
Legacy BI Platforms
Visualization Platforms
Data Mapping
Business Process Data
Modeling
Data
Analytics
Reporting
DATA
LAKE
ARCHITECTURE
Data Ingestion Governance
Framework
Semantic Layer (Optional)
Data Storage EDW
Business Reporting Data
Modeling
What’s different about Next Generation Data
Traditional Enterprise Data Warehouse (EDW) Vs. Data Lake

Integrated dashboard enables users to analyze financial performance and resource constraints across
enterprise hierarchies and planning scenarios and horizons
Financial Measurement
12-24 Months
Monitoring
Actuals Long-Term
Short-Term
30-90 Days
1-5 Days
Daily/Monthly
Scenario Horizon
CFO Insights
Performance
Profitability
Efficiency
Growth
Capital
Funding
Constraint
• Net Income
• RaROC / EVA
• ROE / ROA
• EPS
• Efficiency Ratio
• Operating Margin
• Net Interest
Margin
• Revenue Growth
• Earnings Volatility
• RWA
Growth
• HQLA
• Unfunded Commitments
• LCR Ratio
• RWA
• CET1 Ratio
• Leverage Exposure
Customer Product Business
Channel Geography Investment
Stress
Scenario
Baseline
Scenario
Scenario Analysis
Trend Analysis Comparative Analysis Scenario Analysis
Sensitivity Analysis What-if Analysis Anomaly Detection
Early Warning Predictive Modeling Pattern Recognition
Dimension
Scenario
Condition
Chandra

Note: Dashboards are for illustrative purposes only and all figures presented are hypothetical
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
CFO insights

Insurance FRAC Solution
What was the need ?
► Life insurers typically use multiple modelling platforms such as Polysystems, Moses,
GGY AXIS and Prophet. An common reporting solution external to these modelling
systems is therefore a valuable solution
► However, due to distinct target operating models, and little experience with new
platforms, “end to end” implementations have been scarce and they will continue to
have disparate systems until they see viability in an “end to end” vendor solution
► This would mean data would exist in different formats in different systems for some
time which calls for a solution that would help hold things together and create an
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
Hardware/Software
Platform :
► Azure HD Insight ( 4 Node Cluster)
Components:
► Apache Spark (2.1.1)
► Apache Sqoop
► Hive on Tez
► Tableau
► MySQL
► Scala 2.11
► Java 1.8.0
► Python 2.7.12
► IntelliJ IDEA
► Ambari
LIRA an effective solution framework for Life Actuarial data and reporting needs
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

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
Artificial Intelligence (AI) is defined as the
science of making computers do things that require
intelligence or reasoning when performed by
humans
Machine Learning (component of AI) is the ability
of computers to self-learn using statistical and
optimization techniques
Predictive Analytics is a form of Advanced
Analytics that leverages data mining, statistics,
modeling, and artificial intelligence to analyze
current and/or historical data to predict future
events
Data Sources
Big Data supports new data types that were
once inaccessible, which allows AI and
Advanced Analytics to leverage more sources
of data to drive business value.
Big Data Platform
AI & Machine Learning Platform
Big Data capabilities such as high volume storage and
schema-on-read data access allows AI platforms to
flexibly access massive data sets in real-time.
Advanced Analytics
Big Data allows the storage, processing, and
access to large volumes of unstructured data,
which is required by Predictive Analytics to
analyze data to predict future events.
Overview of AI, Machine Learning and Predictive Analytics
How Big Data Enables AI, Machine Learning and Predictive Analytics
Chandra

EY’s Strategic Capability Development
Artificial Intelligence and Advanced Analytics

Sampling of Case Studies

Business Methodology Cloud DevOps Model Data Classification Process Semantic Layer Approach and
Metadata Framework
MVP and Sprint Framework
Assisted a large global bank in creating their global credit risk modeling
capabilities using a big data ecosystem on the cloud
Client opportunity / challenge
Outcome and benefits
EY approach / innovation
EY took the following approach to implement a GCP/AWS cloud environment:
► Extended the current batch use cases by adding additional functional and non-functional features through building user stories for use cases
► Assisted in defining an operating model to roll out the future releases of the architecture across priority use cases
► 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
Illustrative artifacts
► Provided an optimized data cloud experience through a commercially viable
solution that is scalable for additional depth of data for prioritized geographical
locations
► Provided data quality enforcement and metadata tagging
1
2
3 4
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.
Chandra

Business Event Level Data Architecture Data Quality and Governance Framework Enterprise Data Management Target Operating Model
EDMC Maturity Model and Capabilities Framework
Data Quality
Data Management Operations
Platform & Architecture
Objectives
Data Management Support Process Areas
DM Goals
Data Management Scope
Data Management Priorities
Strategy & Objectives
Corporate Culture
Communication Strategy
Alignment
Governance Model
Oversight
Organization Model
Governance Structure
Measurement
Human Capital Requirements
Governance Implementation
DM Funding
Funding Model
Business Case
Total Lifecycle Cost of
Ownership
Requirements
Lifecycle
Data Lifecycle
Management
Operational Impact
Data Requirements
Definition
Standards and Procedures
Ontology and Business
Semantics
Business Process and Data
Flows
Areas
Data Change
Management
Data Dependencies
Lifecycle
Promulgation
Data Sourcing
Procurement &
Provider Process
Data Sourcing
Requirements
Architectural Framework
Architectural
Standards
Architectural
Approach
Platform and Integration
Data Management Platform Application Integration Release Management Historical Data
Data Quality Framework
Data Quality Assurance
Defining organization's vision and
overall strategy for data
management, approved and
adopted by stakeholders.
Determining organization
structures, and managing the
components associated with the
implementation of data
management.
Defining the technical
requirements and architectural
framework for integrating data into
business processes.
Determining the approach and
measuring the effectiveness of
processes that ensure timely
delivery of accurate, consistent,
complete data.
Configuration
Management
Requirements
Management
Risk Management
Data Quality Strategy Development
Data Profiling
Data Cleansing
Data Quality
Assessment
Data Quality for
Integration
Data Quality Measurement and Analysis
Dat a governance Dat a management Dat a qualit y Data archit ect ure Dat a usage
Program office
Enterprise data management
oProgram management
Solutions that include definitions ar ound data
owner ship, standar ds and policies. Also
includes pr ocesses and pr ocedur es for the
cr eation, movement, usage, stor age,
retention and disposal of information.
Descr ibes how data will be collected, stor ed,
managed and distr ibuted for all solutions in the
ar chitectur e. Includes defining str ategies ar ound
metadata, reference and master data management
and how best to ar chitect the data consolidation
points.
Examines completeness, validity, consistency,
timeliness and accur acy of enterpr isedata as it
moves fr om sour ceto reporting. Defines data
enr ichment and enhancement str ategies to
addr ess any issues with well defined contr ol
points.
Deter mines the over all conceptual, logical and
physical view of the enter pr ise. Defines
standar ds and policies on all ar chitectur e
components including solution
recommendations, implementation patterns and
common ser vicing.
Under stands business objectives and goals to
define how data will used for r epor ting and
suppor t analysis activities for all functional ar eas
including management, financial, oper ational and
risk.
Organizational model
o Organizational structure
o Roles and responsibilities
o Governance routines
o Regulatory control and monitoring
Standards and policies
o Accountability policy
o Data quality standards
o Metadata standards
o Data provisioning standards
o Data movement standards
o Reference data standards
o Unstructured data standards
o Key data elements standards
Processes and procedures
o Change management and
communication processes
o Planning and budgeting processes
o Resource allocation process
o Issue management process
o Remediation process
Data profiling and analysis
o Data profiling strategy
o Data profiling design and
development
o Data profiling operations
o Data profiling vendor management
o Data profiling tool evaluation
o Rule validation services
Cleansing
o Root cause analysis services
o Issue management services
o Data cleansing tools and methods
Controls
o Data management control definition
o Software delivery life cycle
integration
Enrichment and enhancement
o Data quality monitoring strategy
o Data quality scorecard design and
development
o Data quality scorecard operations
o Data quality incident management
Analytics and data mining
o Analytics strategy
o Analytics design and development
o Analytics operations
o Analytics vendor management
o Tool evaluation
Reporting and scorecarding
o Reporting strategy
o Reporting design and development
o Reporting operations
o Reporting vendor management
o Tool evaluation
o Management reporting services
Quantitative analysis
o Cross business analysis services
o Predictive and trend analysis services
Alerts and notifications
o Data monitoring services
o Exception triggering process
Conceptual data model and design patterns
o Logical data modeling management
o Conceptual data model management
o Data-sharing patterns
Logical data model
o Logical data model management
o Relationship management
Physical data model
o Physical data model management
Services
o Data modeling services
o Data management standard services
(framework, maturity model)
o Data source certification services
o Unstructured data services
o Business process modeling service
(standards and governance)
o Data logical modeling services
Standards
o Standardize design, development and
implementation of data architectures
o Provide oversight of local governance of
key data
o Execute enterprise policies and
standards
Metadata management
o Metadata strategy
o Metadata design and development
o Metadata operations
o Metadata vendor management
o Data lineage services
Reference and master data management
o Reference data definition
o Customer and client data services
o External data acquisition
Data movement and protection
o Application/information integration/services
o Data transformation services
o Security assessments & services
Data warehouse and data marts
o Data warehouse strategy
o Data warehouse design and development
o Data warehouse operations
o Data warehouse vendor management
Operational data stores and
systems of record
o Design and development
o Operations
o System of record services
o Operate and maintains local data platforms (e.g.,
systems of records, data marts)
o Provide local metadata
o Consume data and drive reports and
analytics
o Manage local reporting and analytics
platforms
o Identify key business metrics
o Measure and remediate data quality
o Implement and design local platforms
o Provide interoperability of the local
platforms
Business act ivit ies
Information security
o Information security policy definition
o Information security standards and
governance
o Access and entitlements
o Data protection system security operations
Infrastructure
o Enterprise architecture governance
o Data retention services
o Physical and logical design standards and
services
o Hardware and infrastructure development
and deployment and support
Audit
o Data management audit strategy, planning,
execution and reporting
o System of record for data audit issues
Compliance
o Data privacy policy and standards
o Data retention policy
Risk management
o Risk appetite
o Regulatory standards
Change management
o Data requirements in software development
life cycle
o Data requirements in project management
life cycle
Support partners
oTraining and communications
Assisted a large mortgage GSE in modernizing their enterprise data platform by
architecting and implementing a big data lake based ecosystem
EY assisted the customer with a multiyear, multi-phased implementation — deploying a multidiscipline, diversified team (on-site, near shore):
► Defined the data strategy and implemented the future state road map for non-pooled asset data
► Designed and implemented canonical data store for standardizing and rationalizing mortgage servicing data from multiple sub servicers, including the forensic
reconstruction of historical positions and business events
► Designed and implemented centralized rules driven accounting event generation and subledger application that supports multi-basis accounting
► Designed a financial data mart and enabled self-service reporting
► Assisted with account reconciliations, financial statement analysis and acted in an audit liaison role
► Supported financial platform modernization
► Supported loan-level forensic analysis
► Completed loan-level forensic analysis, accounting policies and procedures
► Established a “single source of truth” for all non-pooled assets data serving all
downstream applications
► Enabled the client to get the consistent view of data across different functional areas
► Provided a sub-ledger self-serving reporting option that helped business users quickly
visualize data and generate actionable business insights
3 4
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.
1
2
Chandra

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
infrastructure, network, information security and governance. The key requirements were:
► Delivered a basic (foundational) analytics platform to enable analysts to develop models
► Produced an analytics platform design that enables a longer term future-proofed, consistent solution globally to support the Hub and Spoke model
► Streamlined analytics model deployment and the generation of insights
► Created a global governance framework and operating processes to allow a consistent approach to analytics across divisions
► 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
maintain global consistency
► “Minimum viable product” for global teams to access a standardized development
environment
► Standard set of templates that package together analytics and data tools in a “data
container”
► Analytics team gained ability to manage and productionize models using a
“deployment factory,” reusable frameworks
► “Data container” for analytics development, deployment, and other enterprise initiatives
3 4
1
2

Building Semantic Layer in Birst Business Requirements Document Kanban Method of Prioritization Report/Dashboard Creation
Assisted a large US life insurance company in building its data and
analytics organization to help the company achieve strategic data goals
EY assisted in the BI COE implementation with the following approach:
► Developed a COE operating, governance, rationalization, and prioritization framework to drive synergies across business functions
► Prioritized reports from 14 business functions and conducted report rationalization
► Built a report inventory comprising approximately 1000 reports
► Defined tactical and strategic business and functional requirements to generate reports
► Defined Implementation framework for each of the Agile teams and created Agile PODs
► Created a robust and scalable star schema data model and developed a semantic layer design in Birst, encompassing all the in-scope business function
► Better collaboration between Business and IT helped lower capex and opex costs
► Promoted increased client adoption of agile and adaptive platforms with an ability to
connect to data for streamlined communications, collaborations and decisions
► Enabled client to rationalize and re-evaluate reporting needs
► Created enterprise data solution and enabled single source of truth across business
functions operating in siloes
► Unified semantic layer allowed client to leverage existing data models for self-service
BI capabilities
3 4
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
1
2

Data architecture Tool-based development End-to-end lineage
Endto enddatalineage
Advised a retail brokerage firm in creating their next generation data
architecture and platform for regulatory reporting
EY assisted the client to develop a supporting architecture providing end-to-end delivery from strategy to implementation including full SDLC:
► Designed strategy to develop foundational data architecture with the following:
► Metadata and governance-based ingestion layer
► Semantic-based data distribution/vending layer
► Designed and built Hadoop data platform on Cloudera distribution
► Implemented architecture for client and assisted in updates as needed
► Assisted in planned test filing and parallel run for one quarter and cutover
► Comprehensive common data platform to support all regulatory reporting needs
► Foundational platform for finance and risk reporting and analytics
► Enhanced data quality and insights value
► Flexible extendible data lake capable of integrating with action based applications
► Ability for easy integration of additional sources
► Ability to leverage machine learning in data integration/ingestion to create metadata
and data mapping
3 4
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.
1
2
Chandra

Appendix:
Next Generation Data
Reference Architecture & Tools Landscape

Next Generation Data Reference Architecture
Solution Building Blocks
Key Data Data Store Processing Engine Function Machine Learning Capable
Enterprise Data Architecture Access
/
Deliver
y
Data
Source
Web
Services /
Portals
Applications
Mobile
Collaboration
Semi-
Structured
Data
Unstructure
d Data
Structured
Data
Data Ingestion
Streaming Data Distribution
and Provisioning
Data Transfer
Shared Operational Data
Supports data transfer and processing at a steady, high-speed rate
Semantic Layer
Analytic &
Operational
Applications
Standard Reporting
Data Wrangling
Modeling / Data
Exploration / Data
Discovery
In Memory Computing
Data
Acquisition
Data
Ingestion
Master Data Reference Data Integrated Rules Metadata Learning Patterns
Operational Control
Metrics
API Gateway Synchronous Services Event Management
Batch Control
Management
Common Exception
Handling
Asynchronous
Pub/Sub Services
Data Tagging |
Indexing
Data Delivery
Data Management
Metadata
Management
Data Quality Control Framework
Common Exception
Handling
Audit and Balance
API Gateway &
Orchestration
Security and Privacy
DG Standards and
Policies
Virtualization &
Federation
Self Service
Search
Visualization
Enterprise Search
Virtualization
Data as a Service
Ad-Hoc Analysis
Data Lake
Data Transformation and Storage
Data Repository
Raw Layer
Harmonized
Layer
Conformed
Layer
Analytical
Layer
Cataloging | Integration | Transformation | Curation |
Preparation
Data
Warehouse
Appliances
Data Marts
Discovery and Exploration
Calculation Engine
1
2 3 4
5
6
7
Artificial Intelligence

Data Management Framework & Architecture – Data Lake
DataSources
Operational Data
Master Data
Reference Data
DataProductionLayer
Ingestion
Uncertified Data
EnterpriseArchive
Data
Quality
(Technical
&
Business)
|
Matching
|
Metadata
Tagging
|
Catalog
|
Certification

Data
Services
(Format,
Transfer
Protocol,
Frequency,
Terms)

Landing
Archive
Staging
RawData


Certified Data Stores
EnterpriseDataLake

CertifiedData Store
Customer,Account,
Product,
Transactions,GL,
Loans,Channels,
Sales,
Insurance,
IB,etc.

DataVirtualizationLayer
In Memory
Composite Views (CV)
Single Subject Areas
Credit
Customer
Other4
Product
Multi Subject Areas
Cust+ Prdct
Cust+ Prdct + Crdt
Other
Use CaseView
Cross-LOB View
Risk View
CRMView

Data
Services
(SOA
/
ESB
/
Vending
Patterns)

DataConsumptionLayer
Advance Analytics Applications
CustomerSegmentation Campaign Management
Credit PaymentProxy
Business Banking
Risk Profiling
Digital Analytics
Fraud Analytics
Product Profitability Risk Analytics

DataManagement
Data Quality | IntegratedRules Service | MetaData | Security & Privacy | Data Governance | AdministrativeServices
CommonExceptionHandling and Logging (CEHL)
Events/ Message
Event
• CanonicalData Model
• MetadataTags
• Data Mapping
• Search
Metadata&
Governance



Consuming Applications




Front-OfficeSystems
Middle-OfficeSystems
Back-OfficeSystems
Accounting& FinanceSystems
HR / Audit / ComplianceSystems
BI / Analytics
Data Warehouse
External
Others
Master
Structured DataSources
Enterprise Data Warehouse (EDW)
Data Marts (Fit-For-Purpose/Persisted)
Finance Risk Credit
DataWarehouse
Analysis & Models Development
•Time Series
•Regression
•Clustering



Risk
Customer
Data
Services
DataServices

Digital Product
IB Insurance


•Decision Tree
•Machine Learning

Machine Generate
SystemData
Documents
Web & Social Media
Multimedia
Content Data

# Best practices Category Description
1 Ingest all – use as needed Data Management
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
a data lake. An integration layer should be created for data rationalization and standardization by extracting only
required data elements from the staging layer.
2 Ingest most granular data
Data Management, Data
Architecture
Ingesting data at the most granular level ensures consistent data at various aggregate level that reconciles
appropriately. It is recommended that most granular data is captured at the ingestion stage in the Hadoop data
lake.
3
Tag metadata during
ingestion
Data Governance
Hadoop eliminates the need of expensive data lineage efforts by integrating metadata with the data elements at
the time of ingestion. Hence it’s recommended that business and/or technical metadata are associated with the
data elements at the time of ingestion enabling stronger and consistent data lineage and governance.
4 Flat schema and simple joins Data Architecture
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
of complex third normal form or snowflake models. This will enable efficient use of memory and maximize data
retrieval performance.
5 Leverage schema on read Data Architecture
Hadoop supports “schema on read”, in which a schema is applied on data as it is pulled out of the semantic layer,
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).
6
Storage format for optimum
data retrieval
Data Management, Data
Architecture
Appropriate data storage formats, such as ORC and Parquet, should be used for most efficient storage and
performance.
7 Partitioning Data Architecture
Partitioning in Hadoop is synonymous to creating indexes on the datasets, hence is extremely important for
efficient data access or retrieval.
Data Lake Architecture Guiding Principles

Landscape of Next Gen Tools
Traditional v/s Next Generation tools
Key Legacy Next Gen “Apache - Open Source” Next Gen “Third Party” vendor
Enterprise Data Architecture Access
/
Deliver
y
Data
Source
Web
Services /
Portals
Applications
Mobile
Collaboration
Semi-
Structured
Data
Unstructure
d Data
Structured
Data
Data Ingestion
Streaming Data Distribution
and Provisioning
Data Transfer
Shared Operational Data
Semantic Layer, Virtualization
& Federation, Data Delivery,
Self Service, Search
Supports data transfer and processing at a steady, high-speed rate
Analytic &
Operational
Applications
Standard Reporting,
Visualization, Ad-hoc Analysis,
Data Wrangling, ..., Data as
Service
Data Acquisition Data Ingestion
Master Data, Reference Data Integrated Rules, Metadata, Learning Patterns
Data Management
Data Lake
Data Transformation and Storage
1
2 3 4
5
6
7
Platform Data
Processing
Data Store Platform – On-
Premise
Data
Processing
Data Store
Platform –
Cloud
Driver
Web API Gateway, Synchronous Services, Asynchronous Pub/Sub Services, Event Management, Batch Control Management, Common Exception Handling
Metadata Management Data Quality
API Gateway, Orchestration
DG Standards and Policies
SQL
Controls
MDG
Code
Atlas
Kylo
Spark
Vendor
Web
HTML
Script
VB
REST
XML
JSON
OS
MDM
Custom
Separate
Integrated
Atlas
Ranger
Kylo
Web
HTML
Script
VB
REST
XML
JSON
OS
Server
copies
DB Links
SFTP
Informatica
Ab Intio
Datastage
SSIS
Goldengate
IBM CDC
NiFi
Flume
Sqoop
Streaming
Golden
SpringXD
ETL
Custom
ELT
Informatica
ETL
SQL
DataStage
SSIS
Ab Intio
Replication
File Upload
Traditional
Map
NiFi
BigQL
Kafka
Samza
Spark
SpringXD
Storm
Zeppelin
Impala
Oracle
Access
Paradox
Teradata
DB2
Netezza
SQL Server
PL/SQL
Shell
Scripts
Progress
ETL
RDBMS
Flat File
MAPR
Hortonworks
Cloudera
Mongo DB
Cassandra
AWS
Azure
Hive
Python
Java
Spark
Storm
Scala
Kudu
HBase
Tez
Avro
Parquet
ORC
Actuate
Excel
PDF
Tableau
Cognos
SAS
Power BI
Excel
PDF
Tableau
Cognos
BI Reports
Canned
Reports
MDM
MDG Collibra Custom
IGC
Kylo
Ranger Atlas Custom
IGC
Kylo
NiFi
ETL
Excel SQL
Script
HTML SOAP REST JSON
XML
MiniFi
SAM Python
Control Framework Common Exception Handling Security and Privacy
Code
SQL
Script
MDG
ML
AI/RPA
Atlas
Ranger
Java
Trigger
SQL
Custom
Zookeeper
NiFi
XML
JavaScript
Kerberos
LDAP
Kerberos
SAM
Ranger
KNOX
Elastic
GraphQL
REST
Watson
Lucene
Solr
Docker
GraphDB
Consul
Python
Spark
R
Zeppelin
D3
Tableau
Qlik
Spotfire
Birst
Neo4j
Python Viz
R
SAS
HUE
Kibana
Zeppelin

Landscape of Next Gen Tools
Big Data Technology Stack – Hortonworks “Apache” Distribution
Delivery
HORTONWORKS Distribution
Data Operating System, Operations, System administration, and Scheduling
Data Source
Governance and Security
Ranger KNOX
Data Ingestion, Integration,andAccess
Data Ingestion
NFS Web HDFS
Batch
SQL
Other
ISV Engine
Script
NoSQL Stream
In-Memory
Search
Hadoop Distributed File System
YARN Apache Ambari Apache Cloudbreak

Category Vendor Description Key Capabilities
Analytics &
► Datameer is an end-to-end big data discovery and Hadoop analytics
application which uses machine-learning and advanced algorithms for data
discovery
► Web-based end-to-end big data discovery platform
► Text, behavior, and sentiment analytics
► Supports unstructured data
Data Integration
► Tamr is a data discovery, unification, and integration platform that combines
machine learning with human expertise
► Data unification platform
► 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
► 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
Data Quality
► MIOsoft’s provides contextual data quality technology and big data analytics
using graph analytics and unsupervised machine learning cluster algorithms
► Profiling, visualization, usability and scalability/performance
► Ataccama specializes in solutions for data quality, master data management,
and data governance.
► Comprehensive DQ suite
Architecture and
Governance
► Snowflake operates a cloud-based data warehouse service. It offers a platform
to store, transform and analyze business data
► Automated infrastructure management through cloud services
► Dataguise is a leading provider of Big Data security intelligence and protection
services.
► Cloud migration, masking and encryption capabilities at the data
element level
► BigID’s platform aims at transforming enterprise protection and privacy of
personal data by utilizing patent-pending machine learning & identity
intelligence technology
► Advanced data discovery
► “Living” data maps of all PII data
Landscape of “Third Party” Vendor Tools
Third Party Vendor Tools - Capabilities

TOP_407070357-Data-Governance-Playbook.pptx

More Related Content

What's hot (20)

Similar to TOP_407070357-Data-Governance-Playbook.pptx (20)

Recently uploaded (20)

TOP_407070357-Data-Governance-Playbook.pptx

Editor's Notes