# Presentation: 189610

## Congestion and Cascades in Payment Systems

- Walt Beyeler1
- Kimmo Soramäki2
- Morten L. Bech3
- Robert J. Glass1
- 1Sandia National Laboratories
- 2European Central Bank
- 3Federal Reserve Bank of New York

*PAYMENT AND SETTLEMENT SIMULATION SEMINAR AND WORKSHOP*
*Helsinki                August 2006*

- The views expressed in this presentation are those of the authors and do not necessarily reflect those of the Federal Reserve Bank of New York or the Federal Reserve System

## Physics of Payment Systems

- Purpose of “complexity” models
- Understand how interactions among many agents can generate system-level behavior
- Understand regimes of behavior and what governs transitions among them
*Models are accordingly abstract and usually very simple because accurate simulation of a specific system or situation is not the goal*
- Payment systems as complex systems
- Understand how liquidity controls congestion
- Characterize congested state
- Understand how liquidity markets relieve congestion

## Payment Physics Model

**Bank i**

**Bank i**

**Payment system**

**2***** Depositor account is debited***

- Liquidity
- Market

- Central bank

**Notes:**
We’ve decided to begin simply, adding features and processes once we understand how the system works without them.  This model was developed in the spirit of SOC models, which try to understand how a collection of agents, following simple rules that respond to local stresses, produce a system that has interesting properties, such as fat-tailed distributions.  The art is to capture the critical agent processes as simply as possible.

Banks form the network nodes, and payment relationships among banks define the network links.  Here we depict the processes that control the states of two nodes I and J connected by a payment link.

Real-world bank’s decisions can include many factors (we are studying this in a more complex model).  Here they only consider balance, and they pay if possible.  They are reflexively cooperative, and so any loss of coordination we see is only a result of liquidity shortages (the first factor Morten discussed) and not to hoarding.  

Payments allow receiving banks to send a queued payment: processing becomes coupled when liquidity is scarce.

In the “primitive” system banks must wait for incoming payments to fund their operations.  This is unpredictable and inefficient.  Real systems include other procedures for managing this scarce resource.  Here we include a liquidity market that creates a second set of pathways for banks to share liquidity.  This is a simple linear diffusion process in which excess funds flow into the market from some banks and out of the market to others.

Talk about deposit dependence

## Instruction Arrival

- Each bank has a given level of customer deposits (Di)
- Each unit of deposits has the same probability of being transformed into a payment instruction
- 	where λi is the initial rate
- When a bank receives a payment its deposits increase
- 	-> the instruction arrival rate increases
- When a bank sends a payment its deposits decrease
- 	-> the instruction arrival rate decreases

## Influence of Liquidity

- Payment
- System

- When liquidity is high payments are submitted promptly and banks process payments independently of each other

- Instructions

- Payments

- Summed over the network, instructions arrive at a steady rate

- Liquidity

**Notes:**
Here we look at aggregate behavior of the system: input (total instructions) and output (total payments) in intervals

Banks see independent random instruction streams.  Adding over all banks produces a fairly uniform stress

High-liquidity output closely tracks input; easier to see on scatter plot because variations are small

Lowering liquidity couples processing across banks.  Payments loose correlation with input because their timing becomes determined by internal dynamics of the system.
NOTE: we would see increasing correlation of payment activity between neighboring banks as correlation with instructions declines.  This is akin to reaction function.

## Influence of Liquidity

- Reducing liquidity leads to episodes of congestion when queues build, and cascades of settlement activity when incoming payments allow banks to work off queues. Payment processing becomes coupled across the network

- Payment
- System

- Instructions

- Payments

- 1

- 1

- Liquidity

**Notes:**
Here we look at aggregate behavior of the system: input (total instructions) and output (total payments) in intervals

Banks see independent random instruction streams.  Adding over all banks produces a fairly uniform stress

High-liquidity output closely tracks input; easier to see on scatter plot because variations are small

Lowering liquidity couples processing across banks.  Payments loose correlation with input because their timing becomes determined by internal dynamics of the system.
NOTE: we would see increasing correlation of payment activity between neighboring banks as correlation with instructions declines.  This is akin to reaction function.

## Influence of Liquidity

- Payment
- System

- Instructions

- Payments

- At very low liquidity payments are controlled by internal dynamics.  Settlement cascades are larger and can pass through the same bank numerous times

- Liquidity

- 1

- 1

**Notes:**
Here we look at aggregate behavior of the system: input (total instructions) and output (total payments) in intervals

Banks see independent random instruction streams.  Adding over all banks produces a fairly uniform stress

High-liquidity output closely tracks input; easier to see on scatter plot because variations are small

Lowering liquidity couples processing across banks.  Payments loose correlation with input because their timing becomes determined by internal dynamics of the system.
NOTE: we would see increasing correlation of payment activity between neighboring banks as correlation with instructions declines.  This is akin to reaction function.

## Influence of Market

- Payment
- System

- Instructions

- Payments

- A liquidity market substantially reduces congestion using only a small fraction (e.g. 2%) of payment-driven flow

- Liquidity
- Market

**Notes:**
Here we look at aggregate behavior of the system: input (total instructions) and output (total payments) in intervals

Banks see independent random instruction streams.  Adding over all banks produces a fairly uniform stress

High-liquidity output closely tracks input; easier to see on scatter plot because variations are small

Lowering liquidity couples processing across banks.  Payments loose correlation with input because their timing becomes determined by internal dynamics of the system.
NOTE: we would see increasing correlation of payment activity between neighboring banks as correlation with instructions declines.  This is akin to reaction function.

## Liquidity and Markets Influence Congestion

**Notes:**
What does this mean?  Scaling relationship is independent of market conductance.  Small inset with linear scale

## Influence of Return Time on Congestion

- Amount of deposits determines the variability of a bank’s net position

## What determines transition?

- Three key time constants
- Time over which a bank is in surplus or deficit (d0)
- Time to deplete initial liquidity (L)
- Time for the market to redistribute liquidity (1/c)

**Market redistribution time**

**Liquidity depletion time**

**Net Position return time**

**Liquidity depletion time**

**Uncongested**

**Uncongested**

**Congested**

**Congested**

**Notes:**
Green is good, red is bad

## What we’re learned

- System performance can be greatly improved by moving small amounts of liquidity to the places where it’s needed
- System congestion seems to be determined by the relative values of three time constants
- Liquidity depletion time
- Net position return time
- Liquidity redistribution time through the market
*What about disruptions?* ...