Generic Barrier Option

Table of Contents

A generic barrier option pays a European payoff at maturity, made conditional on American barriers and on a single European barrier at expiry. ORE prices it on FX, equity and commodity underlyings, single or multiple. This note records the domain grounding, as ORE documents it in its product catalogue.

1. Identifiers

What a trader books it as, and what to grep for. The codes are the trade type catalogue's, which is what the database enforces.

Field Value
Full name Generic Barrier Option
Short name Generic Barrier Option
ORE Studio product code FxGenericBarrierOption, EquityGenericBarrierOption, CommodityGenericBarrierOption
Asset class commodity, equity, fx
Family Option
ORE trade data node FxGenericBarrierOptionData, EquityGenericBarrierOptionData, CommodityGenericBarrierOptionData
ORE documentation generic_barrieroption.tex

2. Summary

The product pays a vanilla call or put, an asset-or-nothing or a cash-or-nothing payoff at maturity. American knock-in and knock-out barriers are monitored on a defined schedule. An option that knocks out cannot knock in again. A knock-out before a knock-in, and the reverse, are separate sub-types. A Transatlantic Barrier adds one European barrier check at expiry. Rebates can compensate the holder when the barriers deactivate the option.

3. Detail

3.1. What it is

ORE defines the product as follows:

Generic Barrier Options pay a (European) vanilla call / put, an asset or nothing or a cash or nothing payoff at their maturity. The payoff at maturity can be made conditional on (single) European Knock-In or Knock-Out barrier condition ("Transatlantic Barrier").

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

ORE describes the American barriers:

In addition, a number of American Knock-In and Knock-Out barrier conditions can be defined that are monitored on a defined schedule, e.g. a daily schedule between a monitoring start and end date.

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

ORE states the knock-in and knock-out logic:

The different barrier types are "UpAndIn", "UpAndOut", "DownAndIn", "DownAndOut". If at least one Knock-In barrier is defined, the final payoff is only activated if at least one Knock-In barrier is touched.

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

An option that is knocked out, can not knock in again.

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

3.2. In plain terms

A generic barrier option is a customisable barrier package on one payoff. The payoff can be a plain call or put, the asset itself, or a fixed cash amount. Several American barriers can watch the underlying on a schedule, each able to knock the option in or out. Once knocked out, the option stays dead. The timing rules decide whether a knock-out can happen before or only after a knock-in. A final European barrier adds one more condition at expiry. Rebates soften the loss when a barrier kills the option.

3.3. How it works in ORE

ORE introduces the trade types:

Generic Barrier Options are defined using one of the trade types FxGenericBarrierOption, EquityGenericBarrierOption, CommodityGenericBarrierOption depending on the underlying asset class and an associated node FxGenericBarrierOptionData, EquityGenericBarrierOptionData, CommodityGenericBarrierOptionData.

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

A generic barrier option has one or multiple underlyings. The single Underlying node names one underlying. The Underlyings node is the alternative form, present when several underlyings are used, and only one of the two can be present. In the multi-underlying case every barrier must provide one level per underlying. For FX underlyings the currency order defines the observed value: for EUR-USD the domestic currency is USD and the observed value is USD per EUR, while for USD-EUR the roles are reversed.

PayCurrency is the payment currency. It is usually the domestic currency for an FX underlying, and the equity or commodity currency for those types. Quanto payoffs are allowed: the foreign currency for FX, or a third currency, or a currency different from the equity or commodity currency.

OptionData carries the option description. LongShort takes Long or Short. PayoffType selects Vanilla, AssetOrNothing or CashOrNothing. OptionType is required for the vanilla payoff and takes Call or Put. ExerciseDate is the exercise date. A Premiums node is optional and holds premiums paid unconditionally. SettlementDate is optional and used unadjusted as given. Instead of it, a settlement lag, convention and calendar can be given relative to the exercise date; the two specifications exclude each other. The lag defaults to 0D, the calendar to the underlying calendar, and the convention to Following. Quantity is the option quantity, required for the vanilla and asset-or-nothing payoffs; for FX it is the amount in foreign currency. Strike is required for the vanilla payoff. Amount is required for the cash-or-nothing payoff.

Barriers holds the barrier definition. Its ScheduleData node is the observation schedule; alternatively a daily schedule with respect to the underlying calendar comes from StartDate and EndDate. Each BarrierData block defines one barrier with its Type, one Levels entry, and the rebate terms. Rebate defaults to zero. RebateCurrency defaults to PayCurrency. RebatePayTime takes atExpiry or atHit; only atExpiry is allowed for knock-in barriers. ORE describes the timing choice for knock-out barriers:

If only Knock-Out barriers are defined, one can associate different rebate amounts to each of the barriers. Once the option knocks out at a barrier, the associated amount is paid. Furthermore, the timing of the payment can be "atHit" (i.e. immediately when the barrier is hit) or "atExpiry" (i.e. on the settlement date associated to the expiry date of the underlying option).

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

For knock-in barriers, or a mixed set, only one rebate amount can be defined, paid at expiry. ORE describes the Transatlantic rebate as follows:

In both cases a separate Transatlantic Barrier Rebate amount can be specified that is paid when the American barriers do not deactivate the underlying option, but the additional Transatlantic Barrier does.

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

StrictComparison tunes the barrier checks: the value 0 uses less-or-equal and greater-or-equal comparisons for knock-in barriers and strict comparisons for knock-out barriers; 1 uses strict comparisons for both; 2 uses less-or-equal and greater-or-equal for both. The value defaults to 0.

KikoType is required when both knock-in and knock-out barriers are defined. ORE lists its values:

KoAlways: The option can knock out any time in the monitoring period KoAfterKi: The option can only knock out after a Knock-In KoBeforeKi: The option can only knock out before a Knock-In

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex.

TransatlanticBarrier is optional. It holds one BarrierData block with one level per underlying, or the matching number of blocks with one level each. Its type, level, strict comparison and rebate are the relevant fields. The rebate is paid when there is no knock-out from the American barriers and no payoff from the Transatlantic barrier.

3.4. Mathematical notes

ORE states the payoff types with S the underlying value and K the strike. The vanilla payoff is the positive part of S minus K for a call, or of K minus S for a put, paid in the pay currency. The asset-or-nothing payoff pays S in the pay currency. The cash-or-nothing payoff pays the fixed amount in the pay currency.

The American barriers scale the payoff. A knock-out barrier zeroes it when touched on the monitoring schedule; a knock-in barrier activates it when touched. The sub-type rules order the knock-out relative to a knock-in. The Transatlantic barrier applies the same in-or-out logic in a single check at expiry. The rebates pay the associated amounts at the barrier hit or at expiry, per the RebatePayTime setting.

3.5. What moves its value (static sensitivities)

  • The underlying value at expiry. It drives the payoff and the Transatlantic barrier.
  • The path of the underlying over the monitoring schedule. It drives the American barriers.
  • The volatility of the underlying.
  • The correlation between underlyings, in the multi-asset form.
  • The barrier levels, types and the KikoType ordering.
  • The payoff type and its parameters: strike, amount, quantity.
  • The rebate amounts and their payment timing.
  • The interest rates that discount the payoffs and rebates.

3.6. How the profile ages (dynamic sensitivities)

Each date of the monitoring schedule checks the American barriers. A knock-out can end the option at any monitored point, subject to the KikoType ordering. A knock-in can activate a dormant payoff. The Transatlantic barrier is decided once, at expiry, together with the payoff. Rebates fall due at the barrier hit or at expiry, per their payment time. The settlement date then settles the payoff.

3.7. Why a customer would want it

A generic barrier option assembles several barrier features in one trade. The buyer can combine American windows, a European barrier at expiry, sub-type ordering and rebates in one contract. The structure serves structured products that need precise barrier timing and protection against barrier losses. In ORE Studio a customer books generic barrier options to value them and run sensitivities on the ORE engine.

3.8. Example

ORE's catalogue shows a long vanilla call on EUR-USD struck at 1.2 with a full barrier structure. The trade monitors a down-and-out at 1.1 and an up-and-in at 1.3 daily until expiry, and adds a Transatlantic up-and-out at 1.3:

<FxGenericBarrierOptionData>
  <Underlying>
    <Type>FX</Type>
    <Name>ECB-EUR-USD</Name>
  </Underlying>
  <PayCurrency>USD</PayCurrency>
  <OptionData>
    <LongShort>Long</LongShort>
    <PayoffType>Vanilla</PayoffType>
    <OptionType>Call</OptionType>
    <ExerciseDates>
      <ExerciseDate>2023-06-06</ExerciseDate>
    </ExerciseDates>
  </OptionData>
  <SettlementDate>2023-06-08</SettlementDate>
  <Quantity>100000000</Quantity>
  <Strike>1.2</Strike>
  <Barriers>
    <ScheduleData>
      <Rules>
        <StartDate>2021-07-10</StartDate>
        <EndDate>2023-06-06</EndDate>
        <Tenor>1D</Tenor>
        <Calendar>TGT,US</Calendar>
        <Convention>F</Convention>
        <TermConvention>F</TermConvention>
        <Rule>Forward</Rule>
      </Rules>
    </ScheduleData>
    <BarrierData>
      <Type>DownAndOut</Type>
      <Levels>
        <Level>1.1</Level>
      </Levels>
      <Rebate>1000000</Rebate>
      <RebateCurrency>USD</RebateCurrency>
      <RebatePayTime>atExpiry</RebatePayTime>
      <StrictComparison>1</StrictComparison>
    </BarrierData>
    <BarrierData>
      <Type>UpAndIn</Type>
      <Levels>
        <Level>1.3</Level>
      </Levels>
      <Rebate>1000000</Rebate>
      <RebateCurrency>USD</RebateCurrency>
      <RebatePayTime>atExpiry</RebatePayTime>
    </BarrierData>
    <KikoType>KoAfterKi</KikoType>
  </Barriers>
  <TransatlanticBarrier>
    <BarrierData>
      <Type>UpAndOut</Type>
      <Levels>
        <Level>1.3</Level>
      </Levels>
      <Rebate>2000000</Rebate>
      <RebateCurrency>USD</RebateCurrency>
      <StrictComparison>1</StrictComparison>
    </BarrierData>
  </TransatlanticBarrier>
</FxGenericBarrierOptionData>

Source: ORE User Guide, Products catalogue, generic_barrieroption.tex, listing Generic Barrier Option data (FX Underlying). The catalogue also shows the multi-asset form with two FX underlyings and one barrier level per underlying.

4. See also

Emacs 29.3 (Org mode 9.6.15)