1

Designing Large Value Payment Systems: An Agent-based approach

Amadeo Alentorn CCFEA, University of Essex

Sheri Markose Economics/CCFEA, University of Essex

Stephen Millard Bank of England Jing Yang Bank of England

2

Roadmap Payment system 101

The Interbank Payment and Settlement Simulator (IPSS)

Demonstration & Experiment results

Conclusions

3

Payment system 101

4

Payment System: DNS vs RTGS

£10£10

£10 £10

Bank C

Bank B

Bank A

Liquidity

DNS £ 0

RTGS £ 40Bank

D

5

LVPS design issues

Two polar extremes:- Deferred Net Settlement (DNS)- Real Time Gross Settlement (RTGS)

Liquidity Delay

DNS Low High

RTGS High Low Hybrids+

6

Risk-efficiency trade off (I)

RTGS avoids the situation where the failure of one bank may cause the failure of others due to the exposures accumulated throughout a day;

However, this reduction of settlement risk comes at a cost of an increased intraday liquidity needed to smooth the non-synchronized payment flows.

7

Risk-efficiency trade off (II) Free Riding Problem:

Nash equilibrium à la Prisoner's Dilemma, where non-cooperation is the dominant strategy

If liquidity is costly, but there are no delay costs, it is optimal at the individual bank level to delay until the end of the day.

Free riding implies that no bank voluntarily post liquidity and one waits for incoming payments. All banks may only make payments with high priority costs.

So hidden queues and gridlock occur, which can compromise the integrity of RTGS settlement capabilities.

8

UK payment system: CHAPS 13 direct members, and other banks have

indirect access to CHAPS through correspondent relationship.

Payments through the system average about ￡ 175 bn per day (175 of UK annual GDP).

CHAPS is a Real time gross settlement system (RTGS).

Each direct member has an account at the BoE. Bank A ￡ X amount to Bank B: Bank A instruct the BoE

to transfer ￡ X to bank B’s account.

9

Liquidity A bank may obtain liquidity needed to

make payments in two ways. 1). Obtain liquidity directly by posting

collateral with the Bank. 2). Obtain liquidity by receiving a payment

from another bank. Total amount of liquidity in the system is

determined by the amount of collateral the member banks post with the BoE.

10

What are the design issues in a Large Value Payment Systems (LVPS)?

Three objectives :

1. Reduction of settlement risk2. Improving efficiency of liquidity usage3. Improving settlement speed (operational

risk)

11

What are agent-based simulations?

Using a model to replicate alternative realities

Agent-based simulations allow us to model these characteristics:

1. Heterogeneity2. Strategies: rule of thumb or optimisation3. Adaptive learning

12

The Interbank Payment and Settlement Simulator

(IPSS)

13

What can IPSS do?1. Payments data and statistics

- Each payment has :- time of Request: tR

- time of Execution: tE

- Payment arrival at the banks can be:- Equal to tE from CHAPS data files (Chaps Real)- IID Payments arrival: arrival time is random

subject to being earlier than tE. (CHAPS IID Real)- Stochastic arrival time (Proxied Data)

14

Upperbound & Lowerbound liquidity Upper bound (UB) : amount of liquidity

that banks have to post on a just in time basis so that all payment requests are settled without delay. Note that the UB is not know ex-ante.

Lower bound (LB) :amount of liquidity that a payment system needs in order to settle all payments at the end of the day under DNS. It is calculated using a multilateral netting algorithm.

15

What can IPSS do?2. Interbank structure

Heterogeneous banks in terms of their size of payments and market share

-tiering N+1; -impact of participation structure on risks.

16

Herfindahl Index measures the concentration of payment

activity:

In general, the Herfindahl Index will lie between 0.5 and 1/n, where n is the number of banks.

It will equal 1/n when payment activity is equally divided between the n banks.

HIPayments =

i

i

PaymentsofValueTotal

PaymentsBank2

17

Herfindahl Index and Asymmetry

BilateralDNS

Lower Bound(Multilateral

DNS)

UpperBound

Equal Size Banks(Proxied Data ) Herfindhal Index 1/14 ~ 0.071

£0 £0

£2.4 bn

Chaps DataHerfindhal Index ~ 0.2

£19.6 bn £5.6 bn £22.2 bn

Note that total value of payments is the same in all scenarios

18

Liquidity posting Two ways of posting liquidity in RTGS:

Just in Time (JIT): raise liquidity whenever needed paying a fee to a central bank, like in FedWire US

Open Liquidity (OL): obtain liquidity at the beginning of the day by posting collateral, like in CHAPS UK

A good payment system should encourage participants to efficiently recycle the liquidity in the system.

19

Open Liquidity Banks start the day by posting all liquidity upfront to the

central bank. The factor α applied exogenously gives liquidity ranging from LB to UB:

In the benchmark OL case, IPSS simply applies the FIFO (first in first out) rule to incoming payment requests if it has cash. Otherwise, wait for incoming payments.

Strategic behavior leading to payment delay or reordering of payments occurs only if the liquidity posted is below the upper bound UB.

L(UB - (UB –LB)

20

JIT – Optimal rule of delay

Minimization of total settlement cost, which consists of delay costs plus liquidity costs. Gives an optimal time for payment execution tE*

ab

i

btt RE ln

1*

21

Demonstration

22

Experiment Results

23

IPSS Experiments Open liquidity vs. Just in time liquidity

(Optimal rule)

Under two payment submission strategies:

1. First in first out (FIFO)2. Order by size (smallest first)

24

Liquidity/Delay: JIT vs. OLTime weighted delay vs. Liquidity

£0

£5

£10

£15

£20

£25

0.00% 1.00% 2.00% 3.00% 4.00% 5.00% 6.00% 7.00% 8.00% 9.00% 10.00%

Percentage TW delay value

Liq

uid

ity

po

sted

(b

illio

ns)

OL (Delay by size)OL (FIFO)

JIT (Delay by size)

JIT (FIFO)

25

Throughput in JIT vs. OL

Throughput in JIT vs OL

0%

20%

40%

60%

80%

100%

05:00 07:00 09:00 11:00 13:00 15:00 17:00Time

Perc

enta

ge

of paym

ents

made b

y va

lue

JIT

OL

Throughput: Cumulative value (%) of payments made at any time.

26

Failure analysis IPSS allows to simulate the failure of a bank, and to

observe the effects. For example, under JIT:

Note that, because of the asymmetry of the UK banking system, a failure of a bank would have a very different effect, depending on the size of the failed bank.

Scenario Failure big bank (K)

Failure small bank (F)

Chaps IID Real 32,384£94.2 bn

2,634£1.0 bn

Equal size banks 11,732£21,1 bn

27

summary We developed a useful payments simulator: - able to handle stochastic simulation; - able to handle strategic behaviour.

The experiments we ran suggested that open-liquidity leads to less delay than just-in-time.

Future work will covers adaptive learning by banks to

play the treasury management game and their response to hybrid rules.