finos
Addition of new transferType to support transfer of securities
Background
In a securities lending trade, the lender will deliver the security being lent to the borrower. This is performed on a date agreed by the parties (i.e. it is scheduled) and forms part of the settlement obligations of the trade.
The actual transfer of the shares can be processed using the TransferInstruction primitive instruction. However, under the scheduledTransfer type there is a mandatory transferType attribute where the type of this scheduled transfer must be defined. This enum currently has no option that can be used to define the delivery of the security to the borrower.
Proposal
Add a new “SecurityDelivery” option to the ScheduledTransferEnum
Compatibility
This is adding a new option to an existing enum so has no compatibility issues
Release
CDM V7 dev only
Additional Context
The ScheduledTransferEnum appears to be related to cashflows. However, the transfer -> transferExpression is mandatory and must contain either a priceTransfer or a scheduledTransfer. Within scheduledTransfer, either the transferType or corporateActionTransferType must be set, with transferType being relevant to this use case.
Due to these cardinality constraints the need for a new option in ScheduledTransferEnum is being proposed, even though it looks like all the options in that enum appear to relate to cash flows and not securities per se.
The proposal makes sense. To be sure: the "security delivery" enum value would be used for both the cash and the security components of the transfer?
On a related note, I think that the enum values for the transfer expression types need to be reviewed. For instance, CreditEvent and CorporateAction appear both in ScheduledTransferEnum and FeeTypeEnum, where the latter is taken to mean "unscheduled". It seems to me that the 2 lists should be mutually exclusive since TransferExpression is meant o be a one-of.
@chrisisla Let us know when you're ready to push this to the CRWG - it currently sits in the the "Pipeline".
Hi @lolabeis
The new enum value would be specific to the transfer for the securities ONLY i.e. the transfer of the security being lent from the lender to the borrower. If this is a trade against cash collateral then we would also expect an additional transfer for the cash being used as collateral, for which the existing "PrincipalPayment" will work.
If this is a cash DVP trade then we would expect the cash and the security to be transferred at the same time. However, this is still best represented as two transfer events, as they are in different directions i.e. a "SecurityDelivery" from the lender to the borrower and a "PrincipalPayment" from the borrower to the lender.
I'm happy for this to go to the CRWG as I think we're ready to go with it 👍
Thanks!
@chrisisla and @lolabeis
reading the above, please tconsider the following :
1 / the fact that current individual Enum values in the list of ScheduledTransferEnum currently refer to "obligations of the trade" rather than "the nature of the Asset" being transferred
- proposed new value
SecurityDeliverymight look a bit inconsistent with that regards
2/ Besides, I beleive the fact it is a "Security" or another kind of Asset is already clarified in path below :
-
- proposed new value
SecurityDeliverymight look a bit redundant with that regards
- proposed new value
Alternate proposal : instead of SecurityDelivery , why not to add :
- one value
RepoSettlement - and 2nd one
LendingBorrowingSettlement
this would remain consistent with current list in ScheduledTransferEnum and would avoid creating overlaps
what do you think ?
Hi @JBZ-Fragmos
Thank you for the feedback! Yes, I can see what you are saying - the Asset is described so we know what is being transferred i.e. Cash or Security.
I agree with your assessment of the options in transferType. Although transfers are related to settlement I don't think that using "settlement" in the option name is the right approach though. As you say, this is about the obligation, and securities are "delivered" and cash is "paid" (in securities lending anyway.)
So how about adding a new option of "Delivery"? Or is that a bit too generic? Then the Asset can be used to determine what is actually being delivered. If required, we could add a condition to ensure "Delivery" is only used if the Asset is a Security.
Incidentally, transferType is mandatory so we definitely need to add a suitable option to that enum 🙂
Thanks!
"Delivery" looks too generic to me... would not assume that in all business cases that "delivery" necessarily relates to "Security"... I beleive the term may be relevantly used for other kind of Assets... say Commos, also DigitalAssets, etc.
what about this updated proposal, then ? @chrisisla
- one value
RepoDelivery - and 2nd one
LendingBorrowingDelivery
for the avoidance, I recommand NOT to add any condition in regards to Asset being effectively delivered, because you could have a Transfer that is a payment, else physical delivery, as specified per kind of Asset, and any could apply together with either RepoDelivery or LendingBorrowingDelivery
if i only have 1 delivery of security then you model such event with 1 transfer leg, say Asset is Security and that coud be eitther RepoDelivery or LendingBorrowingDelivery
if there is an exchange cash vs. security, then you mpodel with 2 transfer legs, say one has Asset is Security, other one is the Cash, and still that could be either RepoDelivery or LendingBorrowingDelivery
etc.
Hmmm. I'm not convinced on prefixing with the product type e.g. Repo or LendingBorrowing. Seeing as we're talking about the delivery of an asset, and we're expecting the Asset to be defined in the transfer, how about we add an option of "AssetDelivery"?
That way we're specifying this as a delivery and the Asset can be used to define what is being delivered.
@lolabeis @JBZ-Fragmos Do you have any further feedback on this? I think adding "AssetDelivery" as a new option is the best solution here. Thanks!
Hi @chrisisla
I'm with you that trying to be too specific and prefixing with the product type lends itself to having to maintain an ever-growing list. But the problem with "AssetDelivery" is that it's tautological: a transfer is always delivering some asset, even when it's cash.
Going back to the original idea behind this enum: while a (scheduled) transfer can always identify its payout source, in some cases it may not be enough to identify what this transfer is - e.g. between interest and principal for an InterestRatePayout, or between dividend and performance for a PerformancePayout, etc.
In the case you described, I believe the transfers originate from either a SettlementPayout or AssetPayout and correspond to the "principal" in both cases. For SettlementPayout, principal should be the only possible option, but an AssetPayout could generate other types of transfers, like interest or dividend. However the corresponding enum value, "PrincipalPayment", was clearly named around cash.
My proposed alternative fix is to remove the "Payment" suffix and replace with "Principal" only. The same enum value would be used for both the cash and security parts of the settlement, which could be further delineated based on the underlying Asset.
agree with last proposal from @lolabeis in terms of "conceptual direction"
about the exact (re)naming of the Enum value, not a fan of Principal alone... only reason for that - not blocker for me to be honest - simply does not ring to my ears as something having a movement... looks quite a "fixed" thing...
what about PrincipalSettlement (implicitly we have still either cash or physical possibility behind it) ?
For our use case the transfers would originate from an AssetPayout for the securities being lent and an InterestRatePayout for any cash. "Principal" would actually work to represent either the securities or the cash, so that is a nice suggestion.
The only concern I have is that the term "Principal" is more about referring to the whole amount i.e. all the shares, or all the cash. We need to be able to support the full or partial transfer of the principal though. For example, if the principal is 1000 shares then this could be fulfilled over 3 transfers of 100, 300 and 600 shares, or as a single transfer of the entire 1000 shares.
However, even if we have multiple transfers to transfer the entire principal, I think this should be okay, as really (for us) the enum is there to help identify a transfer as being associated to the transferring of the principal (and the quantity of the transfer would allow us to determine whether it was full or partial).
I would be happy with "PrincipalSettlement", but I don't think it would be ideal when we transfer the shares back to the lender i.e. when they are returned. I think we'd need "PrincipalReturn" or something similar in that case...
if any complexification due to suffix "Settlement" then as far as I'm concerned, fine for me to come back to more generic proposal from Leo that is to say simply "Principal"
It looks like we are all now in agreement, and, based upon the feedback, I think the enhancement required is to change the existing "PrincipalPayment" option to now be just "Principal".
@lolabeis @JBZ-Fragmos thank you both for all your input!
It looks like we are all now in agreement, and, based upon the feedback, I think the enhancement required is to change the existing "PrincipalPayment" option to now be just "Principal".
Cool. For the record, I am also conscious that the term "principal" is imperfect and is usually understood as the cash variety. I just couldn't find any less bad 😄. Since we would typically have 2 transfers, both of type "principal" but with different underlying asset types, I think it would be quite clear.
Discussed at CDM Contribution Review Working Group - October 14th, 2025
Solution seems clear and has been discussed, but Tom Healey would like to look at the item himself
@chrisisla Sorry I should have picked up on that earlier: the change of enum value is backward incompatible, so I'm adding the label and including at the SWG agenda.
Hi @tomhealey-icma As per the CRWG on 14th October please can you review this in time for the next CRWG planned for October 28th. Thanks!
Discussed at CDM Steering Working Group - October 27th, 2025
On the basis that the change introduces backward-incompatible changes, it has been ratified on merit, and the issue is moved to Follow Up pending ratification at CRWG.
I may be coming into this a little late but my questions and comments are:
- How are these enums intended to be used. I could not find any functions or qualifications in the CDM that used them. If they are to be used by external service, which service and what is the data model interface for those services?
- The names are all confusing, TransferExpression implies some type compound or complex data type, ScheduledTransfer implies that there should be a date or time period.
- I agree with some of JBs comments that the enum are more events whereas what is being proposed is a designation of what is being transfer. I believe that what is being transferred should be aligned with the CDM which already has an AssetType. So if transfer needs an a asset type it should use AssetType from the mode.
- So before adding more enums we need to agree on the purpose, and how it's intended to be used.
@tomhealey-icma
The proposal is not to actually add any further options to the enum, we're changing "PrincipalPayment" to "Principal" so it is not explicitly tied to cash.
The Asset itself within the Transfer will denote what is actually being transferred, so no need to add AssetType.
@CDM-ReleaseManagement-OT : New PR created and linked to this Issue (as could not upgrade the original PR so created a new one as it was easiest) 👍