The Receipt Reactive Gross Settlement (RRGS) method was proposed by Jamie McAndrews in Johnson-McAndrews and Soramaki (2004) as a new, incentive compatible liquidity saving mechanism. The basic idea of RRGS is that banks are sure to use only incoming funds to settle their less urgent payments. Each bank has the incentive to submit payments to the RRGS queue as costly liquidity is consumed only when the bank receives funds from other banks.
This simulator allows simulations of one version of RRGS with historical payment data. It is easy to use and efficient, being able to simulate a day with half a million payments in less than 60 seconds. The fast speed of the simulations and quick set-up allows one to test many alternative scenarios easily.
Read the rest of the entry for instructions on downloading and using this application. You are welcome to get in touch with me for any questions.
Input files
Payment data file
The data must have the following fields in the following order: id, date, time, value, sender, receiver, priority. NOTE: payments must be ordered ascending by date and time. The file can contain multiple days of data. If the time field is shorter than the expected format, a leading zero is added to the beginning (e.g. to fix a time string 55959 to 055959 – one second to 6am). The priority must be 1 (high) or 2 (low). The field and decimal separators used in the file are defined in Input parameters.
Funds data file
The data must have the following fields in the following order: date, bank, balance. The ‘bank’ field must match the ’sender’ and ‘receiver’ fields in the payment data. It must be ordered by date. A balance is used for subsequent days until a new balance is defined in the file. The field and decimal separators used in the file are defined in Input parameters.
Input parameters
- ‘Payments file’: Select the file with the payment data
- ‘Funds file’: Select the file with the opening balances for each day.
- ‘Overdrafts file’: Select the file with overdraft limits per bank for each day. A value of e.g. 100 means that the balance of the bank can go up to -100.
- ‘Date format’: date format in both Payment data and Funds data files, see possible formats.
- ‘Time format’: time format used in ‘Payment data file’, see possible formats.
- ‘Opening time’: Opening time of the system. The simulator will throw an error in case payments before opening time are encountered. Format as given by ‘Time format’.
- ‘Closing time’: Closing time of the system. The simulator will throw an error in case payments after closing time are encountered. Format as given by ‘Time format’.
- ‘Do queue optimization’: Optimizes the RTGS queue (if ‘Settlement method’ = RTGS) and RRGS queue (if ‘Settlement method’ = RRGS).
- ‘Allow negative balance’: Allows balance in RTGS or RRGS to become negative.
- ‘Settlement method’: RTGS or RRGS, see above.
- ‘Splitting method’: ‘Threshold’ refers to value above which payments are split into equal sizes each under the given threshold value. ‘Liquidity’ method will split the original payment into two: one worth the available liquidity by the bank, and one worth the rest of the value. In both methods payments are split only if liquidity for settling them in whole is not available. In ‘liquidity’ method the liquidity available must also be above the minimum value given as a parameter.
- ‘Field separator’: field separator used in Payments and Rates files, usually ‘;’ or ‘,’
- ‘Decimal separator’: decimal separator used in Payments and Rates files, usually ‘,’ or ‘.’
- ‘Load parameters’ and ‘Save parameters’: loads/saves parameters onscreen from/to a file
Operation
1) Settlement by RTGS
In RTGS settlement a payment is settled immediately if there are sufficient funds. In case there are not sufficient funds to cover the payment, the payment is queued – and released immediately as sufficient funds become available from incoming payments. The RTGS balance is reduced by outgoing payments, and increased by incoming payments.
2) Settlement by RRGS
In RRGS payments marked with priority 1 are settled immediately, irrespective of available liquidity. Payments marked with priority 2 are settled by RRGS against the balance in RRGS. The RRGS balance is reduced by outgoing priority 2 payments, and increased by incoming priority 1 and priority 2 payments.
3) Queue optimization
The queue optimization is run at the defined intervals. Any payments submitted at that time are settled before the optimization is run. An optimization is run before end of day procedures are begun. Queue optimization can be used to optimize either the RTGS queue, or the RRGS queue. Optimization is done according to algorithm in Bech and Soramaki (2001).
4) Splitting
When a payment is split the elements to be queued are put in the queue before the payment that can be processes is settled. This way a chain of events can cause the immediate settlement of the queued parts as well. For details of splitting, see Leinonen and Soramaki (2001).
5) End of day procedures
In end of day procedures all pending payments are settled not taking into account any constraints.
Output
-out.txt contains statistics on all individual payments
- [the same fields as in the input data]
- ’settlement_time’: time the payment was settled
- ‘delay’: (in seconds)
- ’senderbalance’: balance of sending bank after settlement of payment
- ‘receiverbalance’: balance of receiving bank after settlement of payment
- ‘bilateralbalance’: bilateral balance from sender’s perspective (positive if received more than sent)
- ’settlement_method’: method by which the payment was settled: rrgs (immediately by RRGS), rtgs (immediately by RTGS), rrgs_queue (released from RRGS queue), rtgs_queue (released from RTGS queue), rrgs_opt (released by optimization algorithm from RRGS queue), rtgs_opt (released by optimization algorithm from RTGS queue), rtgs_eod (settled by end of day procedures from RTGS queue), rrgs_eod (settled in end of day procedures from RRGS queue)
-stat.txt contains statistics on each bank
- ‘day’: date
- ‘id’: bank id
- ‘value_as_recipient’: value of payments in input data where the bank is a receiver
- ‘number_as_recipient’: number of payments in input data where the bank is a receiver
- ‘value_as_sender’: value of payments in input data where the bank is a sender
- ‘number_as_sender’: number of payments in input data where the bank is a sender
- ‘number_submitted’: number of payments submitted for settlement
- ‘value_settled’: value of payments settled during the operation hours
- ‘number_settled’: number of payments settled during the operation hours. Due to split payments may be higher than number_submitted.
- ‘value_settled_eod’: value of payments settled in end of day procedures
- ‘number_settled_eod’: value of payments settled in end of day procedures. Due to split payments may be higher than number_submitted.
- ‘opening_balance’: balance at the beginning of the day
- ‘overdraft’: overdraft limit for the bank
- ‘minbalance’: minimum balance during the day (also including end-of-day procedures)
- ‘maxbalance’: maximum balance during the day (also including end-of-day procedures)
- ‘avgbalance’: average balance during the day
- ‘eod_balance’: end of -day balance
- ‘minbilateral’: minimum bilateral balance against across all other banks
- ‘maxbilateral’: maximum bilateral balance against across all other banks
- ‘avgsubmissiontime_received’: average submission time of payments received (unweighted)
- ‘avgsubmissiontime_sent’: average submission time of payments sent (unweighted)
- ‘avgsettletime_received’: average settlement time of payments received (unweighted)
- ‘avgsettletime_sent’: average settlement time of payments sent (unweighted)
- ‘avgsubmissiontime_received_weighted’: average submission time of payments received (weighted by value)
- ‘avgsubmissiontime_sent_weighted’: average submission time of payments sent (weighted by value)
- ‘avgsettletime_received_weighted’: average settlement time of payments received (weighted by value)
- ‘avgsettletime_sent_weighted’: average settlement time of payments sent (weighted by value)
- ‘avgdelay’: average delay for a delaying payments, sum of delays divided by the number of all payments. In seconds.
- ‘avgdelayweighted’: value weighed delay for a delaying payments, in seconds
- ‘maxqueuesize’: maximum number of queued payments at any given time
- ‘maxqueuevalue’: maximum value of queued payments at any given time
- ‘number_queued’: number of payments queued
- ‘value_queued’: value of payments queued
- ‘number_split’: number of payments split
- ‘generated_payments’: number of payments generated by splitting
Download, installation and running
Simply copy and extract this file (rrgssimulator1.3) to a folder that you create. Double click run.bat to launch the application. The package contains example files payments.txt, overdrafts.txt and funds.txt files (in the /data folder) and a parameters.txt file that you can load into the application and test the example data (change the paths to the correct files in the /data folder before starting the simulation).
Credits & Usage
I would like to thank John Jackson, Joanne McLafferty and Edward Denbee and Balazs Godeny for their contributions to specifying and implementing this application.
You are free to use the program for any purpose. The .zip file contains the source code as well. Please make a reference to this blog entry in case you use the application for any research.
(updated 29 October 2010 with version 1.3 of the software and updates to documentation)
Receipt reactive gross settlement simulator
The Receipt Reactive Gross Settlement (RRGS) method was proposed by Jamie McAndrews in Johnson-McAndrews and Soramaki (2004) as a new, incentive compatible liquidity saving mechanism. The basic idea of RRGS is that banks are sure to use only incoming funds to settle their less urgent payments. Each bank has the incentive to submit payments to the RRGS queue as costly liquidity is consumed only when the bank receives funds from other banks.
This simulator allows simulations of one version of RRGS with historical payment data. It is easy to use and efficient, being able to simulate a day with half a million payments in less than 60 seconds. The fast speed of the simulations and quick set-up allows one to test many alternative scenarios easily.
Read the rest of the entry for instructions on downloading and using this application. You are welcome to get in touch with me for any questions.
Input files
Payment data file
The data must have the following fields in the following order: id, date, time, value, sender, receiver, priority. NOTE: payments must be ordered ascending by date and time. The file can contain multiple days of data. If the time field is shorter than the expected format, a leading zero is added to the beginning (e.g. to fix a time string 55959 to 055959 – one second to 6am). The priority must be 1 (high) or 2 (low). The field and decimal separators used in the file are defined in Input parameters.
Funds data file
The data must have the following fields in the following order: date, bank, balance. The ‘bank’ field must match the ’sender’ and ‘receiver’ fields in the payment data. It must be ordered by date. A balance is used for subsequent days until a new balance is defined in the file. The field and decimal separators used in the file are defined in Input parameters.
Input parameters
Operation
1) Settlement by RTGS
In RTGS settlement a payment is settled immediately if there are sufficient funds. In case there are not sufficient funds to cover the payment, the payment is queued – and released immediately as sufficient funds become available from incoming payments. The RTGS balance is reduced by outgoing payments, and increased by incoming payments.
2) Settlement by RRGS
In RRGS payments marked with priority 1 are settled immediately, irrespective of available liquidity. Payments marked with priority 2 are settled by RRGS against the balance in RRGS. The RRGS balance is reduced by outgoing priority 2 payments, and increased by incoming priority 1 and priority 2 payments.
3) Queue optimization
The queue optimization is run at the defined intervals. Any payments submitted at that time are settled before the optimization is run. An optimization is run before end of day procedures are begun. Queue optimization can be used to optimize either the RTGS queue, or the RRGS queue. Optimization is done according to algorithm in Bech and Soramaki (2001).
4) Splitting
When a payment is split the elements to be queued are put in the queue before the payment that can be processes is settled. This way a chain of events can cause the immediate settlement of the queued parts as well. For details of splitting, see Leinonen and Soramaki (2001).
5) End of day procedures
In end of day procedures all pending payments are settled not taking into account any constraints.
Output
-out.txt contains statistics on all individual payments
-stat.txt contains statistics on each bank
Download, installation and running
Simply copy and extract this file (rrgssimulator1.3) to a folder that you create. Double click run.bat to launch the application. The package contains example files payments.txt, overdrafts.txt and funds.txt files (in the /data folder) and a parameters.txt file that you can load into the application and test the example data (change the paths to the correct files in the /data folder before starting the simulation).
Credits & Usage
I would like to thank John Jackson, Joanne McLafferty and Edward Denbee and Balazs Godeny for their contributions to specifying and implementing this application.
You are free to use the program for any purpose. The .zip file contains the source code as well. Please make a reference to this blog entry in case you use the application for any research.
(updated 29 October 2010 with version 1.3 of the software and updates to documentation)