Contingent Claim
Contingent Claim is a direct subtype of Financial
aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
with functions Contingent Claim Functions, direct subtypes Contingent Claim subtypes, keys Contingent Claim keys and example object ContClaim#1
TYPE INCLUSION RELATIONSHIPS
AVAILABLE FUNCTIONS
AVAILABLE CREATE FUNCTION KEYS
TYPICAL OBJECTS OF TYPE Contingent Claim
This type represents a payoff stream conditional on the satisfaction of a condition on the market state observed at any particular observation timet
Below is a simplified schematic diagram of the main parts composing the structure of a Contingent Claim
Both the market state and the observation time t live outside the Contingent Claim definition.
A Contingent Claim object receives them as input in order to calculate the following three quantities:
a) A Boolean b (true or false) that determines whether the condition is satisfied.
b) A number ON amt that represents the payoff amount conditional on b being TRUE, which amount is referred below as the ON payoff.
c) A number OFF amt that represents the payoff amount conditional on b being FALSE, which amount is referred below as the OFF payoff.
Several objects of type Contingent Claim put together form a Payoff Policy that defines the total payoff of a Structured Product.
Below is a detailed description of the above concepts:
Market state
The observation time t is some future date.
The market state at t is represented by a 1D-array of u numbers x₁ , x₂ , ... , xᵤ.
In the context of a Structured Product referencing u underlyings, in most of the cases the x₁ , x₂ , ... , xᵤ are the market prices of those underlyings "observed" at t
The word "observed" is in double quotes because t is in the future, when no market prices can be truly observed as of the present time.
The word "observed" applies in the context of a simulation where several scenarios are programmatically constructed - typically tens of thousands - with each scenario containing fixed market prices of the u underlyings that presumably apply at the future time t.
Within the context of one such scenario, one may refer to the numbers x₁ , x₂ , ... , xᵤ produced by the simulation as the market prices "observed" at time t.
Note the word "prices" here means the observed "values" of the underlyings, which are not necessarily regular prices, but may also be "rates", depending on the nature of the underlyings.
For example, assume the underlyings are two stocks named A and B with their respective share prices at t denoted as xA , xB.
Then u = 2 and x₁ , x₂ , ... , xᵤ become the array xA , xB.
But it could be that only the first underlying is the stock A, while the second underlying is the interest rate r of the 10-year US treasury.
Then x₁ , x₂ , ... , xᵤ become the array xA , r.
While the above reflects the most common case, the market state can be generalized to also include numbers that do not directly correspond to any underlyings.
A good example is a note referencing the stock A that knocks out when the share price stays above a certain barrier during 3 consecutive observations.
Clearly in this case, at any observation time t, the note's calculated payoff does not depend only on the observed share price xA.
One also needs to know an additional number, which can be denoted as k, which is defined to equal the number of consecutive observations up to and including the time t where the share price was observed to exceed the given barrier.
In this case, the market state x₁ , x₂ , ... , xᵤ become the array xA , k.
Condition
Every Contingent Claim is associated with the concept of an event (or condition) of a specific type.
This association is implemented through a predicate function 𝘨 that is included in the Contingent Claim object.
Parenthetically note here that a predicate function is a function that returns a Boolean (TRUE or FALSE).
Concretely, the predicate function 𝘨 is represented by a Deriscope Object of type Trigger that is defined through the key Trigger Fn.
The first task of a Contingent Claim at any observation time t is to determine whether the event occurs or not (equivalently, whether the condition is satisfied or not).
The Contingent Claim accomplishes this task by applying the predicate function 𝘨 on the market state array x₁ , x₂ , ... , xᵤ.
If the result is TRUE, the interpretation is that the event occurs (equivalently, the condition is satisfied).
If the result is FALSE, the interpretation is that the event does not occur (equivalently, the condition is not satisfied).
If no function 𝘨 is explicitly supplied through the key Trigger Fn, by default 𝘨 is set to RealBoolTransf, which is a predicate function that always returns TRUE.
ON Payoff
Every Contingent Claim is associated with the concept of an ON payoff, which is the amount ON amt deemed to be payable if the claim's condition is satisfied at the observation time t.
In fact, ON amt represents a potential payoff because it is only potentially - but not necessarily - paid out, as explained in Payoff Policy.
During simulation, the amount ON amt is calculated only if the claim's condition is satisfied.
Technically, the calculation is performed by a function ƒON represented by a Deriscope Object of type Real Function defined through the key On Pmt Fn.
OFF Payoff
Every Contingent Claim is also associated with the concept of an OFF payoff, which is the amount OFF amt deemed to be payable if the claim's condition is not satisfied at the observation time t.
Similar to the ON amt, the OFF amt also represents a potential payoff because it is only potentially - but not necessarily - paid out, as explained in Payoff Policy.
During simulation, the amount OFF amt is calculated only if the claim's condition is not satisfied.
Technically, the calculation is performed by a function ƒOFF represented by a Deriscope Object of type Real Function defined through the key Off Pmt Fn.
Additional comments applying to both ON and OFF Payoffs
Whatever the case regarding the occurrence of the event might be, the calculated amount (either the OFF amt or the ON amt) is scheduled to be paid at some prescribed later time T, but the actual payment may or may not take place depending on the interference caused by other events that may occur between t and T.
The denomination currencies of the payoff amounts are defined respectively in keys On Pmt Currency and Off Pmt Currency.
It is possible though that either amount does not represent cash but rather some numerical quantity with a context-dependent meaning.
Concretely, there exist two cases:
Non-cash Payoff
In this case, the amount amt is a number that carries some context dependent interpretation that can be financial or pure mathematical.
For example, in the case of an ELN Accumulator a certain number of shares is accumulated on each relevant observation time, in which case the payoff amount represents that number of shares.
This situation is handled by leaving the currency entry unspecified and instead setting some arbitrary text identifier for a special non-monetary account identified by the name specified in the field corresponding to the key On Pmt Account or Off Pmt Account, whatever the case may be.
Boolean Payoff
In this case, the amount amt describes some financial fact in an indirect way that becomes apparent only when the amount is displayed in binary format.
For example, in the case of a note referencing several underlyings and involving a KO Memory Claim, the knock-out event at the observation timet does not depend on the market state array x₁ , x₂ , ... , xᵤ observed at t, but rather on all the previously observed market states, in the following sense:
If the market price of any one of the underlyings breaches the respective knock-out barrier at any time prior to t, the note does not immediately knocks out, but the event is kept in memory in the sense that this particular underlying is flagged as having crossing the barrier.
Eventually the note knocks out only after all underlyings have been flagged as having crossing the barrier.
Therefore, at any given observation time t, it must be known how many underlyings have been flagged in this way.
One way for conveying this information is through a series of Boolean numbers, 0 for false (not breaching the barrier) and 1 for true (breaching the barrier).
For example, in the case of 3 underlyins, this series at t could equal 1 , 0 , 1, meaning the second underlying has not yet breached the barrier but the other two have.
This series of Booleans can be also writen without separating commas as 101, which is the binary form of the number 5.
This latter number 5 may be regarded as a type of a payoff amount "paid" in a special non-monetary account at the observation time t.
Then the eventual knock-out condition can be represented by a predicate function 𝘨 that expects as input this special "amount" in order to decide whether it is satisfied or not.
In the 3-underlying example, 𝘨 would be:
𝘨(x) = true only if x = 7
because 7 equals 111 in binary form, which carries the meaning that all three underlyings have breached the barrier at or before t.