2.4.9

What is being released

Proposed model changes as part of an on-going effort to augment the product coverage with securities

• Added sample implementations of existing functions Allocate and NewAllocationPrimitive which focuses on the securities use case.
• On Execution, mark the attribute Party as a reference. This is allows the Execution.party to be specified as a value (e.g. for a standalone Execution instance) or as a reference (e.g. when the Execution is part of an Event, where the Execution.party can be a reference to Event.party).
• On Position, add attribute cashBalance to allow the cash settlement amounts to be aggregated.
• On Lineage, add attribute transferReference so any previous transfers can be conveniently linked.

Review direction

• In the CDM Textual Browser:
  • Review classes Execution, Position and Lineage.
  • Review functions Allocate and NewAllocationPrimitive.
• In the downloaded CDM Distribution, review sample function implementations AllocateImpl.java and NewAllocationPrimitiveImpl.java and corresponding tests AllocateTest.java.

2.4.7

What is being released

Proposed model changes as part of an on-going effort to augment the product coverage with securities

Added function EvaluatePortfolioState which takes Portfolio as an input and calculates the PortfolioState, including a list of Position based on the given AggregationParameters.

Review direction

• In the CDM Textual Browser, review function EvaluatePortfolioState.
• In the downloaded CDM Distribution, review sample function implementation EvaluatePortfolioStateImpl.java and test EvaluatePortfolioStateTest.java.

2.4.4

What is being released

Proposed model changes related to Confirmationand Affirmation classes as part of an on-going effort to augment the product coverage with securities

1. Add lineage and status attributes.
2. Fix minimum Party and PartyRole cardinality.

Review direction

In the CDM Textual Browser:

• Review classes Confirmationand Affirmation.

2.4.2

What is being released

Proposed model changes as part of an on-going effort to augment the product coverage with securities

1. Add executionReference attribute to Lineage class.
2. Add post-condition to Settle function to assert that the executionReference has been set.

Review direction

In the CDM Textual Browser:

• Review class Lineage and function Settle.

2.4.1

Quantity Refactoring: several IR product types migrated

As presented in the 30-Jul-2019 CDM WG meeting, the essence of the restructuring is to abstract away the quantity from the contractual product definition, such that a contractual product is defined as a "unit" of that product, similar to how non-contractual products (e.g. securities) work. The actual quantity is handled as part of a separate QuantityNotation object, while the product uses the ResolvablePayoutQuantity type to implement the quantity mechanics in the various Payout legs of the product.

What is being released

Following previous (initial) release on Equity Swaps, several Interest Rates product types have been migrated to the new quantity mechanism: Swap (through Swap Stream), Swaption, CapFloor, Xccy Swap and Variable Notional. The Bond Option case has yet to be handled.

For Equity Swaps, a bug where the equity notional amount was not captured in the QuantityNotation has been fixed.

At the moment the mapping to existing FpML documents is being done "as-is". E.g. where the notional is represented 2x in each leg of a swap , we will have 2 quantityNotation attributes with the same value. Whereas in a xccy swap, they have different values but are also associated with different currencies. In "native" CDM objects, this attribute should either be unique, or have an associated data rule to verify that multiple instances do not have conflicting values.

The migration will carry-on gradually to encompass more product types, with credit derivatives as likely next candidate.

Review direction

In the Ingestion Panel of the CDM Portal:

• Look at products / rates for the above product type examples, and search for keyword quantity in the output, to see where respective elements are now positioned.

Tutorials Page

What is being released

To aid users of CDM, a Tutorials page has been created, in which video tutorials will demonstrate the various ways to make use of CDM’s generated code artefacts. Initially, we have created a simple “Getting Started” video that shows how to access the ISDA CDM's generated code artefacts and setup the Maven project correctly in order to download all project dependencies.

More tutorials will be uploaded in the coming weeks and as always, all feedback is welcome, please share them via the usual channels.

Review direction

In the CDM Portal:

• Look for the new Tutorial tile

2.3.0

What is being released

Move the DAML code generator into the external generators project where it can be maintained as an open source project

1. Remove the hard coded DAML generator from the DSL project
2. Create the DAML gnerator as a new project in the code generators repository
3. Create a class to configure the build of CDM to run the DAML generation

Generate function specs for DAML

Review direction

In the CDM Textual Browser:

• View download of CDM sources. Most files have only minor changes but there is a new Functions.daml

2.2.9

What is being released

Proposed model changes as part of an on-going effort to augment the product coverage with securities

1. Affirmation specifies the information required when affirming a trade.
2. Add post-trade processing states Confirmed and Affirmed to WorkflowStatusEnum.
3. During trade post-processing, confirmation and affirmation can occur in any order. Change EventWorkflow to store all workflowStatus so all previous states can be checked. E.g. it can be checked whether workflowStatus contains both Confirmed and Affirmed.
4. The TransferSettlementEnum (e.g. DeliveryVsPayment etc) is known at execution time, therefore it can be specified as part of the SettlementTerms.
5. Proposals for Settle and NewTransferPrimitive funcs, initially supporting the use case of security settlement via DeliveryVsPayment method.

Review direction

In the CDM Textual Browser:

• Review classes Affirmation, EventWorkflow and WorkflowStatusEnum, SettlementTerms.
• Review functions Settle and NewTransferPrimitive.

2.2.6

What is being released

Further bug fix related Date serialization which affected reg reporting functionality in Rosetta Core.

2.2.5

What is being released

Rosetta Syntax Upgrade

As part of on-going improvements, the Rosetta syntax has been upgraded to consolidate language features. This work aims to simplify the syntax needed when adding to, and editing the CDM. This will become increasingly important as the number of CDM contributors increase and as CDM contributions starting coming from a variety of sources.

This is the second release in a series of that will cover the scope described in the Rosetta Syntax Upgrade Wiki[1].

In this release, the func syntax and supporting infrastructure were upgraded to support all remaining use-cases of spec, function and calculation. This consolidation of syntax simplifies the writing of Functions in the model and forces syntactic consistency across the model.

Other Changes

Fixed bug related Date serialization which affected reg reporting functionality in Rosetta Core, and caused failures in the testing infrastructure.

Review directions

From the CDM Portal, make use of the Textual Browser to inspect syntax changes in the model. Download the CDM Distribution Pack to inspect the change to generated Java code artefacts.

[1] https://github.com/REGnosys/rosetta-dsl/wiki/Rosetta-Syntax-Upgrade)

2.2.1

Initial quantity refactoring: Equity Swap

What is being released

As part of an on-going effort to restructure the handling of "quantity" in the CDM, this initial release implements the new structure in the model and applies it for Equity Swap products. Other product types will be migrated to this new structure over time (likely starting with Interest Rate Swap products).

As was presented in the 30-Jul-2019 CDM WG meeting, the essence of the restructuring is to abstract away the quantity from the contractual product definition, such that a contractual product is defined as a "unit" of that product, similar to how non-contractual products (e.g. securities) work.

To this end, 2 new main types are being introduced: QuantityNotation and ResolvablePayoutQuantity, that both leverage the existing Quantity type:

1. QuantityNotation specifies the actual transacted quantity of a given product. It is meant to be specified alongside but separate from the ContractualProduct, as an additional attribute in an Execution or a Contract. The reason for the "notation" qualifier is that this object characterises the type of quantity being specified with a tag, taken from an enumeration value called QuantityNotationEnum. The types of quantities that can be specified include: Notional, NumberOfSecurities and the list is expected to grow over time as more product types get migrated. Multiple quantityNotation attributes can be specified for the same product: e.g. for Equity Swaps, both the number of securities and the notional can be specified (and a validation logic will need to be implemented to verify consistency as notional = no. securities x initial price).

2. ResolvablePayoutQuantity, as its name suggests, is a resolvable quantity concept that applies to each of the underlying Payout legs through the payoutQuantity attribute. The principle is that a resolvable quantity can always be resolved into one number, based on: (i) the quantityNotationTag attribute that must be specified alongside the contractualProduct description, and (ii) a given date, where a schedule is applicable.

For instance: an EquityPayout leg may specify Notional as the tag for its payoutQuantity, in which case the notional will have to be fetched from the corresponding Notional quantity notation, which must be provided upon execution, to resolve the product. In addition to the base case where quantity is specified either directly as a number or indirectly through this quantity notation mechanism, the use-cases for ResolvablePayoutQuantity are:

• Quantity based on some pre-defined schedule: e.g. amortising notional
• Quantity based on some pre-defined events: e.g. resetting cross-currency notional
• Quantity set as reference to another quantity: e.g. equity notional as no. securities x price

In practice, the Contract object has a contractualQuantity attribute containing the (potentially multiple) quantityNotation attributes, plus other information such as whether there is a pre-agreed mechanism to amend such quantity in future. synonyms have been implemented for the QuantityNotation and ResolvablePayoutQuantity classes for the Equity Swaps use-case only. Other product types have been left untouched. For technical reasons a (new but temporary placeholder) type called ExecutionQuantity is used for the contractualQuantity attribute, until such time when it will be renamed as, and supersede, the existing ContractualQuantity type which will be progressively "emptied-out".

Review direction

In the CDM Textual Browser:

• Review the Contract type with the additional contractualQuantity attribute and its underlying quantityNotation attribute.
• Review the InterestRatePayout and EquityPayout types, that implement the new PayoutBase containing the payoutQuantity attribute.

In the CDM Ingestion panel:

• Test the products/equity use-cases, and see the structure of the newly ingested CDM. The actual quantity numbers (number of securities and notional) have been extracted away and replaced by tags in the product description. The actual numbers now sit under the contractualQuantity attribute that is part of the Contract object.