Download presentation

Presentation is loading. Please wait.

Published byAlec Openshaw Modified about 1 year ago

1
Real-Time Gross Settlement and Hybrid Payment Systems: A Comparison Matthew Willison Bank of England The views expressed in this paper are those of the author, and do not necessarily reflect those of the Bank of England.

2
Background DNS versus RTGS credit risk versus liquidity demands. Hybrids no credit and settlement risk but more liquidity efficient (?).

3
Literature Review BIS Report (1997) McAndrews and Trundle (2001) Roberds (1999) Simulations; e.g., Johnston et al. (2003)

4
Aim of the paper Assess the welfare properties of RTGS and hybrid payment systems. But while allowing bank behaviour to fully depend on the payment system design in place.

5
Criteria Liquidity demands (≡ Collateral posted) Speed of settlement ( system’s exposure to operational risk) First-best: - Total collateral posted is minimised. - All payments are settled early in the day.

6
The Model n (settlement) banks; n>2 All payments have a value = 1 Each bank has a single payment to send to each other bank A payment between bank i and bank j; i→j

7
The Model Two periods: morning and afternoon Collateral costs: - ¹ per unit in the morning - ² per unit in the afternoon

8
The Model ¹ ² a bank only posts collateral in the morning that it uses in the morning. Morning payments can be used to make afternoon payments. Afternoon payments can be used to repay the CB at the end of the day.

9
The Model Delay cost; incurred when a payment is not settled in the morning. Delay cost, (i→j) (i→j) takes one of n-1 possible values.

10
The Model (i→j)= (i→k) iff j=k Highest (i→j)> ¹ Lowest (i→j) ¹- ²

11
The Model Delay costs are bank’s private information; I.e., only i knows (i→j) A bank forms internal queue Q i Position of payment in Q i is inversely related to its delay cost.

12
The Model Cancellation cost, Incurred when a payment is not settled in the afternoon, given that it is not settled in the morning. > ²

13
RTGS Banks borrow liquidity from the CB Banks make payments Banks borrow liquidity from the CB Banks make payments Banks repay the CB MorningAfternoon

14
RTGS Morning action : Morning action set: Afternoon action: Afternoon action set:

15
Afternoon > ²; optimal for a bank to settle all remaining payments in the afternoon, for any Value of i’s afternoon payments is

16
Morning A bank is affected by other banks’ morning actions through effect on afternoon collateral needs. Internal queue ordering is private information a bank is uncertain about the value of its incoming payments in the morning.

17
Morning Bank chooses morning action to minimise expected total cost. Expected total cost = Morning collateral cost + Delay cost + Expected afternoon cost

18

19
Equilibrium Equilibrium (in pure strategies)

20
Equilibrium Each bank settles at least one payment in the morning because (1)> ¹ {Q 1,…,Q n } is not an eqm. because expected afternoon collateral costs = 0 and (n-1)< ¹

21
Hybrids Two ways of settling a payment: RTGS and offset. Offset: a payment has to be submitted to the central queue.

22
Hybrids H1: Offset in the afternoon H2: Offset in the morning H3: Offset in both periods

23
Hybrids Central queue transparency: - Opaque; a bank cannot see other banks’ payments in the central queue. - Visible; a bank can see payments to it in the central queue. May effect how well banks co-ordinate use of the central queue.

24
Hybrids Split each period into two sub-periods. Sub-periods, 1a, 1b, 2a, 2b. Results for RTGS with four sub-periods are the same as those with two periods.

25
Hybrids Placing a payment in the central queue in one sub-period is not ≡ a commitment to keep the payment in the central queue in subsequent sub-periods. Submission behaviour depends on what a bank expects other banks to do.

26
Hybrids there is the potential for co-ordination problems. Not guaranteed that visibility will overcome problems.

27
H1 If j→i is received in the morning, i→j is settled by RTGS in the afternoon. All RTGS payments settled in 2b.

28
H1 If j→i is not received in the morning, a bank submits i→j to the central queue in 2a if each other bank submits at least one payment. Because each payment should be offset with a positive probability.

29
H1 So all payments that can be offset will be offset in 2a. If a payment is offset, needs no liquidity.

30
H1 If a payment is settled by RTGS in 2b, the offsetting payment arrived in the morning. So need no liquidity. Expected afternoon collateral = 0

31

32
H1 Bank’s cost minimisation problems are disentangled from each other. Each bank settles the same value of payments in the morning (have the same cost structure).

33
H1 Value of morning payment in H1 value of morning payments under RTGS. Liquidity in H1 liquidity in RTGS H1 is not necessarily better than RTGS.

34
H2 In 2a, a bank submits all payments if each other bank submits at least one payment. Because each payment could be settled with positive probability. All payments offset in 1a.

35
H3 In 2a, a bank submits all payments if each other bank submits at least one payment. Because each payment could be settled with positive probability. All payments offset in 1a.

36
H2 and H3 First-best since all payments are offset ( no liquidity required) in sub-period 1a.

37
Delay costs are private information Under H2 and H3 there exist ‘bad’ equilibria where the central queue is not used at all in 1a. But no intermediate cases because each payment could be settled with positive probability if each other bank submits 1 payment.

38
Delay costs are private information If delay costs are public information we can show there exist intermediate cases, where some but not all payments are submitted to the central queue in 2a.

39
Conclusion The first-best is attained under Hybrid payment systems if offset is available in the morning. Offering offset in the afternoon can only be as good than RTGS.

40
Conclusion Central queue transparency is unimportant. Maybe because of the information structure and that the cost of using the central queue = 0

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google