6.0.0-dev.79

Product Model - Asset Refactoring: Payout as a Choice

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 some additional functionality (following three planned major tranches of work in CDM 6 to implement the refactored model).

What is being released?

Payout:

• The Payout data type has been refactored as a Choice. Choice data types work slightly different from the regular one-of condition because they force each of the members of the choice to have a single cardinality. Therefore, the use of Payout, for example on EconomicTerms and ResetInstruction, now have multiple cardinality.

Product Qualification:

• Some minor changes have been made to the product qualification functions to ensure that the functionality and logic is unaffected by this change.

Documentation updates:

• The CDM documentation on the FINOS website has been updated.

Review directions

The changes can be reviewed in PR: #3178

Backward-incompatible changes

This release contains changes that are not backward-compatible:

• All references to a payout need to be updated as references to a payout are now treated as capitalised Data Types rather than lower case Attributes. For example, a previous reference might have read: payout -> interestRatePayout -> floatingAmount must now be written as: payout -> InterestRatePayout -> floatingAmount.
• Logic or mapping that expects certain cardinality may need to be reviewed; see the explanation above.

CDM Product Model - Refactor ETD Product Qualification

Background

In an earlier Asset Refactoring release, the modelling of Exchange Traded Derivatives was enhanced
by introducing a new item ListedDerivative as an option of one of the values in the Asset choice
data type. However, the product qualification functions were still expecting these products to be
modelled using the Security choice within Asset. This has been corrected.
The enumerator type SecurityTypeEnum has been renamed to InstrumentTypeEnum and the value of
ListedDerivative has been removed from the list. This broadens the potential use of this
enumeration for additional assets.

The attribute instrumentType, using the InstrumentTypeEnum data type, has been added to InstrumentBase
so that this basic type determination is on all types of instrument. The corresponding attribute,
securityType has been removed from Security to avoid duplication.

The attribute securityType on the data type AssetType has been changed to use the renamed data
type, ie InstrumentTypeEnum.

Occurrences of logic to test the type of a security or instrument
have also been updated to use this new name InstrumentTypeEnum, including a number of references
to this enumerator in the product qualification logic. Where product qualification was only
looking for the type of a security, it has also been broadened to instrument.

Changes can be reviewed in PR #3200

6.0.0-dev.77

CDM Product Model - Underlier in Corporate Action

Background

In an earlier Asset Refactoring release, an unintending defect was introduced on the CorporateAction data type.
This release corrects that.

What is being released?

The data type of the underlier attribute within CorporateAction has been undated to be Underlier rather than
Instrument. Instrument is too restrictive as a broader range of assets can be the subject of corporate actions
and this is best represented by the Underlier data type.

Review Directions

In Rosetta, select the Textual Browser and inspect the changes to the data type identified above.

Changes can be reviewed in PR #3201

CDM Product Model - Add Price to Payouts

Background

This is an additional enhancement following the Asset Refactoring initiative by improving the consistency
of the modelling of prices on payouts.

What is being released?

The new attribute fixedPrice of type PriceSchedule has been added to the OptionPayout and to the
SettlementPayout. Both additionally have a metadata address link, pointing to the PriceQuantity
in the TradeLot.

Review Directions

In Rosetta, select the Textual Browser and inspect the changes to the two payouts identified above.

Changes can be reviewed in PR #3202

5.18.0

CDM Model - Equity Product Qualification and Validation

Background

This release contains modifications required to accomodate Equity and Exotic Products under individual Asset Classes

What is being released?

This release creates following modifications:

• a new qualification function Qualify_Equity_OtherOption to add qualification for Exotic Options

func Qualify_Equity_OtherOption: <"Qualifies a product with properties of an Exotic Option as Equity Option (Other)">
    [qualification Product]
    inputs:
        economicTerms EconomicTerms (1..1)
    output:
        is_product boolean (1..1)
            [synonym ISDA_Taxonomy_v1 value "Qualify_EquityOther"]
            [synonym ISDA_Taxonomy_v2 value "Qualify_EquityOther"]
    set is_product:
        Qualify_AssetClass_Equity(economicTerms) = True
            and economicTerms -> payout -> optionPayout only exists
            and economicTerms -> nonStandardisedTerms = True

• changes in existing options to avoid duplicate qualification of options

e.g.
func Qualify_EquityOption_PriceReturnBasicPerformance_SingleName
now contains additional clause
and (if economicTerms -> nonStandardisedTerms exists then economicTerms -> nonStandardisedTerms = False else True)

• modification in FpML conditions FpML_ird_9 and FpML_ird_29

    condition FpML_ird_9: <"FpML validation rule ird-9 - If calculationPeriodAmount/calculation/compoundingMethod exists, then resetDates must exist.">
        if compoundingMethod exists then resetDates exists

    condition FpML_ird_29: <"FpML validation rule ird-29 - If compoundingMethod exists, then fixedRateSchedule must not exist.">
        if compoundingMethod exists
        then rateSpecification -> fixedRate is absent

• relaxation of cardinality rule for expirationTime

expirationTime BusinessCenterTime (0..1) <"The latest time for exercise on expirationDate.">

condition ExpirationTimeChoice: <"Condition to validate the existence of correlation between expirationTime and expirationTimeType">
    ExpirationTimeType(expirationTime, expirationTimeType)

func ExpirationTimeType: <"Conditional Validation function to check the existence of correlation between expiration Time and expiration Time Type.">
    inputs: 
        expirationTime BusinessCenterTime (0..1)
        expirationTimeType ExpirationTimeTypeEnum (0..1)
    output: 
        success boolean (1..1)
    
    set success:
        (if expirationTime exists and expirationTimeType exists then expirationTimeType = ExpirationTimeTypeEnum -> SpecificTime)
        and 
        (if expirationTimeType exists and expirationTimeType = ExpirationTimeTypeEnum -> SpecificTime then expirationTime exists) 

• modification to Qualify_AssetClass_Commodity

addition of clause:
or (economicTerms -> payout -> forwardPayout, economicTerms -> payout -> commodityPayout) only exists
or economicTerms -> payout -> forwardPayout only exists)

Review Directions

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

Changes can be reviewed in PR: #3163

CDM Model - RoundToPrecisionRemoveTrailingZeros Function

Background

This release contains a new function for RoundToPrecisionRemoveTrailingZeros function, as described in issue #2915.

What is being released?

This release creates the new function cdm.base.math.RoundToPrecisionRemoveTrailingZeros to not add any trailing 0's in the end if they do not already exist.

ffunc RoundToPrecisionRemoveTrailingZeros: <"Round a number to the supplied precision, using the supplied rounding direction.">
    inputs:
        value number (1..1) <"The original (unrounded) number.">
        precision int (1..1) <"The number of decimal digits of precision.">
        roundingMode RoundingDirectionEnum (1..1) <"The method of rounding (up/down/nearest).">
    output:
        roundedValue number (1..1) <"The value to the desired precision">

    condition NonNegativePrecision: <"The number of decimal digits of precision should be greater than or equal to zero.">
        precision >= 0

The following examples show the function behaviour:

• RoundToPrecisionRemoveTrailingZeros(1023.123456789, 5, RoundingDirectionEnum -> NEAREST, true) = 1023.12346
• RoundToPrecisionRemoveTrailingZeros(1023.12000, 5, RoundingDirectionEnum -> NEAREST, true) = 1023.12
• RoundToPrecisionRemoveTrailingZeros(1023, 5, RoundingDirectionEnum -> NEAREST, true) = 1023
• RoundToPrecisionRemoveTrailingZeros(999999999, 4, RoundingDirectionEnum -> NEAREST, true) = 999999999

This would is new function, so there are no compatibility issues.

Review Directions

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

Changes can be reviewed in PR #3181

CDM Model - RoundToSignificantFigures Function

Background

This release contains a new function for RoundToSignificantFigures function, as described in issue #3154.

What is being released?

This release creates the new function cdm.base.math.RoundToSignificantFigures to round to the significant number of decimal places.

func RoundToSignificantFigures: <"Round a number to the supplied significant figures, using the supplied rounding direction.">
    inputs:
        value number (1..1) <"The original (unrounded) number.">
        significantFigures int (1..1) <"The number of significant figures.">
        roundingMode RoundingDirectionEnum (1..1) <"The method of rounding (up/down/nearest).">
    output:
        roundedValue number (1..1) <"The value to the desired number of significant figures.">
        
    condition NonZeroSignificantFigures: <"The number of significant figures should be greater than zero.">
        significantFigures > 0

The following examples show the function behaviour:

• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> NEAREST) = 1023.1
• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> UP) = 1023.2
• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> DOWN) = 1023.1
• RoundToSignificantFigures(1023.123456789, 1, RoundingDirectionEnum -> NEAREST) = 1000
• RoundToSignificantFigures(1023.1, 7, RoundingDirectionEnum -> NEAREST) = 1023.1

This is a new function, so there are no compatibility issues.

Review Directions

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

Changes can be reviewed in PR #3180

Infrastructure - Dependency Update

What is being released?

This release updates the DSL dependency.

Version updates include:

• DSL 9.19.0: support for switch operation on choice types. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.19.0
• DSL 9.20.0: support for passing metadata to functions and highlighting fixes. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.20.0

Review directions

The DSL 9.19.0 changes can be reviewed in PR: #3153
The DSL 9.20.0 changes can be reviewed in PR: #3192

6.0.0-dev.76

Infrastructure - Dependency Update

What is being released?

This release updates the DSL dependency.

Version updates include:

• DSL 9.20.0: support for passing metadata to functions and highlighting fixes. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.20.0

Review directions

The changes can be reviewed in PR: #3191

6.0.0-dev.75

CDM Model - RoundToSignificantFigures Function

Background

In an earlier release, function cdm.base.math.RoundToSignificantFigures was added, however it was missing configuration.

What is being released?

Added missing Guice configuration for Java function implementation for cdm.base.math.RoundToSignificantFigures.

Review Directions

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

Changes can be reviewed in PR #3184

6.0.0-dev.74

CDM Model - RoundToPrecision Function

Background

This release contains an enhancement for the RoundToPrecision function, as described in issue #2915.

What is being released?

This release updates the existing function cdm.base.math.RoundToPrecision to add a new boolean flag which specifies whether to remove trailing zeros.

func RoundToPrecision: <"Round a rate to the supplied precision, using the supplied rounding direction">
    inputs:
        value number (1..1) <"The original (unrounded) number.">
        precision int (1..1) <"The number of decimal digits of precision.">
        roundingMode RoundingDirectionEnum (1..1) <"The method of rounding (up/down/nearest).">
        removeTrailingZeros boolean (1..1) <"Flag to specify whether to remove trailing zeros.">
    output:
        roundedValue number (1..1) <"The value to the desired precision">

The following examples show the function behaviour:

• RoundToPrecision(1023.123456789, 5, RoundingDirectionEnum -> NEAREST, false) = 1023.12346
• RoundToPrecision(1023.123456789, 5, RoundingDirectionEnum -> NEAREST, true) = 1023.12346
• RoundToPrecision(1023.12000, 5, RoundingDirectionEnum -> NEAREST, false) = 1023.12000
• RoundToPrecision(1023.12000, 5, RoundingDirectionEnum -> NEAREST, true) = 1023.12
• RoundToPrecision(1023, 5, RoundingDirectionEnum -> NEAREST, false) = 1023.00000
• RoundToPrecision(1023, 5, RoundingDirectionEnum -> NEAREST, true) = 1023
• RoundToPrecision(999999999, 4, RoundingDirectionEnum -> NEAREST, false) = 999999999.0000
• RoundToPrecision(999999999, 4, RoundingDirectionEnum -> NEAREST, true) = 999999999

Review Directions

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

In GitHub, review Java unit tests cdm.base.math.functions.RoundToPrecisionImplTest and cdm.product.asset.floatingrate.functions.ApplyFloatingRateProcessingTest.

Changes can be reviewed in PR #3182

6.0.0-dev.73

CDM Model - RoundToSignificantFigures Function

Background

This release contains a new function for RoundToSignificantFigures function, as described in issue #3154.

What is being released?

This release creates the new function cdm.base.math.RoundToSignificantFigures to round to the significant number of decimal places.

func RoundToSignificantFigures: <"Round a number to the supplied significant figures, using the supplied rounding direction.">
    inputs:
        value number (1..1) <"The original (unrounded) number.">
        significantFigures int (1..1) <"The number of significant figures.">
        roundingMode RoundingDirectionEnum (1..1) <"The method of rounding (up/down/nearest).">
    output:
        roundedValue number (1..1) <"The value to the desired number of significant figures.">
        
    condition NonZeroSignificantFigures: <"The number of significant figures should be greater than zero.">
        significantFigures > 0

The following examples show the function behaviour:

• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> NEAREST) = 1023.1
• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> UP) = 1023.2
• RoundToSignificantFigures(1023.123456789, 5, RoundingDirectionEnum -> DOWN) = 1023.1
• RoundToSignificantFigures(1023.123456789, 1, RoundingDirectionEnum -> NEAREST) = 1000
• RoundToSignificantFigures(1023.1, 7, RoundingDirectionEnum -> NEAREST) = 1023.1

This is a new function, so there are no compatibility issues.

Review Directions

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

Changes can be reviewed in PR #3179

6.0.0-dev.72

Product Model - Asset Refactoring: Product, SettlementPayout, Underliers

WORK IN PROGRESS

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 is being developed - through a cross-industry Task Force - to implement this remodelling in the CDM.

This release includes the third tranche of changes (of three planned tranches in CDM 6) to implement the refactored model. It introduces some significant refactoring of the Product structure in to the model.

What is being released?

Product Refactoring:

• This release completes the refactoring of the major financial product data types, that is Asset, Observable, and Index, and combines their use in a new structure for financial products.
• The new data type NonTransferableProduct has replaced the former ContractualProduct and is the main "product" data type used on a trade; it appears as the attribute product on the data type TradableProduct.
• On a Trade, all financial products should be composed into the EconomicTerms of a NonTransferableProduct.
• Separate PR but included here for completeness The data type payout is now a choice construct with the consequence that references to specific instances of a specific payout should refer to the capitalised data type name rather than an attribute, for example economicTerms -> payout -> performancePayout becomes economicTerms -> payout -> PerformancePayout. This has large impact in terms of the number of changes in this PR.

Underliers:

• An Underlier represents the financial product that will be physically or cash settled.
• Whereas all underliers were previously defined to use data type product, this has now been improved so that they can also be an Observable when the case warrants it.
• Underlier is modelled as a choice data type, that is, it can either be an Observable or a Product.
• A Product is also a choice type, either a TransferableProduct (a type of financial product which can be held or transferred, represented as an Asset with the addition of specific EconomicTerms), or a NonTransferableProduct (a product that can be traded, as part of a TradableProduct, but cannot be transferred to others).

Product and Trade Hierarchy:

• The Trade data type now extends TradableProduct; this means that the latter is "hidden" in many uses in the CDM, eg in the graphical view, and one level within the hierarchy is removed when generating JSON. This change has resulted to updates to 100s of occurences to path accesses within the model (particularly in the Event and Product functions). For example, the previous access path tradeState -> trade -> tradableProduct -> tradeLot has become tradeState -> trade -> tradeLot.
• The financial product hierarchy has also changed so that the previous path trade -> tradableProduct -> product -> contractualProduct -> economicTerms -> payout -> InterestRatePayout has become trade -> product -> economicTerms -> payout -> InterestRatePayout.

Product details:

• Security
  • Removed the attributes economicTerms and ProductTaxonomy because these are not appropriate for an Asset data type which is standardised. if economicTerms are required, these can be added by wrapping security into a TransferableProduct. The taxonomy of assets is explicitly defined in the type.
• Index
  • Index is now an Observable and the replaces the existing data type rateOption.
  • The path observable -> rateOption has become observable -> Index -> FloatingRateIndex.
  • Data type CreditIndex now extends IndexBase.

ProductQualification:

• Additional functions have been created to ease with the qualification process: UnderlierQualification. ObservableQualification.
• Extensive refactoring has been made to the qualification functions to reflect the refactoring, albeit with no changes to the actual logic.
• The qualification for options has been tidied up to be more readable and maintainable in the new model, without change to the functionality.
• The introduction of SettlementPayout has been included in the qualification logic.
• The qualification of Foreign Exchange transactions has been updated.
• The securities financing qualification functions have been enhanced to differentiate repos and lending; the new functions are: Qualify_RepurchaseAgreement, Qualify_BuySellBack, and Qualify_SecurityLending.
• A new enumerator data type has been added to support repo qualification: RepoTypeEnum. The corresponding attribute repoType was added to AssetPayout.

Payouts:

• A new payout type has been created: SettlementPayout
• The existing ForwardPayout has been collapsed into SettlementPayout; the latter should be used whereever the former was previously.
• Separate PR but included here for completeness The Payout data type has been refactored to be a choice and payouts now have multiple cardinality on EconomicTerms. The conditions that validated the business logic on payouts has been moved to EconomicTerms.

Event Model:

• Create_Exercise has additional logic to support an option underlier that coan be an Asset, a TransferableProduct or a NonTransferableProduct.
• Create_Execution now acts upon a more narrowly defined NonTransferableProduct rather than a generic product.
• Additional functions have been created to support events using the new product model: Create_NonTransferableProduct, Create_TransferableProductFromAsset, Create_TransferableProductFromIndex, CheckTransferableProduct, CheckTradeNotTransferableProduct, CreateTradableProduct.
• The function NewEquitySwapProduct now creates a NonTransferableProduct not a generic product.
• Event processing has been refactored to handle the new modeling of TradableProduct.
• The unused data types Affirmation and Confirmation have been removed.

Observable:

• The attribute Observable has been removed from ObservationTerms where it created duplication.

Collateral:

• AssetIdentifier replaces ProductIdentifier on AssetCriteria.
• The function CheckEligibilityForProduct now uses TransferableProduct not Product.

Namespace re-alignments:

• The following data objects have been moved to a more appropriate namespace:
  • enum PutCallEnum to cdm.base.staticdata.asset
  • choice Index to cdm.observable.asset
  • type IndexBase to cdm.observable.asset
  • type PriceQuantity to cdm.observable.asset
• The function InterestRateObservableCondition has been moved to the cdm.observable.asset function namespace.

Deprecated data types which have been removed:

• IndexReferenceInformation: replaced with Index.

Documentation updates:

• Significant improvements have been made to the pages on Product Model, Event Model and Process Model.
• As well as incorporating the direct changes that result from the refactoring, the pages have been restructured to improve the hierarchy, sections have been resequenced where this improves understanding, and "tips" have been added to highlight important definitions.
• The use case sections on Collateral, Securities Lending and Repos have been updated to reflect the revised modeling.

Review directions

The changes can be reviewed in PR: #3127

Backward-incompatible changes

This release contains changes that are not backward-compatible:

• TBA

A full description of the backward-incompatible changes, and how persisted objects should be remapped, will be included in the release notes for the production release of CDM 6.

6.0.0-dev.71

Infrastructure - Dependency Update

What is being released?

This release updates the DSL dependency.

Version updates include:

• DSL 9.19.0: support for switch operation on choice types. For further details see DSL release notes: https://github.com/finos/rune-dsl/releases/tag/9.19.0

Review directions

The changes can be reviewed in PR: #3152

6.0.0-dev.70

Legal Documentation Model - New ContractualDefinitionsEnum value to support the 2022 ISDA Verified Carbon Credit Transactions Definitions

Background

The International Swaps and Derivatives Association, Inc. published in 2022 the ISDA Verified Carbon Credit (VCC) Transactions Definitions (see https://www.isda.org/book/2022-isda-verified-carbon-credit-transaction-definitions/).

This release includes the reference to the ISDA VCC Transaction Definitions by including a new value to the existing ContractualDefinitionsEnum.

What is being released?

New ContractualDefinitionsEnum value:

• Add a new value ISDA2022VerifiedCarbonCredit, in line with the existing values.
• The annotation of the value is: ISDA 2022 Verified Carbon Credit Transactions Definitions.
• Correct a typo in the annotation of the ISDA2023DigitalAssetDerivatives value, with a year of 2023 instead of 2021 as the value indicates.

Review directions

The changes can be reviewed in PR: #3047

Backward-incompatible changes

The change is backward compatible.