Title: ASI Workshop Simultaneous Multilateral Settlement Procedure 5
1ASI WorkshopSimultaneous Multilateral
SettlementProcedure 5
Paris 8th 9th March 2006
2Content
- 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
31. 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
41. 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
51. 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
62. 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
72. 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
82. 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
93. 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
104.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
114.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
124.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
134.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
145. Filling of important fields of
ASTransferInitiation
ASTransferInitiation
156. Mapping of fields among different messages