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 Expert Forum: Payment System Architecture and Oversight - 1 st Feb 2005

2 Roadmap  Background  The Interbank Payment and Settlement Simulator (IPSS)  Demonstration  Experiment results  Further work

3 Background

4 What are agent-based simulations?  Using a model to replicate alternative realities  Agent-based modelling has three characteristics: 1.Heterogeneity 2.Strategies: rule of thumb or optimisation 3.Adaptive learning

5 Agent based vs. Analytical models  Analytical models make simplifying assumptions: equal size banks with equal size payments  Agent based models can process and run data in real time and can simulate a system in “model vérité” to replicate its structural features and perform “wind tunnel” tests  Nirvana of Agent based Computational Economics (ACE) Have agents respond autonomously and strategically to policy changes

6 What are the design issues in a LVPS? Three objectives : 1.Reduction of settlement risk 2.Improving efficiency of liquidity usage 3.Improving settlement speed (operational risk)

7 Design issues Two polar extremes: -Deferred Net Settlement (DNS) -Real Time Gross Settlement (RTGS) LiquidityDelay DNSLowHigh RTGSHighLow Hybrids +

8 Example: DNS vs. RTGS Bank C Bank B Bank A Liquidity DNS0 £ RTGS40 £ Bank D

9 Logistics of liquidity posting  Intraday liquidity can be obtained in two ways: waiting for incoming payments; or posting liquidity.  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.  Folk theorem: “A dollar posted earlier in the day improves the liquidity recycling capabilities of RTGS”

10 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 increased intraday liquidity needed to smooth the non-synchronized payment flows.

11 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.

12 The Interbank Payment and Settlement Simulator (IPSS)

13 Related Research (I)  Bech and Garratt 2003 A nalyse the effects of different central bank intraday credit policy on payment incentives and the equilibrium depends on magnitudes of the opp cost of collateral and delay penalty. 1. free intraday liquidity: no delay 2. collateralised intraday liquidity: different equilibria possible depending on costs. 3. priced intraday liquidity: delay can be efficient

14 Related Research (II)  Bech and Soramaki, 2002 BoF-PSS1 allow banks to post varying amounts of liquidity at opening assume payment arrival time is the time of submission evaluate delays at different level of liquidity

15 What’s the difference with the BoF Simulator?  We can handle stochastic simulations while the BoF simulator can only deal with deterministic simulations based on actual data.  Stochastic simulations enable us to vary the statistical properties of interbank system in terms of the size, arrival time, and distribution of payments flows.  We can model strategic behaviour of banks

16 What can IPSS do? 1. Payments data and statistics -Each payment has : -time of Request: t R -time of Execution: t E -Payment arrival at the banks can be: -Equal to t E from CHAPS data files (Chaps Real) -IID Payments arrival: arrival time is random subject to being earlier than t E. (CHAPS IID Real) -Stochastic arrival time (Proxied Data)

17 Liability matrix Rows: payments from A to other banks Columns: payments from other banks to A

18 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 known 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.

19 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.

20 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.

21 Herfindahl Index Asymmetry And Liquidity Needs Bilateral DNSLower Bound (Multilateral DNS) Upper Bound Equal Size Banks (Proxied Data ) Herfindhal Index 1/14 ~ £2.4 bn Real Chaps Data Herfindhal Index ~ 0.2 £ 19.6 bn £5.6 bn £22.2 bn Proxied Data (IID Real) Herfindahl Index ~ 0.2 £19.6 bn £5.6 bn £17.6 bn Note that total value of payments is the same in all scenarios

22 IPSS Strategies -Open liquidity (with exogenous levels of liquidity posted) -Just in Time -No strategy -Rule of Thumb -Optimal Rule

23 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.

24 JIT - Rule of thumb  Banks order the payment requests according to order by size or FIFO rule.  Make payments which have high delay cost first and raise liquidity when needed.  After that, if the bank still has extra liquidity, it goes down the queue to make payments.

25 JIT – Optimal rule of execution Minimization of total settlement cost, which consists of delay costs plus liquidity costs. Gives an optimal time for payment execution t E *

26 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 value (smallest first)

27 Experiment Results

28 Open liquidity --FIFO

29 Open liquidity –order by size Note that strategic behaviour leads to failed payments!

30 Just in time liquidity –FIFO

31 Just in time liquidity-order by size

32 Liquidity/Delay: JIT vs. OL

33 Throughput in JIT vs. OL Throughput: Cumulative value (%) of payments made at any time.

34 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. ScenarioFailure big bank (K) Failure small bank (F) Chaps IID Real32,384 £94.2 bn 2,634 £1.0 bn Equal size banks (with same total value of payments and arrival time) 11,732 £21,1 bn

35 Demonstration of IPSS …

36 Conclusion  We developed a useful payments simulator: - able to handle stochastic simulation; - able to handle strategic behaviour.  Two particular experiments we ran suggested that open-liquidity leads to less delay than just-in-time.  Future work covers adaptive learning by banks to play the treasury management game and their response to hybrid rules.

37 Services offered by CCFEA Demonstration & training on IPSS Bespoke modeling of specific payment systems Advanced policy analysis Advanced treasury management analysis