Liquidity Management in TARGET2

Transcription

1 Liquidity Management in TARGET2 In a Real-Time Gross Settlement (RTGS) system, transactions are continuously settled in central bank money and on a gross basis. One of the key advantages of RTGS systems is to reduce systemic risk: payments are final as soon as they are settled by the system. However, prompt finality can be achieved only if sufficient liquidity is available on the debtor RTGS account and/or efficient settlement mechanisms are implemented. To this purpose, TARGET2 will provide its users with the most up to date liquidity management tools currently offered in RTGS systems. The aim of this note is to describe the features of those tools. 1

2 LIQUIDITY POOLING TARGET2 will consist of a single shared platform. This architecture enables realtime, consolidated monitoring of the liquidity position in all RTGS accounts of a credit institution across Europe. Multi-country banks will also be able to manage the activity of their branches from a single point and to centralise their cash management, which will include the liquidity involved in the settlement of Ancillary Systems as settlement of these systems will be performed over RTGS accounts after a transition period (maximum 4 years after TARGET2 golive). liquidity available on all the single accounts belonging to a group of accounts: this liquidity can be managed in a consolidated way. Each transaction involving an account belonging to a group of account will be immediately booked on the relevant single account using the global liquidity available at the group of accounts level; this global liquidity available is defined as the sum of balances of all the RTGS accounts belonging to the group of accounts (plus the sum of all the credits lines, if any, of all the RTGS accounts belonging to the group of accounts). This feature is only available for RTGS accounts open on the books of a Central bank within the Eurozone. The liquidity pooling functionality is based on the concept of the virtual account. BBBBFRPPXXX BBBBDEFFXXX BBBBESMAXXX Cross-border Euro zone The Virtual Account AAAAFRPPXXX Virtual Account BBBBGB3LXXX The purpose of a virtual account («liquidity pooling») is the intraday aggregation of the Domestic «Outs» 2

3 PRIORITIES A priority level can be assigned to each payment depending on its criticality; the three possible priority levels are highly urgent, urgent and normal. A highly urgent payment will always be settled in priority compared to the other payments type, regardless of its entry time into the system. Direct Payment Module (PM) participants will be allowed to switch the priority of a payment from normal payment to urgent or from urgent to normal. However, it is not possible to change the priority level of a highly urgent payment. Participants can also reserve liquidity on their RTGS accounts for the execution of highly urgent (respectively urgent) payments (see 3). In addition, each queued payment is assigned to a specific payment queue in function of its priority level (see 4). Payment types Class of priority Highly urgent Urgent Normal (restricted use) Submission by Ancillary Systems Ancillary Systems Ancillary Systems Central Banks Central Banks Central Banks Direct Payment Module (PM) Direct PM Participants Direct PM Participants Participants (*) Principal Settlement of Ancillary Systems Urgent customer and Interbank payments Interbank payments Use Monetary policy operations Customer payments Cash transactions (*) CLS pay-ins and pay-outs + liquidity transfers in favour of an ancillary system 3

4 LIQUIDITY RESERVATION Direct PM participants have the possibility to use a liquidity reservation feature in order to facilitate the settlement of their operations: - They can reserve liquidity for the execution of payments with a highly urgent (respectively urgent) priority level; - They can set aside liquidity on specific sub-accounts in order to dedicate it to the settlement of transactions stemming from Ancillary Systems using the settlement procedure number 6 1. Direct PM participants can reserve liquidity in an interactive manner through the Single Shared Platform (SSP) user interface - the Information and Control Module (ICM). Effect of reservation on the available liquidity Available liquidity on RTGS account = 1, Available liquidity for normal payments = Available liquidity for urgent payments = Available liquidity for highly urgent payments = Urgent reserve = Highly urgent reserve = The participant has set a highly urgent reserve of 100 and an urgent reserve of 200. Assuming a balance of 1,000, the available liquidity to settle normal payments is 700 ( ) and the available liquidity to settle urgent payments is 900 (1, ). 1 Settlement in dedicated sub-accounts 4

5 QUEUE MANAGEMENT Three payment queues, each one corresponding to a level of priority - normal, urgent and highly urgent - are managed on each account. Highly urgent and Urgent queues are resolved following the FIFO principle whereas the normal payments are processed following the so called «FIFO bypassing» principle. - A (highly) urgent payment will not be settled as long as payment(s) with a higher position in the queue are not settled (or re-ordered or revoked). However, it should be recalled that a payment can be immediately settled in the entry disposition of the platform using offsetting mechanisms (see 6) even though payments with a higher priority level are queued. The algorithm offsetting check with liquidity increase is successful if offsetting payments from the receiver are available and the sender will afterwards have an increased liquidity position. Participants can also facilitate the settlement of their operations by acting on the payment queues, namely: - A normal priority payment will not be settled as long as (highly) urgent payment(s) are still in the respective queue but it could be settled even if another normal payment was previously queued subject to the fulfilment of other settlement criteria: sufficient available liquidity, respect of reservations and limit conditions. - Changing the priority of a payment (from urgent to normal or from normal to urgent ), which will move it to the corresponding payment queue; - Re-ordering queued transactions by placing a payment to the top or to the end of its payment queue; - Changing the set execution time («from» or «till») of a transaction; - Revoking a queued transaction. 5

6 LIMITS In order to avoid that some participants are inclined to wait for receiving payments from their counterparties before issuing their own payments, TARGET2 offers a bilateral and multilateral sending limit feature. Setting a bilateral limit vis-à-vis a participant prevents the settlement of payments that would cause the bilateral balance with this participant to breach this limit. Setting a multilateral limit prevents the settlement of payments that would cause the balance vis-à-vis all the participants towards whom no bilateral limit was set to breach this multilateral limit. Thanks to the multilateral limit feature, there is no need for participants to manage bilateral limits towards each other (TARGET2 should have around 1,000 direct participants). Effect of bilateral limits on normal priority payments Bank A Normal payments to Bank B Bank B Normal payments to Bank A Bilateral limit of Bank A with Bank B Available liquidity for payments with Bank B Unsettled payments from A to B (wait queue) because the bilateral limit is exceeded 6

7 OPTIMISATION MECHANISMS The optimisation mechanisms implemented in TARGET2 aim at reducing participants liquidity needs while improving the fluidity of settlements. They may be classified in two categories: offsetting processes on the one hand, and actual optimisation processes on the other hand; these two categories of processes run in parallel in TARGET2. Offsetting Offsetting processes are triggered by the arrival of a transaction in the system. They attempt to immediately settle this transaction, in combination with already queued transactions. Thus, when receiving a credit transfer issued by participant A for participant B, the system will search B s queue for transactions going in the opposite direction (i.e. from B to A) which, when settled at the same time as the former credit transfer, will make it possible to reduce A s or B s liquidity requirements. If the transaction cannot be settled immediately, it is posted in the queue, and then processed with the optimisation algorithms described below. Optimisation There are five optimisation processes. The first three of them are applied to payments placed in the queue (normal priority) and are sequentially triggered throughout the day. The other two correspond to specific settlement methods for ancillary systems. payments and identifies the transactions which, when set aside, would make it possible to empty a wait queue. If this algorithm fails, the multiple optimisation algorithm is triggered ; The multiple optimisation algorithm scans all bilateral positions of a bank vis-àvis all its counterparties in order to identify the transactions, which, when set aside, allow the settlement of other transactions to be accelerated. Settlement of Ancillary Systems optimisation algorithm for the settlement of ancillary systems using settlement procedure No This algorithm facilitates the settlement of one or several ancillary systems by attempting to settle simultaneously the transactions stemming from this/these system(s) and other operations in the participants wait queues; optimisation algorithm for the settlement of ancillary systems using settlement procedure No It is in fact the equivalent of the all or nothing optimisation process described above, applied to sub-accounts. These offsetting and optimisation processes only allow the settlement of payments which respect the bi- and multilateral limits and the amount of liquidity that has been reserved. Payments with normal priority The «All or nothing» optimisation algorithm simulates the settlement of all queued operations from all participants. If all balances calculated in this simulation are positive or covered by collateralised credit lines, all operations are settled in a single batch. If not, no payment is settled and the partial optimisation algorithm is triggered ; The «partial» optimisation algorithm simulates the settlement of all queued 7 2 Simultaneous multilateral settlement 3 Settlement in dedicated sub-accounts

8 COMPARISON WITH TBF AND PNS Liquidity pooling TBF offers the equivalent of TARGET2 virtual accounts, with the exception that the pooling of liquidity is done at the national level only. Each direct participant may share intraday liquidity with its branches and other institutions belonging to the same banking group, provided that the accounts are part of the same group. Priorities PNS does not offer a classification of operations according to priority. TBF offers two priority levels, the most urgent being reserved for central bank operations, ancillary system settlements and CLS settlements. In comparison, TARGET2 offers more sophisticated priority management. Furthermore, each priority level has its own wait queue and allows reservation of liquidity. Limits There is no limit in TBF. The management of bilateral limits between participants is similar in TARGET2 and PNS, except for the requirement that bilateral limits have a minimum value of 1 million euros in TARGET2. The following features are common to both systems,: - Bilateral sending limits; - Limits can be deactivated (PNS does not propose deactivation at present, but a limit 8 can be set to a very high value, which in practice has the same effect as deactivation 4 ); - Limits can be increased or decreased during the operating day: changes are taken into account for the processing of pending and new incoming credit transfers. In addition to bilateral limits, which exist both in PNS and TARGET2, the latter also provides multilateral limits, which apply to all participants with whom a bilateral limit has not been set. Efficiency of optimisation processes Comparative analysis of the optimisation algorithms of PNS and TARGET2 allows two elements to be highlighted: - They are on the whole extremely similar in their functioning: the bilateral optimisation algorithm is the same in PNS and in TARGET2; the multilateral optimisation algorithms used are similar in the two systems (the TARGET2 algorithm respects a pure FIFO sequence, whereas strict FIFO is not observed in the PNS algorithm). - Optimisation algorithms are invoked much more frequently in TARGET2 than in PNS. In effect, in the absence of human intervention, the multilateral optimisation of PNS is launched three times a day (10:30 am, 2:00 pm, 4:00 pm), and other operations cannot be processed by the system while it runs. The bilateral optimisation between two participants is triggered in PNS only when a payment between two participants is posted in the wait queue. By contrast, the bilateral and multilateral optimisation procedures of TARGET2 are triggered by each payment entered in the system and then on a continuous basis throughout the day; these two types of mechanism operate in parallel without interrupting the processing of other operations. Consequently, optimisation processes will be more efficient in TARGET2 than in PNS, notably because they are invoked very frequently. 4 Many PNS participants have set their bilateral limit vis-à-vis the virtual participant TBFPNS (involved in liquidity transfers between the PNS and TBF systems) to 90 billions euros.

9 CONCLUSION Among other comparable high value payment systems, TARGET2 is the one that offers the most comprehensive and efficient optimisation and liquidity management tools. Nevertheless, a participant will only fully benefit from these mechanisms if it relies primarily on TARGET2 for the processing of its operations and for optimising its intraday liquidity, by issuing its operations as soon as they are ready to be submitted, without retaining them on its participant platform or waiting for the needed liquidity to become available 9