How much liquidity would a liquidity-saving mechanism save if a liquidity-saving mechanism could save liquidity? A simulation approach for Canada's large-value payment system Shaun Byck
Bibliographic record
Abstract
Canadas Large Value Transfer System (LVTS) is in the process of being replaced by a real-time gross settlement (RTGS) system. A pure RTGS system typically requires participants to hold large amounts of intraday liquidity in order to settle their payment obligations. Implementing one or more liquidity-saving mechanisms (LSMs) can reduce the amount of liquidity participants need to hold. This paper investigates how much liquidity requirements can be reduced with the implementation of different LSMs in the Financial Network Analytics simulation engine using LVTS transaction data from 2018. These LSMs include: 1) Bilateral offsetting, 2) FIFO-Bypass, 3) Multilateral offsetting, and 4) a combination of all LSMs. We simulate two different scenarios. In the first scenario, all payments from Tranche 1, which are considered time-critical, are settled in a pure RTGS payment stream, while less time-critical Tranche 2 payments are settled in a payment stream with LSMs. In the second scenario, we settle all payments (Tranches 1 and 2) in the LSM stream. Our results show that when there is ample liquidity available in the system, there is minimal benefit from LSMs as payments are settled without much delay†the effectiveness of LSMs increases as the amount of intraday liquidity decreases. A combination of LSMs shows a reduction in liquidity requirements that is larger than any one individual LSM.Â
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.004 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.004 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".