Equity Derivative Structuring Case Study

This document illustrates the process of structuring a new financial product with LexiFi. The case study is based on a multi-period, multi-underlying equity derivative, representative of the products marketed in European retail markets.

Topics covered include: • Product definition • Simulation • Pricing • Event planning • Transition from prototyping to production Product Definition Sample Product The sample contract is based on a basket of twenty assets and pays 85% of the basket’s initial value plus the highest positive average return calculated on ten annual observation dates.

Each year, the basket’s value is calculated using the following rules: • As soon as an asset becomes the best performer on a given year, that year’s performance, subject to a performance boost applicable in each of the first seven annual observation dates (see below), is used in the calculation of the average basket’s performance not only for the given year but also Copyright © 2004-2005 LexiFi SAS Page 2 for the following years. The contribution of a once best performing asset to the value of the basket is effectively “frozen” on the date the asset becomes the best performer.

The basket’s value is therefore insensitive to future changes in the value of a once best performing asset. On each of the first seven annual observation dates, if the best performing asset returns less than 100%, the performance is set to 100%. The basket’s value on each annual observation date is equal to the arithmetic average of individual asset returns.

The contract’s payoff is equal to 85% of the basket’s initial value plus the maximum of the ten average basket returns or zero if the maximum is negative. • • • The following table illustrates the contract’s mechanics:

Table 1 Asset Spot Prices (Scenario 0) and Illustration of Sample Contract’s Mechanics 200311-14 100 100 100 100 100 100 100 100 200411-15 106 95 156 159 98 110 114 173 hence 200 105 159 200511-14 113 99 198 147 97 126 107 200 200611-14 156 105 156 218 101 123 113 200 200711-14 189 169 148 213 103 157 154 200 200811-14 195 115 196 157 159 143 134 200 200911-16 268 89 210 214 125 121 147 200 201011-15 268 95 165 226 265 107 168 200 201111-14 268 102 189 245 265 99 159 200 201211-14 268 198 165 245 265 101 148 200 201311-06 268 202 143 245 265 107 156 200

Asset Asset Asset Asset Asset Asset Asset Asset 1 2 3 4 5 6 7 8 Asset 9 Asset 10 100 100 Asset Asset Asset Asset Asset Asset 11 12 13 14 15 16 100 100 100 100 100 100 150 121 99 124 158 157 198 199 hence 200 195 156 94 144 173 152 123 200 159 200 143 200 156 200 123 200 156 200 189 200 201 200 242 189 93 168 187 158 268 168 96 182 181 205 Asset Asset Asset Asset 17 18 19 20 100 100 100 100 109 113 154 134 115 135 192 164 126 154 243 199 162. 7 134 174 243 221 178. 2 268 198 97 197 197 199 hence 200 146 196 243 198 179. 1 268 201 91 205 212 200 68 168 95 231 196 200 268 149 97 243 217 200 268 165 92 301 217 200 268 203 57 301 194 200 157 157 243 203 163 176 243 198 178 198 243 233 164 176 243 222 164 137 243 237 Average 131.

05 150. 25 183. 35 187. 75 195. 45 201.

35 199. 55 Maximum The highlighted cells identify the contributions of best performing assets. The highest average basket return, identified by the yellow cell, is obtained on 2012-11-14. On the payment date, the holder of the contract receives: 85% + Max (201. 35/100 – 1, 0) = 186.

35% MLFi Definition New Product vs.

Existing Product Template The skills required to describe a product with LexiFi depend on the task at hand. Two situations may be distinguished: • Defining a new product. Structurers define entirely new payoffs using the MLFi language and libraries of higher-level contract assembly components. Five to twenty lines of MLFi code generally suffice to capture the product’s logic.

If required, LexiFi assists customers in designing new contracts. Copyright © 2004-2005 LexiFi SAS Page 3 • Specifying the parameters of a pre-defined product template.

Once the core logic of the contract is written in MLFi, the definition is extended to enable non-technical users to instantiate the contract with parameters. Salespeople may specify simple parameters (e. g.

, a date to describe a maturity date, a float to describe a notional amount) or more complex parameters (e. g. , an algebraic expression to describe a complex payoff). Parametric MLFi product definitions are used to generate trade entry screens with Windows Forms, the application programming interface for writing graphical applications, delivered as part of the Microsoft .

NET framework. In practice, structurers progressively expand the library of high-level contract assembly components and create increasingly general product templates. Over time, a growing proportion of “new” products is defined by modifying the parameters of an existing structure instead of writing MLFi code. For their part, salespeople access a catalog of product templates that defines the potential range of solutions that they may offer to customers. The sales team is able to autonomously adapt products in the catalog to meet customer needs.

Possible Parametric Representation The table below presents a possible parametric representation of the sample product.

Table 2 Possible Parametric Representation of Sample Product Parameter Name / MLFi Type / Description initial_date date Parameter Value 2003-11-14 Initial observation date. The values of underlyings on the initial date serve as denominators for calculating the performance of relevant assets on each annual observation date. Assets string list List of underlying assets. observation_dates date list

Dates on which the values of underlyings are observed in order to calculate each asset’s performance. number_withdrawn int * (int * int) list ["asset01”; "asset02”; "asset03”; "asset04”; "asset05”; "asset06”; "asset07”; "asset08”; "asset09”; "asset10”; "asset11”; "asset12”; "asset13”; "asset14”; "asset15”; "asset16”; "asset17”; "asset18”; "asset19”; "asset20”] [2004-11-15; 2005-11-14; 2006-11-14; 200[2004-11-15; 2005-11-14; 2006-11-14; 2007-11-14; 2008-11-14; 2009-11-16; 2010-11-15; 2011-11-14; 2012-11-14; 2013-11-06] withdrawn from the basket on observation date tj.

lways 1 means that one asset is withdrawn on each observation date. cell_payoffs string * (int * string) list “max 2 CELL”, [8, “CELL”] Defines the function app[8, "CELL”]formance of the best performing asset on observation date tj in order to determine the value used in the local payoff calculation. The first string is the default expression that characterizes such function, and the (int * string) list describes the observation date index from which a new expression starts to apply and the new expression.

The list is empty when the default expression applies to all observation dates. Copyright © 2004-2005 LexiFi SAS Page 4 In the opposite column, “min 2 CELL” means that function f: x > min 2 x is applied to the performance of the best performing asset from the first observable date t1.

The performance boost is abandoned from the eighth observation date, as specified by “8, CELL”. CELL is the only primitive that may be used to defined cell payoff expressions. local_payoffs string * (int * string) list always “AVG”

Defines the function applied (vertically) to cell payoffs on observation date tj to calculate the local payoff. Local payoffs are defined almost identically to cell payoffs. always “AVG” means that the “AVG” expression applies to all observation dates.

Four primitives, AVG, MAX, MIN, SUM, may be potentially combined to define local payoffs. global_payoff string “0. 85 + max 0 (MAX – 1)” Defines the function applied (horizontally) to local payoffs to calculate the global payoff. Four primitives, AVG, MAX, MIN, SUM, may be potentially combined to define global payoffs.

In the opposite definition, max is an operator and MAX a payoff primitive.

payment_date date 2013-11-14 Date on which the global payoff is paid. The logic of the above parametric representation for the sample product may be summarized as follows: Figure 1 Logic of Possible Parametric Representation Initial Date t0 Asset 1 Observation Dates tj ? {t1, …, tn} Payment Date tp >= tn Asset i Cell Payoff tj Asset m Local Payoff tj Global Payoff The choice of parameter set depends on the user’s requirements.

The above representation, while specific to the sample contract, enables the description of several product variations, as illustrated below: Table 3 Examples of Product Variations Product Variation Local payoff is difference between maximum and minimum performance, with local cap of 50%. Global payoff is average of local payoffs, without floor. Parameter local_payoff global_payoff Parameter Value always “min 0.

5 (MAX – MIN)” “AVG” Copyright © 2004-2005 LexiFi SAS Page 5 Note that users who are interested in analyzing only a limited number of product variations may opt for a more concise parametric definition than the one presented above.

Alternatively, the definition could be generalized to cover a much broader set of products. A Microsoft . NET / Windows Forms trade entry screen is derived from the above parametric representation, as illustrated below. Figure 2 Sample Product Trade Entry Screen Simulation Simulation covers • the execution of a contract over past, present, or future market scenarios, typically to analyze the potential performance of a product, and • the evolution of a contract’s value over a set of future dates.

Simulation of Contract’s Execution (Performance Analysis)

LexiFi users may simulate the execution of a contract through time for a given market scenario, record the cash flows derived from the contract along the simulated path, and calculate summary performance metrics such as the contract’s annual return. Scenarios may be historical or forward-looking: • historical scenarios reflect the past evolution of the contract’s underlyings; • hypothetical, forward-looking scenarios of the contract’s underlyings are qualitative and may reflect the customer’s view, the provider’s view, or a consensus forecast. Copyright © 2004-2005 LexiFi SAS

Page 6 The simulated execution of a contract provides an intuitive understanding of the proposed transaction and, ultimately, helps to validate a marketing idea. Historical Simulation Historical simulation quantifies the performance of the proposed product as if it had been acquired in the past. The shaded area in the chart below represents the annual yield that an investor would have received if he had acquired the sample product at weekly time intervals from 1983-11-15 to 1993-1114, the last date on which the historical acquisition of a 10-year product may be simulated, if we assume that today’s date is 2003-11-14.

Figure 3 Historical Simulation of Sample Product and Three Product Variations over Ten-Year Period 8.

0% 7. 0% 6. 0% 5. 0% 4. 0% 3. 0% 2.

0% 1. 0% 0. 0% -1. 0% -2. 0% -3. 0% ov -9 0 ov -8 5 ov -8 3 ov -8 4 ov -8 7 ov -8 8 ov -8 9 ov -8 6 ov -9 1 15 -N ov -9 2 15 -N Annual Yield (%) 15 -N 15 -N 15 -N 15 -N Historical Contract Acquisition Dates Base Case Local Floor, No Global Floor 15 -N 15 -N 15 -N No Cell Bonus 15 -N Tw o Assets Withdraw n

The historical scenario is also run for three product variations described in the table below: Table 4 Product Variations Product Name (Index) Base case (0) No cell bonus (1) Two assets withdrawn (2) Description Sample contract.

Sample contract without cell bonus from the first to the seventh observation date. The best two (instead of one) performing assets are withdrawn from the basket on the first five observation dates. Only one asset is withdrawn from the sixth observation date. Local payoff changes from “AVG” to “max 0 AVG”. Global payoff changes from “0. 5 + max 0 MAX” to “MAX”.

Local floor, no global floor (3) Users may describe scenarios explicitly with time series data or derive scenarios from one or more other scenarios. For example, users may use substitution rules when historical data is unavailable either because an asset did not exist on a simulated acquisition date or market data is missing. Forward-Looking Simulation The execution of a contract may also be simulated for a single acquisition date (today) and for a set of forward-looking scenarios. Copyright © 2004-2005 LexiFi SAS

Page 7 We augment the set of forward-looking scenarios: in addition to the bullish spot price scenario 0 presented in Table 1 above, we define a bearish scenario 1 and a (very) bullish scenario 2. The table below displays the payoff and the annual yield of contracts 0 to 3 as well as the annual yield of the best and worst performing assets in each of the three scenarios. Figure 4 Forward-Looking Simulation Results Scenarios Data Scenario 0 Scenario 1 Scenario 2 Payoff 186.

35% 85. 00% 263. 55% 6. 43% -1. 61% 10.

19% Annual Yield Best Performer 12. 03% 7. 71% 14. 4% Worst Performer -5. 47% -9. 98% 4.

75% No Cell Bonus Payoff 184. 90% 85. 00% 263. 55% 6. 35% -1. 61% 10.

19% Annual Yield Best Performer 12. 03% 7. 71% 14. 24% Worst Performer -5. 47% -9. 98% 4.

75% Two Assets Withdrawn Payoff 184. 55% 123. 55% 256. 60% 6. 33% 2.

14% 9. 90% Annual Yield Best Performer 12. 03% 7. 71% 14. 24% Worst Performer -5. 47% -9.

98% 4. 75% Local Floor No Global Floor Payoff 201. 35% 100. 00% 278. 55% 7.

26% 0. 00% 10. 80% Annual Yield Best Performer 12. 03% 7. 71% 14. 24% Worst Performer -5.

47% -9. 98% 4. 75% Contracts Base Case

Simulation of Future Price The goal here is to measure a contract’s value over a set of future dates. The system simulates the evolution of the contract as life cycle events unfold, records cash flows that occur between today and each future valuation date, and calculates the value of the residual contract. The figure below illustrates the price of contracts 0 to 3, calculated on five future dates (2003-12-01, 2004-12-01, 2005-12-01, 2006-12-01, 2007-12-01), using base scenario 0 and holding other model inputs (yield curve, dividends, volatilities, correlations, etc.

constant. Figure 5 Simulation of Future Price 1. 8 1. 6 1. 4 Price 1. 2 1.

0 0. 8 0. 6 14 -M ay -2 00 4 14 -N ov -2 00 4 14 -M ay -2 00 5 14 -N ov -2 00 5 14 -M ay -2 00 6 14 -N ov -2 00 6 14 -M ay -2 00 7 14 -N ov -2 00 7 ov -2 00 3 14 -N Valuation Date Base Case No Cell Bonus Two Assets Withdrawn Local Floor, No Global Floor Copyright © 2004-2005 LexiFi SAS Page 8 The simulation of future prices helps banks to properly represent derivatives risk and enables structured product users to monitor limits and management constraints through time.

It also provides a rigorous framework for calculating value at risk and potential credit exposures on a portfolio of exotic products. Simulation Audit LexiFi provides extensive details on how simulated fixing values were obtained.

For example, LexiFi indicates that a value was available on the expected date or that a substitution rule was applied with the details of the preceding date, the following date, or both for interpolated values. When a fixing value is the result of a formula—e. g. , for scenarios derived from other scenarios—all inputs of the scenario composition formula are provided. Figure 6 Simulation Audit (2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, ((2004-11-15, “asset01”), “asset02”), “asset03”), “asset04”), “asset05”), “asset06”), “asset07”), “asset08”), “asset09”), “asset10”), “asset11”), “asset12”), “asset13”), “asset14”), “asset15”), “asset16”), “asset17”), “asset18”), “asset19”), “asset20”), ((Obs_float(106. )), Fix_from_data)); ((Obs_float(95.

)), Fix_from_data)); ((Obs_float(156. )), Fix_from_data)); ((Obs_float(159. ), Fix_from_data)); ((Obs_float(98. )), Fix_from_data)); ((Obs_float(110. )), Fix_from_data)); ((Obs_float(114. )), Fix_from_data)); ((Obs_float(173.

)), Fix_from_data)); ((Obs_float(105. )), Fix_from_data)); ((Obs_float(159. )), Fix_from_data)); ((Obs_float(150. )), Fix_from_data)); ((Obs_float(121. )), Fix_from_data)); ((Obs_float(99.

)), Fix_from_data)); ((Obs_float(124. )), Fix_from_data)); ((Obs_float(158. )), Fix_from_data)); ((Obs_float(157. )), Fix_from_data)); ((Obs_float(109. )), Fix_from_data)); ((Obs_float(113. )), Fix_from_data)); ((Obs_float(154.

)), Fix_from_data)); ((Obs_float(134. )), Fix_from_data));

The above figure displays fixing values for scenario 0 of the forward-looking simulation, on date 2004-11-15 and for assets 1 to 19. Fix_from_data means that data was available on that date. Pricing Price, Greeks, Payoff Distribution LexiFi generates specialized pricing code for each contract with the correct sequence of numerical calculation steps. The pricing code is then linked with an in-house or LexiFi-provided model implementation.

LexiFi’s Monte-Carlo framework automatically generates multi-dimensional pricing routines. The user-definable output includes price, Greeks, cash flow distribution, pricing error estimates, and runtimes.

Table 4 Price and Vega Price Vega 0. 878818142 0. 271% In the table above, vega (i.

e. , the sensitivity of the sample product’s price to the volatility of one asset) is calculated with respect to asset 11. All values are calculated immediately after the initial fixing. Copyright © 2004-2005 LexiFi SAS Page 9 The payoff distribution is illustrated below. Figure 7 Payoff Distribution for Monte-Carlo Model (10,000 paths) 400 350 300 250 Frequency 200 150 100 50 0 0. 91 0.

8 3 0. 781 5 97 13 7 1. 562 1 04 26 1 1. 343 1 10 39 5 1. 124 2 16 8 52 1. 905 3 23 2 65 1.

68 3 29 67 8 6 1. 467 4 36 91 0 1. 249 5 42 4 04 1. 30 6 48 7 17 1. 811 6 55 1 30 1. 592 7 61 43 5 1.

373 8 67 5 91 68 1. 54 7 4 69 9 2 1. 935 80 83 1. 671 87 69 0 1. 498 6 93 09 4 1.

279 1 99 8 22 2. 06 2 06 03 5 1 2. 841 2 12 4 56 83 2. 2 18 26 1 9 2. 403 4 25 31 744 2. 31 848 7 6 2.

966 5 38 00 07 47 6 13 7 M or e Sensitivity Analysis Correlation We compare the different product variations in terms of their sensitivity to an overall level of correlation between the assets. We assume that there is an overall level of correlation ? such that the correlation between (log-) asset i and (log-) asset j equals ? for all i ? j. We then vary the level ? etween zero and one to determine the correlation sensitivity of the different products. Copyright © 2004-2005 LexiFi SAS Page 10 Figure 8 Price Sensitivity to General Correlation Level 1. 20 1. 15 1.

10 1. 05 1. 00 0. 95 0. 90 0.

85 0. 80 0. 75 0. 70 0. 0 0.

1 0. 2 0. 3 0. 4 0. 5 0.

6 0. 7 0. 8 0. 9 Price Correlation Base Case No Cell Bonus Two Assets Withdrawn Local Floor, No Global Floor Vega For correlation products, the vega on one asset depends on the spot level of other assets. The vega on asset 11 in the sample contract changes, depending on the average spot price of the nineteen other assets.

This behavior contrasts with vanilla options where there is no correlation effect and the vega is unique.

This means that a multi-underlying option may not be hedged with a stable combination of vanilla options. Hedging must be adjusted throughout the life of the product. Figure 9 Vega Stability Analysis 3. 0% Vega on Asset 11 2. 0% 1. 0% 0.

0% -1. 0% -2. 0% -3. 0% 50 75 100 125 150 175 200 Average Spot Price of Nineteen Other Assets In the above example, the price of asset 11 is fixed at 100 and the price of all other assets in the basket is moved as illustrated on the horizontal axis.

The simulation feature helps to visualize the evolution of vega along a given forward-looking scenario. The figure below shows the future value of vega on asset 11 for scenario 0.

Copyright © 2004-2005 LexiFi SAS Page 11 Figure 10 Evolution of Vega on Asset 11 for Scenario 0 2. 0% Vega on Asset 11 1. 0% 0. 0% 03 04 05 06 1Ju n05 1Ju n04 1Ju n06 1Ju n07 1D ec 1D ec 1D ec 1D ec 1D ec 07 Future Valuation Dates Vega on asset 11 goes to zero from 2007-11-14 when asset 11 is removed from the basket. Event planning Event Detection

LexiFi provides tools to systematically detect contract life cycle events and to analyze the potential behavior of a contract in the future. In particular, users may visualize a contract’s entire execution calendar.

For example, users may wish to view the next fixing date (2004-11-15) and the list of assets that need to be fixed on that date, as illustrated below: Figure 11 Event Planning Date 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 2004-11-15 12:00:00 Contract Type Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Equity Derivative Trade Id base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case base_case Event Type Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Fixing Event Description asset01 asset02 asset03 asset04 asset05 asset06 asset07 asset08 asset09 asset10 asset11 asset12 asset13 asset14 asset15 asset16 asset17 asset18 Copyright © 2004-2005 LexiFi SAS Page 12 004-11-15 12:00:00 Equity Derivative base_case Fixing 2004-11-15 12:00:00 Equity Derivative base_case Fixing asset19 asset20 Contract Explorer In addition, a contract explorer enables users to exhaustively analyze all potential contract execution paths. In the figure below, the contract explorer provides the inputs and outputs of the cell, local, and global payoff formulas on the last observation date, assuming base scenario 0. The contract’s performance may be compared with that of the best and worst performing assets. Figure 12 Simulation of Contract’s Execution with Contract Explorer From Prototyping to Production LexiFi facilitates the transition from a prototyping to a production environment. Product Design, User Interface, and Persistence

As discussed in the Product Definition section above, the specification of entirely new products is initially written by structurers using the MLFi language. The definition is then expanded and transformed into a parametric definition that non-technical users can use.

Finally, a Microsoft . NET / Windows Forms trade entry screen is derived from the parametric definition and trades are persisted in a SQL database. The figure below summarizes the steps, tools and services provided by LexiFi for rapidly defining new products and automating their management. Copyright © 2004-2005 LexiFi SAS Page 13 Figure 13 Steps, tools, and services for commodifying new products MLFi Definition MLFi combinators Libraries of contract assembly components

Market conventions, schedules, elementary contracts, etc. Parametric Definition Sample contracts Complete product libraries Production Graphical user interface Microsoft . NET / Windows Forms integration SQL database integration Other integration tools Contract design assistance Professional services Systems planning, design, custom development, and integration Rapid Prototyping and Staged Deployment of New Valuation Algorithms MLFi may serve as a shared contract description language that generates pricing code to drive internally developed or commercially available pricing libraries.

MLFi can drive both prototyping and production valuation libraries.

For example, in order to rapidly respond to a customer inquiry, quantitative analysts may initially want to generate prototype code in the language of their choice. After the transaction is consummated, MLFi may generate production code in C in order to integrate the new product in the trading system. The MLFi compiler’s ability to output different flavors of valuation code from the same product definition eases the programming and maintenance workload of financial engineers, and allows them to spend more time on value-added tasks such as deepening their understanding of exotic derivatives. Reporting LexiFi provides immediate operational reporting capabilities for all contracts, regardless of their complexity. Pre-packaged management reports cover transaction activity, event monitoring, and payments.

Users may also create precise, product-specific reports on exotic contracts with SQL-compatible tools. Figure 14 Transaction Activity Report Id Trade Id Initial Assets Date 7 base_case 2003-11- asset01; asset02; 14 asset03; asset04; asset05; asset06; asset07; asset08; asset09; asset10; asset11; asset12; asset13; asset14; asset15; asset16; asset17; asset18; asset19; asset20 Number Local Cell Payoffs Global Payoff Withdrawn Payoffs 2004-11-15; 2005-11-14; 1 max 2 CELL, AVG 0. 85 + max 0 2006-11-14; 2007-11-14; [8, CELL] (MAX – 1) 2008-11-14; 2009-11-[8, CELL]11-15; 2011-11-14; 2012-11-14; 2013-11-06 Observation Dates The above transaction activity report is tailored to the sample contract. Copyright © 2004-2005 LexiFi SAS Page 14