6.0.0

CDM Version 6.0

CDM 6.0, a production release, corresponds to developments made to the Common Domain Model throughout 2024 and previously released as CDM 6-dev. These developments include items that featured in the 2024 CDM roadmap:

• Option Payout Refactoring
• Asset Refactoring
• Standardized IM Schedule

as well as several additional model changes, bug fixes and synonym mappings since the latest production release (CDM 5.20).

What is being released

The release includes changes to the CDM model itself (manifested in changes to .rosetta source files) but also enhancements to:

• The CDM Documentation, which should be consulted as a good resource to understand the enhanced design of products and business events in CDM 6.
• The CDM Sample Files, which have been updated to reflect the new modelling designs.
• The CDM Object Builder, which can be used to construct CDM objects and generate JSON serialised data.

Below are some of the high-level modelling changes included in CDM 6.0, with links to their corresponding development release tags containing more detailed release notes.

Asset refactoring

A major feature of CDM 6 is the refactored product model with the introduction of the concept of Asset. This is the result of a CDM task force which came together to extend the model into additional asset classes and to address some long-standing challenges. The objectives and design artefacts of the task force were documented in GitHub Issue 2805.

This diagram shows the new product model at a high level; please read the FINOS CDM documentation for a full explanation:

Individual releases related to asset refactoring:

• New Data Types: 6.0.0-dev.46
• Remove AssetPool and deprecated data types: Backward incompatible changes 6.0.0-dev.47
• Asset, Index, Identifier: Backward incompatible changes 6.0.0-dev.58
• Basket, Index, Observable, Foreign Exchange: Backward incompatible changes 6.0.0-dev.60
• Product, SettlementPayout, Underliers: Backward incompatible changes 6.0.0-dev.72
• Underlier in Corporate Action: 6.0.0-dev.77
• Payout as a Choice: Backward incompatible changes 6.0.0-dev.79
• ETD Product Qualification: 6.0.0-dev.79
• AssetCriteria: Backward incompatible changes 6.0.0-dev.81
• Settlement Payout Price: Backward incompatible changes 6.0.0-dev.84.
  • Note: this change is only backward-incompatible because it reverts the Add Price to Payouts change in 6.0.0-dev.77. The two changes are backward-compatible in aggregate.
• Security Finance trade types: Backward incompatible changes 6.0.0-dev.86
• FloatingRateIndex and InterestRateIndex: Backward incompatible changes 6.0.0-dev.87
• Cashflow Generation for Settlement Payout : 6.0.0-dev.89
• Commodity Payout Underlier: 6.0.0-dev.90

Option Payout refactoring

• Option Payout Refactoring: Backward incompatible changes 6.0.0-dev.24
• Modification of AmericanExercise Condition in ExerciseTerms: 6.0.0-dev.41

Standardized IM Schedule

• Implementation of the Standardized Schedule Method for Initial Margin Calculation: 6.0.0-dev.69
• Enhancement and Optimization of the Standardized Schedule Method: 6.0.0-dev.90

Misc. model changes

• Product model
  • Day Count Fraction: RBA_Bond_Basis: Backward incompatible changes 6.0.0-dev.22
  • Trigger type refactoring: 6.0.0-dev.42
  • Principal Amount Conditions: 6.0.0-dev.43
  • Portfolio Return Terms: Backward incompatible changes 6.0.0-dev.55
  • Exotic Equity Products and Exercise Terms validation conditions: Backward incompatible changes 6.0.0-dev.88
  • Qualification functions:
    • Zero Coupon Swaps: 6.0.0-dev.13
    • Bond Option and Forwards: 6.0.0-dev.32
• Event model
  • Addition of new enumeration to AvailableInventory: 6.0.0-dev.36
• Eligible Collateral model
  • Determination of the Party Roles: 6.0.0-dev.4
  • CheckEligibilityResult cardinality fix: 6.0.0-dev.10
  • CreditNotationMismatchResolutionEnum update: 6.0.0-dev.26
  • New Attributes: 6.0.0-dev.48
  • Collateral Criteria AND/OR Logic: 6.0.0-dev.90
  • Eligible Collateral condition logic: 6.0.0-dev.95
  • Addition of SpecificAsset to CollateralCriteria: 6.0.0-dev.96
• Base model
  • Natural Person and NaturalPersonRole circular reference: Backward incompatible changes 6.0.0-dev.3
  • RoundToPrecision Function: 6.0.0-dev.40 & 6.0.0-dev.74

FpML mappings

• Synonym mappings for BusinessCenterEnum: 6.0.0-dev.33

Backward-incompatible changes

Asset refactoring

Main changes using the choice data type

A new feature in the Rune DSL - the choice data type - has been used extensively for the asset refactoring in CDM 6.

Example of new items defined as choice types include:

• Asset
• Instrument

In addition, some fundamental data types previously defined using a one-of condition have been updated to choice types. Compared to the regular one-of condition, choice types force each of the choice options to have single cardinality.

• Product: defined as a choice between TransferableProduct (which extends Asset) and NonTransferableProduct (renamed from ContractualProduct, previously included in Product). Other data types previously included in Product are now defined as Asset or Observable choices instead:
  • Commodity: now extends AssetBase not ProductBase.
    • Accordingly, productTaxonomy has been replaced by taxonomy and the conditions updated.
  • Security and Loan: now extend InstrumentBase not ProductBase.
  • Basket: now extends AssetBase not ProductBase.
    • BasketConstituent now extends Observable not Product.
    • Moved from the product namespace to the observable namespace.
  • Index: now extends IndexBase not ProductBase
  • ForeignExchange has been marked as deprecated.
    • The deprecated ExchangeRate and CrossRate data types have both been deleted.
  • AssetPool: removed (it was previously introduced from FpML but has been found to be incorrect and unusable).
    • Removed the reference to AssetPool from Product.
• Observable: defined as a choice between Asset, Index and Basket. In addition, the following attributes have been removed from Observable:
  • Commodity: now available directly as an Asset.
  • QuotedCurrencyPair: replaced by the the FX observable data type inside Index.
  • The unused attribute optionReferenceType and its corresponding enumerator OptionReferenceTypeEnum have been removed from the model.
    -...

6.0.0-dev.96

Product Model - Addition of SpecificAsset to CollateralCriteria

Background

The choice data type CollateralCriteria was introduced in Release 6.0.0-dev.90. It combines all the criteria terms that previously appeared in AssetCriteria and IssuerCriteria.

The Asset choice data type was originally included in CollateralCriteria but was deemed difficult to differentiate from the AssetType attribute. This release is an enhancement from Asset to the new data type SpecificAsset to improve the usability of the model.

What is being released?

This release added SpecificAsset to the CollateralCriteria attributes, to replace the original Asset.

Backward-incompatible changes

None.

Review Directions

The addition of the new attributes Asset to CollateralCriteria can be reviewed in PR: #3321

The adition of the attribute SpecificAsset to replace Asset can be reviewed in PR: #3335

6.0.0-dev.95

CDM - Eligible Collateral condition logic

Background

A recent enhancement to the validation in the Rune DSL has highlighted some logic defects in the conditions that are applied on EligibleCollateralCriteria. This release does not change the functionality but ensures that the logic will work correctly in all possible scenarios.

What is being released?

The following three conditions were impacted:

• ConcentrationLimitTypeIssueOSAmountDebtOnly
• ConcentrationLimitTypeMarketCapEquityOnly
• AverageTradingVolumeEquityOnly

The fixes ensure that the logic works correctly when there are multiple concentration limits.

Review Directions

The changes can be reviewed in PR: #3326.

6.0.0-dev.94

Infrastructure - Dependency Update

What is being released?

This release updates the rune dependencies.

Version updates include:

• DSL 9.28.2: syntax error handling fixes and additional annotation types added. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.28.0

Review directions

The changes can be reviewed in PR: [#3323](#3323

6.0.0-dev.93

CDM Model - CollateralCriteria Asset and Index fields

Background

CollateralCriteria was created as part of Release 6.0.0-dev.90. It is a choice data type, combining all the criteria terms that previously appeared in AssetCriteria and IssuerCriteria.

A DSL bug blocked the addition of Asset and Index choice data types to CollateralCriteria. The bug has since been resolved under DSL 9.27.0 with further details in the DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9

What is being released?

This release added the fields Asset and Index to the CollateralCriteria data type following the DSL bug fix.

Backward-incompatible changes

None.

Review Directions

The change can be reviewed in PR: #3321.

5.20.0

Mapping Update - Related party role mapper

Background

The Party Role mapping issue involved the incorrect transfer of FpML's relatedParty structure into CDM, particularly in cases where multiple relatedParty elements exist within the same partyTradeInformation block. The mapping process was only capturing the first relatedParty role found, which led to incorrect associations between party references and roles. Furthermore, if the role of the first relatedParty was not found in PartyRoleEnum, another role was incorrectly assigned, causing mismatches and inaccuracies in the data mapping.

What is being released?

• We are introducing a new RelatedPartyRoleMappingProcessor that addresses the limitations of the previous implementation. This processor evaluates all relatedParty elements within a partyTradeInformation block instead of just mapping the first one. It ensures that each relatedParty is independently assessed, verifies its role against the PartyRoleEnum list, and assigns the correct role and reference accordingly. Additionally, if a role is not found in PartyRoleEnum, the processor omits that reference rather than assigning an incorrect role to the relatedParty.

Review directions

In Rosetta, select the Textual Browser and inspect each of the changes identified above.

Changes can be reviewed in PR: #3259

Event & Product Model Qualification and Cardinality Fixes

Background

Due to a recent DSL update (see DSL release notes) which adds additional logical checks related to cardinality, some errors were found in the model.
These errors stem from an ambiguity of how to handle multiple elements in certain situations.

In general, the solution is to follow one of two approaches:

• Do we expect only a single item to be present? Then use the only-element operator.
• Should we support multiple elements? Then use the extract operation to handle all of them, and reduce them
  to a single result according to the context, e.g., using the all = True operation.

What is being released?

This release includes fixes for all cardinality related errors detected by the DSL, which are listed below.
It also includes a related fix to the Qualify_CashAndSecurityTransfer function, which is described in more detail below the list.

1. The function SecurityFinanceCashSettlementAmount contained a multiplication of which one operand - securityQuantity -
   was of multi cardinality. In practice, due to filtering, it should always be a single element, so this was fixed with only-element.
2. The function ResolveSecurityFinanceBillingAmount had a similar problem as in (1).
3. The function Qualify_Repurchase was performing an only exists operation on multiple primitiveInstructions at
   once. Since a former check verifies there is only one, this was fixed with only-element.
4. The function Qualify_Shaping had a similar problem as in (3).
5. The function Qualify_PartialDelivery was comparing two multi cardinality quantities. In practice, due to filtering,
   both should always be a single element, so this was fixed with only-element.
6. The function Qualify_OnDemandPayment had a similar problem as in (3).
7. The function Qualify_CashTransfer was performing an only exists operation on multiple primitiveInstructions at
   once. To resolve ambiguity, the check is now performed on all primitiveInstructions separately using extract.
8. The function Qualify_OpenOfferClearedTrade was performing an only exists operation on two primitiveInstructions at
   once. The check has been replaced with two equivalent exists operations, one for each of the two primitiveInstructions.
9. The function Qualify_Renegotiation had a similar problem as in (8).
10. The function Qualify_SecuritySettlement was performing two only exists operations on unsupported input, which
    always resulted in False. This was fixed by replacing them with an exists check instead.
11. The function Qualify_ValuationUpdate was performing an only exists operation on multiple primitiveInstructions at
    once. Given that the specification requires only a single component to be present, this was fixed with only-element.
12. The function CheckAgencyRating was performing a contains operation on two operands of single cardinality.
    The operation has been replaced with an equality check = instead.
13. The function CheckAssetType had a similar problem as in (13).
14. The function Qualify_EquityOption_PriceReturnBasicPerformance_SingleName was performing an only exists operation on multiple payouts
    at once. Since a former check verified there is only one, this was fixed with only-element.
15. The function Qualify_EquityOption_PriceReturnBasicPerformance_Index had a similar problem as in (15).
16. The function Qualify_EquityOption_PriceReturnBasicPerformance_Basket had a similar problem as in (15).
17. The function Qualify_ForeignExchange_Spot_Forward was performing an only exists operation on the underliers
    of multiple forwardPayouts. Since a later check verifies there is only one, this was fixed with only-element.
18. The function Qualify_ForeignExchange_Swap was performing an only exists operation the underliers
    of multiple forwardPayouts. To resolve ambiguity, the check is now performed on all underliers separately using extract.
19. The function Qualify_ForeignExchange_NDF had a similar problem as in (17).
20. The function Qualify_ForeignExchange_NDS had a similar problem as in (18).
21. The function Qualify_ForeignExchange_ParameterReturnCorrelation was performing an only exists operation on multiple basketConstituents at
    once. To resolve the ambiguity, the check is now performed on all basketConstituents separately using extract.
22. The function Qualify_ForeignExchange_VanillaOption was performing an only exists operation on multiple optionPayouts
    at once. To resolve the ambiguity, the check is now performed on all optionPayouts separately using extract.
23. The function Qualify_SecuritiesFinance was performing an only exists operation on multiple assetPayouts
    at once. To resolve the ambiguity, the check is now performed on all assetPayouts separately using extract.

Due to the bug fix in the function Qualify_SecuritySettlement, another bug in the function Qualify_CashAndSecurityTransfer
came to light. According to its specification, a business event should only be qualified as a CashAndSecurityTransfer
only if the cash and security move in the same direction - however, this was never actually checked. The check has been implemented
and three expectation files have been updated accordingly.

Review Directions

Please inspect the changes identified above for the functions and conditions in the Textual Viewer of the Rosetta platform.

The changes can also be reviewed in PR: #3295.

CDM Model - TaxonomySourceEnum

Background
A DRR issue has been identified where reporting the Underlying CO values was not supported for MAS. To address this, we proposed replicating the reporting logic used for BaseProduct and SubProduct in EMIR. In CDM, this involves adding "MAS" as a value to the TaxonomySourceEnum, since the TaxonomySource in CDM determines the jurisdiction based on the commodityClassificationScheme being used. So the "MAS" value will be added in the TaxonomySourceEnum.

What is being released?

• Updated TaxonomySourceEnum in cdm.base.staticdata.asset.common:enum

Enumerations

• Updated TaxonomySourceEnum by adding MAS to support Monetary Authority of Singapore (MAS) as a taxonomy source.

Review directions

In Rosetta, select the Textual Browser and inspect each of the changes identified above.

The changes can be reviewed in PR: #3265

Infrastructure - Dependency Update

What is being released?

This release updates the DSL dependency.

Version updates include:

• DSL 9.24.0: add a feature to override attributes in extended types. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.24.0
• DSL 9.25.0: improve type errors and cardinality errors. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.25.0
• DSL 9.27.0: addresses a bug where the switch operator could sometimes break the model. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.27.0
• DSL 9.28.2: addresses a Fatal error when reporting rule is not given a name and addition of new transform annotations . For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.28.2

Review directions

The changes can be reviewed in PR: #3316

6.0.0-dev.92

Infrastructure - Dependency Update

What is being released?

This release updates the rune dependencies.

Version updates include:

• DSL 9.27.0: addresses a bug where the switch operator could sometimes break the model. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.27.0

Review Directions

The changes can be reviewed in PR: #3315.

6.0.0-dev.91

Event & Product Model Qualification and Cardinality Fixes

Background

Following a recent DSL update (see DSL release notes) which adds additional logical checks related to cardinality, some errors were found in the model.
These errors stem from an ambiguity of how to handle multiple elements in certain situations.

In general, the solution is to follow one of two approaches:

• Do we expect only a single item to be present? Then use the only-element operator.
• Should we support multiple elements? Then use the extract operation to handle all of them, and reduce them
  to a single result according to the context, e.g., using the all = True operation.

What is being released?

This release includes fixes for all cardinality-related errors detected by the DSL, which are listed below.
It also includes a related fix to the Qualify_CashAndSecurityTransfer function, which is described in more detail below the list.

1. The function SecurityFinanceCashSettlementAmount contained a multiplication of which one operand - securityQuantity -
   was of multi cardinality. In practice, due to filtering, it should always be a single element, so this was fixed with only-element.
2. The function ResolveSecurityFinanceBillingAmount had a similar problem as in (1).
3. The function Qualify_Repurchase was performing an only exists operation on multiple primitiveInstructions at
   once. Since a former check verified there is only one, this was fixed with only-element.
4. The function Qualify_Shaping had a similar problem as in (3).
5. The function Qualify_PartialDelivery was comparing two multi cardinality quantities. In practice, due to filtering,
   both should always be a single element, so this was fixed with only-element.
6. The function Qualify_OnDemandPayment had a similar problem as in (3).
7. The condition SettlementPayout of the type Trade was performing an only exists operation on multiple payouts
   at once. This was fixed by calling the existing function SettlementPayoutOnlyExists instead, which handles multiple
   payouts.
8. The function Qualify_CashTransfer was performing an only exists operation on multiple primitiveInstructions at
   once. To resolve the ambiguity, the check is now performed on all primitiveInstructions separately using extract.
9. The function Qualify_OpenOfferClearedTrade was performing an only exists operation on two primitiveInstructions at
   once. The check has been replaced with two equivalent exists operations, one for each of the two primitiveInstructions.
10. The function Qualify_Renegotiation had a similar problem as in (8).
11. The function Qualify_SecuritySettlement was performing an only exists operation on an unsupported input, which
    always resulted in False. This was fixed by replacing it with an exists check instead.
12. The function Qualify_ValuationUpdate was performing an only exists operation on multiple primitiveInstructions at
    once. Given that the specification requires only a single component to be present, this was fixed with only-element.
13. The function CheckAgencyRating was performing a contains operation on two operands of single cardinality.
    The operation has been replaced with an equality check = instead.
14. The function CheckAssetType had a similar problem as in (13).
15. The function Qualify_EquityOption_PriceReturnBasicPerformance_SingleName was performing an only exists operation on multiple payouts
    at once. Since a former check verified there is only one, this was fixed with only-element.
16. The function Qualify_EquityOption_PriceReturnBasicPerformance_Index had a similar problem as in (15).
17. The function Qualify_EquityOption_PriceReturnBasicPerformance_Basket had a similar problem as in (15).
18. The function Qualify_ForeignExchange_VanillaOption had a similar problem as in (15).
19. The condition Basket of the type SettlementPayout was performing an only exists operation on multiple basketConstituents at
    once. To resolve the ambiguity, the check is now performed on all basketConstituents separately using extract.

Due to the bug fix in the function Qualify_SecuritySettlement, another bug in the function Qualify_CashAndSecurityTransfer
came to light. According to its specification, a business event should only be qualified as a CashAndSecurityTransfer
only if the cash and security move in the same direction - however, this was never actually checked. The check has been implemented
and three expectation files have been updated accordingly.

Review Directions

Please inspect the changes identified above for the functions and conditions in the Textual Viewer of the Rosetta platform.

The changes can also be reviewed in PR: #3294.

6.0.0-dev.90

Initial Margin Model - Enhancement and Optimization of the Standardized Schedule Method

Background

Following the initial contribution of the Standardized Schedule Method for calculating Initial Margin (IM) within the Common Domain Model (CDM) and after receiving feedback from the working group, further work has been carried out to enhance the model by introducing new functionalities.

What is being released?

In this second contribution, improvements have been made to the model, categorized into three main areas: the creation of conditions, code optimization, and cosmetic changes.

Key components of this release include:

• New conditions have been added to validate the outputs of functions, ensuring they make sense from a business perspective.
• Code optimization has been implemented to reduce redundancy by avoiding repetitive use of qualifying functions within data extraction functions, resulting in improved efficiency.
• The name of one function has been updated, and some definitions have been expanded for better user understanding.

Conditions

• Added new PositiveNotional post-condition:
  • Ensure the notional is greater than 0.
• Added new ValidCurrency post-condition:
  • Ensure the currency is a valid ISO 3-Letter Currency Code.
• Added new PositiveDuration post-condition:
  • Ensure the duration is greater than 0.
• Added new PositiveGrossInitialMargin post-condition:
  • Ensure the gross initial margin is greater than 0.
• Added new NonNegativeNetInitialMargin post-condition:
  • Ensure net initial margin is non-negative.
• Added new TotalGIMAddition post-condition:
  • Ensure that only a single currency exists.
• Added new NGRAddition post-condition:
  • Ensure that only a single currency exists.

Types

• Modification to the StandardizedSchedule type
  • The following conditions have been added: PositiveNotional , ValidCurrency , and PositiveDuration .
• Modification to the StandardizedScheduleTradeInfo type
  • The attributes grossInitialMargin and markToMarketValue, which were previously of type Quantity, are now of type Money. Additionally, the conditions PositiveGrossInitialMargin and SameCurrency have been included.
• Modification to the StandardizedScheduleInitialMargin type
  • The condition NonNegativeNetInitialMargin has been added.

Functions

• Modification to the BuildStandardizedSchedule function
  • Aliases for productClass and assetClass have been introduced to serve as temporary variable assignments.
• Modification to the StandardizedScheduleNotional function
  • The qualifying functions have been substituted with the newly created aliases.
• Modification to the StandardizedScheduleNotionalCurrency function
  • The qualifying functions have been substituted with the newly created aliases.
• Modification to the StandardizedScheduleDuration function
  • The qualifying functions have been substituted with the newly created aliases.

Rename

• GetStandardizedScheduleMarginRate is now used instead of GetIMRequirement.

Backward Incompatible

The following changes are backward incompatible:

• All the function condition additions specified in the Conditions section of these release notes.
• All the type modifications specified in the Types section of these release notes.

The changes can also be reviewed in PR: #3305.

Product Model - Commodity Payout Underlier

Background

The Asset Refactoring initiative (see #2805) is seeking to improve the Product Model to address some long-standing issues and to ensure the continued extensibility to additional financial products and markets. A proposal has been agreed - through a cross-industry Task Force - to implement this remodelling in the CDM.

This release includes an adjustment following three planned major tranches of work in CDM 6 to implement the refactored model.

What is being released?

In the original Asset Refactoring scope, the underlier on CommodityPayout was changed from being type Product to type Commodity.

This has proven to be too restrictive in DRR, where Commodity Payout can operate on a basket or index. Therefore, the data type of the underlier has been updated to Underlier with the added benefit of making it consistent with the other payouts.

To ensure that the underlier is indeed commodity-related, conditions have been added to force the underlier attribute to reference a commodity-related underlier. The CommodityUnderlier condition uses a switch statement to evaluate whether the underlier is an Observable or Product, and to assess it accordingly. A new function ObservableIsCommodity is used to standardise this and handles the different choice types of observables and the potential recursive nature of baskets.

Backward-incompatible changes

The change to the data type of the underlier attribute is not backward-compatible.

Review directions

The changes can be reviewed in PR: #3277 or in Rosetta.

Infrastructure - Dependency Update

What is being released?

This release updates the rune dependencies.

Version updates include:

• DSL 9.24.0: add a feature to override attributes in extended types. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.24.0
• DSL 9.25.0: improve type errors and cardinality errors. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.25.0

Review directions

The changes can be reviewed in PR: #3302

CDM Model - Collateral Criteria AND/OR Logic

Background

This release enhances the modelling of Eligible Collateral Criteria to enable the use of complex AND, OR and NOT logic in the combination of terms within a criteria.

Eligible Collateral is currently modelled using the data type EligibleCollateralSpecification which can contain many EligibleCollateralCriteria, which are themselves constructed from CollateralTreatment, IssuerCriteria and AssetCriteria.
The attributes isIncluded (true/false) and qualifier (all/any) can be used to model some simple cases of and / or logic in the construction of certain parts of the criteria (eg AgencyRatingCriteria).

Members of the CDM Collateral Working Group have requested that the functionality is extended to enable more complex combinations of AND and OR logic across multiple terms. This has been implemented by combining all the criteria terms in a single new data type CollateralCriteria. This is a choice data type that includes all the criteria terms that previously appeared in AssetCriteria and IssuerCriteria. As each term can only occur once, in its simplest form, only one criteria can be specified. If more than one criteria is required, it is necessary to specify whether the terms are all required or only that any of them are required. The two new data types AllCriteria and AnyCriteria also appear on CollateralCriteria to enable this. If all terms are required, ie AND logic, then the terms should be linked in a parent AllCriteria. If any of the terms are required, ie OR logic, then the terms should be linked in a parent AnyCriteria. These two terms can be used iteratively to create complex logic between terms. Additionally, the data type NegativeCriteria can also be used in the logic to apply a NOT function to a single term.

What is being released?

This release implements AND, OR and NOT logic between the Collateral terms.

There is no longer a separate data type for each of asset and issuer criteria; they have been combined in a single new data type called CollateralCriteria.

• The new choice data type CollateralCriteria replaces the removed AssetCriteria and IssuerCriteria data types as the combined type.
• The attributes issuer and asset on CollateralCriteriaBase have now been replaced with the single one collateralCriteria which is the specific criteria that applies. It can be created using AND, OR and NOT logic, and both asset and issuer characteristics.
• The conditions on CollateralCriteriaBase have been updated and now use the new CriteriaMatchesAssetType function.
• The data type ConcentrationLimit has been refactored to reduce the cardinality of concentrationLimitCriteria to 1 and the condition is updated accordingly.
• The condition on ConcentrationLimitCriteria has been updated to reflect the combined CollateralCriteria.
• Three new logic data types have been introduced to support the AND, OR and NOT logic of terms and are used in CollateralCriteria:
  • AllCriteria
  • AnyCriteria
  • NegativeCriteria,
• The following new data types have been introduced and are used in CollateralCriteria:
  • IssuerCountryOfOrigin
  • AssetCountryOfOrigin
  • IssuerName
  • IssuerAgencyRating
  • SovereignAgencyRating
  • AssetAgencyRating
  • AssetMaturity
  • ListingExchange
  • ListingSector
  • DomesticCurrencyIssued.

Changes to remove the old model:

• The data types AssetCriteria and IssuerCriteria have been removed.
• The qualifier attribute has been removed from AgencyRatingCriteria as it is now redundant.
• The data type ListingType has been removed.

In addition, the following functions have also been updated to reflect the new modelling:

• CheckEligibilityByDetails which now references a new function CheckCriteria which takes a single criteria and evaluates it against the criteria. This function handles the recursive use of AND and OR logic.
• CheckAssetCountryOfOrigin has been made more generic as the country of origin can apply to both an Issuer and an Asset; it has been renamed to CheckCountryOfOrigin.
• CheckMaturity has been...

6.0.0-dev.89

Product Model - Cashflow Generation for Settlement Payout

Background

This release contains changes required to enable the generation of cashflows from a simple settlement payout. This change allows FX transactions, which are now represented using a settlement payout, still to be viewed as two legs for downstream reporting purposes in DRR.

Further background is detailed in Issue: #3269

What is being released?

This release includes core modifications to the Cashflow type, so that it can be generated by a settlement payout and used to represent the two legs of an FX transaction. Because a settlement payout can take any sort of asset as underlyer, the generated cashflows can in fact represent the transfers of any asset and not just cash as in an FX transaction.

Changes are therefore brought to the Cashflow type to accomodate any type of asset. Because that type becomes closely aligned functionally to the Transfer type, the two types have been harmonised to extend a common ancestor: AssetFlowBase, which defines the what (asset), how much (quantity > 0) and when (settlement date) of an asset transfer. The "AssetFlowBase" name is generalising the term "cash" in "cashflow" to any "asset", whereas the Cashflow type retains its original name to minimise downstream impact.

A new function: Create_CashflowFromSettlementPayout, takes a single SettlementPayout and returns the two Cashflow implied by this payout. The two cashflow legs are called assetLeg and priceLeg, respectively. The function works generically regardless of the type of asset used as underlyer in the SettlementPayout and assetLeg. The priceLeg always consists of cash, whose amount and currency are implied by the price and quantity parameters of the settlement payout.

Finally, the Cashflow choice is being removed from Payout as it is no longer used there.

Accordingly, this release includes the following changes:

Types and attributes

• New type:

  • AssetFlowBase, in product.common.settlement, that provides the common ancestor to harmonise Cashflow and Transfer
  • Its attributes are aligned onto the former TransferBase ones and are all mandatory:
    • asset as Asset
    • quantity as NonNegativeQuantity
    • settlementDate as AdjustableOrAdjustedOrRelativeDate

• Modification to existing types:

  • Both Cashflow (previously extending PayoutBase) and Transfer (previously extending TransferBase) extend AssetFlowBase
  • Transfer is unchanged as a result of this change, i.e. it has the same attributes as before
  • Cashflow no longer has the following irrelevant attributes previously inherited from PayoutBase:
    • principalPayment
    • settlementTerms, replaced by settlementDate only
    • priceQuantity, replaced by asset and quantity only

• Deletions:

  • TransferBase has been deleted
  • Cashflow is no longer a choice of Payout

Validation rules

• EconomicTerms: Rules that rely on the presence of Cashflow for certain CDS transactions are no longer relevant. In cases where the fee leg includes a stand-alone cashflow payment, it is already represented by a Transfer in the transaction event.
  • FpML_cd_26_28
  • FpML_cd_27

Functions

• New function:

  • Create_CashflowFromSettlementPayout

• Modification to existing function:

  • Create_OnDemandInterestPaymentPrimitiveInstruction has been modified to include a transfer instead of a termsChange primitive (the latter previously featured an additional Cashflow in the payout).

• Deletions:

  • Create_CashflowTermsChangeInstruction: no longer used
  • Create_Cashflow: no longer used

Backward incompatible changes

Most changes in this release are backward-incompatible, with some types and functions being deleted or their attributes modified.

The most consequential change is to the Cashflow type and the fact that it has been removed from the Payout choice. However, no sample illustrates this change because practically this component was no longer being used as a payout.

Transfer remains unchanged.

Review Directions

Please inspect the changes identified above for the functions and types in the Textual Viewer Rosetta.

The changes can also be reviewed in PR: #3290.