Keeping track of latest version of an instrument

[GeorgSchneider]

@matteolimberto-da :

Use-case: I would like to write a forward contract for the delivery of a stock of Apple at a specified time T in the future.

Apple might pay dividends in the time interval [today, T] and hence the corresponding Issuable might change before the forward contract matures.

Question: how do we write a derivative that references the "latest version" of the underlying?

One approach is to

use an identifier (e.g. ISIN) to reference the underlying in the derivative have a way to map the identifier to the latest ContractId Issuable An alternative approach is to

write the derivative referencing the Issuable which is live at the time of contract creation each time there is a corporate action on the underlying (e.g. dividend payment) one should lifecycle the derivative (in this case, just updating the Issuable reference for the stock)

[GeorgSchneider]

@lucianojoublanc-da :

Couple of random thoughts:

What do we mean by 'latest' when a instrument has optionality, e.g. a convetible bond? It sounds like what we need is a Time -> Instrument, or rather Time -> Update Instrument, which could be an Observation t a a from contingent claims.

[GeorgSchneider]

@johan-da :

I would think approach 1 ^^ together with a Time -> Instrument (to get the prevailing version at delivery time) would be best. A future contract could then be sampled at delivery time to get what should be settled.

Furthermore, one would also need to consider the case of a deferred settlement due to a settlement failure. Assume, for example, a dividend happens between the settlement date and the deferred settlement date. Then the future contract would need to be lifecycled again and compensate for the missed out dividend (similar to the way buyer protection works for Dvps).

In a sense, a Dvp is a T+2 future contract where we know what the prevailing version will be at delivery time (as ex-dates are being announced in due time).

[GeorgSchneider]

@lucianojoublanc-da :

I would think approach 1 ^^ together with a Time -> Instrument (to get the prevailing version at delivery time) would be best. A future contract could then be sampled at delivery time to get what should be settled.

What would happen in the case of say, a convertible bond, so that at maturity there exist two separate ISINs (the original bond, and the converted equity)?

[GeorgSchneider]

@johan-da :

@lucianojoublanc-da Maybe something along the following lines (only thoughts):

There are 2 types of corporate actions mandatory (like stock splits, dividends, entitlements, ...), and voluntary (like the exercises of rights/options/convertible bonds/put bonds).

For a convertible bond, the owner has the right (i.e., voluntary corporate action) to convert the bond into an equity. Maybe we could model that as a timely-bound effect (to convert the equity into the bond), i.e., you as an owner can only use the effect and convert your bond until a certain time. If the owner does not apply the effect until that time, the bond remains as is.

Alternatively, a corporate action could spawn one effect for each choice targeting the same instrument, i.e., a timely-bound one for converting, and an open-ended one for not-converting which only upgrades the bond to its next version.

More generally, if an input is required from the owner, a pre-step contract which captures the input could be used, before the effect is spawned, and such effects would be on a per owner basis (as the inputs may vary from owner to owner).

For (many) mandatory corporate actions, like a stock split, I would envision the effect to have no time bound, such that every owner can lifecycle whenever they feel like it or need to (lazely). Even a corporate action effect which gives you an entitlement (say a cash dividend) could be open ended (and lifecycled lazely). The actual entitlement could in turn be restricted such that it can only be lifecycled/converted into cash until a certain date. So if you don't life cycle your equity in time, the entitlement you receive might actually be worthless (as it can no longer be converted to cash).

So if you are not an active lifecycler, you might miss out on benefits, but you can always lifecycle your asset to the newest version. And if you don't want to miss out on benefits, maybe you better give standing instructions to your custodian how to lifecycle your assets on your behalf..

...but there are edge cases, and it really depends on your derivative how to treat corporate actions of the underlying assets. For example:

If you have a forward of an underlying with an option (like a forward of a convertible bond) with maturity of the forward after the exercise time of the option (not sure there are such products), I guess such an exotic forward contract would pass on the optionality to its owner . So, in such a case, the derivative would actually need to be lifecycled to reflect the underlying option choice. Say there is a merger for 2 underlyings of a Barrier Reverse Convertible (BRC). Then the BRC is typically lifecycled by adding an extra underlying at the sole discretion of a calculating agent (in a somewhat "fair" manner).

[GeorgSchneider]

@matteolimberto-da :

What do we mean by 'latest' when an instrument has optionality, e.g. a convertible bond? Indeed, as you mentioned this morning, "latest" is not uniquely defined if an instrument does not have a total order (like in the case when it admits optionality and this optionality has already been exercised)

[GeorgSchneider]

@GeorgSchneider :

For a convertible bond I actually see it differently: it's not that you still hold a version of the bond after converting, you hold a different instrument (and your original bond expires). So the version history of the bond is still linear and reflects the "unexercised bond".

But I guess in the general case where both options in a branch continue to exist you do in fact have two parallel "latest" versions of an instrument and it's unclear how one would refer to such in a derivative. However, I can't currently think of a real-world instrument that would exhibit this property.

[GeorgSchneider]

@GeorgSchneider :

We could also consider to state explicity that optionality is only supported if one of the branches terminates the instrument. Then we would still have a linear instrument history. But this would of course limit the generality of the framework. The question for me is, are there actual, real-world instruments out there that exhibit true branching behaviour?

[GeorgSchneider]

@GeorgSchneider :

Another thought I just had: the problem with underlyings going through corporate actions and evolving only exists if we actually manage the underlying evolution on the ledger. That is, if we consider the underlyings instruments, where dividends etc. are actually handled off-ledger (ie. through existing processes), it should be enough to keep a single version of an underlying on-ledger, and consider this the only version to exist and be referenced in derivatives.

[markus-da]

The question for me is, are there actual, real-world instruments out there that exhibit true branching behaviour?

I think instruments where individual investors have optionality (e.g. puttable bonds) could be an example. Not sure these would be used as underlyings though.