ASI Workshop Simultaneous Multilateral Settlement Procedure 5

1
ASI WorkshopSimultaneous Multilateral
SettlementProcedure 5

Paris 8th 9th March 2006
2
Content

• Objective of the business scenario
• Optional connected mechanisms
• Successful business scenario
• Failure of the business scenario
• 4.1 Failure of the business scenario
  (Disagreement)
• 4.2 Failure of the business scenario
  (Insufficient Liquidity no guarantee mechanism)
• 4.3 Failure of the business scenario
  (Insufficient Liquidity with guarantee
  mechanism procedure 4 successful)
• 4.4 Failure of the business scenario
  (Insufficient Liquidity with guarantee
  mechanism - procedure 4 failed)
• Filling of important fields of the messages
  exchanged
• Mapping of fields among different messages

3
1. Aim of the business scenario

• An AS can settle multilateral balances (dependent
  debits and credits) on PM accounts through the
  ASI in a batch mode
• Works on an all or nothing basis settlement
  only if all needed funds are blocked, otherwise
• New attempts of settlement will be made till the
  end of the settlement period has been reached
• Afterwards the entire cycle will be rejected
• AS balances are presented to the PM for
  settlement at an entry time which is the latest
  of the following two instances
• As soon as they are received through the ASI
• The end of the information period if such a
  period was specified and no disagreement was
  received

4
1. Aim of the business scenario (2)

• The settlement of debits and credits can benefit
  from the optimisation mechanism with a specific
  algorithm (the algorithm 4) triggered by the ASI
• Starts when settlement period of procedure 5 of
  an AS is reached
• If algorithm 1,2 or 3 is still running algorithm
  4 is waiting until they finish
• Settlement process
• All pending payments (highly urgent, urgent,
  normal) are considered
• If not all debits are covered with liquidity
  participant with largest debit position is
  selected, his payments are removed until covered
  position is reached
• If the selected payment is an AS payment all
  payments of the respective AS are removed

5
1. Aim of the business scenario (3)

• Algorithm runs until
• All debits covered or
• Time maximum reached or
• No further AS payments in settlement process
  included
• After algorithm 4 ends payment algorithms 1-3
  will run, so liquidity status of the participants
  can change
• There can be several algorithm 4 runs within one
  settlement period

6
2. Optional connected mechanisms

• Information period
• Balances in the AS are pre-announced to collect
  the needed liquidity
• The Settlement Banks may express disagreement
  within the information period to avoid the
  settlement of erroneous balances

7
2. Optional connected mechanisms (2)

• Settlement period ("till")
• Limited period of time allocated to the
  settlement by the AS, so as not to prevent or
  postpone the settlement of other operations.
• If the whole set of transactions is not settled
  at the end of this period
• Either the whole set is rejected or
• If applicable, a guarantee fund mechanism is
  activated
• AS can modify (anticipate or postpone) the end of
  the settlement period before it has expired

8
2. Optional connected mechanisms (3)

• Guarantee mechanism
• Could be used to provide the needed liquidity, if
• A settlement failure is notified to AS and
• The end of settlement period is reached
• Mechanism is based on a guarantee account where
  the liquidity is collected to support the AS
  settlement procedure
• Either continuously (pre-funding) or
• Arranged shortly before
• If guarantee mechanism envisaged and time limit
  for settlement exceeded
• ASI re-enters debits as settlement procedure4
• If this fails guarantee mechanism starts

9
3. Successful business scenario
AS
Monitoring via ICM
Info All transactions settled
4
ASTransferInitiation
1
ASInitiationStatus
SSP
Information Period
Settlement Period
Successful optimisation
ICM Broadcast
MT 900/910
2
3
SBs
Monitoring via ICM
10
4.1 Failure of the business scenario Case 1
Disagreement
AS
3b
Monitoring via ICM
6
1
Info All transactions failed
ASTransferInitiation
ASInitiationStatus
5
ICM Broadcast
Disagreement
Managing CB
3b
ICM
SSP
Information Period
Revocation of file
4
2
ICM Broadcast
5
ICM Broadcast
3a
Disagreement
SBs
Monitoring via ICM
11
4.2 Failure of the business scenario Case 2
Insufficient liquidity (no guarantee fund
mechanism envisaged)
AS
Monitoring via ICM
Info All transactions failed
5
ASInitiationStatus
ASTransferInitiation
1
SSP
Information Period
Settlement Period
Optimisation failed
Optimisation failed
Optimisation failed
ICM Broadcast (info on failed transaction)
ICM Broadcast
ICM Broadcast (info on queued transaction)
2
3
4
SBs
Monitoring via ICM
12
4.3 Failure of the business scenario Case 3
Insufficient liquidity (guarantee mechanism
envisaged version 1)
AS
Monitoring via ICM
1
Info All transactions settled
ASInitiationStatus
ASTransferInitiation
5
SSP
Information Period
Settlement Period
Settlement as procedure 4
Optimisation failed
Optimisation failed
ICM Broadcast
ICM Broadcast (info on queued transaction)
MT 910
MT 900
2
3
5
4
SBs
Monitoring via ICM
13
4.4 Failure of the business scenario Case 4
Insufficient liquidity (guarantee mechanism
envisaged version 2 settlement procedure 4
fails)
AS
Monitoring via ICM
1
ASInitiationStatus (info on missing liquidity)
MT 900 (debit of guarantee account)
ASTransferInitiation
ASInitiationStatus
Direct debit or mandated payment
11
receipt
7a
6
9
8
SSP
Settlement P4 failed
Information Period
Settlement Period
Collection of liquidity
Settlement attempt
Optimisation failed
ICM Broadcast
ICM Broadcast (info on queued transaction)
ICM Broadcast (info on queued transaction)
Credit transfer
MT 900
2
3
7b
10
4
5
MT 910
SBs
Monitoring via ICM
14
5. Filling of important fields of
ASTransferInitiation
ASTransferInitiation
15
6. Mapping of fields among different messages