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

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

The obvious first step is to fully understand what risk managers actually want (and interpret that into requirements you and I can understand)

Technology – Getting Back-to-Basics

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

2. Clear separation of functions/tasks of each downstream architecture component, typically including:

– 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

3. 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– Even if Middle Office/ Controlling run this on behalf of FO, the intellectual ownership needs

to be with the FO2. FO Produce all position information required for sensitivity reporting, VaR, Stress

Testing and SNI– Historical focus has often been on VaR only

3. Where there are multiple risk engines run by businesses, ensure these utilise a common set of analytical models

4. Develop systems as best-of-breed for asset class and allow systems to be used as a utility– 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

5. Optimise risk engines to provide data in time to meet risk reporting (T+0) deadlines– 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.

6. Common data standard– Publish risk information in accordance with a common data standard

7. New Systems– Need to consider existing internal candidates before building new systems

Strategic Risk Architecture – MR IT Principles

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

2. Avoid building ‘point to point’ connections between systems. Systems should publish and subscribe to a data-bus using a common data format.

3. Straight-Through-Processing. Event driven architecture to be adopted where possible. Exception based processing with minimal manual or user intervention.

4. Golden source systems (for position and static data etc) are identified and used consistently

5. Clearly defined logical data model mapped to FO view through the common data standard (also with common feed interface definition)

6. Clearly defined aggregations…e.g. clear definition of position level for risk versus FO view

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

2. Downstream governance should adhere to the following principles– 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

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

– Front Office– Finance / Controlling / Middle Office– Market Risk– Operations

• 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:– 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 B

FRONT OFFICE

CONTROLLING MARKET RISK

OPTION A

FRONT OFFICE

CONTROLLING

MARKET RISK

Business Process Principles

1. Clarify roles & responsibilities for each department in carrying out the key market risk process activities

– 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

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

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