Building a Scaleable Market Risk Infrastructure

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

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

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

4. 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: • 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

5. Strategic Risk Architecture – FO Principles • 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 FO • FO Produce all position information required for sensitivity reporting, VaR, Stress Testing and SNI • 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 • 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 • 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 • Publish risk information in accordance with a common data standard • New Systems • Need to consider existing internal candidates before building new systems

6. Strategic Risk Architecture – MR IT Principles • 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)

7. Governance • 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 • 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

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

9. Business Process Principles • 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 • 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.

10. How might this look?