Alive Triggers
Key Alive Triggers in Payoff Policy refers to an optional set of claims - represented as an object of type KeySet - that are meant to stay "alive" (i.e. active and therefore "triggerable") after an event associated with any specific claim is triggered.
In effect, the entry here introducess an exception to the default rule applying to all policies whereby the occurrence of any event causes the deactivation of all subsequent claims and all subsequent payoff valuations.
In more formal terms, it defines an optional mapping 𝘨ᴬᵀ (AT for Alive Triggers) that establishes an association between certain selected Contingent Claim objects to corresponding sets of Contingent Claim objects, which association affects the future triggering events of the claims in those sets as described below.
So, formally 𝘨ᴬᵀ acts on any such selected Contingent Claim object C as follows:
𝘨ᴬᵀ: C → { C₁ , C₂ , ... , Cᵣ }
where r is a positive integer.
and C₁ , C₂ , ... , Cᵣ are all available Contingent Claim objects.
Before explaining the meaning of this association, a fact must be stated regarding the default impact that any trigger event has on all other trigger events, past, present and future.
By default, when a trigger event takes place, all future claims will cease to exist and also any payoff commitments that were perhaps established by previous trigger events are deemed void and need not be honored.
For example, a typical barrier knock-out event exemplifies this generic default rule since only the payoff (i.e. the barrier rebate) associated with this event is paid and all other claims simply disappear, including the claim associated with future knock-out events at the same barrier.
The mapping defined here allows to override this default rule with respect to events triggered by certain selected claims.
Concretely, for any claim C in the mapping defined here, the following holds:
If during a simulation run at some time T an event E takes place, whereby the claim C is triggered , then all the claims in the set { C₁ , C₂ , ... , Cᵣ } stay alive and thus are allowed to be triggered anytime at or after T.
Below are the technical details on how the Alive Triggers mapping is implemented on the spreadsheet.
a) The key Alive Triggers expects an object of type KeySet and works as follows:
The names used for the Keys part of the KeySet object serve to identify the special claims C discussed above by means of the unique ID each claim bears through its key Claim ID.
It is therefore imperative that the chosen key names cannot be arbitrary, as they should match the IDs of the objects defined through the key Contingent Claims.
b) The Value corresponding to each key is expected to be a 1D-array of text labels that - similarly as with the keys - are interpreted as claim IDs and thus identify the associated Contingent Claim objects.
For example:
Let a key be KI-LOWER-BARRIER= and let its associated value be an array consisting of the two labels KO-UPPER-BARRIER and COUPON.
The meaning of this assignment is as follows:
First of all, the assignment becomes relevant only if the trigger of the Contingent Claim object whose Claim ID equals KI-LOWER-BARRIER fires up, i.e. if that object's embedded Trigger Fn valuates to TRUE during the simulation.
Then the assignment decides which - if any - of the available Contingent Claim objects should be observed at future times during that simulation.
For example, assume the KI-LOWER-BARRIER trigger fires up at some time during a simulation run.
If the value associated with the key KI-LOWER-BARRIER= were an empty array, there would be generally no reason to continue with the simulation since there would be no future triggers to observe, with the sole exception of already claimed payoffs.
But the current assignment stipulates that the simulation run should continue its course because of the likely occurrence of future events caused by the triggers of the Contingent Claim objects whose Claim ID is KO-UPPER-BARRIER or COUPON.
Note it is not required that all Contingent Claim objects are represented through the keys here.
In fact, it is sensible to not include a Contingent Claim that acts as a typical knock-out, since in the case of a knock-out event no further triggers are usually observed.
Alternatively, the key associated with a knock-out Contingent Claim may still be present, but with an empty associated array of labels.