Background

Background

There’s a pattern to the Workflow model where BusinessEvents should be proposed for approval in a WorkflowStep, with an Instruction that has all the necessary details to describe the BusinessEvent fully. Currently Reset doesn’t conform with this CDM design principle.

The ResetInstruction does not contain observations or calculations, instead, the business logic and reset value determinations are performed later in the workflow within the Create_Reset function, which sits under the Create_AcceptedWorkflowStepFromInstruction stage. 

This process differs from other Instructions creation, such as the Transfer logic, which already follows a more robust pattern. In the Transfer case, a Primitive Instruction is created first by determining and calculating the transfer details. This instruction specifically records the Quantity, Asset, Settlement Date, and Payer/Receiver details before the workflowStep is even proposed. By the time the Create_AcceptedWorkflowStep is reached, it records the instruction in the new tradeState.

Current Transfer process:

Current Reset process:

This proposal shifts the Reset process "upstream" to mirror this Transfer pattern. By refactoring the logic, the specific reset values and observations are determined during the Instruction phase, ensuring that the proposed event contains all relevant data when it is proposed and before it is accepted into the trade state.

Proposal Reset process:

Proposal

Objective

The primary goal is to refactor the Reset workflow to align with a more transparent "calculate then record" pattern.

• Decouple logic from trade state transition: Move calculations out of the final tradeState update function

• Enhance instruction data: Ensure the ResetInstruction carries the actual calculated values and observations

• Simplify state updates: Change Create_Reset to focus solely on setting the relevant Reset value in the tradeState

Scope

1. Model Redefinition: ResetInstruction

The ResetInstruction type is updated to hold all the relevant data for the reset process:

• New attribute: ResetValue: To hold the final calculated rate

• New attribute: Observations: To persist the specific market data points used

• New attribute: Averaging Methodology: To record the logic applied to the observations

2. Functional Refactoring

• Modified Function: Create_Reset:

  • Change: Decoupled calculation logic from state change

  • Responsibility: Records the ResetInstruction into the TradeState history to enable downstream interest amount calculations

Process

1. Instruction generation: The ResetInstruction is created. It performs the necessary observations and calculations to determine the reset value

2. Workflow proposal: A Proposed WorkflowStep is created, which now contains the explicit Event Instruction including the calculated Reset Value

3. Acceptance and recording: Upon reaching Create_AcceptedWorkflowStepFromInstruction, the platform records the instruction into the new tradeState

   1. History update: The Create_Reset function executes, performing a simple data append to ensure the trade history reflects the instruction's values

Outputs

• Populated ResetInstruction: Includes Reset Value, Reset Date, Observations, and Averaging Methodology

• Updated TradeState: A new state where the resetHistory matches the values defined in the upstream instruction

Compatibility

This introduces breaking changes as to how the reset is constructed

Release

version 7 release (along with the reset smart contract work)

Additional Context

No response