Skip to content

Releases: finos/common-domain-model

7.0.0-dev.1

14 Feb 11:19
@regnosys-ops regnosys-ops
7.0.0-dev.1
7554b6b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
7.0.0-dev.1 Latest
Latest

CDM Examples - Extended test coverage

Background

This release updates the examples project improving the test scenario coverage for several Common Domain Model Java features. All extended scenarios use publicly available CDM Test Pack samples.

What is being released?

This release adds the following examples scenarios:

Processor scenarios

  • org.finos.cdm.example.processors.QualificationProcessorTests with different qualification report expectation scenarios
  • org.finos.cdm.example.processors.ValidationProcessorTests with different validation report expectation scenarios

Qualification scenarios

  • org.finos.cdm.example.qualification.QualifyBusinessEventTest with PartialTermination, ContractFormation, PartialNovation, Allocation, Clearing, Compression, CorporateAction, CreditEvent, Execution, Exercise, Novation, IndexTransition, Termination, StockSplit, Increase
  • org.finos.cdm.example.qualification.QualifyProductTest with InterestRate_Fra, InterestRate_Option_Swaption, InterestRate_CrossCurrency_FixedFloat, InterestRate_CapFloor, InterestRate_IRSwap_FixedFloat, CreditDefaultSwap_SingleName, CreditDefaultSwap_Index, CreditDefaultSwap_Basket, EquitySwap_TotalReturnBasicPerformance_SingleName, EquitySwap_ParameterReturnVariance_SingleName

WorkflowStep transition scenarios

  • org.finos.cdm.example.BusinessEventExecutionTest with business event execution tests and instruction creation mocks for ContractFormation, Execution, Novation, Increase, Decrease, Termination, Reset, Valuation, OptionExercise, Transfer, TermsChange, StockSplit, Allocation, CorporateAction, CreditEvent, Compression, Clearing

Performance Metrics

  • org.finos.cdm.example.performance.ProcessorPerformanceTests with deserialization, object validation, qualification, and state transition metrics at product and event level.

Review Directions

Please inspect the changes identified above for the test scenarios in the examples module.

The coverage for this release can also be reviewed in PR #3299.

The full scope description of the proposal can be found at #3298.

CDM - A CDM user can access an extended FRO model

Background

The ISDA Foundations project is a model extension built on top of the CDM that contains legal IP (contained in legal documentation references) only available to ISDA members. Additions or updates to the ISDA Foundations project can cause it to go out of sync with the CDM.

The issue #3348 proposes to migrate the ISDA Foundations project to the CDM, without the ISDA legal documentation IP

Preparation must be first be done in the CDM to synchronise it with the ISDA Foundations project and simplify the migration of any ISDA Foundations components.

What is being released?

As part of the preparation for the migration of any ISDA Foundations components to the CDM, this release creates an extended FRO Model in the CDM. This includes adding some (already sanitised) ISDA Foundations components into CDM, and moving other components around.

  1. Added extra attributes from FloatingRateIndexDefinitionExtension (and their required types) directly into FloatingRateIndexDefinition
  2. Added extra attributes from FloatingRateIndexCalculationDefaultsExtension (and their required types) directly into FloatingRateIndexCalculationDefaults
  3. Moved ValidateFloatingRateIndexName and ValidateFloatingRateIndexTradeDate to observable.asset.fro
  4. Updated ValidateFloatingRateIndexTradeDate to call the existing FloatingRateIndexMetadata function iteratively.
  5. Renamed function ValidateFloatingRateIndexTradeDate to FilterInvalidFloatingRateIndexTradeDate, and updated the description, to specify it returns an invalid index or indices only.

Backward-incompatible changes

None.

Review Directions

The change can be reviewed in PRs:

CDM - A CDM user can access an extended Agreement model

Background

The ISDA Foundations project is a model extension built on top of the CDM that contains legal IP (contained in legal documentation references) only available to ISDA members. Additions or updates to the ISDA Foundations project can cause it to go out of sync with the CDM.

The issue #3348 proposes to migrate the ISDA Foundations project to the CDM, without the ISDA legal documentation IP

Preparation must be first be done in the CDM to synchronise it with the ISDA Foundations project and simplify the migration of any ISDA Foundations components.

What is being released?

As part of the preparation for the migration of any ISDA Foundations components to the CDM, this release creates an extended Agreement model in the CDM. This includes adding some (already sanitised) ISDA Foundations components into CDM, and moving other components around.

  1. Added BrokerConfirmationTypeEnum in legaldocumentation.contract.enum
  2. Added BrokerConfirmation and IssuerTradeId to legaldocumentation.contract.type
  3. Added brokerConfirmationType attribute to AgreementName
  4. Moved all empty types related to “additional terms” (used in TransactionAdditionalTerms) to a sub-namespace: legaldocumentation.master.additionalterms

Backward-incompatible changes

None.

Review Directions

The change can be reviewed in PR: #3352.

CDM - A CDM user can access a contract's closed status component

Background

The ISDA Foundations project is a model extension built on top of the CDM that contains legal IP (contained in legal documentation references) only available to ISDA members. Additions or updates to the ISDA Foundations project can cause it to go out of sync with the CDM.

The issue #3348 proposes to migrate the ISDA Foundations project to the CDM, without the ISDA legal documentation IP

Preparation must be first be done in the CDM to synchronise it with the ISDA Foundations project and simplify the migration of any ISDA Foundations components.

What is being released?

As part of the preparation for the migration of any ISDA Foundations components to the CDM, this release allows CDM users to access a contract’s closed status component in the event namespace.

  1. Moved ClosedStateEnum to event.common.enum
  2. Moved ClosedState to event.common.type

Backward-incompatible changes

None.

Review Directions

The change can be reviewed in PR: #3386.

CDM - Addition of changedCriteria to outputSpecification when using the CloneEligibleCollateralWithChangedTreatment function

Background

The CloneEligibleCollateralWithChangedTreatment function creates a new Eligible Collateral Specification based on an input specification but with one changed criteria and one changed treatment.

Currently, when the function is invoked, the output of an EligibleCollateralSpecification only includes the inputSpeciifcation and the changedTreatment, but not the changedCriteria. This means that users can only change the treatment of a collateral item, but not a specific attribute.

What is being released?

This release sets an attribute of the collateralCriteria in the output to the changedCriteria specificied by the user when invoking the function.

Backward-incompatible changes

None.

Review Directions

This change can be reviewed in PR: #3344

Infrastructure - Dependency Update

What is being released?

This release updates the Rune dependencies.

Version updates include:

This release also updates the FpML / ISO code scheme syncing configuration from exact matching to additive matching to ensure no backward incompatible changes, as per the production version guidelines.

Review Directions

The changes can be reviewed in PR: #3379

Infrastructure - GitHub Actions

Background

GitHub Actions is used to perform checks on Pull Requests (PRs) raised on FINOS/common-domain-model.

What is being released?

This release fixes usage of GitHub Actions APIs that have been deprecated, as per the [documentation](h...

Read more
Assets 2
Loading

6.0.0

24 Jan 16:16
@hugohills-regnosys hugohills-regnosys
6.0.0
2f86259
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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

FpML mappings

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.
      -...
Read more
Loading

6.0.0-dev.96

22 Jan 17:24
@regnosys-ops regnosys-ops
6.0.0-dev.96
4a03379
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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

Loading

6.0.0-dev.95

20 Jan 14:51
@regnosys-ops regnosys-ops
6.0.0-dev.95
7d6b2a9
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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.

Loading

6.0.0-dev.94

20 Jan 13:01
@regnosys-ops regnosys-ops
6.0.0-dev.94
b4a9f90
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
6.0.0-dev.94

Infrastructure - Dependency Update

What is being released?

This release updates the rune dependencies.

Version updates include:

Review directions

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

Loading

6.0.0-dev.93

17 Jan 11:34
@regnosys-ops regnosys-ops
6.0.0-dev.93
6b39c53
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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.

Loading

5.20.0

17 Jan 11:41
@regnosys-ops regnosys-ops
5.20.0
c14c9a1
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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:

Review directions

The changes can be reviewed in PR: #3316

Loading

6.0.0-dev.92

13 Jan 13:25
@regnosys-ops regnosys-ops
6.0.0-dev.92
a902db0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
6.0.0-dev.92

Infrastructure - Dependency Update

What is being released?

This release updates the rune dependencies.

Version updates include:

Review Directions

The changes can be reviewed in PR: #3315.

Loading

6.0.0-dev.91

08 Jan 19:04
@regnosys-ops regnosys-ops
6.0.0-dev.91
2ca34c5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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.

Loading

6.0.0-dev.90

03 Jan 10:15
@regnosys-ops regnosys-ops
6.0.0-dev.90
4eb1da8
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
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:

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...
Read more
Loading