Proposed change to the CDM - Completion Life Cycle Events Implementations

[dschwartznyc]

CDM's support for life cycle events has limited documentation and seems to be incomplete. These gaps are not aligned with the goals for standardization and are limiting the technology's potential.

Background

Two notable examples of gaps in the OTC derivatives workflow support are the Allocation and Affirmation events. In both cases the workflow implementation is incomplete.

• For example, Qualify_Allocation is the function provided to confirm that an allocation is appropriately formed but this function does not confirm that the sum of the notionals of the allocated trades is equal to the notional of the unallocated trade.
• Similarly, while the model includes a data model type to encapsulate an affirmation, it is unclear what function should be used to execute the event.
  If an existing function such as Qualify_ContractFormation is part of the workflow, then shouldn't there be an EventIntentEnum corresponding to affirmation or confirmation?

Proposal

In response, there should be a prioritized review of the events CDM intends to support leading to complete workflow implementation where there are gaps and more comprehensive documentation.

For OTC derivatives, the suggested primary working group is the CDM Derivatives Products and Business Events Working Group.

Gaps in the Collateral Management, if any, should be covered by the CDM Collateral Working Group
Securities Lending and Repo/Reverse may best be supported in the respective Trade Association Working Groups.
Unclear where analysis of the gaps in the documentation workflow should reside.

[JBZ-Fragmos]

in regards of current WF structure in CDM, hereunder some feedback / gap analysis / proposals

• i beleive there is a need to harmonize and clarify functional relations between TradeState and CounterpartyPositionState
  • before State and primitive Instruction do not exist in CounterpartyPositionState structure, when comparing to Trade State structure... this looks like preventing generic builder implementation "After = Before x Primitive Instruction"
  • missing key information in CounterpartyPositionState that is the cumulated position quantity per se, that is expected to be resolved by aggregating corresponding positions from multiple TradeState[*] but no functional relation is clarified for now

@dshoneisda : as an info, it's been quite long time since FRAGMOS has been asking/raising the need to clarify the representation of a Position concept accross the model
FRAGMOS would be happy to get funded for the purpose of participating/leading some work about it, and to bring on the table some concrete modelling proposals prepared in WorskSpace to initiate the work... Actually some work has already been started jointly with JPM togather with the topic of the Portfolio Swap which typically involves fine-tuned position management

• another point but more minor update is about the current list of Status values in WorkflowStatusEnum : would add two new ones, quite typically used when the workflow is embedded in matching logic :
  • "Paired" (means side-A and side-B events are "attached" notwithstanding there may remain some actions to perform until fully confirmed, etc.), or could also use value "Matched" but not recommending because this may create confusion given the fact you may match but not 100%, hence using "Paired" to say side-A row can be linked to "side-B" without meaning that all components involved are fully matching...
  • "DontKnow" (usually used with acronym "DK" that is a way for given party, say side-A to tag an event received from side-B that party A does not recognize)