Modelling bonds and options
In the previous parts of my DAML Masterclass blog post series, I made the case for reverse engineering advanced DAML reference applications in order to get inspiration for your own projects. I also reviewed the Financial Library, which defines data types and contract templates to be used as building blocks for financial applications.
One of the applications which make use of the Financial Library is the Asset Servicing reference application, which I will review in this part.
In the Instrument folder, you can find templates that model several instrument types of the equity and equity derivative, fixed income, loan, and repo category.
Below, I will explain how two asset types, which are among the most common ones, bonds and equity options, are modelled with DAML data types and contract templates.
I will also show you how the full lifecycle of these asset types can be modelled with DAML Scripts.
Bond
Bonds and bond deposits are described via the following data types and contract templates (I’m using as example the definition from the Init.daml file of the refapp).
A) The asset id, which is an Id data type instance, containing
- the signatories of the corresponding instrument contract,
- the label of the bond, in our example “CSGN-3Y-2.5-Jan20”, which stands for a bond issued by Credit Suisse Group AG, with a maturity of 3 years, paying 2.5% per coupon, and expiring in January 2020, and
- a version number, which gets incremented in each transaction, in order to prevent double spending.
(The label is just a convention, nothing enforces that the coupon payment and redemption rules, represented by the Bond contract instance, see below, are consistent with it.)
B) A Bond contract instance, which represents the instrument itself, maintaining uniqueness via its contract key, containing as data the following:
- the aforementioned asset id of the bond,
- the asset id of the currency, in which the bond is denominated,
- the coupon dates,
- the coupon index, which is the index of the next coupon payment,
- the coupon rate, and
- the observers.
C) An AssetDeposit contract instance which contains the following data, plus the choices to set observers, and splitting and merging the deposit:
- the aforementioned asset id,
- the quantity of the bond principal,
- the account on which the bond is deposited, and
- the observers.
The best way to make sure that you understand something is to experiment with it. So I have stripped and extended the Init.daml file of the reference application, so that it only contains data relevant for a bond deposit and its full lifecycle in the form of a DAML Script.
I have also changed the DAML SDK version to 1.6.0 in order to show you how the DAML Studio presents the result of the script. ( 1.5.0 was the first version of the DAML SDK where the DAML Studio presents the result of DAML scripts, similarly to scenario results. From now on nothing prevents you from using scripts instead of scenarios. Scenarios are going to be deprecated, and scripts are the long term supported way of testing workflows and interacting with ledgers. The reason for the switch is that scenarios support atomic operations which are not supported by the ledger API.)
So this is the full process of issuing and lifecycling a bond, and the final result of the lifecycle, which is that the bond principal and the coupon payments are returned to the owner, and deposited on their account.
The bond’s issuer is the CSD (Central Security Depository), owher is the BANK (a retail bank), the bond is denominated in CHF, issued by the SNB (Swiss National Bank).
Lifecycling the bond asset follows a quasi 2 step propose/accept pattern: In the first step the CSD creates a quasy proposal with exercising the asset lifecycle choice on the rule contract which only takes effect with the BANK lifecycling its own deposit.
The main part of the active contract set at he end of the process, namely the bond details and the deposits holding the results of the three coupon payments and the principal redemption, as displayed in the DAML Studio, looks like this:
Equity option
The equity option is the most common type of derivatives. It provides to the owner the right, but not the obligation, to buy (call option) or sell (put option) a quantity of underlying equity, at a set price (strike price), within a certain period of time (at or prior to the expiration date, depending on wether we are speaking about a European or an American option).
Equity options are represented in the Asset Servicing reference application “mutatis mutandis” similarly to bonds, as discussed above.
A) The asset id, which is an Id data type instance, containing
- the signatories of the corresponding instrument contract,
- the label of the option, in our example 1) of a call option, “CSGN-CALL-Sep19”, which stands for a call option for the stock of Credit Suisse Group AG, with a maturity at Sep 2019, and 2) a put option, “UBSG-PUT-Jul19”, which stands for a put option for the stock of UBS Group AG, with a maturity Jul 2019, and
- a version number, which gets incremented in each transaction, in order to prevent double spending.
(Again, the labels are just a convention, nothing enforces that they correspond to the instrument details, represented by the EquityOption contract instance, see below.)
B) An EquityOption contract instance, which represents the instrument itself, maintaining uniqueness via its contract key, containing as data the following:
- the aforementioned asset id or the option,
- the asset id of the underlying stock,
- the option type (CALL, or PUT),
- the exercise type (EUROPEAN or AMERICAN),
- the strike price,
- the contract size, which means the quantity of the underlying stocks to which the option applies,
- the date of maturity, and the
- settlement type (CASH or PHYSICAL — CASH meaning that the price difference gets settled, PHYSICAL meaning that the underlying stocks change hands at settlement).
C) The AssetDeposit contract instances which contain the following data, plus the choices to set observers, and splitting and merging the deposit:
- the aforementioned asset id,
- the quantity of the options,
- the account on which the options are deposited, and
- the observers.
Again, I have stripped and extended the Init.daml file of the reference application, so that it only contains data relevant for the option deposits and their exercising in the form of a DAML Script.
The result of exercising the options are expressed as entitlements, based on the Entitlement contract template:
The full script describing the exercise of the two aforementioned options looks like this:
In the case of the UBSG put option exercise, the bank’s result is:
Result1 = (deposit quantity = 1000)*(contract size = 100)*(price delta = 0.1 CHF) = 10,000 CHF.
In the case of the CSGN call option exercise, the bank’s result is:
Result2 = (deposit quantity = 10,000)*(contract size = 100)*(price delta = 0.2 CHF) = 200,000 CHF.
The main part of the active contract set at the end of the process, namely the details of the options, and the deposits holding the cash entitlements resulting from the exercise of the options, as displayed by the DAML Studio, looks like this:
Conclusion
So far in my DAML masterclass blog post series, I focused on financial applications by reviewing the Financial Library and the Asset Servicing refapp which uses building blocks from it.
In the next two parts of the series, I will open up a wide range of application potential beyond finance for DAML driven applications, showing how they can implement transactions in Healthcare Claims Processing and online Chess.
