Embed Size (px)
DESCRIPTION
We present an agent based model where banks choose the amount of liquidity to post to an interbank payment system
Citation preview
An agent-based model of payment systems
Marco GalbiatiBank of England
Kimmo SoramäkiECB, www.soramaki.net
ECB-BoE ConferencePayments and Monetary and Financial Stability
12-13 November 2007
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Motivation, related work
Model
Results
Conclusions
Overview of the presentation
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Motivation, related work
Model
Results
Conclusions
Overview of the presentation
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Motivation, related work
Model
Results
Conclusions
Overview of the presentation
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Motivation, related work
Model
Results
Conclusions
Overview of the presentation
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Motivation, related work
Model
Results
Conclusions
Overview of the presentation
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Liquidity in payment systems
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Liquidity in payment systems
Deferred Net Settlement vs Real Time Gross Settlement
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Liquidity in payment systems
Deferred Net Settlement vs Real Time Gross Settlement
Liquidity risk (and operational risk)
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Liquidity in payment systems
Deferred Net Settlement vs Real Time Gross Settlement
Liquidity risk (and operational risk)
Liquidity as a common good
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Liquidity is costly: tradeoff cost-of-liquidity / cost-of-delay
Liquidity in payment systems
Deferred Net Settlement vs Real Time Gross Settlement
Liquidity risk (and operational risk)
Liquidity as a common good
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Related literature
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Related literature
SimulationsKoponen-Soramaki (1998), Leinonen, ed. (2005, 2007)Work at BoE, BoFr, US Fed, BoC, BoFin, others.
Use actual payment data and investigate alternative scenarios:effect on payment delays, liquidity needs, and risks
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Related literature
SimulationsKoponen-Soramaki (1998), Leinonen, ed. (2005, 2007)Work at BoE, BoFr, US Fed, BoC, BoFin, others.
Use actual payment data and investigate alternative scenarios:effect on payment delays, liquidity needs, and risks
Game theoretic modelsAngelini (1998), Bech-Garrat (2003), McAndrews (2007)…
Investigate "liquidity management games" to analyze intraday liquidity management behavior of banks in a RTGS (and DNS) environment
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Model overview
RTGS á la UK CHAPS: banks choose an opening balance at the beginning of each day, used to settle payments during the day.
Banks face a random stream of payment orders, to be settled out of their liquidity.
Beside funding costs, banks (may) experience delay costs
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Model overview
RTGS á la UK CHAPS: banks choose an opening balance at the beginning of each day, used to settle payments during the day.
Banks face a random stream of payment orders, to be settled out of their liquidity.
Beside funding costs, banks (may) experience delay costs
Banks adapt their opening balances over time, learning from experience, until equilibrium is reached
We look at properties of equilibrium liquidity
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Model overview
We consider two scenarios:“normal conditions” and “operational failures”
RTGS á la UK CHAPS: banks choose an opening balance at the beginning of each day, used to settle payments during the day.
Banks face a random stream of payment orders, to be settled out of their liquidity.
Beside funding costs, banks (may) experience delay costs
Banks adapt their opening balances over time, learning from experience, until equilibrium is reached
We look at properties of equilibrium liquidity
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
else, the order is queued
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
if j has queued payments, the first one (say to k) is settled
else, the order is queued
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
if j has queued payments, the first one (say to k) is settled
if k has queued payments, the first one (to ...) is settled
else, the order is queued
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
if j has queued payments, the first one (say to k) is settled
if k has queued payments, the first one (to ...) is settled
... cascade ends when the recipient of the payment has no queued payments
else, the order is queued
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
if j has queued payments, the first one (say to k) is settled
if k has queued payments, the first one (to ...) is settled
... cascade ends when the recipient of the payment has no queued payments
else, the order is queued
the algorithm is run 30 million times, for different liquidity levels
k receives order to pay to z
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
i receives order to pay to i
if i has funds the order is settled : j receives funds
if j has queued payments, the first one (say to k) is settled
if k has queued payments, the first one (to ...) is settled
... cascade ends when the recipient of the payment has no queued payments
else, the order is queued
the algorithm is run 30 million times, for different liquidity levels
k receives order to pay to z
Payment orders arrive according to a Poisson process.Each bank equally likely as sender/ recipient complete symmetric network
time
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
• Distribution of others’ liquidity does not matter (much), only total level does
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
• Distribution of others’ liquidity does not matter (much), only total level does
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0 5 10 15 20 25 30 35 40 45 50
funds committed
de
lay
(0-1
) 0
1
5
10
50
committed by others
(avg)
funds committed by i
Delays
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Settlement algorithm
• Distribution of others’ liquidity does not matter (much), only total level does
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0 5 10 15 20 25 30 35 40 45 50
funds committed
de
lay
(0-1
) 0
1
5
10
50
committed by others
(avg)
funds committed by i
0
50
100
150
200
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff
0
1
5
10
50
committed by others
(avg)
Delays Costs
Cos
ts
funds committed by i
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
The liquidity game
• Costs minimized at different liquidity levels, depending on others’ funds
each bank plays a “two-player game“
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
The liquidity game
• Costs minimized at different liquidity levels, depending on others’ funds
each bank plays a “two-player game“
0
5
10
15
20
25
0 5 10 15 20 25 30 35 40 45 50
funds committed by others
be
st r
ep
ly
Best reply
if others post 1, I should post 24if others post 5, I should post 15if others post 50, I should post 10….
funds committed by others
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Learning the equilibrium
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Learning the equilibrium
Banks adapt actions over time,on the basis of experience (“Fictitious play”)up to equilibrium.
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Learning the equilibrium
Banks adapt actions over time,on the basis of experience (“Fictitious play”)up to equilibrium.
Property of Fictitious Play:
IF actions converge to a pure profile (or to a distribution)THEN that is a Nash equilibrium of the game
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Learning the equilibrium
Banks adapt actions over time,on the basis of experience (“Fictitious play”)up to equilibrium.
In our case, actions do converge
We show (analytically) that given cost parameters,all possible equilibria feature same average liquidity
So we can speak about “the equilibrium liquidity demand”
Property of Fictitious Play:
IF actions converge to a pure profile (or to a distribution)THEN that is a Nash equilibrium of the game
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Total costs
0
50
100
150
200
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff
0
1
5
10
50
committed by others
(avg)
0
50
100
150
200
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff
0
1
5
10
50
committed by others
(avg)
0
50
100
150
200
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff
0
1
5
10
50
committed by others
(avg)
price of delays = 1 price of delays = 2
price of delays = 5
0
50
100
150
200
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff
0
1
5
10
50
committed by others
(avg)
price of delays = 20
cost
, i
cost
, ico
st, i
cost
, i
funds committed by i funds committed by i
funds committed by i funds committed by i
funds committed by <j>
funds committed by others
funds committed by others
funds committed by others
funds committed by others
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Base case results (15 banks)
• Banks (naturally) use more liquidity when delay price is high
• At price parity, banks commit exactly 1 unit
• The amount used increases by 13-15 units per bank (200-230 for the system) for each 10-fold increase in the price of delays
• Banks will practically not commit over 49 units
price of delays
fun
ds
com
mit
ted
del
ays
funds committed by i
10-fold decrease for each ~20 units of liquidity
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
Efficiency
0
100
200
300
400
500
600
0.1 1 10 100
price of delays
ext
ern
al l
iqu
idity
• The outcome is not efficient
• Higher levels of liquidity would yield overall lower costs
0
100
200
300
400
500
600
700
0.1 1 10 100
price of delays
pa
yoffs
price of delays price of delays
liqu
idit
y
cost
s
orange = best non-equilibrium common action
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
n=2
n=5
n=15
n=50
0
0.05
0.1
0.15
0.2
0.1 1 10 100
price of delays
ne
ttin
g r
atio
System size, fixed turnover by bank
• Banks post more liquidity for a given payment volume, the more other banks there are in the network
• Due to higher variation in the time to receive your own funds back
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
System size, fixed total turnover
• Concentrated systems are more liquidity efficient
• Smaller number of banks -> higher value of payments per bank -> economies of scale
n=2n=5
n=15
n=50
0
0.2
0.4
0.6
0.8
1
0.1 1 10 100
price of delays
ne
ttin
g r
atio
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions0
50
100
0 5 10 15 20 25 30 35 40 45 50
funds committed
pa
yoff incident
normal
• One bank can receive, but cannotsend for first half of the day (liquidity sink)
• Delays of “non-incident” banksare increased
• More so, when liquidity is scarce
• We expect banks to choose inequilibrium a higher level of liquidity
– e.g. (with delay cost 4)– if others choose 14, in normal
circumstances I should choose 10, in case of an incident 14
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0 5 10 15 20 25 30 35 40 45 50
funds committed
incr
ea
se in
de
lay
(0-1
)
0
1
5
10
50
committed by others
(avg)
increase in delays
example of changed behaviorco
st, i
funds committed by i
funds committed by <j>
funds committed by i
incr
ease
in d
elay
s fo
r i (
0,1)
Operational incident 1
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
incident
normal
0
10
20
30
40
50
0.1 1 10 100 1000 10000
price of delays
ext
ern
al l
iqu
idity
Operational incident 2
• With low delay cost, only small difference• As delays get costlier, more liquidity is used• At extremely high delay cost, adding funds does not help
price of delays
fun
ds
com
mit
ted
by
i
1 Overview
2 Liquidity
3 Literature
4 Model
5 Algorithm
6 Algorithm II
7 The game
8 Learning
9 Total costs
10 Base case
11Social Optimum
12 Size I
13 Size II
14 Incident I
15 Incident II
16 Conclusions
• We developed a model with endogenous decisions by banks on their level of funding
• We investigated the game with more “realistic” costs from settlement than analytical game theoretic models
• The game collapses to “me vs. others” as only the aggregate behavior of others is relevant. The type of the game depends on model parameters (system size and delay cost)
• Equilibrium– not a social optimum– more participants, fewer payments par bank and higher delay costs
more liquidity
• Operational incident impact on liquidity holdings is ambiguous– payoffs are not improved in equilibrium
• Model being extended to account for alternative delay cost specifications, and heterogeneous banks -> policy purposes of Bank of England
Conclusions
