Technical Group 3 Analysis of Target2-Securities Dedicated Cash Accounts

T2S_AG_meet6_prioritisationT2S-08-0033

  • 10 pages
  • Confidential
  • February 26, 2009

Download

During its 28/29 November 2007 meeting, the Advisory Group agreed to add possible
functionality in the URD on the prioritisation of multiple T2S dedicated cash accounts. The AG also asked TG3 to analyse the issue in more depth and the 3CB+ to calculate the
additional costs of this approach. The AG agreed to review the matter in view of the feedback from the public consultation and the cost and the consequences for the market.
Following the AG decision, the prioritisation of multiple T2S dedicated cash accounts
functionality was immediately added into the URD by the project team. This functionality was designed with a view to allow CSDs participants to resort to several liquidity providers in a pre-determined sequence. A confidentiality constraint was also taken into account with a view to avoid that a liquidity provider may be informed of the liquidity provision agreement its client may have with additional liquidity providers.

In order to meet the AG request, a meeting of TG3 was convened on 23rd January in order to analyse more in depth the functionality and provide TG3 feedback to the AG. Despite views were diverging regarding the business case for this functionality, the TG agreed that the way it had been envisaged so far in the URD was quite complex, in particular due to the confidentiality constraint above mentioned. TG3 consequently agreed to envisage an alternative procedure that could help reducing the complexity of this functionality. However, this new requirement may not fully meet the initial confidentiality constraint.

This note aims at describing the two possible procedures envisaged so far for this
functionality and the associated levels of complexity (I). It provides also an analysis of the
business case for this functionality (whatever the procedure preferred) with regards in
particular to its potential impact in terms of liquidity management (II).
I/ Two procedures for the prioritisation of multiple T2S dedicated cash accounts
The prioritisation of multiple T2S dedicated cash accounts functionality was initially
considered as a procedure leading to transfer (“loop” hereunder) unsettled transactions from
one T2S dedicated cash account to a subsequent T2S dedicated cash account, when the
liquidity available on the initial account was not sufficient to ensure the cash settlement of the
relevant transaction. By looping transactions from one cash account to another, none of the
liquidity providers would have aware of the existence/use of additional liquidity providers.
With the alternative procedure envisaged by TG3, transactions would no longer be looped
from one account to another, but would remain on the T2S dedicated cash account of the main
liquidity provider. With this alternative proposal, instead of looping transactions from one
account to another subsequent account, T2S would trigger automated liquidity transfers from
subsequent T2S dedicated cash account(s) to the main T2S dedicated cash account used by
the relevant CSD participant. Of course, with this functionality, the confidentiality constraint
would not be fully met, as the holder of the main T2S dedicated account would identify the
liquidity transfers arriving on its account and the relevant liquidity providers.

As detailed hereunder, whereas the initial procedure was quite complex with significant
impact on the whole settlement process (e.g. requiring transactions splitting), the second
procedure was deemed by TG3 as less complex, as it would only lead to trigger basic cash
settlements.

Initial procedure

As already mentioned, the procedure initially envisaged for the prioritisation of multiple T2S dedicated cash accounts was leading to loop unsettled transaction from one T2S dedicated cash account to a subsequent account. According to this procedure, CSD participants would have had to identify for each securities account a T2S dedicated cash account to be used by default and when necessary1 a list of subsequent T2S dedicated cash accounts to be used according to the priority assigned to each of them by the relevant CSD participant.

In order to evidence the business case, it was agreed that Clearstream Banking Frankfurt
(being currently the only CSD offering this functionality) would provide figures on the
current frequency of use of the prioritisation of multiple T2S dedicated cash accounts. It was
also agreed that Clearstream would provide data on the evolution of the frequency of use of
this functionality after the recent extension of the auto-collateralisation mechanism in CBF.
(The information provided by Clearstream has been the following: 3 Clearstream customers
use the functionality of Multi Cash Sourcing on a daily basis involving a total of 5 RTGS
accounts across 3 countries. These customers settle a high turnover value and represent a
significant percentage of the total CBF turnover).

TG3 considered that if the business case was evidenced, the use of this functionality would be
mainly concentrated on night-time settlements. For day-time settlements, TG3 expressed the
view that the continuous use of this procedure would not necessarily make sense, as liquidity
providers would have the possibility to make cash transfers from T2 to T2S on demand of
their clients on a real-time basis during the whole day-time settlement cycle. Nevertheless, it
was envisaged resorting to this functionality at least once during the day-time cycles, for
instance a few minutes before the end of the day in order to clear transactions that would
remain pending due to a lack of cash.

Impact on liquidity management

With regards to the impact of this functionality on liquidity management, two cases have been
identified: (i) the case where the CSD participant knows in advance ahead of the relevant
settlement cycle that it will need additional cash from its liquidity providers and (ii) the case
where the CSD participant faces an unexpected need of cash during the night-time settlement
cycles for instance.

Share this:

Facebooktwitterredditlinkedinmail