Security Lending Qualification function issue

[chrisisla]

In PR#2084 a request was made to change the cardinality of collateralProvisions -> collateralType from 1..1 to 0..1. For securities lending trades the collateralType needs to be specified as it cannot be inferred from other details on the trade. The suggestion was that we could use the Qualify_SecurityLendingAgreement function to put a condition into collateralProvisions that would make collateralType mandatory for securities lending trades.

While investigating the feasibility of this request it was found that recent changes to the Qualify_SecurityLendingAgreement function meant that it was no longer able to explicitly qualify a trade as being a securities lending trade – it would also qualify a repo trade as a securities lending trade.

Prior to the changes made to the model on January 17th the function used the presence of the securityFinancePayout to qualify a securities lending trade (snippet taken from github version on January 11th):

func Qualify_SecurityLendingAgreement: <"Qualifies a product as a Security Loan.">
    [qualification Product]
    inputs: economicTerms EconomicTerms (1..1)
    output: is_product boolean (1..1)
    set is_product:
        economicTerms -> payout -> securityFinancePayout exists

From January 17th the securityFinancePayout was replaced with assetPayout. The function was updated to now be as follows:

func Qualify_SecurityLendingAgreement: <"Qualifies a product as a Security Loan.">
    [qualification Product]
    inputs: economicTerms EconomicTerms (1..1)
    output: is_product boolean (1..1)
    set is_product:
        economicTerms -> payout -> assetPayout exists and
        economicTerms -> payout -> interestRatePayout exists and
        economicTerms -> collateral exists

Unfortunately, the logic in place now will also qualify a repo as a securities lending trade.

Additionally, this new version of the qualification will only work for a securities lending trade against cash. For a trade against non-cash collateral there would be two instances of assetPayout, one for the securities being loaned and one for the securities being used as collateral.

We now need to investigate how we can qualify a securities lending trade, because this does not work in the current version of the model.

Once we have got the qualification working then we should be able to update the cardinality of the collateralType.

Seeing as the model can no longer differentiate between securities lending and repo trades can I ask that we prioritise the investigation and resolution of this issue.

[chrisisla]

@valdensmith - This is in relation to the collateralType request that we discussed on the Collateral WG the other week.

@iansloyan - we discussed this issue with the qualification function the other day. I think we probably need to have a discussion about how this gets resolved.

[chrisisla]

@minesh-s-patel - as discussed, the issue with the securities lending qualification

[tomhealey-icma]

I don't think there is a model structure for repo and sec lending that is deterministic unless we add to the model what is being lent, security vs cash. Collateral may be cash and/or securities in both scenarios although it never occurs in repo unless it's against a margin account holding cash but not at the transaction level.

The other possibility would be to enforce a taxonomy definition. CFI codes for repo start with LR and sec lending LS. I would prefer not to use this since I believe that taxonomies should be derived from the object and not the other way around.

Another option is the legal agreement. All transactions are backed by some form of legal agreement even if it's not a standardized MRA or MSLA, as it may be a private agreement, but at least there is some type of agreement.

There is also the accounting questions, not all repos even if they are traded on a GMRA are consider repo for accounting purposes.

So this raises the question, what are we trying to qualify?

As a base case, repo transactions currently use external key enumerations for purchase date and repurchase date. This terminology would not apply to sec lending, loans and swaps so this would be a possible solution, notwithstanding the need to define what is being lent and what is collateral.

[chrisisla]

Agreed, there is now no way to differentiate between a repo and securities lending trade in the model. We used to be able to qualify a securities lending trade which we now cannot.

I ran through this with some SMEs and the consensus was inline with what has been mentioned here so far - we may end up needing some specific flag that can set whether the trade is a repo, securities lending or derivatives trade.

[tomhealey-icma]

After further consideration I believe that repo qualification will use the productQualifier string and set it to repurchase_agreement or buy/sell_back_agreement among other fields that will be compared for completeness. The reason for this is that we need to support repo and buy/sell-back transactions traded on a GMRA or MMRA, and the same types that are undocumented. So there is no structural or legal agreement definition that can uniquely determine the correct type of transaction without knowing the intent of the counterparties. The original intent of productQualifier was to derive the product from the model which could be used in the case where the model does agree with the productQualifier.

[chrisisla]

Hi @tomhealey-icma, Off the back of your last comment on this Issue, and the follow up conversation on the Collateral WG, it looks like we have a consensus on the fact that we need some way to identify different trade types that cannot be easily differentiated based upon their legal agreements or the economic terms. Using the "productQualifier" looks like a good suggestion as a potential way forward. Is this something we need to request a separate meeting of the CDM Maintainers for, so that we can present the proposal and get sign off before proceeding with any scoping/dev work?

[tomhealey-icma]

Chris and I had thought the best way to resolve the qualification problem would be to add productDefinitionEnum to productTaxonomy. After attempting this I found that all the qualification functions are based on economicTerms so product level attributes will not work.

To resolve this we need to consider new qualification process that include product level attributes like productDefinition and legal agreements. Also I noticed that setQualifier has hard coded the source to ISDA. We need to be able to set the source based on the qualification function result.

[lolabeis]

@tomhealey-icma @chrisisla As discussed we will look to address this in 2 steps:

1) Immediate / tactical: change the current qualification logic at the product level to be "coarse" and return SecuritiesFinance in all existing cases, Repo/SecLending etc. Or would you suggest a different string? 2) Strategic: extend the qualification logic to work on a higher level too, where the product may be wrapped together with a legal agreement plus some other product-related definition.

I propose that the PR on 1) should be closing this issue. For 2), the discussion should carry-on on issue #2365 , which will remain open.

[tomhealey-icma]

I would suggest SecuritiesFinanceAgreement. Also related to this change is the productTaxonomy:source values which will change from ISDA to ICMA for repo and BuySellBack and ISLA for SecLending. Additionally, all the ICMA PRs and ISLA PRs discussed and any related changes plus the repo and sec lending test cases input files and output files.

Further to the strategic change, this was agreed to be included in a production release as expeditiously as possible and no later than year end.

[lolabeis]

I would suggest SecuritiesFinanceAgreement

@chrisisla you also ok with that name? Personally I would have removed the term "Agreement", which has a legal connotation, from the qualifier if we're saying that this level of qualification applies at the economic terms level only.

I would also use "Security" singular rather than "Securities"

[lolabeis]

Also related to this change is the productTaxonomy:source values which will change from ISDA to ICMA for repo and BuySellBack and ISLA for SecLending

There is no way to implement this taxonomy source switch in the current state of affairs. This will have to come from the strategic qualification work.

[lolabeis]

Further to the strategic change, this was agreed to be included in a production release as expeditiously as possible and no later than year end.

Let's re-discuss once we've been able to assess the work and have estimates

[chrisisla]

@tomhealey-icma @lolabeis

My preference would be "SecuritiesFinance" as that looks to be the commonly used term to cover both stock loan and repo. I know we try to use singular wherever possible in the model but I think this term is more appropriate - plus it is going to be removed again in the next few weeks so is probably not a major issue 😉

I would not add "agreement" to the name as we're describing the product.

I agree that we should get the strategic fix into the model asap, let me know if you need any input from myself during your assessment Leo 👍