## 8 FX PRODUCT ARCHITECTURE

### 8.1 FX Scope

The Scope of FpML 5.5 Recommendation includes redesigned FX product model developed by the Modeling Task Force (MTF) and FX Working Group to make it more consistent with other FpML product representations and to facilitate its further development. As a result of this work many of an original 4.x model’s issues were addressed:

- A number of sets of reusable components that facilitates product development were defined, so that the existing and future FX products will leverage these building blocks to ensure the FX model is coherent and easy to maintain, as per FpML best practices
- Extended the existing coverage to include Dual Currency Deposits and FX Flexible Forward.
- Rationalized the models' constraints:
  - Made use of grammar to bring related data together.
  - Made better use of XML schema to simplify the validation rules.

In FpML 5.5 Recommendation the following FX products are covered:

- Basic FX Products
  - FX Spot, FX Forward (including non-deliverable settlements, or NDFs) and FX Flexible Forward.
  - FX Swap
- Simple FX Option Products (including, features, cash and physical settlement)
  - FX options
    - European and American
    - Averaging
    - Barriers
  - Digital Options
- Option Strategies (multiple simple options)

In addition, support for the following money market instrument is also provided:

- Term Deposits (including features)
  - Money Market Deposits
  - Dual Currency

NOTE: Some additional fields for Foreign Exchange Flexible Forward product are being considered for the next draft.

### 8.2 Foreign Exchange Spot and Forward

Foreign exchange single-legged instruments include spot and forwards. fxSingleLeg contains a reusable entity (FxCoreDetails.Model) that describes common components to FX spot, forward and swap legs: two instances of the exchangedCurrency component (the first currency and the second currency), an optional dealtCurrency that indicates which currency was dealt, either a single value date component for the trade or an optional value date per exchanged currency, an optional tenorPeriod that denotes the tenor on which both currencies traded will settle, a single instance of the exchangeRate component, and an optional nonDeliverableSettlement component.

Note: An optional confirmationSenderPartyReference (to the party that is sending the current document as a confirmation of the trade is accommodated) has been moved out from the product economics. It will be placed at the trade level.

####

8.2.1 Exchanged Currency

The simple FX transaction contains two currencies which are exchanged between parties. The characteristics of each currency exchange: the currency, the amount, and optionally settlement instructions are described in the exchangedCurrency structure. An optional payment date is allowed per currency if there is a requirement to provide for date adjustments for each currency based upon business day conventions to accommodate unscheduled holidays.

##### 8.2.1.1 Settlement Information

An optional settlementInformation structure has been included for each exchanged currency. This can be used in a variety of ways: flagging a trade for standard settlement, flagging a trade for settlement netting, or specifying the detailed settlement instructions for that particular currency flow.

##### 8.2.1.1.1 Settlement Instruction

| If the specific settlement instruction is included, then this is broken out into correspondent, intermediary, and beneficiary information. This includes the identification of the routing mechanism (e.g., SWIFT, Fedwire, etc.) that the trade will settle via and the id and account that the trade will settle via. Routing can be handled either via purely a routing id (e.g., SWIFT code), routing details (a customer name, address, and account number), or a combination of routing id and details. The following diagrams show the correspondent, intermediary, and beneficiary structures.

##### 8.2.1.1.1.1 Correspondent Information

##### 8.2.1.1.1.2 Intermediary Information

##### 8.2.1.1.1.3 Beneficiary Information

##### 8.2.1.1.1.4 Beneficiary Bank

##### 8.2.1.1.1.5 Split Settlement

Split settlement is also accommodated. Split settlement will mean that there will be multiple beneficiaries associated with a single trade, where the payment amounts are broken down between beneficiaries. The following diagram shows how this has been modeled:

####

8.2.2 Exchange Rate

The rate of exchange is required for a foreign exchange trade. The rate of exchange includes a reusable entity (QuotedCurrencyPair) that describes the underlying composition of the rate: the currencies and the method in which the rate is quoted. The actual trade rate is required, but other rate information such as spot rate, forward points and point value are also accommodated. For non-base currency trades, cross rates (or rates to base) to accommodate the currency exchange rates to cross between the traded currencies are provided for.

Note: the refactored rate of exchange model has stricter grammar than FpML 4.x, which eliminates a few rules (e.g. fx-1, fx-2, fx-3, fx-28, fx-29 ).

####

8.2.3 Non Deliverable Settlement

Non-deliverable settlement is catered for within the conventional FX single leg structure by including an optional non-deliverable information structure that is used to describe a particular type of FX forward transaction that is settled in a single currency (for example, a non-deliverable forward). This content identifies the agreed-upon settlement currency and describes the fixing date and time, as well as the settlement rate source that the fixing will be based upon. The non-deliverable structure is shown below.

If present the fixing element indicates a currency pair that should be observed to obtain the settlement rate for the trade. The details of where the rate should be sourced and when the rating should be performed are defined within the structure.

In FpML 5.5 an alternative structure that allows the definition of fixings from standard rate sources has been added to the schema.

####

8.2.4 Disruption Events

The disruption section of the FX single leg describes the settlement provisions that come into force if the normal settlement process cannot be carried out due to some unexpected market event.

A disruption section can be defined for each currency pair related to the final settlement as shown in the following diagram. Each section must define one or more provisions which in turn define a set of events and a set of fallbacks. Should any of the events listed inside a provision occur then any of the corresponding fallbacks can be used to try and achieve settlement. By having multiple provision sections it is possible to associate specific fallbacks with specific events if needed.

The elements used to denote events and fallbacks are defined using a substitution group to allow additional definitions to be more easily added either within the FpML schema or in bespoke extensions to it.

### 8.3 Foreign Exchange Flexible Forward

FxFlexibleForward-Product model for a flexible-term fx forward (also known as callable forward, window forward). This is a term forward transaction over a specific period, allowing the client full flexibility on the timing of the transactional flow(s). The product allows for (full or partial) execution at a predetermined forward rate, at any time between the start date and the expiry date. Although, the product is an outright, it has some option-like characteristics, leading to the use of option components in the model: (i) the BuyerSeller model expresses the roles of the parties in the overall transaction - the client "buys" the product (ii) the PutCallCurrency model expresses the buyer's perspective on the exchanged currencies i.e. the client may buy (call) or sell (put) the notional currency for the alternative currency.

| BuyerSeller.model-No Annotation Available PutCallCurrency.model-No Annotation Available notionalAmount-The aggregate notional amount which will be exchanged, possibly as multiple partial executions, during the course of the execution period. Any residual notional which remains unexchanged at the expiry date will automatically be executed at the applicable exchange rate (strike). minimumExecutionAmount-The minimum notional amount which must be executed in any single transaction. executionPeriodDates-The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur. earliestExecutionTime-The earliest time of day at the specified business center, at which the client may execute a transaction. latestExecutionTime-The latest time of day at the specified business center, at which the client may execute a transaction. settlementDateOffset-The date on which delivery of the transacted currency amounts will occur, expressed as an offset from the execution date. * This property is optional in the schema, allowing it to be omitted by systems which do not support it; however this information would be expected in contractual documentation (e.g. termsheet, confirmation).The date on which delivery of the transacted currency amounts will occur, expressed as an offset from the execution date. * This property is optional in the schema, allowing it to be omitted by systems which do not support it; however this information would be expected in contractual documentation (e.g. termsheet, confirmation). finalSettlementDate-The final date for settlement. This is the date on which any residual exchange amount will be delivered. * This is an adjusted date i.e. a good business day for delivery in the location(s) specified in executionPeriodDates /businessCentersThe final date for settlement. This is the date on which any residual exchange amount will be delivered. * This is an adjusted date i.e. a good business day for delivery in the location(s) specified in executionPeriodDates /businessCenters forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period. forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period.

####

8.3.1 FxFlexibleForward->executionPeriodDates

executionPeriodDates-The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.

| startDate-Start date of the execution period/window. expiryDate-Expiry (maturity) date of the execution period. businessCenters-Business centers for determination of execution period business days.

####

8.3.2 FxFlexibleForward->forwardRate

forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period.

| rate-Constant rate value, applicable for the duration of the execution period.Constant rate value, applicable for the duration of the execution period. spotRate-The spot exchange rate for the specified currency pair as per the specified quote basis, as at the trade date.The spot exchange rate for the specified currency pair as per the specified quote basis, as at the trade date.

### 8.4 Foreign Exchange Swap

A foreign exchange swap is a single product that combines two trades, either spot/forward or forward/forward. (The FpML 4.x 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). A standard FX swap contains only two legs, nearLeg and farLeg to indicate the value date order. There are a variety of different types of FX swaps in the marketplace: standard (round-amount) swaps, overnight swaps, unequal-sided swaps, forward-forward swaps. All of the features that are available within FxCoreDetails.Model, common components to standard FX spot and forward trades (described previously) can be utilized in describing an FX swap as well.

####

8.4.1 FX Swap Leg

Near and far legs are based on a new FxSwapLeg type and derived from a super type Leg from which all swap legs are extended (and is not derived from Product as in 4.x).

### 8.5 Foreign Exchange Option

Foreign exchange options model is completely redesigned compared to 4.x model that was very loose with too many independent optional elements. It did not enforce relationships between elements. The basic data types used for values like rates had no constraints (e.g. could be negative). The 5.x model is designed to bring related data together and many elements were renamed in line with FpML naming convention and MTF recommendations.

Foreign exchange options are now more consistent with other option products. FxOption type extends new Option base type - a type that defining the common features of options - buyer and seller model and derived from a Product type (the Option type could be used to re-factor other option types). It also includes separate exercise structures for standard European and American options.

FxOption structure now can be used for both 'vanilla', as well as for Averaging and Barriers options that are represented in fxOption as 'features' and not as separate products like in 4.x. (Note: the Barrier structure has been refactored in FpML 5.5 to support the correct definition of simple barrier products, e.g. the concept that a barrier must be crossed in a direction. In making the directional quality of a barrier separate from its in/out quality, we follow the approach taken in the Swift confirmation message format, and the confirmation templates in the 2005 ISDA FX Barrier Options Supplemental Definitions. Taking this approach also has the advantage that it is least disruptive to the existing schema.)

A vanilla fxOption identifies an exercise style, the put currency and amount, and call currency and amount, strike price and premium information. The premium is structured similar to an exchanged currency for a conventional FX trade, where optional settlement information for the premium can be attached. In addition, there are optional procedures associated with the exercise, a soldAs reference to allow buyer/seller perspective to be easier to derive – did I buy a put or sell a call, spotRate that this represents the current market rate for a particular currency pair. Note: quotedAs component has been removed as it was a legacy element carried through the versions and the group felt it was confusing.

####

8.5.1 FX Option Exercise

The fxOption element allows the description of a basic FX Vanilla option with European or American exercise.

It provides a (mandatory) choice between describing European or American exercise:

##### 8.5.1.1 American Exercise

Fx American Exercise structure has a commencement date, expiry date, cut, latest value date and the ability to describe minimum and maximum currency amounts for multiple exercise. multipleExercise with optional limits on the notional size.

##### 8.5.1.2 European Exercise

European exercise is at a date, time, cut and identifies the value date.

####

8.5.2 FX Features

With a vanilla option described, the model then provides optional features which may be used in a one-to-many fashion to add to the option to build up the desired structure.

##### 8.5.2.1 Fx Barrier Feature

The 4.x FX barrier option model extended fx option product with spot rate, fx barrier and trigger payout. As part of the refactoring work, Asian and/or Barrier represented as a new features to the FxOption and not as separate products. An fxOption with barrier features - a conventional option except that it is changed in a predetermined way when the underlying trades at predetermined barrier levels. Foreign exchange barrier features defines the level and the condition for activation. A knock-in option pays nothing at expiry unless at some point in its life the underlying reaches a pre-set barrier and brings the option to life as a standard call or put. A knock-out option is a conventional option until the price of the underlying reaches a pre-set barrier price, in which case it is extinguished and ceases to exist. Barrier options have both a strike price and a barrier price.

The Barrier structure has been refactored in FpML 5.5 to support the correct definition of simple barrier products. The refactored structure provides an additional direction element following the barrierType. This would be an enumeration with values 'Up' and 'Down'. In addition it deprecates the use of the existing enumerable values: 'ReverseKnockin' and 'ReverseKnockout'; only 'Knockin', and 'Knockout' are necessary. In making the directional quality of a barrier separate from its in/out quality, we follow the approach taken in the Swift confirmation message format, and the confirmation templates in the 2005 ISDA FX Barrier Options Supplemental Definitions. Taking this approach also has the advantage that it is least disruptive to the existing schema.

The present observationStartDate and obervationEndDate elements provide the ability to describe, full barrier, forward barrier, partial barrier or window barrier options. In addition to the dates, the MT306 and the ISDA confirmation templates require the specification of the start and end times for a barrier in terms of the business center and time. In order to remain backwardly compatible with the present definitions, in FpML-5-5, the provision of start date times and end date times is added optionally, and if start date and end date are provided, observationStartTime and observationEndTime remain optional.

MT306: An MT306 barrier block will specify the end location and time and is always mandatory. In the case of the start time, the location is mandatory and time is optional. If no time is specified this implies that the barrier starts at the execution date time. The optionality of the start date is a concession to the fact that the exact time of execution is subjective and frequently unrecorded; and certainly should not be a matching field on a confirmation.

    				Additional Conditions	:BRUP
    				____________________________________________________________
    				Barrier Block

    				Type of Barrier	:SKOT
    				Barrier Level	:1.5000000000
    				____________________________________________________________
    				Barrier Window Block

    				Start Date	:Aug 11, 2011
    				Location and Time	:USNY
    				End Date	:Aug 13, 2012
    				Location and Time	:USNY 10:00
    				____________________________________________________________

ISDA FX Barrier Options Supplemental Definitions 2005:The confirmation templates within the ISDA definitions provide, for example, in the Barrier Option template at Page 10:

    				[Event Period Start Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]]23
    				Event Period End Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]24]25

    				23 Because the Trade Date is the most common Event Period Start Date for a Barrier Option Type, Section
    				3.9(i) of this Supplement contains a presumption that, unless otherwise specified, the Event Period Start
    				Date and Time is the Trade Date at the time the Transaction was entered into. Parties should specify the
    				Event Period Start Date and Time if they wish to modify this presumption.

    				24 Parties should include Event Period End Date and Time if they wish to modify the presumption in Section
    				3.9(h) of this Supplement that the Event Period End Date and Time are the Expiration Date at the
    				Expiration Time. Nonetheless, for an at-expiration Currency Option Transaction, parties may wish to
    				specify that the Event Period End Date and Time are the Expiration Time on the Expiration Date.

    				25 Event Period Start Date and Time and Event Period End Date and Time may be specified for any Barrier

American Barriers are represented using the observationStartXxxx and observationEndXxxx elements.

European Barriers are represented by providing a single observationPoint element, with the date equivalent to the trade expiry date as defined in the fxOption/EuropeanExercise or American Exercise elements, and the time either equivalent to the expiry time, or omitted.

Discrete Barriers are not supported by MT306, but a new structure added in FpML 5.5. will support them. Discrete Barriers would be represented by providing a collection of observationPoint elements, with individual observation times.

| barrierType-This specifies whether the option becomes effective ("knock-in") or is annulled ("knock-out") when the respective barrier event occurs. Note: only 'Knockin', and 'Knockout' are necessary; 'ReverseKnockin' and 'ReverseKnockout' are DEPRECATED. direction-This specifies whether the barrier direction is "Up" or "Down"; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american barrier, or at the times of observation of a discrete or european barrier. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a trigger event is deemed to have occurred. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750. observationStartDate-The date on which the observation period for an american barrier starts. If the start date is not present, then the date and time of the start of the period is deemed to be the date and time the transaction was entered into. observationStartTime-The time on the start date at which the observation period for an american barrier starts. If the time is not present and the start date is equivalent to the transaction date, the time is deemed to be the time the transaction was entered into. If the time is not present and the start date is other than the transaction date, then the time is deemed to be the same as the expiration time. observationEndDate-The date on which the observation period for an american barrier ends. If the end date is not present, then the date and time of the end of the period is deemed to be the date and time of expiration. observationEndTime-The time on the end date at which the observation period for an american barrier ends. If the time is not present, then the time is deemed to be the same as the expiration time. observationPoint-The dates and times at which rate observations are made to determine whether a barrier event has occurred for a discrete or european barrier. If the time is not present then the time is deemed to be the same as the expiration time.

The FpML schema envisages that a double barrier product would be described using two of these barrier elements.

The FpML schema provides for the definition of the Barrier Determination Agent. The Barrier Determination Agent is a definition of the contract in a similar way to the Calculation Agent. The 'barrierDeterminationAgent' reference therefore reside as a child of the trade element in a similar way to the Calculation Agent.

The usage is:

    				<trade>
    				  <tradeHeader>…</tradeHeader>
    				  <fxOption>…</fxOption>
    				  …
    				  <barrierDeterminationAgent href="Party1"/>
    				</trade>

    				<party id="Party1">
    				  <partyId>LEI</partyId>
    				  <!-- Other Party Information -->
    				</party>

##### 8.5.2.2 Fx Asian Feature

Foreign exchange asian features - (sometimes referred to as asian or average rate) captures the parameters for the average rate calculation. FxOption with asian feature is an option whose payout is based upon the average of the price of the underlying, typically (but not necessarily) over the life of the option. These options are popular because they are usually cheaper than conventional options because the averaging process over time reduces volatility.

FxAsianFeature includes a FX rateObservation component, a collection of specific observation dates, accompanied by a specific weighting factor and average rate options on occasion when struck already have agreed-upon rate observations in the past. FX rateObservation can be produced either as an independent representation of a series of specific observation dates, or to supplement the parametric representation of the observationSchedule (e.g., daily, 2nd Friday, etc.), utilizing the same rolling convention schemes as utilized within the interest rate derivatives area. The model is constructed as an “at-least-one-of” model which enforces the existence of observationSchedule, or rateObservation, or both. Below are the structures for an FX OTC asian feature.

The rateObservation collection is optionally accompanied by a rateObservationQuoteBasis, allowing this to be made explicit.

The following diagram shows a graphical view of a collection of specific observation dates, accompanied by a specific weighting factor and average rate options:

Where the observation schedule is represented parametrically, the rateObservation series may be absent, or limited to observations which have already occurred – but now the observed rate values are accompanied by their weighting factor:

A combination of an average rate and one or more barrier are supported.

####

8.5.3 Premium

####

8.5.4 Cash Settlement

The cash Settlement component specifies the currency and fixing details for cash settlement. It has the identical underlying type that is also used within FX Single leg and FX Swap products (see section 8.2.3.). This cash Settlement optional structure is produced only where it has been specified at execution time that the option wlll be settled into a single cash payment - for example, in the case of a non-deliverable option (although note, that an Fx option may be contractually cash settled, without necessarily being non-deliverable). Physical delivery means - entering into a spot transaction for currency delivered on both sides. Cash settlement means - settling into one of the option currency or quanto arrangement, and then supply FX spot rate observation and other parameters in the cash settlement block.

### 8.6 Foreign Exchange Binary and Digital Options

The terms binary and digital are not clearly defined in the FX markets and can occasionally be synonymous. This is used to define an option that has a discontinuous payout profile. It typically pays out a fixed amount if the underlying satisfies a predetermined trigger condition or else pays nothing. Unlike the standard option, the amounts quoted are the payout amounts as opposed to a notional underlying amount. Below are the structures for FX OTC binary and digital options.

####

8.6.1 Option Style

The schema provides for a choice between Digital with American Exercise, as a grouped pair of elements of American exercise and a touch element. Digital with European Exercise, as a grouped pair of elements of European exercise and a trigger element.

American Barriers is represented using the observationStartXxx and observationEndXxx elements.

Discrete Barriers are not supported by MT306, but a new structure added in FpML 5.5. will support them. Discrete Barriers would be represented by providing a collection of observationPoint elements, with individual observation times.

European Barriers is represented using the grouping of the europeanExercise and trigger elements. In the case of a European Barrier, there is no need to specify a datepoint for the barrier, because it is intrinsically the same as the expiry date, which would be specified in the European Exercise block accompanying the trigger block.

##### 8.6.1.1 American Exercise and American Barrier/ Discrete Barrier

Binary options, on the other hand, are more like American options (but with out multipleExercise element), meaning that the payout occurs if the spot rate trades through the trigger level at any time up to and including the expiry date. The four examples that have been included in the specification are the one-touch, no-touch, double one-touch, and double no-touch binary options.

##### 8.6.1.1.1 American Exercise

| commencementDate-The earliest date on which the option can be exercised.The earliest date on which the option can be exercised. expiryDate-The latest date on which the option can be exercised.The latest date on which the option can be exercised. expiryTime-Time at which the option expires on the expiry date.Time at which the option expires on the expiry date. cutName-The code by which the expiry time is known in the market.The code by which the expiry time is known in the market. latestValueDate-The latest date on which both currencies traded will settle.The latest date on which both currencies traded will settle.

##### 8.6.1.1.2 American Barrier/ Discrete Barrier

The option may have one to many touch elements of type 'FxTouch' to describe the triggers.

Touch and no Touch Binary options have the concept that the trigger must be touched in a direction. That is, that the barrier is triggered if spot is at or above the barrier level or at or below the barrier level. In the MT306 format, the trigger direction is specified in Field 77D with values TRDN, TRUP. In line with the proposal for barrier options, the 'FxTouch' structure has been refactored in FpML 5.5 to define the trigger 'direction'. This segregates the 'touch'/'no touch' ('touchCondition') condition from the 'above'/'below' ('direction') condition. The 'direction' is of type 'TriggerConditionEnum'. This type is reused from the case of the European Digital, where the same definitions apply. This type's present the enumerated values 'Above' and 'Below' are deprecated in favour of the more precise new values 'AtOrAbove' and 'AtOrBelow'.

Mirroring the changes for Barrier Options, in FpML-5-5, the provision of start date times and end date times is added optionally, and if start date and end date are provided, observationStartTime and observationEndTime remain optional.

MT306:

    						The Swift MT306 protocol does not support binary options with window barriers as there is no Trigger Window Block equivalent to the Barrier Window Block.

ISDA FX Barrier Options Supplemental Definitions 2005 (The confirmation templates within the ISDA definitions provide, for example, in the Binary Option template at Page 14 and 15):

    						[Event Period Start Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]]16
    						Event Period End Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]17]18

    						16 Because the Trade Date is the most common Event Period Start Date for a Binary Option Type, Section
    						3.9(i) of this Supplement contains a presumption that, unless otherwise specified, the Event Period Start
    						Date and Time is the Trade Date at the time that the Transaction was entered into. Parties should specify
    						the Event Period Start Date and Time if they wish to modify this presumption.

    						17 Parties should include Event Period End Date and Time if they wish to modify the presumption in Section
    						3.9(h) of this Supplement that the Event Period End Date and Time are the Expiration Date at the
    						Expiration Time. Nonetheless, for an at-expiration Binary Option Type, parties may wish to specify that
    						the Event Period End Date and Time are the Expiration Time on the Expiration Date.

    						18 Event Period Start Date and Time and Event Period End Date and Time may be specified for any Binary
    						Option Type, but they are more commonly used to define “Window Event Periods.”

| touchCondition-This specifies whether the applied trigger is a touch or no touch type. direction-This specifies whether the trigger direction is "AtOrAbove" or "AtOrBelow; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american trigger, or at the times of observation of a discrete trigger. DEPRECATE: Values "Above" and "Below" are deprecated. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a barrier event is deemed to have occurred. spotRate-An optional element used for FX forwards and certain types of FX OTC options. For deals consumated in the FX Forwards Market, this represents the current market rate for a particular currency pair. For barrier and digital/binary options, it can be useful to include the spot rate at the time the option was executed to make it easier to know whether the market rate needs to move "up" or "down" to trigger a barrier event. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750. observationStartDate-The date on which the observation period for an american trigger starts. If the start date is not present, then the date and time of the start of the period is deemed to be the date and time the transaction was entered into. observationStartTime-The time on the start date at which the observation period for an american trigger starts. If the time is not present and the start date is equivalent to the transaction date, the time is deemed to be the time the transaction was entered into. If the time is not present and the start date is other than the transaction date, then the time is deemed to be the same as the expiration time. observationEndDate-The date on which the observation period for an american trigger ends. If the end date is not present, then the date and time of the end of the period is deemed to be the date and time of expiration. observationEndTime-The time on the end date at which the observation period for an american trigger ends. If the time is not present, then the time is deemed to be the same as the expiration time.

##### 8.6.1.2 European Exercise and European Barrier

Fx digital option model uses grammar to ensure triggers match the exercise style.

##### 8.6.1.2.1 European Exercise

Digital options typically are defined as being European, meaning the observation occurs only if the spot rate trades above (or below) the trigger level on expiry date. The two examples that have been included in the specification are the digital and the range digital.

##### 8.6.1.2.2 European Barrier

These 'trigger' structure allows to describe a simple European style digital option with one or more trigger levels. At least one 'trigger' element is mandatory and describes the nature of the trigger, the underlying, the trigger level and the rate source.

The 'triggerCondition' is of type TriggerConditionEnum. This type is reusable in the case of the American Digital, where the same definitions apply. Note, the enumerated values 'Above' and 'Below' are deprecated in favour of the more precise new values 'AtOrAbove' and 'AtOrBelow'.

| triggerCondition-The condition that applies to a european trigger applied to an FX digital option. It determines where the rate at expiry date and time at must be relative to the triggerRate for the option to be exercisable. The allowed values are "AtOrAbove" and "AtOrBelow". DEPRECATE: Values "Above" and "Below" are deprecated. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. Note, the 'quotedCurrencyPair' element provides the ability to describe the underlying. The association of an underlying with each trigger; implies that there may be multiple underlyings. This is not a feature of basic digitals; however this is not something that we see any need to change as it would be required to support more complex digitals. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a barrier event is deemed to have occurred. spotRate-An optional element used for FX forwards and certain types of FX OTC options. For deals consumated in the FX Forwards Market, this represents the current market rate for a particular currency pair. For barrier and digital/binary options, it can be useful to include the spot rate at the time the option was executed to make it easier to know whether the market rate needs to move "up" or "down" to trigger a barrier event. Note, that in the standard confirmation process, the spot level is not a confirmed value. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750.

####

8.6.2 Fx Option Payout

The payout element provides for a payout in 'Currency1' or 'Currency2'. The payout is specified as a precise amount and currency, which allows for digital options which pay out at less than 100% of the nominal.

| currency-The currency in which an amount is denominated. amount-The non negative monetary quantity in currency units.The non negative monetary quantity in currency units. payoutStyle-The trigger event and payout may be asynchonous. A payout may become due on the trigger event, or the payout may (by agreeement at initiation) be deferred (for example) to the maturity date.The trigger event and payout may be asynchonous. A payout may become due on the trigger event, or the payout may (by agreeement at initiation) be deferred (for example) to the maturity date. settlementInformation-The information required to settle a currency payment that results from a trade.The information required to settle a currency payment that results from a trade.

##### 8.6.2.1 Fx Option Payout Style

FX Option payoutStyle is an enumeration:

- 'Deferred' - If the trigger is hit, the option payout will not be paid now but will be paid on the value date of the original option.
- 'Immediate' - If the trigger is hit, the option payout will be paid immediately (i.e., spot from the payout date).

### 8.7 Term Deposit

The term deposit is an agreement between two parties to enter into a financial contract. Similar to a forward rate agreement, a term deposit is contained within a single component and contains no interim interest payments. It is an on-balance sheet transaction that pays interest at maturity based upon an agreed interest rate. While the term deposit instrument is technically an interest rate product, it is included within the FX section of FpML because many institutions that utilize FX transactions also conduct short-term deposits in their respective portfolios to fund foreign currency requirements.

Although there are a number of structured deposits that are occasionally transacted in the marketplace, including deposits with amortizing structure, rate set schedules, and periodic interest payment or interest recapitalization schedules, or even deposits that are denominated in one currency but pay interest in another currency, those types of transactions represent a significant minority of the number of deposits dealt in the wholesale financial marketplace. Therefore, the term deposit structure is intentionally very simple to accommodate the simple yet highly liquid deposit instruments.

The fixed interest rate + the foreign exchange option that can provide a higher rate of return become increasingly popular. These products are confirmed as a single trade which combines deposit and option data attributes. In FpML 5.1, a dual currency option has been modeled as a ‘feature’ that is embedded into a term deposit that causes the payout to be in a second currency.

| Note that both the start date and maturity date of the term deposit is negotiated upfront and are typically of short duration, so the dates of these instruments are fixed. Any unforeseen holidays will generally cause for renegotiation of the contract. Therefore there are no allowances for date adjustments.

####

8.7.1 Term Deposit Features

The variants of main Term Deposit product are represented in the redesigned model as term deposit features (e.g. Dual Currency feature). There are other variants that could be added (e.g. deposit taker can decided interest and principal payment currency).

Dual Currency Term Deposits is 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 provide a higher rate of return. These products are confirmed as a single trade which combines deposit and option data attributes which has been modeled as a ' features' that can be added to a term deposit. Element ‘ dualCurrency' of type 'DualCurrencyFeature' represents Dual Currency Deposit using the 'termDeposit' product's 'features', instead of the 'strategy' like in 4.x model ( [termDeposit] and [fxSimpleOption] products).

### 8.8 Trade Strategies

One or more financial instruments, of any sort that are supported by the FpML specification, can be combined to form what is called a strategy. This can include various packages of the same or different asset classes in a single trade. Typical examples of this would include option packages (e.g., straddles, strangles) or a delta hedge (FX OTC option with spot risk hedged by FX spot deal). Additionally, other asset classes can be combined in a strategy (e.g., interest rate swap with FX, etc.)

Previous | Top of Section | Next
--- | --- | ---