Updating FpML’s FX Products

Andrew Jacobs HandCoded Consulting Ltd.

4 th Mar, 2010

Contents

• Introduction ▫ Background ▫ The ‘Option’ Framework ▫ Validation Issues • • • Basic FX Products ▫ Spot & Forward ▫ FX Swaps FX Option Products ▫ Simple FX options   Barriers Averaging ▫ Digital Options ▫ Range Accrual Term Deposits ▫ Money Market Deposits ▫ Dual Currency Deposits

Background

• • This presentation describes a number of change to the FX options to bring them into line with other product areas ▫ Turned out not to be that easy as every product area derives its options inconsistently with the others ▫ The changes also update the base products to make better use of XML schema and simplify the validation rules This work has been based on experience of using the FX products at BNP Paribas, JP Morgan and a few other firms, as well as designing the FX validation rule set.

Currently No Common Option Base

Product Commodity Option FxAverage RateOption FxDigital Option FxOptionLeg FxBarrier Option OptionBase OptionBase Extended BondOption Swaption Equity Derivative ShortForm Base Equity Derivative Equity Derivative LongForm Base BrokerEquity Option Equity Option

Option Framework?

• • There is no common ‘Option’ base type in FpML ▫ ‘OptionBase’ comes close but forces the inclusion of a put/call flag which is no good for digitals The only thing all option types have in common is that they have is a buyer and seller/writer.

New Option Base Type

• • Only enforces a buyer and seller Could be used to re-factor other option types

Grammar & Rule Issues

• FX products where added to FpML 3.0 as a DTD based model ▫ The grammar is very loose – Too many independent optional elements. It does not enforce relationships between elements ▫ The basic data types used for values like rates have no constraints (e.g. can be negative)

Validation Issues

• • • The FX product set current has ~47 rules ▫ A lot of rules for such simple products A number of rules can be eliminated by adding constraints to element ▫ e.g. FX rates must be greater than zero Some can be eliminated by having more general enumerations ▫ e.g. sideRateQuoteBasis

Spot & Forward Trades

• In 4.x the spot and forward trades are based on the same fxSingleLeg element ▫ New model renames this to fxSpotOrForward

FxSpotOrForward

• Largely the same as 4.x

▫ New dealtCurrency element

Exchange Rate

• Stricter grammar than 4.x

▫ Eliminates a few rules

FX Swap Trades

• • An FX Swap is a combination of two trades, either spot/forward or forward/forward ▫ The old model allowed any number of exchanges but the new restricts it to just two.

In the old model FX Swap was a container for other products – like a strategy. In the new model it’s a single product ▫ Underlying FX trades are named the ‘nearLeg’ and the ‘farLeg’ to indicate the value date order

FxSwap

• Now contains only two underlying legs ▫ 4.x. allowed any number – was effectively a strategy

FX Swap Legs

• Near and far legs based on a new type and not FxSpotOrFoward ▫ Is not derived from Product as in 4.x

FxOption

• • • More consistent with other products ▫ Separate exercise structures for American and European ▫ Averaging and barriers are represented as ‘features’ not separate products New ‘soldAs’ reference to allow buyer/seller perspective to be easier to derive ▫ Did I buy a put or sell a call? Reordered to bring related data together

FxAmercanExercise

• Adds support for multiple exercise ▫ With optional limits on the notional size

FxEuropeanExercise

• Describes the exercise parameters and the associated value date

FxOptionFeatures

• Adds Asian and/or Barrier features to the option

FxAsianFeature

• Captures the parameters for the average rate calculation

FxBarrierFeature

• Defines a barrier level and then condition for activation

FxDigitalOption

• Uses grammar to ensure triggers match the exercise style

FxTouch

FxTrigger

FxRangeAccrualOption

• • Payout is proportional to the number of days that an FX rate remains between bounds ▫ notional * accruing days / days in period Can have additional barrier features ▫ e.g. Knock-out barriers

Consistency with Interest Rates?

• • It was suggested that the TermDeposit model be made more consistent with Swaps, but ▫ Confirmations for Term Deposits are much simpler ▫ The current model is compares well with example confirmations The changes introduced ▫ Change the terminology used to identify the parties (e.g. the depositor and deposit taker) ▫ Re-order some of the elements to group related data

TermDeposit

• Some renaming and reordering compared to 4.x model

Dual Currency Term Deposits

• • • A term deposit with an embedded option that causes the payout to be in a second currency ▫ The fixed interest rate + the foreign exchange option can provides a higher rate of return These products are confirmed as a single trade which combines deposit and option data attributes Has been modelled as a ‘feature’ that can be added to a term deposit ▫ There are other variants that could be added (e.g. deposit take can decided interest and principal payment currency)

DualCurrencyFeature

• Describes the properties of an option used to deliver the interest and principal in another currency

Compatibility with 4.x

• • All 4.x FX products can be transform into the new model ▫ Some element renaming and re-ordering ▫ Could be achieved with XSLT FX Swaps with more than two legs can be modelled as strategies