Tools For Risk
Management
Week 9
Lecturer: Barney Baldwin
Announcements
• Individual Project due date moved to Thursday, April 10, 11:59 PM.
• Presentations will be in class, April 10.
• Group project DRAFT artifacts due today, 11:59 PM.
• Office hours Wednesday 11-11. As always, let me know via email or text
when you will join.
2
Quiz 3
Individual Project
Individual Project
• Revised due date is April 10, 11:59 PM
• Artifacts are (in order of importance)
• Presentation of the problem and the results
• 8-15 slides
• 5-10 minute presentation in class, April 10
• Includes:
• Problem statement
• Approach (e.g. List of questions, who will answer, etc)
• Results (quantitative results, graphs with explanations, qualitative analysis)
• Proposed mitigation strategy
• Revised version of the document describing the problem and approach
5
Group Project
Required Deliverables
• Presentation is the most important – Powerpoint
• Problem Statement
• Summary of Plan
• Strengths of the Plan (why are we doing it this way)
• Business Opportunities (what benefits will we get and when will we get them)
• Risks and Mitigations
• Presentations will be in class (time permitting), or office hours if needed
• 10-20 slides, 20-minute max presentation, all students speaking
• Tasks and Plan (Gantt Chart) is needed to support the presentation –
Excel
• BRD (word) provides high-level supplementary material
• Scrum templates are required, but less important
7
Feedback on the work to-date
• Sequencing the software releases in the Gantt chart is critical
• De-risk the delivery
• Engage the organization iteratively
• Focus on the critical items
• Plan for one cycle of dev/test/release for each business
migration
• Op Risk – one cycle for each migration from a legacy tool
• Credit Risk – one cycle for each business line
8
Why won’t a single dev cycle work?
• People
• Too much work for individual teams to do all at once. Dev, test, business staff are
limited
• Training all users at once is too hard
• Coordination across all teams will be very challenging
• Prioritization across too many business stakeholders will be challenging
• Process
• Op risk problem: It will take too long to fix the critical business process (US Reg
reporting)
• Business processes are divergent. Process maturity is relatively low.
• Business process migration and training is too hard to do at one time
• Better to set up a system that works well, test it on a simpler processes, then adapt
for other processes
9
Why won’t a single dev cycle work? (cont’d)
• Technology
• Too many technology changes for one big release.
• System and data flows are very complex
• Testing will be extremely challenging, and too many bugs will come out
• Failure is very likely, and could be disastrous because of all the dependencies
• Data
• Too much divergent data to move between systems
• Consider
• Data Standardization
• Data Mapping
• Data Migration
10
Technology Context
T4RM Framework – Where are we?
PPT Framework: Data
Data
• So far we covered Data
People/
• People/Organization Data
People/
Organization
Data
• Started Process/ Functions People/
Organization
• Change Capability People/
Organization
People/
Organization
Process/
Organization Technology
Process/
Functions
• Today we will continue with the Process/
Functions
Technology
technology context Process/
Functions
Technology
Technology
Process/
Functions
• Next week, Data Functions
Technology
12
Technology Context (review from last lecture)
• This is the Risk Tools themselves, how they are built and what
makes them work
• Technology tools are comprised of
• Hardware (aka Infrastructure)
• Software (aka Applications)
• Systems Architecture defines how the components interact
Tools for Risk Management, Summer 2022 13
Software
• Software is *mostly* written by humans
• No-Code / Low-code is configured by humans (e.g. Archer)
• AI tools are helping to automate common development tasks
• Coding is: converting natural language to steps for a computer
• Coding is a hard problem to automate
• DeepMind’s AlphaCode, OpenAI’s Codex platforms are leveraging AI to code
• Many tools have become available in the past year
• Writing software is costly. This is why organizations buy
software from vendors.
14
Software (continued:1)
• Software is written in a programming language
• A programming language must be converted into low-level
instructions to run on a computer
• Low-level instructions are known as Machine or Assembly language
• A ”Compiler” converts code into a file containing machine
instructions
• Creates an assembly file to be executed on the computer later
• An “Interpreter” reads code and runs it directly by issuing
machine instructions.
• Reads code and issues machine instructions at the same time
15
Software (continued:2)
• There are hundreds of programming languages
• Per IEEE Spectrum 2022 rankings, the top programming
languages are:
• Python, C, C++, C#, Java, SQL, JavaScript, R, HTML, Typescript, Go, …
• For Risk Tools
• Python for general coding
• R for statistical computing
16
Hardware (aka Infrastructure)
• Components of system Infrastructure
• Client (display)
• Server (compute)
• Databases (storage)
• Network
• Risk tools (software) runs on the client, servers, and often the
databases
• Systems Architecture defines how the components interact
17
Systems Architecture
• Defines how software and Tier 1 Tier 2
Business Logic
Tier 3
Data & Resource
Presentation
hardware work together to
solve a problem
• Most risk tools have a
multi-tier architecture:
• Presentation (user interface) layer
• Application Servers
• Databases
• External resources (market data,
system feeds, etc.)
18
Cloud vs. On premise
• “Cloud” means renting hardware,
and potentially software
• IaaS – Infrastructure as a Service
• SaaS – Software as as Service
• “On-premise” systems are hosted in
the organization’s data centers.
• The trend is towards cloud
implementations, due to improved
cost and scalability
• Amazon, Google, and Microsoft are
the largest cloud vendors
• Most major risk tool vendors offer
cloud implementations
Source: Prescience Tech [link]
19
Why the Cloud?
• Infrastructure (servers, network, storage) is abstracted (handled *almost* transparently)
• Technical Application components are in place
• Databases
• Web servers
• Compute servers
• Load balancers
• … and much more
• Security infrastructure is built-in, generally lower risk
• Firewalls, Access controls, encryption, etc.
• Quick start-up, shut-down
• Total cost is generally lower than in-house infrastructure
• Pay only for what you use
• ➔ In-house management of technology is still required
20
Technology Risk and Application Security
• The technology risk team will generally assess
applications for technology risk.
• Assessment should follow a standard process
(identify, measure, aggregate, present, control)
• Depends on the maturity of the tech processes
• Major technology risk issues for risk tools:
• User authentication
• Configurable user roles (minimum privilege needed for the job)
• Robust data management (retention, sharing, encryption at rest,
encryption in transit)
• Robust technology process management (start/stop, monitoring,
etc.)
• Recovery from disasters and outages
21
What makes a problem complex?
• We all face problems every day – some are harder than others
to solve
• Is that because of the problem itself, or because of our own
perspective and limitations?
• Complex systems are characterized by many interacting
“components” and large volumes of data
• Examples include biological systems, climate, social networks,
financial systems, and organizations
• Risk problems are some of the most difficult to solve
22
Properties of Complex Systems (examples)
• Emergence: new properties arise from the interactions within a complex
system that are not present in the components. For example, market
booms and busts arise from the actions of individual investors
• Non-linearity: Small changes can have disproportionately large effects.
For example, stock market crashes may arise from a bug in a single
trading algorithm.
• Self-organization: Components in complex systems sometimes organize
into structures without central coordination, for example in the growth of
neural structures in animal brains.
• All of these properties introduce risk that is challenging to quantify,
requiring sophisticated models and lots of data.
23
Is complexity just our own perspective?
• Complexity theory (a math field) shows that some problems
are more difficult than others.
• For example:
• Given a list of size N, how long does it take to find the largest element?
• Given a list of size N, how long does it take to sort the list?
• Many problems are much more complex, for example finding the shortest path
between two points.
• Some problems provably cannot be solved at all – see Turing’s “Halting Problem”.
• However, solving these problems is trivial if you have a tool (or
component) that solves the problem
24
How to Measure Process Complexity
• Measuring business process complexity turns out to be a very
difficult (complex?) problem
• Common metrics for business processes include:
• The number of applications
• The size of applications
• Amount and type of data consumed
• The number of system or process interfaces (connection points)
• The cost of supporting the processes (most common, but often not helpful)
• Regardless of the measure, reducing complexity in Risk Tools
and processes is a key factor for business success
25
Decomposing Technology Problems
• “Enterprise” problems such as risk management are “complex”
• Require multiple hardware and software components, lots of data, and human processes
• These must work in tandem, communicating and interacting
• Industry standards and tools have evolved for solving these problems
• Why is decomposition necessary?
• Greater re-use of existing components
• Less code to manage
• Systems and processes are simpler, easier to understand and to modify
• Two of the most common ways to break down technology into components:
• Software: Object-oriented design
• Hardware: Service architectures
26
Breaking Down Complexity using Components
• To build complex systems, we need components that:
• Represent repeatable business processes with a desired outcome
• Are self-contained (no external dependencies)
• Are a “black box” (a user does not need to understand the inner workings)
• May be comprised of other components.
• These components may exist as
• Portions of an application, in code
• As a “service” running on a network
• Very complex objects have been encapsulated as technology
components
27
Example – components of Generative AI platforms
28
Simple Example – Risk for a portfolio of equity derivatives
• Data “components”:
• The positions (quantity) for all the derivatives
• Market data for models (assuming Black-Scholes)
• Current spot prices for the underlying stocks
• Volatility of each underlying stock
• Risk-free interest rates
• Instrument data: strike price and expiry for each option
• A pricing model implementing Black-Sholes
• Components to store and display the data
• Database (for example, MongoDB)
• Reporting user interface (for example Tableau)
29
Discussion
• Consider the problem of setting up a tool to capture and
measure consumer credit fraud events at a large bank.
• What data components are needed?
• What model(s) are needed?
• What tools can be used to analyze the data?
30
Risk Tools are built using many components
• “Business” components
• Representations of data
• Risk models
• Application Technology components
• Databases
• Orchestration tools to manage computations, batch jobs, etc.
• User interface components
• Reporting and visualization tools
• Load balancers, job monitoring, etc.
• Infrastructure components
• Servers, networks
31
Object Oriented Design
• Object-oriented (OO) design is a tool for separating software
into components
• Incorporated explicitly into most modern programming
languages – Python, Java, C++ are called “OO languages”
• The key concept is that objects are things that have
• Data
• Functionality
• Interfaces (function calls) for managing the object
32
Classic OO example
• Consider a system modeling fruit
• Oranges, Pears, Bananas are special types of
(instances of) fruit.
• Each type of Fruit inherits some attributes of
Fruit (e.g. all Fruit is edible)
• Each type of Fruit has attributes of it’s own
• Imagine that each type of fruit can provide a
“Sweetness” value.
• You can then compute the sweetness of a
basket of fruit by iterating asking each fruit for
it’s sweetness
33
Financial Risk OO example
• Consider a base class “Instrument”
• It has a function called “GetPrice”
• We create Derived classes of Instrument called Bond, Option,
Stock, each with a GetPrice function.
• A tool performing aggregation can go through a list of
products, calling GetPrice for each one, without knowing what
type of product this is.
• A portfolio could also support a “GetPrice” function to perform
the aggregation!
34
OO Financial Example, continued
Instrument
- Has Price() method • ”Instrument” object is defined
Derives from (”Is a…”) with a default ”Price()”
method
Bond Stock Option
- Has Price() method - Has Price() method - Has Price() method • Bond, Stock, and Option
objects implement
(“override”) the Price()
method.
Portfolio
- - Has [list of Instruments] • Portfolio object has a list of
- - Has Price() method
Instruments
• What does the “Price()”
method for Portfolio do?
35
Key OO concepts
• Inheritance – Objects can “Inherit” from others, i.e. become
instances of another class (e.g. Apple inherits from Fruit)
• Polymorphism – Object can have multiple types (e.g. A
Pineapple is also a Fruit)
• Encapsulation – The inner workings of a class are a “black box”,
i.e. a user should not care how an object does it’s work. For
example, a portfolio pricing function should not care how the
price of each instrument is calculated.
36
Processes, Applications, and Services
• A “process” is an executing program
• Runs on a single computer
• Same memory space
• May have multiple “threads” that can run in parallel on a single computer
• Risk Tools (Applications, Platforms) are generally comprised of
multiple processes
• E.g Database processes, compute processes, display processes, etc.
• A “service” is a process that responds to network requests from
other processes
• E.g. database service, web service
• Usually, but not always, on separate machine
37
Network Services
• When running a business process on multiple computers,
network services are required
• The internet is a giant web of network services connected by
HTTP and HTTPS protocols
• Database servers provide network services for data access
using protocols such as ODBC
• Risk tools are generally comprised of multiple services
connected by one or more network protocol
38
Network Protocols and Cloud infrastructure
• Most interactive network services leverage the secure variant of HTTP
(HyperText Transport Protocol), called HTTPS (Secure HTTP).
• Almost all modern enterprise risk tools use web clients, supported by
services in a public or private cloud.
• This standard client approach is supported by many industry tools,
including web browsers, load balancers, monitoring, and test tools.
• Cloud providers such as Amazon, Microsoft, and Google, provide
proprietary and open-source application components, including
databases, infrastructure provisioning,
39
Data consistency
• For network services to interoperate, two things are necessary:
• Common network protocol
• Common data formats
• When services are written in the same programming language
things are simpler, as shared code libraries can be leveraged.
• Risk tools such as Beacon and Archer leverage common
libraries (built using the same object models) to create a
platform
40
Web Application Architecture Example
Most Enterprise Risk Tools
are web applications, built
using many of the same
components as any web
application.
The risk business logic,
which may be comprised of
many servers, is in the box
called “App Backend”.
[Link]
Next Week…
Next Module (Week 10)
• We will discuss data, the foundation of all risk management
• focus on Risk Data Aggregation
• Complete the Reading:
• Bank For International Settlements. (n.d.). Principles for effective risk data
aggregation and risk reporting. Retrieved Feb 1, 2022 from [link]
43
