Updating positionState to "Settled" for securities lending trades

[chrisisla]

Background

The current status of a trade is held in the tradeState->state->positionState attribute. This is an enumerated list that has several options, including "Executed", "Formed", "Settled", "Cancelled" and "Closed".

For securities lending, knowing whether a trade has "Settled" is imperative, as this controls whether specific lifecycle events can be performed upon it. For example, if a trade has not settled then you would not mark or return it.

Proposal

The positionState of a securities lending trade should be set to "Settled" once the settlement obligations of that trade have been fulfilled.

To support this, the proposal is as follows:

• Create new functions to:
  • determine whether the full quantity of securities have been delivered
  • determine whether the total cash expected has been paid (only for trades collateralised by cash)
  • these functions will use the details in the tradeState->transferHistory and tradeState->trade->tradeLot
• Update the Create_Transfer function to set positionState to "Settled" if:
  • this is a securities lending trade, and
  • the settlement obligations (security delivery and potentially cash payment) have been fulfilled

This change will be applied only to trades that qualify as securities lending trades. This will restrict the impact to only this product type.

Compatibility

This should not be a breaking change, as it is enhancing how existing attributes are set.

Release

CDM 7

Additional Context

The proposed change is solely for securities lending trades. If the same functionality is required for other product types then this can be picked up by interested parties and considered separately.

[CDM-ReleaseManagement-BP]

Discussed at CDM Contribution Review Working Group - October 21th, 2025

Further discussion is required to suggest possible changes. @chrisisla suggested the creation of functions logic should be discussed and what settled should mean in CDM

[chrisisla]

I have reached out to @lolabeis separately to discuss the pseudocode/workflows for settlement.

[chrisisla]

Yesterday (30th) had a call with @lolabeis where I presented the general ideas I had for how we could potentially approach settlement in the model, including how this works in securities lending and the pseudocode for the functions I propose adding to fulfil the requirements for this issue.
I sent the slides to Leo and we will have follow up discussions over the coming weeks.

[chrisisla]

Further discussion reinforced the fact that the proposal being put forward for securities lending will also work for other product types. The suggestion is that a more generalised approach to the development is taken.

The idea is that each type of Payout has its own specific settlement obligations. These requirements can be put into individual functions specific to each type of Payout. For example, an AssetPayout will expect a specific number of shares to have been transferred; if these shares have all been transferred then the settlement requirements for this AssetPayout will have been met.

The Payouts required for a specific trade can be determined by looking at the economicTerms -> payout and economicTerms -> collateral. Thus, the overall settlement obligations for a trade can be checked by calling the functions for each of the Payouts on that trade.

The Transfer event is used to record the actual movement of assets related to the Payouts. This means that the Transfer event can be updated to check the settlement status of each Payout on a trade. If the settlement obligations of all Payouts on the trade have been fulfilled then the Transfer event can set the positionState attribute of the trade to "Settled".

The development required would be as follows:

1. Create new individual functions for each Payout which will:
   • Expect Input of a Payout and TransferHistory
   • Logic will be to check the TransferHistory to determine if the Payout obligations have been fulfilled
   • If the obligations have been fulfilled then the function will return True, otherwise False
   • Initially we’ll only create functions for the securities lending use case i.e. to check AssetPayout and InterestRatePayout
   • Other Payout types will just return False for now
2. Create a new generic Trade level function which will:
   • Expect Input of a TradeState
   • This will extract the Payouts from the trade's economicTerms and collateral
   • It will then call the individual Payout functions (described in point 1) to check overall fulfilment of the settlement obligations for this trade
   • If the obligations for all Payouts have been fulfilled then it will return True, otherwise False
3. Update the Transfer event
   • After each successful Transfer event the new Trade level function (described in point 2) will be called
   • If that function returns True then this function will update positionState for the trade to "Settled"

Note that points 1 and 2 can be implemented without impacting any current processing in the model.

[CDM-ReleaseManagement-OT]

Discussed at CDM Contribution Review Working Group - November 18th, 2025

Presented by @chrisisla who requested feedback from the group.