An approach to the risk management of structured financial products. Marco Cammi Unità di Risk Management della Banca Monte dei Paschi di Siena

Size: px

Start display at page:

Download "An approach to the risk management of structured financial products. Marco Cammi Unità di Risk Management della Banca Monte dei Paschi di Siena"

Derek Harrison
5 years ago
Views:

1 An approach to the risk management of structured financial products Marco Cammi Unità di Risk Management della Banca Monte dei Paschi di Siena Abstract The core of any risk management information system is always an analytical engine working according to a specific approach to calculate value-at-risk indicators. In this paper a description of relevant financial modeling issues and their implementation in the context of the risk management information system of Gruppo Monte dei Paschi di Siena will be presented. Introduction The Value-at-Risk analysis required by Gruppo Monte dei Paschi di Siena, whose trading portfolios include traditional financial instruments and derivatives, must be settled up to respond to a number of technical and organizational requirements. Among the most relevant issues, is worth mentioning the following: 1. the analytical procedure must be governed by analytical users, so that they can manage the inclusion of new financial instruments or different types of analysis. This activity must be kept easy and simple (analytical user are not system programmers) but at the same time it should allow users the treatment of complex modeling issues; 2. the whole computational procedure should be modular and trackable, so that the analytical model be self-documented and accessible for testing and validation by institutional authorities. This paper will shortly describe the way the risk analysis procedure has been organized in the context of the implementation of the Risk Management Information System of Gruppo Monte dei Paschi di Siena. First, the implementation approach will be reviewed, describing how Risk Dimensions basic concepts (environment, financial instrument, and so on) have been used to support the implementation. Then some critical implementation issues will be shortly mentioned, together with their proposed solutions. Organizing an analitical engine for Value-at-Risk Calculation

2 General architecture The risk analysis process is divided in several layers: 1. Operational Data Definition layer (data upload, transfert, import); 2. Data Warehouse layer (decoding, quality check, merging across different data sources); 3. Pre-analysis layer (retrieval of data, preparing data for subsequent analyses (VaR, ALM, other analyses); 4. Value-at-Risk analysis (computing VaR and other indexes at the required crossclassification level); 5. Post-analysis layer (storing of data produced during the analyses); 6. Report layer (presentation and publication of results). In the context of this project, these layers have been treated according to the following approach: - implement input data processing in SAS Warehouse Administrator (this covers layers 1 to 3); - implement VaR analysis in RD environment (layer 4); - implement post processing and reporting processes in SAS Warehouse Administrator (layer 5 and 6). Logic of implementation From a logical point of view, the implementation of these layers will proceed incrementally by singular steps, each step being related to a specific financial instrument. In fact, the data processing to be performed and the information of interest in each layer depend on the financial instrument we are considering. Different financial instruments and different analyses may require different data; different data may come from different sources; different sources may need different extraction techniques. For each classified financial instrument type, all layers are implemented progressively. Instrument covered are consolidated in a production procedure that incrementally provides a multiinstrument analysis procedure and can be used for calculation even before completion. When the entire set of instrument types has been treated, the production procedures is able to process all interesting portfolios. A pratical implementation using Risk Dimensions For the above mentioned reasons, we decided to organize data across layers, but at the same time to develop our procedures by financial instrument type and analysis. A further logical extension of this structure was the idea of dividing the Risk Dimensions analysis flow (layer 4) in steps and, for every step and for every financial instrument, to develop a suitable Risk Dimensions environment. A single instrument is then treated by means of an instrument environment, built by inheritance using several component environments, these latter covering the following steps:

3 - configuration settlement; - position data treatment; - market data treatment; - pricing. To obtain complete portfolio-based analyses, the inheritance between environments is used again to collect all the risk objects together. Complete analysis environments covering entire portfolios are built by selecting and merging appropriate instrument environments. By this means the complexity of complete analysis environments is kept to a minimum, and it is very easy to perform single- or multi-instrument analyses. An example of instrument environment inheritance structure is given in figure 1 for long futures. In figure 2 the inheritance structure of a complete analysis environment is partially shown. Environment creation is based on warehouse processes, so that variable definitions and position inclusions are performed automatically by using the proper functionalities of Risk Dimensions. In figure 3 processes building long future component environments of figure 1 are shown. The drawback of this approach is, obviously, the large number of component environments we had to put in place. In our case the front-office database is currently working with some twenty different instrument types. For every one of them, five steps have been singled out, each of them with its own Risk Dimensions environment. Moreover, in our system there are some other utility environments, e.g. pricing libraries links or common definitions. All this add up to a total of about one hundred environments. Possible critical issues and their management With so many different objects to manage and with non-trivial links between them, we had to pay attention to avoid some dangerous pitfalls. Two of the major critical issues are: - objects with the same usage should have the same definition (otherwise it will lead to inconsistency) - different objects should have different references (otherwise it will result in some ambiguity). One not being aware of that, even if very good risk measures for every single financial instrument can be obtained, rather poor performances will be achieved when executing portfolio analyses. For example: it is clear enough what is generally meant for maturity of a bond. But when talking about a bond option, what is maturity? The expiry date of the option, or the day when the bond pays back the principal amount? To compute risk calculations, both are needed, but mixing them in the wrong way, a quite bad result will be produced. A possible way to ensure consistency is to keep in a single place objects used across several instruments. Ambiguity must be managed by a proper discipline in naming conventions. Conclusions

The implementation of multi-stage and wide scope calculation procedures, like Value-at-Risk computations for real-world bank portfolios, is a complex task that

This contribution has briefly reviewed the pratical approach used in the Risk Management Unit of Gruppo Monte dei Paschi di Siena in building such procedure using

4 The implementation of multi-stage and wide scope calculation procedures, like Value-at-Risk computations for real-world bank portfolios, is a complex task that must address opposing issues: - efficiency; - easiness in maintenance; - user friendiliness in naming and conventions. This contribution has briefly reviewed the pratical approach used in the Risk Management Unit of Gruppo Monte dei Paschi di Siena in building such procedure using the analytical environment of Risk Dimensions. Figure 1. - Inheritance structure of instrument environment for the treatment of long futures. Figure 2. - Inheritance structure of a complete analysis environment.

5 Figure 3. - Generation processes for component environemts of long futures. Figure 4. - Input data sources for a complete analysis environment.

Release notes. IBM Industry Models IBM Banking and Financial Markets Data Warehouse Version

Release notes. IBM Industry Models IBM Banking and Financial Markets Data Warehouse Version Release notes IBM Industry Models IBM Banking and Financial Markets Data Warehouse Version 8.8.0.0 28 th April 2016 Table of Contents About these release notes... 2 What s in the box... 2 Fixes since the