RDP 2012-06: The Impact of Payment System Design on Tiering Incentives Appendix A: Sub-limits and Bilateral Offsetting

We use bilateral limits in the simulator to replicate RITS's sub-limits feature. This involves modifying the simulator's entry and queuing sub-algorithms so that they conduct the appropriate settlement tests (e.g. test priority payments against a participant's entire settlement account balance, and test active payments against a participant's account balance in excess of its sub-limits). However, data limitations mean that we are unable to pinpoint when a queued payment's status is changed by the sending participant; we only know the status of the payment upon submission to the RITS queue, and the status of the payment when it is settled in RITS. Input to the simulator requires payments to have a single status, which remains unchanged during queuing, thus we need to modify our underlying transaction data. Table A1 summarises the approach.

Payments that were submitted to RITS as deferred are submitted to the simulator at the time that they were settled in RITS. This change is based on the assumption that the sender of a deferred payment did not intend for the payment to settle upon its submission, but rather intended to change the status of the payment at a later time. (We assume that the actual settlement time in RITS is a better approximation of this time than the time of submission.) Payments that were submitted as active but later settled as priority also have their submission time to the simulator changed to their actual settlement time in RITS. A number of participants in RITS have been observed to manage liquidity by setting very high sub-limits, submitting payments to the queue as active, and subsequently changing a payment's status to priority when they want it to be settled. Therefore, again we assume in these cases that actual settlement time in RITS is a better approximation of the time at which the sending participant wished settlement to occur.

We also design a bilateral-offset sub-algorithm for the simulator that seeks to replicate RITS's own bilateral-offset algorithm. In RITS, payments which are queued for over a minute are tested for bilateral offset with up to 10 payments due from the receiving participant on a next-down looping basis.^[19] By contrast, the BOBASIC bilateral-offset sub-algorithm provided with the simulator only tries to offset all queued payments between the counterparties to the first queued transaction, iteratively removing the last queued transaction between these counterparties to find a combination of offsetting transactions that it can settle simultaneously.

Footnote

We have not incorporated the minute delay feature of RITS's bilateral-offset feature into our sub-algorithm, and this is not expected to affect our results significantly. [19]