notional, pay/receive and auxiliary information. All the required details are wrapped up in an organized way that permits easier understanding and repeated usage without code repetitions.
Objects Interconnection and Architecture
Figure 2.3 illustrates how the objects are interconnected from the architecture perspective.
Figure 2.3 Object Interconnection and Architecture
Generic interface should be very thin, and its sole task is to transit and map data, reformatting data as necessary. Interfacing is extremely important, as the quant library must be integrated into trading and risk systems to be of value to the business. A badly designed interface will significantly increase the time and costs of developing new products. In the following, the “attributes table” approach is explained as an example of a generic interface for systems.
In trading and risk systems, common attributes such as spot, notional, currency, yield curve, etc. are readily available and a quant developer can simply pull them out and group them into objects that are fed into the pricing models and/or risk engines. For the exotic (or even common) attributes, an attributes table can be created inside the trading system. An example can be seen in Table 2.3.
Table 2.3 Example attributes table
Once the attribute table is set up inside the trading system, the quant developer can simply loop through the table, and pass all attributes in the table into the model interface. The model interface should be designed so that it can recognize the attributes and map them into the relevant objects. The beauty of this approach is that the looping codes are simple, and they do not change, no matter what the attributes are. This makes the quant developer's job much easier and more standardized. For some risk engines or back office systems that sit outside the trading system, a risk developer can use similar looping codes to read attributes and call the same model interface. The attribute table approach makes it possible for the same looping codes to be used in the trading and downstream systems, for many different products. It is therefore feasible that once quants have developed and added a new product into the trading system, all downstream systems will automatically work.
Object-oriented quant library architecture is fundamental in meeting the challenges in modern derivatives business. Many banks had to rewrite their quant libraries every a few years, wasting a huge amount of time and resources, because their prevailing libraries were not properly designed and constructed or simply became too complex to handle.
A quant library should be a child born from the marriage of brilliant mathematical modelling and skilful IT programming. A well-designed and constructed, object-oriented quant library can offer:
• Integrated business efficiency and much-enhanced productivity, including streamlined interfacing to systems and infrastructures.
• Standardization of model development and testing process, and minimization of model implementation risks.
• Application of higher-quality operational control procedures, allowing four eyes to watch a centralized piece.
Finally, an object-oriented quant library should be kept simple. Overly complicated object structures are tempting, but they may in fact defeat the purpose of having an efficient quant library. So keep it simple and object-oriented (KISOO).
Quantitative Documentation
Derivative models developed by Quants must be documented comprehensively. The key quantitative documents are listed in Table 2.4.
Table 2.4 Key quantitative documents
Table 2.5 and Table 2.6 show examples of the model technical and testing documentation templates respectively. These tables are given to illustrate the scopes and details required for achieving a high documentation standard.
Table 2.5 Technical documentation template
Table 2.6 Model testing documentation template
Model technical and testing documents also serve as the audit trail of the quantitative works done during the model/product development. These works are essential to pursue the highest possible quality for the model and the quant library as a whole.
Product Issuance and Wrappers
This section explains the typical mechanism of product issuance and hedge, and product wrappers with their characteristics.
Issuance and Hedge
When a structured derivative product is issued, it typically involves three parties: investors, an issuer and a derivative desk. The investors buy the product (e.g. a structured note) from the issuer, who subsequently hedges the derivative risks with a derivative desk. The flow is illustrated in Figure 2.4 and described in Table 2.7.
Figure 2.4 Flow of product issuance and hedge
Table 2.7 Flow description
Notes:
1 Issuer's position can be booked as a floating rate note (with coupon Lf) plus a swap. Net-net this is equivalent to a zero coupon bond plus an option.
2 Issuer's total funding level (Lf) includes issuer-specific credit spread (s1). Lf is an important factor in derivatives pricing given it is included in the swap hedge.
3 If the structured note is callable or autocallable, the swap and funding leg are also callable or autocallable. One needs to assess or value the associated callable effects.
From investors' perspective, in addition to the market risks, the counterparty (issuer) risks in the structured products must be taken into account when they make investment decisions. The pricing of the products must include the counterparty (issuer) risks and it is typically manifested in issuer's funding spread.
Wrapper Categories
Structured products are distributed to investors via different channels in various wrappers. Different wrappers have different features and benefits. In a nutshell, a wrapper specifies what the product will be issued as (e.g. a security or bank saving account), and their subsequent tax and financial protection treatment. Naturally, different jurisdictions have different preferences in terms of meeting investors' needs.
Table 2.8 lists some of the key structured product wrappers and their features.
Table 2.8 Key structured product wrappers
