Compenser n'est pas économiser : ce qu'un simulateur ouvert montre sur la liquidité des paiements instantanés

Dans le Pix, le système de paiements instantanés du Brésil, chaque paiement est réglé seul, immédiatement. Pour cela, la banque qui paie doit disposer d'un solde à la banque centrale avant chaque virement, à toute heure du jour ou de la nuit. Dans les systèmes plus anciens, les banques accumulaient les paiements et compensaient les entrées avec les sorties, le netting, et avaient besoin de beaucoup moins d'argent immobilisé.

Une étude de la Banque centrale du Brésil elle-même (Working Paper 619) a montré qu'avec le Pix les banques ont perdu cette capacité de différer et de compenser, et qu'elles détiennent désormais plus d'actifs liquides. Si l'on regarde les chiffres d'une journée quelconque, presque tout semble compensable : ce qu'une banque paie ressemble à ce qu'elle reçoit. D'où une idée séduisante : retenir les paiements quelques secondes, trouver ceux qui forment un cycle (A paie B, B paie C, C paie A) et régler le cycle d'un seul coup. Le client ne s'en aperçoit presque pas et la banque économise de la liquidité.

J'ai voulu mesurer combien de cette idée se transforme en argent réel. J'ai donc construit LoopSettle, un simulateur ouvert de la liquidité dans les paiements instantanés. Cet article présente ce qu'il a montré, y compris la partie qui a renversé ma propre hypothèse.

Ce que j'ai construit

LoopSettle génère une journée synthétique de paiements entre 200 établissements (grandes et moyennes banques, fintechs et établissements de paiement), calibrée sur les données ouvertes du Pix publiées par la Banque centrale du Brésil : volume, montant moyen, concentration par participant et profil de chaque heure de la journée. Il règle ensuite le même flux selon plusieurs architectures de système et compare l'argent que chacune exige :

• règlement brut en temps réel, comme le Pix ;
• compensation différée, de toutes les 10 secondes à une fois par jour ;
• micro-cycles atomiques : à chaque fenêtre courte, le moteur cherche des cycles dans la file d'attente et règle chaque cycle en entier ou pas du tout, avec une attente maximale par paiement.

Le cœur est écrit en Rust et fonctionne en flux (un million de paiements occupent quelques mégaoctets de mémoire). Il se compile aussi en WebAssembly : une interface fonctionne entièrement dans le navigateur. Tout a été conçu pour tenir sur un ordinateur portable doté d'un processeur i3 de 4e génération et de 4 Go de RAM.

Je n'utilise que des données publiques et synthétiques. LoopSettle est un projet indépendant, sans lien avec la Banque centrale du Brésil et sans son approbation ; Pix est une marque de la BCB.

Le résultat : compenser n'est pas économiser

Avec le scénario calibré, 10 graines aléatoires et de 1 à 30 millions de paiements par jour :

• selon la mesure « potentielle », qui compare les entrées et les sorties de la journée sans regarder l'ordre dans le temps, 85 % du volume semble compensable ;
• les micro-cycles d'au plus 10 secondes règlent jusqu'à 63 % de la valeur à l'intérieur de cycles, mais économisent environ 0,01 % de la liquidité (0,0116 %, avec un intervalle de confiance à 95 % de 0,008 % à 0,015 %) ;
• compenser une fois par jour économise davantage, mais ce gain diminue quand le volume augmente. Avec 30 millions de paiements par jour et une structure entre banques ajustée aux données réelles du WP 619, il se situe entre 0,2 % et 2,8 %, selon l'écart entre les horaires des banques.

Autrement dit, le volume compensable et la liquidité économisée sont deux choses différentes, et l'écart entre les deux est énorme.

Pourquoi le compte n'y est pas : le plafond

La liquidité dont une banque a besoin est fixée par le pire moment de sa journée : celui où elle a payé beaucoup plus qu'elle n'a reçu. Un mécanisme qui retient chaque paiement au plus d secondes ne peut agir que sur les paiements arrivés dans les d secondes précédant ce pic. Tout ce qui est arrivé avant est déjà réglé et ne revient pas.

On en tire un plafond valable pour n'importe quel algorithme, aussi habile soit-il : l'économie de chaque banque est au plus la valeur qu'elle a payée dans les d secondes précédant son pire moment. Dans le scénario calibré, avec 10 secondes, ce plafond reste sous 1 % de la liquidité dans toutes les configurations testées, et ce que les micro-cycles obtiennent réellement en est une fraction faible et stable, de 3 % à 5 %. Le plafond répond à l'objection la plus fréquente (« un meilleur algorithme économiserait peut-être davantage ») : non, car la limite ne dépend pas de l'algorithme.

Là où l'idée fonctionne

Le même plafond explique pourquoi réordonner les paiements est payant dans les systèmes de montant élevé, où les paiements sont peu nombreux et très importants. Le travail le plus proche de LoopSettle, de McMahon et coauteurs avec la Banque du Canada, a utilisé des données réelles du système canadien de paiements de montant élevé : réordonner des lots de 70 paiements, avec environ 90 secondes d'attente, a permis d'économiser en moyenne 240 millions de dollars canadiens par jour par rapport à l'ordre d'arrivée. Selon mon propre calcul, cela représente de l'ordre de 1 % à 2 % de la liquidité que les banques allouent. Dans LoopSettle, un scénario stylisé de montant élevé a un plafond de 13,7 % à 10 secondes, contre 0,76 % pour les paiements de détail. La différence tient à la forme du flux, pas à l'algorithme.

La contrainte qui compte est le week-end

Le compte que les banques utilisent pour le Pix ne peut être alimenté que lorsque le système de réserves est ouvert, les jours ouvrables de 6 h 30 à 18 h 30. Les banques doivent donc mettre de l'argent de côté pour les nuits et pour les 59,5 heures du week-end. Dans le simulateur, cette réserve représente environ 2,7 fois le pic d'un jour ouvrable. Même là, tout compenser à la fin du week-end n'économiserait que 0,4 % à 1,0 %. Le besoin vient des soldes qui s'accumulent dans un seul sens, pas de l'argent qui tourne en boucle.

Ce que l'étude ne dit pas

• Les données sont synthétiques, calibrées sur des agrégats publics. Qui paie qui, en détail, n'est pas public et reste la principale hypothèse du modèle.
• L'échelle est réduite : chaque paiement simulé tient lieu d'environ 239 paiements réels. Les proportions sont le résultat ; les valeurs absolues ne s'appliquent pas au Pix réel.
• La question qui reste (0,2 % ou 2,8 %) ne peut être tranchée qu'avec des données par participant au fil de la journée, que seule la banque centrale possède.

Ce que j'ai appris en tant qu'ingénieur

Je travaille dans la qualité logicielle, et le projet a été construit comme j'aimerais qu'un système financier soit testé :

• Les invariants d'abord. Huit règles qui ne doivent jamais être enfreintes, comme « la masse monétaire totale ne change pas », « aucun solde ne devient négatif » et « un cycle est réglé en entier ou pas du tout », sont vérifiées par des tests fondés sur les propriétés, avec des milliers de cas aléatoires à chaque exécution.
• Reproductibilité totale. Chaque chiffre provient d'une commande avec une graine fixe et se reproduit à l'octet près ; la version du code est enregistrée avec le résultat.
• Critères d'abandon écrits à l'avance. Avant les tests de robustesse, j'ai noté ce qui ferait tomber le résultat. L'un d'eux a fait tomber mon titre préféré : la première version affirmait que le potentiel était 630 fois supérieur à l'économie réalisable, mais ce potentiel diminue avec le volume. Le titre a disparu, et le résultat restant est plus solide parce qu'il a survécu.

Essayez-le sur vos données

Quiconque dispose de fichiers de paiements (une banque, une fintech, une banque centrale) peut exécuter LoopSettle sans que les données quittent la machine : le fichier est lu en flux et la sortie ne contient que des agrégats. La commande loopsettle bound paiements.csv calcule la liquidité nécessaire et le plafond d'économie pour chaque temps d'attente.

Le code est ouvert (Apache-2.0), avec une documentation en anglais et en portugais, un guide d'installation pas à pas et tous les résultats. La prochaine étape est l'article scientifique. Les critiques, et les données pour tester le plafond, sont les bienvenues.

• Le dépôt de LoopSettle sur GitHub
• Résumé de tous les résultats (en anglais)
• Ce que l'étude peut ou ne peut pas affirmer (en anglais)