qualities:
• capturing market risks which matter from a hedging perspective;
• calibrating reliably to the markets to enable reliable hedging;
• numerical stability for pricing and computing risk sensitivities (Greeks);
• computationally efficient for front office pricing as well as downstream risk calculations.
Model Implementation Process
Model implementation is an interactive process among quants, traders, IT and risk managers. It entails the following stages:
• Quants develop pricing models including all the necessary calibration routines in a quant library. It is vital that the quant library is structurally well-designed and object-oriented.
• Quants, working with IT, develop system and user interfaces for the trading and risk systems.
• Quants conduct model development testing to examine the validity and implementation of the model. The model test scopes as well as the results should be documented.
• IT develops the downstream applications, including the relevant Risk and Back Office requirements.
• Risk conducts independent model validation.
A typical model/product implementation flow chart is shown in Figure 2.2.
Figure 2.2 Typical model/product implementation flow chart
Note that the model trading/risk system integration should be accomplished during the model development stage as a parallel task, rather than after. This is because most of the model integration and interfacing works are not specific to a particular model. In a well-designed object-oriented quant library, the permitted parallel approach can greatly enhance the overall model and product development efficiency.
Model Testing
Quants model testing is to ensure that the model is implemented properly. It is aimed to minimize the implementation risks, which constitute a very large portion of model risks occurred in real life. Model testing should include development testing and system testing.
Development testing checks the fundamental mathematical and numerical implementation. Whenever possible, an alternative model should be developed for comparison purposes. The comparison between the models can reveal differences and deficiencies. Differences should be thoroughly examined and understood; some are due to legitimate differences in numerical methods and some due to implementation bugs.
Model system testing is to ensure that the implemented model performs as expected in the production environment. The testing within the trading and risk systems enables an assessment on model's pricing stability and its capability in generating sensible risk sensitivities, for hedging over a wide range of real market data at portfolio level. It is beneficial to run system tests using the live system overnight daily risk report and analysis tools. The impact of the new model on the live portfolio in terms of P&L and risk sensitivities should be assessed and fully understood.
System testing is vital for new model development. It is also essential for model change control. Live models may be changed and updated, and they should be subject to release change control procedure, including thorough system regression tests. All live models should be version-controlled, and this can usually be done easily by the source code's repository. Accompanying each model release, there should be a release note explaining any model changes together with version number and date, etc.
Independent Model Validation
Independent Model Validation (IMV) is based on the four-eyes principle to verify the model theory and test the model implementation. In practice, IMV develops its own equivalent models independently to conduct model comparison and testing. The actual model testing tends to be a large part of the work, as many implementation details need to be verified.
Once the models have been tested and approved by IMV, they can be released into production for pricing and hedging. It is the best practice that IT carries out the model release into trading and risk production systems independent of quants and trading. IT should manage and maintain production systems following a standard but independent procedure.
Quants should communicate effectively with the IMV team to facilitate its model validation, and more importantly model testing tasks. Some of the key information is listed in Table 2.1.
Table 2.1 Key model information
IMV is a very important development and control function, and its focus should be on mathematical verification and actual model testing. It should avoid spending time to go through front office quants' source codes for obvious reasons:
• The amount of tiny detail in the source codes is overwhelming. Going through source codes does not help with the independent mathematical or numerical verification.
• It does not help either with the most important part of IMV: the actual thorough model testing.
• It can potentially compromise IMV's “independent” validation.
• It substantially increases the bank's security risks of model source codes leaking out.
• Overall it consumes valuable resources and prolongs the validation process with little real benefit on control or business.
Object-Oriented Quant Library
A quant library consisting of implemented models is the engine in the modern derivatives business. It should be scalable, simple and transparent, allowing generic, efficient and user-friendly modular interfaces to the pricing tools, trading and risk systems. The quant library requires a well-designed architecture at the outset as well as ongoing enhancement to survive and succeed.
The quant library should be written in an object-oriented framework. Object-oriented programming and design has many advantages. At the programming level, the (C++ or C#) programs are well-structured and modular. At the practical level, it permits orthogonal combinations of objects. For example, by keeping the instrument/product objects distinctively separate from the valuation/model objects, the orthogonal combination allows one to price a particular instrument/product with any suitable model using any suitable numerical approach. This can be done at trade as well as portfolio level, reusing the same objects without coding repetitions.
Key Objects in a Quant Library
Table 2.2 lists some examples of the key objects or components in a quant library.
Table 2.2 Key objects in a quant library
When all the required objects are coded up properly in the quant library, it will allow efficient and flexible interactions among the objects in the process of developing new models and products. A generic description of a product can be constructed naturally by connecting together the relevant objects. For example: a swap consists of legs, a leg consists of cash flows, and cash flow consists of various attributes including
