Building a Scaleable Market
Risk Infrastructure
Gavin Slater
Global Head – Market Risk Infrastructure
Barclays Capital
The view expressed here are my own and do not
necessarily represent those of my employer
Agenda
• Introduction
• Step 1 – understand your users
• Technology Platform – getting “back-to-basics”
– FO IT Principles
– MR IT Principles
• Governance – it’s a politicians game
• Business Process – understand the touchpoints but don’t
make it technology driven
• How might this look?
Step 1 Understand your users
The obvious first step is to fully understand what risk managers actually want (and
interpret that into requirements you and I can understand)
What a RM tells me
What this actually means
I want more data
More metrics such as LID, correlation sensitivity,
basis risk etc. (not just those for VaR!)
I want my data much quicker
Straight Through Processing - Reduce number of
system interfaces between FO and downstream
risk systems (T+0)
I want better quality data
Using golden sources for static and getting better
trade capture upstream
I want the data to be complete
Early detection of trade capture issues as well as
“far flung” positions not on strategic platforms (or
even “off system”)
I want to see my data aggregated….but I want to
be able to drill down to low levels of granularity
Establishing a good data schema with flexible
systems which are able to “slice and dice” on
various reporting pivots…also sorting out
hierarchy issues
I want to be able to reconcile back to FO data
Reduce the number of transformations and
ensure these are transparent (and using similar
FO analytics) if they occur
Technology – Getting Back-to-Basics
Go back to “risk 101” approach where risk systems only need to add up (perhaps
with a small amount of multiplication) – any complex tasks and calculation need to
be pushed upstream to FO systems (where the budget is!)
Clear separation of functions/tasks of each downstream architecture component,
typically including:
1.
2.
–
–
–
–
–
–
3.
Interface component – for feed loading, data standardisation, transformations & enrichment
Database component for data storage (and archiving)
Engines/Calculations component – for VaR & Stress Test calculation and perhaps some of
the transformations (the multiplications!)
Reporting component – this is separate from the user interface as it refers to a physical data
storage component optimised for reporting data to end user according to a structure
(aggregations & pivots) defined by them
User Interface component – a GUI
Workflow component – decoupled from the system such that it can be extended to all
“participants” in the market risk process without them needing to understand the system
Connect FO and downstream through a common data standard and risk data
model/schema
Strategic Risk Architecture – FO Principles
1.
Risk (Sensitivity) calculations are owned and performed upstream
–
2.
FO Produce all position information required for sensitivity reporting, VaR, Stress
Testing and SNI
–
3.
4.
Split between structured/complex risk versus flow positions which may require different risk
engine set-up/configuration (Ultra-fast end-to-end processing for the "flow" end, with large
number of trades and simple models. Very flexible for the "structured" end with small number
of trades, but complex models.
Common data standard
–
7.
Functions are performed by most suitable system (consistent across businesses and regions)
De-coupling of trade capture & risk calculation can avoid duplication of risk engines
Optimise risk engines to provide data in time to meet risk reporting (T+0) deadlines
–
6.
Historical focus has often been on VaR only
Where there are multiple risk engines run by businesses, ensure these utilise a
common set of analytical models
Develop systems as best-of-breed for asset class and allow systems to be used as a
utility
–
–
5.
Even if Middle Office/ Controlling run this on behalf of FO, the intellectual ownership needs to
be with the FO
Publish risk information in accordance with a common data standard
New Systems
–
Need to consider existing internal candidates before building new systems
Strategic Risk Architecture – MR IT Principles
1.
2.
3.
4.
5.
6.
7.
Architecture must be easily scalable to meet future business – market risk data
volumes are large, necessitating a good physical data model optimised to receive
and store. (different to the logical data model)
Avoid building ‘point to point’ connections between systems. Systems should publish
and subscribe to a data-bus using a common data format.
Straight-Through-Processing. Event driven architecture to be adopted where
possible. Exception based processing with minimal manual or user intervention.
Golden source systems (for position and static data etc) are identified and used
consistently
Clearly defined logical data model mapped to FO view through the common data
standard (also with common feed interface definition)
Clearly defined aggregations…e.g. clear definition of position level for risk versus FO
view
Get the balance right between data standardisation and data transformation (try to
achieve minimal transformation)
Governance
1.
The market risk process is heavily dependent on other parties (FO, MO, Finance
etc) and cannot operate in a silo – hence the need participate in the relevant
governance forums to influence (or beg!) to get initiatives prioritised &
delivered…influencing skills are a key asset…if not there is always the Reg “card”!
Downstream governance should adhere to the following principles
2.
–
–
–
–
3.
Active engagement & buy-in from end users…balance participants across IT, Projects,
Production and end users
Focus on challenge & decision making – use a a channel for healthy challenge and
opportunity for end users to make critical decisions
Clear, concise and consistent MIS to all stakeholders
Expectation management
Participate actively in other bank-wide forums
–
–
–
Trade Capture – data quality issues are best solved by getting it right “up front”
Static Data – consistency across silos is difficult to achieve and market risk suffer most
being the risk aggregation point across different business silos
End of Day – in a global business such as Investment Banking end of day processes
must be robust to achieve good timeliness
Business Process
•
There are a number of areas “involved” in
the market risk process, typically including:
–
–
–
–
•
•
There are a number of key activities which
take place and where these are housed can
differ between banks (and even within banks
across business silos)
Key activities include:
–
–
–
–
–
–
•
Front Office
Finance / Controlling / Middle Office
Market Risk
Operations
Trade capture
Risk engine configuration & calculation
Risk model development
Risk approval
Data enrichment
Risk Aggregation & Reporting
The key is to keep all necessary parties
involved (with clear responsibilities) but not
build in dependencies
OPTION A
FRONT OFFICE
CONTROLLING
MARKET RISK
OPTION B
FRONT OFFICE
CONTROLLING
MARKET RISK
Business Process Principles
1.
Clarify roles & responsibilities for each department in carrying out the key market
risk process activities
–
–
2.
3.
Try to keep responsibilities consistent between business silo’s
Logically activities which require detailed understanding of trades should be further
upstream, whilst standardisation & aggregation fit better downstream
Don’t build in dependencies eg. If a department is involved in the process add
them through workflow rather than by sending data through their systems
Establish Service Level Agreements (SLA’s) to fit timing required for risk reporting
(for example to meet T+0 or T+1 timetables) – both with Front Office for provision
of core risk information as well as other service providers for static data
enrichment etc.
How might this look?