Improving flexibility at CMB level T2S 0429 SYS Improving flexibility at CMB level

CMB – background information The Credit Memorandum balance (CMB) allows tracking the limits use: Between the Central Bank and the Payment Bank (auto-collateralisation limit), i.e. the so called primary CMB; Between the Payment Bank and its client (external guarantee limit, client-collateralisation limit and unsecured credit limit), i.e. the so called non-primary CMB.

CMB – Current Design The primary CMB is set-up by the NCB linking a DCA to all the BIC11 having the same BIC8 root. All securities accounts linked to this DCA, associated to parties, in whatever CSD they are located, that have their first BIC’s 8 characters equal to such a BIC8, cannot be managed through a non-primary CMB. All securities accounts linked to this DCA, associated to parties, in whatever CSD they are located, that have their first BIC’s 8 characters different from such a BIC8, can only be managed through a non-primary CMB. Business Rule DCC6048: When performing a Credit Memorandum Balance create request, if the Primary CMB is set to true, only one Wildcard Pattern must be specified and it must be equal to the BIC8 of Party Mnemonic of the Party holding the relevant T2S Dedicated Cash Account.

Way forward Requested change Issuing a CR to relax the check on the usage of securities accounts with respect to the authorised BICs in the set-up of primary and secondary CMB. Two options have been proposed so far: Option 1: Provide the same level of flexibility on the set-up of the primary CMB as on the secondary CMB, via a wildcard implementation. This option must also ensure that the securities account linked via the primary and the secondary CMBs are mutually exclusive (i.e. do not overlap). Option 2: In addition to option 1, to decouple the securities accounts which are used to provide collateral for auto / client collateralisation from the securities accounts which are used for the settlement of securities on the same cash account (DCA). In technical terms, this decoupling would imply a change to the data model in T2S by separating the technical linkage (the “CMB securities account link”) into two independent objects, one for the securities accounts for settlement purposes and a separate linkage object for securities accounts providing collateral.

Option 1 The benefit of this change will be to allow the flexible set-up of the CMBs for auto-collateralisation and client collateralisation for banks, in accordance with their Central Banks. It will allow banks to implement the BIC structures that they currently have in place also in T2S. At technical level this implies (preliminary assessment to be further analysed at 4CB level): Removal of Business Rule DCC6048, DCC6049 and DCU6047 to allow the setup and update of Wildcard rules for Primary CMB Modification of DCC6050 and DCU6058 to extend the check on overlapping to Primary CMB Wildcard rules These changes are limited to SDMG domain and do not impact the management of auto-collateralisation at SETT level

Option 2 The benefit of option 2, in addition to the benefits named in option 1, is to allow the banks to set-up the links between their securities and cash accounts for settlement and the provision of collateral independently from each other. They would for example be able to set-up the securities/cash account links for the provision of collateral in a flexible way by using the wildcard pattern (i.e. collateral could be received from flexible providers) whilst specifying the links between securities accounts and cash accounts in a “strict” set-up, (e.g. by specifying BIC 11 for both the cash and securities accounts). At technical level this implies: The same changes to be introduced with option 1 plus A change in the data model to separate the cash links from the collateralisation links and relaxing the constraints on uniqueness of collateralisation links between DCA and a BIC11 producing impacts at the level of maintenance instructions and graphical interfaces. A change in the design of the settlement process in order to take into account the separation introduced.

Conclusions Option 1 allows an higher degrees of flexibility compared to the existing model. The magnitude of the impact is affecting only one T2S Domain and therefore subject to An easier schedule for implementation Option 2 introduces an additional level of complexity in the design; since it is a much more fully-fledged solution triggering changes on several domains and changes on the Data Model, its implementation would entail much more impacts on the current stabilization of the T2S software