Skip to content

7.2.0

Choose a tag to compare

@ReleaseManagement-BP ReleaseManagement-BP released this 25 Aug 09:28
· 4 commits to 7.x.x since this release
c38016e

Amending ingestion mappings - Commodity Swap was being incorrectly mapped

Background

Mapping Price Schedules for Commodity Swap to the correct values

What is being released?

changes to following functions to remove priceSubType and changing priceType to AssetPrice: MapCommmodityFixedPriceToPriceSchedule MapCommmodityFixedPriceScheduleToPriceSchedule

Review Directions

Changes can be reviewed in PR: #5026

Infrastructure - Dependency Update

Version updates include:

  • DSL 10.4.0 - Add CVE Scanning Schedule. See DSL release notes: 10.4.0
  • DSL 10.5.0 - Fix invalid Renovate config: remove redundant * from matchPackageNames. See DSL release notes: 10.5.0
  • DSL 10.6.0 - Namespaces produced by a tool are now marked, and hand edits to them are reported in review.. See DSL release notes: 10.6.0
  • DSL 10.7.0 - Generate a LabelProvider per labelled type. See DSL release notes: 10.7.0
  • Rune-Fpml 3.5.0 - DSL/bundle updates See release notes: 3.5.0

Review Directions
Changes can be reviewed in PR: #5052

Product Qualification - Zero Coupon Enhancement

Background

The Qualify_Transaction_ZeroCoupon function only recognises zero-coupon transactions when the payment frequency is explicitly represented as 1T (term). Transactions where the payment frequency equals the full contract duration are not identified as Zero Coupon, although they represent the same economic outcome.

What is being released?

Extended the qualification logic in to Qualify_Transaction_ZeroCoupon recognise alternative representations of zero-coupon transactions by adding a condition where the payment frequency corresponds to the duration between the effective date and the maturity date. The following new common functions have been introduced to handle frequency-to-day conversions () and dates operations required for the matching logic: - AddPeriod - PeriodCalculation Finally, it has been adjusted the input parameters for the AuxiliarEffectiveDate and AuxiliarTerminationDate to take the EconomicTerms instead of the Trade.

Review Directions

Changes can be reviewed in PR: #4908

Instruction Composition Reset Step 3: Adjust the period

Background

Building upon the functional milestones introduced in the previous release for Step 2 (#4379), the CDM Smart Contract Taskforce is advancing the state-machine execution capabilities within the Instruction Composition Framework. This release delivers the components required to execute Step 3 (Adjust Calculation Period) of the 8-step Interest Rate Reset processing workflow. By introducing this phase, the model can now deterministically apply calendar adjustments and financial business day conventions to unadjusted schedules. For further information, see issue #4389.

What is being released?

This release provides the core business day alignment logic, holiday calendar resolution hooks, and state accumulator mutations necessary to transition an unadjusted calculation period into its adjusted lifecycle state. It incorporates payload bindings for Step 3 into the reusable instruction containers and expands the historical overlay tracking mechanisms to capture the final adjusted period bounds.

Functions

Changes in the cdm.base.datetime namespace:

  • AdjustDateToBusinessDayConvention: Core mapping function that routes an unadjusted date through a selected business day convention matrix when a calendar clash is detected.
  • ApplyFollowing: Recursive utility evaluating calendar forward-shifts to find the next valid business day.
  • ApplyPreceding: Recursive utility evaluating calendar backward-shifts to find the previous valid business day.
  • ApplyModFollowing: Evaluation function ensuring forward-shifted dates do not cross month boundaries, defaulting to preceding lookbacks where necessary.

Changes in the cdm.event.instructioncomposition.reset namespace:

  • Create_AdjustPeriodInstruction: An operational mapping function that compiles adjusted starting and ending coordinates for a calculation period using defined business conventions and holiday datasets.
  • GetNonBusinessDates: An externalized code-implementation hook to query and extract non-business dates from financial calendar providers using either distinct date vectors or defined boundary periods.

Changes in the cdm.event.instructioncomposition namespace:

  • UpdateResetCompositionState: (Updated) Expanded to implement "Step 3" overlay logic. It conditionally captures the incoming adjustPeriod payload to update the active adjustedCalculationPeriod parameter.

Types and Choices

Changes in the cdm.event.instructioncomposition namespace:

  • CompositionStepInstructions (Updated): Expanded to include adjustPeriod, allowing the global step orchestrator to wrap period adjustment data structures.

Changes in the cdm.event.instructioncomposition.reset namespace:

  • AdjustPeriodInstruction: Introduced as the official type for Step 3.
  • ResetInstructionState (Updated): Expanded to hold its third phase state variable (adjustedCalculationPeriod), allowing the cumulative workflow to track adjusted parameters over its lifecycle.

Review Directions

Navigate to the following paths to inspect the new models:

  • rosetta-source/src/main/rosetta/instructionComposition-type.rosetta: Review the updated CompositionStepInstructions container to verify the inclusion of the Step 3 instruction payload mapping.
  • rosetta-source/src/main/rosetta/instructionComposition-func.rosetta: Examine the updated field overlay logic inside UpdateResetCompositionState handling adjusted period state tracking.
  • rosetta-source/src/main/rosetta/instructionComposition-reset-type.rosetta: Inspect the new AdjustPeriodInstruction type structure and the updated tracking properties embedded within ResetInstructionState.
  • rosetta-source/src/main/rosetta/instructionComposition-reset-func.rosetta: Inspect the schedule compilation logic inside Create_AdjustPeriodInstruction and the GetNonBusinessDates interface.

Instruction Composition Reset Step 4: Adjust the Reset Date

Background

This release delivers the complete set of components required to execute Step 4 (Adjust Reset Date) of the 8-step Interest Rate Reset processing workflow. This addition advances the framework's stateful timeline logic, ensuring the deterministic calculation of adjusted, legally binding reset dates based on transactional variables and regional business day rules. For further information, see issue #4388.

What is being released?

This release provides the state mutation structures and operational logic required to calculate, pass, and log adjusted date boundaries. It integrates Step 4 payload structural bindings into the reusable instruction wrapper definitions and introduces the overlay processing mechanics needed to track intermediate date metrics across the active execution lifecycle.

Functions

Changes in the cdm.base.datetime namespace:

  • AdjustDateToBusinessDayConvention: Core mapping function that routes an unadjusted date through a selected business day convention matrix when a calendar clash is detected.
  • ApplyFollowing: Recursive utility evaluating calendar forward-shifts to find the next valid business day.
  • ApplyPreceding: Recursive utility evaluating calendar backward-shifts to find the previous valid business day.
  • ApplyModFollowing: Evaluation function ensuring forward-shifted dates do not cross month boundaries, defaulting to preceding lookbacks where necessary.

Changes in the cdm.event.instructioncomposition.reset namespace:

  • Create_AdjustDateInstruction: An operational mapping function that processes a single unadjusted date entry alongside custom non-business calendars to resolve and output a convention-aligned adjusted reset date.

Changes in the cdm.event.instructioncomposition namespace:

  • UpdateResetCompositionState: (Updated) Modified to include "Step 4" state overlay logic. It checks for the presence of the adjustDate payload, incrementally updating the active state with the new adjustedResetDate or preserving existing attributes if absent.

Types and Choices

Changes in the cdm.event.instructioncomposition namespace:

  • CompositionStepInstructions (Updated): Expanded to include adjustDate as an active data payload property, allowing the global step orchestrator to wrap single date adjustment data structures.

Changes in the cdm.event.instructioncomposition.reset namespace:

  • AdjustDateInstruction: Introduced as the official type for Step 4.
  • ResetInstructionState (Updated): Expanded to hold its fourth phase state variable (adjustedResetDate), allowing the cumulative workflow to track adjusted parameters over its lifecycle.

Review Directions

Navigate to the following paths to inspect the new models:

  • rosetta-source/src/main/rosetta/instructionComposition-type.rosetta: Review the updated CompositionStepInstructions container to verify the inclusion of the Step 4 instruction payload mapping.
  • rosetta-source/src/main/rosetta/instructionComposition-func.rosetta: Examine the updated field overlay logic inside UpdateResetCompositionState handling adjusted date state tracking.
  • rosetta-source/src/main/rosetta/instructionComposition-reset-type.rosetta: Inspect the new AdjustDateInstruction type structure and the updated tracking properties embedded within ResetInstructionState.
  • rosetta-source/src/main/rosetta/instructionComposition-reset-func.rosetta: Inspect the date computation and convention mapping calls wrapped inside Create_AdjustDateInstruction.

CDM Model: FpML executionNotification ingestion mapping to CDM ExecutionInstruction

What is being released

An ingestion mapping has been added for the FpML executionNotification message so that its Trade element is now mapped onto a CDM ExecutionInstruction, in place of the previous mapping which produced a ContractFormationInstruction. This aligns the outcome of ingesting an executionNotification with the semantics of a newly executed trade, rather than a contract formation event that requires a pre-existing trade state.

To support this, a new enumerated value Execution has been added to the EventIntentEnum in the cdm.event.common namespace, with the description "The intent is to execute a new trade." This new intent is used by the ingestion functions to identify that the incoming FpML message represents a new trade execution.

The following ingestion functions have been updated in the cdm.ingest.fpml namespace:

  • MapExecutionNotificationToWorkflowStep (in ingest-fpml-confirmation-message-func.rosetta) — now remaps the resolved FpML intent to Execution when the raw intent is ContractFormation or absent, so that executionNotification messages are routed through the new execution path.
  • MapWorkflowStep (in ingest-fpml-confirmation-workflowstep-func.rosetta) — when intent = Execution, the workflow step's Instruction is now built with an execution PrimitiveInstruction (and no before TradeState), instead of the generic primitive instruction with a before state.
  • A new function MapTradeToExecutionInstruction has been added to map an FpML Trade (together with the party and quotation lists) directly to a CDM ExecutionInstruction, populating product, priceQuantity, counterparty, ancillaryParty, parties, partyRoles, executionDetails, tradeDate and tradeIdentifier.

Expected output JSON files for existing FpML confirmation and record-keeping samples that exercise executionNotification messages have been regenerated to reflect the new ExecutionInstruction-based output.

Review directions

In the CDM Portal open the Textual Browser, search for EventIntentEnum in the cdm.event.common namespace and observe the new Execution value. Then search for MapExecutionNotificationToWorkflowStep, MapWorkflowStep and MapTradeToExecutionInstruction in the cdm.ingest.fpml namespace to review the updated ingestion logic. Ingesting any of the updated FpML executionNotification sample files (e.g. pkg-ex01-pkge-execution-notification, pkg-ex55-execution-notification, msg-ex19-cds-execution-allocations) will now produce a WorkflowStep whose Instruction contains an execution PrimitiveInstruction rather than a contractFormation one.

Inspect Pull Request: #4928

Inspect Issue: #4774