FRAGMOS - Autocallable Provisions

[JBZ-Fragmos]

BACKGROUND

"Autocallable Provision" is a paricular set of feature usually used in so-called exotic/structured products, but we may define it per se, regardless of the nature of the product it is attached to as "a specific type of early termination that is triggered when an embedded Knock-Out condition is activated".

From a modelling standpoint, such a type is an enrichmen

The model proposal notably relies a new type "KnockCondition" - which for clarity means that the implementation of the new type "KnockCondition" is prerequisit for implemented the current new type "Autocallable Provision"

Related PR : #2962

PROPOSAL

The proposed modelling is to create new type AutocallableProvision, added to existing type EarlyProvision as an optional attribute (with condition required choice in regards of other attributes) :

The new type Autocallable Provision "extends KnockCondition", that is consistent with business description of this feature that is all in all a knock out barrier placed at root Trade level, with some additional attribute compared to core knock features, hence why modelling it with a type that "extends" the type that represents knock out barrier

by adding :

• some conditions for restricting the related KnockCondition values in accordance its particular usage in context i.e. for instance the Enum type of KnockCondition used under AutocallableProvision must be "KnockOut" (cannot be "KnockIn")

• and specific attributes, mainly designed for the purpose of specifying the effect on trade in terms of payout at settlement when knocked, because there is no pre-determined link with particular Payout legs of the trade i.e. some are payable when Autocallable event happens, some are not, sometimes none is payable, etc. it depends each particular trade - hence main attributes below, both with an optional cardinality, meaning that no such amount shall be paid if an early termination would occur (conversely, for representing trade terms upon which early termination would trigger some particular payment then such attributes shall precisly be defined)

  • earlyRedemptionPayoutAmount : can be specified via referencing each particular Payout leg that is payable when Autocallable event happens, ; it is of existing type NewPayoutOrigin (see Object details below)

  • earlyRedemptionPrincipalAmount : can be specified if particular Principal Payment is payable when Autocallable event happens

hereunder exhaustive view of the new proposed type with all attributes :

COMPATIBILITY

For clarity, there are two ways to represent the feature, depending if we want tto rely on existing type Trigger else if we want to rely on KnockCondition (being a new type designed with intent to replace Trigger) :

• above screenshot is showing proposal at target where existing type Trigger (mostly used to represent knoc barrier) has been replaced by more rich type named KnockCondition, that is described as one piece in the set of components described in GitHub Issue "BespokePayoutFormula" FRAGMOS - BespokePayoutFormula ( ex- Structured Product) #2941

• but short term implementation is feasible without using KnockCondition, simply by extending the existing type Trigger instead, that being siad if we want to separate topics by postponing the refactoring of Trigger <> KnockCondition at later stage