This document discusses the need for a systematic approach to operational risk reduction through the use of an enterprise operational risk platform. It notes that existing risk frameworks are vague and lack metrics. The document outlines characteristics of operational risks in manufacturing/engineering sectors versus service sectors. It discusses lessons from BCBS 239 implementations, including that no banks met deadlines and regulators lacked resources to properly assess compliance. The document argues for a consistently addressable corpus of risk documents and data to reduce tools sprawl, surface requirements in dashboards, and enable multiple analysis methods over the same data.

1. Operational Risk Debt Reduction
The need for a Systematic Approach
"the risk of loss resulting from
inadequate or failed internal processes,
people and systems or from external
events".

2. Agenda
• Operational Risk Frameworks and Standards
• Service Sector vs Physical Engineering Risk
• BCBS 239 Impact and Lessons
• What do we really need
• The broader Op Risk Architecture Perspective

3. Coso
ERM
ISO 31000
OCEG Red
Book
Basel
(OpRisk)
ISO 27001
Security
Project Risk
Prince2
Institute of
Internal
Auditors (IIA)
Corporate
Specific
Standards
Solvency II
(OpRisk)
COBIT
IT Risk
ISO 22301
(BCM Risk)
Sarbanes
Oxley
COSO
Internal
Controls
Enterprise Risk Management Standards that Integrate with Business
Strategy and execution
Domain Specific Risk Standards/Frameworks
Existing Standards and Frameworks

4.  Modern manufacturing techniques have changed physical
Operational Risks for physical engineering professions.
 Direct lineage from design to manufactured component
 Automated layout – optimised packing and tool path
 Traceability and sampling of component materials
 Simulation of operating conditions
 Static Stress
 Human interactions
Manufacturing/Engineering Sector
Operational Risk Characteristics

5.  Service Industry risks are buried in “Document Archipelagos”
 Contracts and Policies are the key artefacts that define business
relationships
 More stringent Audit and Regulations are driving tighter integration
between business entities
 The drive to intraday reg reporting and B2B XBRL interchange
 BCBS 239 is a warning to prepare
 Semantic Technologies may make frameworks “more than PPT or PDF” but
are regarded as “Science Projects”
 E.g. FIBO BIAN
Service Sector Operational Risk Characteristics

6. The Allure of Frameworks
• Frameworks such as COSO and
OCEG are sold in expensive “manual
sets” with certified practitioner
groups
• Vague promises – no metrics
• “Alignment”, “Enhancement”,
“Harmonisation”

7. COBIT A Semantic Illusion
• As frameworks evolve they attempt to
“define” entities/relationships at an
abstract level in Powerpoint style
graphics.
• There are no standard sets of these
defined to any sufficient detail to be
semantically useful – answering the
questions “What” and “How”

8. Ownerships
Data Lineage
RangesandKeys
Message
Formats
Glossary /
Taxonomy
KPI Metrics
Business Entities and Logical
Relationships
Technical Entities and Physical Data
Models
DataModels
DataQualityMonitoring
DataQualityRulesets
Operationa;Dashboard
Operational Risk Domain
Data Dictionary Data Quality Management,
Reconciliation
Single Identifiers
Data GovernanceLegend
Technical Viewpoint
Business Viewpoint
Business
Process
Lineage
Physical Data
Flows (ETL)
Data
Governance
Data
Monitoring
NB There must be verifiable line of sight across all the Risk Artefacts within the
repository from the Business to the IT viewpoint and vice versa
The Impact of BCBS 239

9. The Lessons of BCBS 239
Implementations
• No G-SIB met the deadline
• They could not succeed as they had no measure of
success
• FoI requests to the regulators (EBA and BoE) showed
they had no resources or sustainable method to assess
the work done
• Bank Of England went out to tender for a new data
management infrastructure delegating much of the
detailed design and compliance.
• We have been left in a subjective morass

10. What do we really need
• A consistently addressable corpus of Design, Review & Control
Documents and the Operational Environment data they
define.
– Reduce Wiki, Jira and Sharepoint and collaboration tools sprawl
– Consistent Access control model with other parts of IT Estate
• Surface Design and Control requirements implicitly in Operational
Dashboards and reports
• Multiple means of aggregation and analysis over the same
data

11. An Enterprise Operational Risk
Platform
Operational
Risk
Supplier
Risk
Conduct
Risk
Technology
Risk
BCM Risk
Fraud
Risk
Legal
Risk
Root
Cause
Analysis
Loss Data
/
Incidents
Scenario
Analysis
Control
Testing
Issues +
Action Plans
Key Risk
Indicators
Capital
Modelling
Enterprise Operational,
Regulatory and Audit
Risk Repository
Regulatory
Obligations
Regulatory
Change
Control
Policy
Management
Regulatory
Issues Action
Plans
Audit
Maintenance
Audit
Planning
Audit
Execution
Reporting and Analytics
Design Time
Run Time