Manufacturing and Managing Customer-Driven Derivatives. Qu Dong

Чтение книги онлайн.

      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:

      ¹ Issuer's position can be booked as a floating rate note (with coupon L_f) plus a swap. Net-net this is equivalent to a zero coupon bond plus an option.

      ² Issuer's total funding level (L_f) includes issuer-specific credit spread (s₁). L_f is an important factor in derivatives pricing given it is included in the swap hedge.

      ³ 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

СКАЧАТЬ