Tools For Risk

Management
Week 5

Lecturer: Barney Baldwin

Announcements

• Individual Project
• DRAFT due today
• Word document and the “Basics” exercise
• I will review this week. Check the comments to see if it needs
revision!
• Final artifacts due April 3
• Group project launches next week
• Office hours Wednesday, 11-1

2
T4RM Framework – Where are we?

PPT Framework: Data

Data
• Last week (week 5) we covered Data
People/
• People/Organization Data
People/
Organization
Data
• Started Process/ Functions People/
Organization
People/
Organization
People/
Organization
• Today we will review the Organization
Process/
Technology
Process/
Organizational and Process Process/
Functions
Functions
Technology
contexts Process/
Functions
Technology
Technology
• Writing Business requirements Process/
Functions
Functions
Technology

3
Discuss Individual Project

• Comments have been provided

Archer general issues
• Some are not bottom-up assessments
• Review the guidance from Lecture 3
• Come to office hours if the comments suggest this

• Beacon demo Thursday at 10

• Will try to find a more friendly time going forward

4
Organizational
Context
Discussion

• Suppose your manager told you to implement a technology tool

to measure risk of a new business initiative, for example
launching a new credit card.
• What questions would you have about the ORGANIZATION,
meaning the PEOPLE, organizational structure, and culture?

6
Is the Organization Ready?

• Risk Tools require:

• Functional Software Platforms
Tool Implementation
• (vendor / in-house)
• Capable users
• Technical Capability Technical Capability
• Capable IT Organization?
• Aligned with business needs? Business Engagement
• Business Engagement
• Clear Objectives?
Management Support
• Culture of innovation and change?
• Management Support
• Engaged and supportive?

7
Scale of the Tools and Businesses

• Local or Global Implementation?

• Regional Expertise
• Culture
• Appetite for change
• Risk Management Context
• Engagement on the Functional Implementation
• What does the tool need to do?
• Engagement of Risk Managers of the Inherent Risks of change
• Vendor Risk
• Technology Risk
• Strategic Risk

Tools for Risk Management, Summer 2022 8

Who is involved with Risk Tools at a large Enterprise? (1)

• Risk Management Function

• Risk management team, as sponsors of the tool
• CRO & board
• Sponsoring risk function (e.g. financial or operational risk)
• Hands-on risk managers
• Modelling teams, risk quants
• Risk management team, as managers of operational risk
• Technology risk
• Model risk
• Vendor (third-party) risk
• Project risk

9
Who is involved with Risk Tools at a large Enterprise? (2)

• Technology teams
• Risk management technology team (faces off to risk management)
• Front-office, finance, other technology teams, depending on scope
• Provide data feeds
• Consume results
• Enterprise architecture
• Infrastructure
• CISO (Information Security)
• Data management
• (CDO - Chief Data Officer)
• Data mapping
• Data quality controls

10
Who is involved with Risk Tools at a large Enterprise? (3)

• Enterprise Change functions

• Budget
• Project management
• Finance
• Forecasts for costs
• As a consumer of risk data
• Front office (sales, trading)
• As data providers and consumers of risk data
• Sometimes as co-sponsors
• Audit
• Operations, HR, other areas as data providers and consumers
11
Which business units sponsor risk tools?

• The entire organization has a First Line of Defense role

• Compliance training and management
• Technology monitoring
• Technology Risk – principally with the IT Organization
• Financial Risk – principally with business units, finance function, and risk management
• Market Risk: Trading: Equities, Fixed Income, Commodities, FX, etc.
• Credit Risk: Lending (CAT1), Derivatives exposure (CAT2), macro financial changes (CAT3)
• Liquidity Risk: Treasury and Finance functions
• Compliance and Fraud detection – often their own divisions
• Operational Risk - operations, and the overall organization
• Risk standards and processes are with the Risk Management division
• Risk Appetite, Stress testing, risk aggregation, reporting

12
Segregation of Duties

• Segregation of Duties (SOD) is a basic building block of sustainable risk management

and internal controls for a business. The principle of SOD is based on shared
responsibilities of a key process that disperses the critical functions of that process to
more than one person or department.*
• For Risk, best practices mandate that:
• Risk Managers (CRO) are responsible for the Risk data, policies, and processes
• Business Unit managers are responsible for the business data and processes
• Technologists (the IT Organization) are responsible for ensuring that technology is sound, secure, and follows the
technology standards and policies.
• Data Office (CDO), if it exists, is responsible for ensuring that data management practices are sound and follow
appropriate standards and policies

• Risk Tools and 3LOD

• Risk Managers are in both a first-line and second-line role
• First line: ensure that the tools follow the organizational standards and policies (Risk Owners)
• Second line: Define and extend risk policies and practices (Risk Oversight)

*From https://us.aicpa.org/ 13
Vendor Risk

• Vendor risk is the potential for harm to a company or its customers

that arises from its relationships with outside vendors. These risks
can include:
• Reputational risk: A vendor's actions can damage a company's public image.

• Financial risk: A vendor's poor credit, decreased revenue, or increased liabilities can
impact a company's business.
• Cybersecurity risk: All vendors, even low-risk ones, pose some cybersecurity risk.
• Operational risk: A vendor's inability to perform as promised can disrupt a company's
operations and cause project delays.
• Regulatory and compliance risk: A vendor's failure to comply with regulations or meet
contractual obligations can impact a company.
14
How Organizations Succeed

• Hire the best talent

• Robust hiring processes
• Continuous development & Training
• Strategic vendor relationships and robust vendor risk management

• Define Clear Objectives

• Shared across all business units

• Develop a culture of continuous change

• Embrace Technology
• Agile delivery
• Innovation

• Invest in building and maintaining competitive differentiators

• Senior management support for change
• Clear, adaptive prioritization of spend

15
Functional/Process
Context
Discussion

• Suppose your manager told you to implement a technology tool

to measure risk of a new business venture, for example a retail
credit card.
• What questions would you have about the business processes,
including the risk processes?

17
Functional Context

• Functional Requirements
• What does the tool do?
• Solve a business (risk) problem
• Functional Questions:
• What data is needed?
• How will the data be captured and managed?
• What calculations are needed?
• How will the results be used or presented?
• … and many more…
• As a risk manager, YOU will need to specify the functions of risk
tools
18
Risk Domains

• Tools are leveraged to automate repeatable processes

• Low-frequency processes (e.g. board-level decisions, macro-
economic opportunities) may not justify application of tools
• Domain of strategic risk
• Some risk domains and processes are more amenable to
automation
• Technology-intensive businesses such as trading
• High-frequency risks, such as cyber attacks
• Data-intensive processes
• Intensive calculation demands
• Regulatory demands

19
Risk Processes and Risk Tools
• Risk Identification
• Intellectual activity, research-oriented
• Tools are research-centered, for example news tools such as Reuters, Factset, and
Bloomberg, …

Risk Measurement
Identify
•
• Risk models and data are leveraged
• SAS, Algorithmics, Moody’s, and most big risk tech companies…
Control Measure
• Risk Aggregation
• Data-centric activity performed by most systems
• Archer, IBM OpenPages, Murex, Calypso, Sophis, Beacon, etc.
• Risk Presentation
• Reporting, graphing, and export functions available in most risk systems Present Aggregate

• Control
• Usually a human-driven process based on reports and feedback
• ”Hard” limits may block risk-taking activities such as trading or lending

20
Risk Processes and Tools (cont’d)

• Tools are used primarily for Measurement, Aggregation, and

Presentation
• Virtually all enterprise risk tools perform these functions
• Aggregation and Presentation will be covered when we review
Data and Risk Reporting
• Measurement is a domain-specific activity (what type of risk?)
• Operational risk involves quantitative and qualitative assessments of operational
issues (generally impact and likelihood) at a granular level
• Financial Risk Involves calculation of values and sensitivities of financial instruments
• Stress-testing and back-testing are higher-level tools

21
Stress Testing and Backtesting

• “Stress testing” evaluates how a portfolio or enterprise

performs under extreme or hypothetical conditions
• Usually simulated market conditions, though it can be used to assess operational
conditions as well
• CCAR (Comprehensive Capital Analysis and Review) is a tool used by the US Fed
(banking regulator) to assess bank strength
• Back Testing evaluates a model using historical data to assess
model accuracy
• For example, using historical data to test a VaR model
• Stress Testing is looking at forward scenarios, while Back
Testing validates models historically

22
Frequency of Risk Processes

Nanoseconds Seconds Hours Days Months

Computer Response Human Response Organizational Response

Cyber-Attack Equity Price Risk Event Management Bank Stress

Detection Changes Notification Reporting Tests
High Frequency Risk Event
Desk-level Regulatory
Trading Review
Risk Aggregation Reporting

Different risk processes require different response times.

23
Enterprise Risk Processes Usually involve Multiple Tools

Measurement is usually near the

Measurement Presentation
• Business and
point of capture of risk events Risk
Systems
Enterprise
Reports
• Sometimes recalculated centrally
• Aggregation is a complex process Aggregation

• Data is standardized (normalized) across

multiple data formats Data Enterprise
Risk
• Aligned with reference data Normalization
Repository
• Stored in standard format
Other
• Presentation produces reports Sources

and dashboards of the data

Reconciliation,
EOD and EOM
processes

24
Real-time vs. Batch processes

• Real-time processing is event-based

• A risk event occurs, and the data is processed immediately
• For example, repricing a derivative when an equity price changes
• Humans interact with real-time data through “dashboards” (dynamic screens)
• Batch processing occurs on a cycle, triggered by a system clock
• For example, end-of-day processing to aggregate risk
• Humans interact with batch data through reports and files (static screens)
• Most systems have some elements of both real-time and batch
processing
• Risk measurement, aggregation, and presentation may be accomplished
by real-time, batch, or both

25
Cost vs. Time for Changes (Scalability)
• Often, adding more resources (and cost) to an initiative will reduce time
• Some problems scale very well – support parallel processing
• For example, add more typists to speed up data entry
• Calculation of risk measures
• Some problems are inherently less scalable
• E.g., sorting a large list
• Aggregation of risk measures
• “Overhead” is a critical factor which reduces or eliminates scalability
• Communication and coordination
• Startup/shutdown costs
• Dependencies (wait time)
• Scalability is an issue for both delivery teams and technology tools

26
Discussion: Risk process consolidation onto risk tools

• What are the benefits of consolidating onto a single risk tool?

• What are the drawbacks?

27
System Decomposition – Issues with too many systems

• People – training, different skills needed to support different systems

• Process – divergent methods, high operational risk
• Technology – cost and complexity of redundant systems
• Data – manipulation is costly, prone to data errors
• Change – Complex environment with multiple system

Issues arise at system boundaries, high costs for overlapping systems

28
System Consolidation – Issues with too few systems

• People – vendor risk with dependency on single system

• Process – supported may not be sufficiently flexible (one size fits all)
• Technology – becomes out-of-date quickly, tech risk
• Data – may not support needed processes
• Change – may impact multiple business areas, testing is challenging

Monolithic systems age quickly as business and tech evolves, vendor risk is
very high

29
What is the Solution?

• In general, fewer systems is better and less complex

• Data and process consistency
• Cost – fewer vendors and staff to support multiple systems
• Adopt a small number of best-of-breed solutions.
• Shut down systems and processes that are not adding
sufficient business value
• Maintain high change capability, nimbleness
• KEEP THE DATA CONSISTENT across systems to the extent
possible.

30
Risk Domain vs. Risk Process Alignment *

Market Credit Op Market Credit Op

Risk Risk Risk Risk Risk Risk
System System System

Risk Risk Reporting System

Reporting

Risk Risk Aggregation System

Aggregation

Risk Risk Measurement System

Measurement

* For Illustration purposes. In general, most ERM tools will support multiple domains and processes

31
Next Week…
Next Module (Week 6)

• Change Capability: required reading:

• Schwaber, K., & Sutherland, J..
(2020). The Scrum Guide..

• https://www.atlassian.com/agile/scrum. (watch the video too)

• https://www.atlassian.com/agile/scrum/roles.

• https://www.atlassian.com/agile/scrum/sprints.

• https://www.atlassian.com/agile/scrum/ceremonies.

• Launch group project

• Read the description of the group project (“ERM Platform Implementation Project”)

33