Les pilotes d'interopérabilité de la BCE font état d'hypothèses ajustées sur la mobilisation des garanties (collateral) pour les fenêtres overnight. Les estimations existantes sur la liquidité TARGET2 le week-end demeurent provisoires.
1. TARGET2, TIPS & la Pile Core RT1
L'infrastructure de règlement de l'Eurosystème repose sur un système à plusieurs niveaux conçu pour les paiements de gros de grande valeur et la compensation instantanée de détail. Au centre se trouve TARGET2 (T2), le système de règlement brut en temps réel (RTGS) qui traite les transactions en monnaie de banque centrale (CeBM) sans risque. TARGET2 fonctionne sur des horaires stricts et ferme les week-ends et jours fériés, créant un décalage opérationnel structurel avec les cycles 24/7/365 des marchés financiers décentralisés.
Pour répondre aux besoins de règlement en temps réel des transactions de détail, TIPS (TARGET Instant Payment Settlement) fonctionne en continu 24/7/365 sur des comptes de banque centrale. Bien que TIPS garantisse une finalité instantanée en CeBM, il est architecturalement limité par des plafonds de transaction (standardisés à 100 000 €) et est optimisé pour les volumes élevés de transactions de détail plutôt que pour les règlements interbancaires complexes et de gros montants.
En parallèle, RT1 (géré par EBA Clearing) propose une alternative de compensation en monnaie de banque commerciale (CoBM). Fonctionnant selon les règles SEPA Instant Credit Transfer, RT1 impose à ses participants de bloquer des liquidités auprès de l'Eurosystème pour garantir la finalité du règlement net, ce qui introduit des risques de crédit et de complexité opérationnelle supplémentaires.
2. La Solution de Déclenchement (Trigger Solution) de la BCE
Pour combler le fossé entre les actifs natifs des registres DLT (comme les obligations tokenisées) et la monnaie de banque centrale sans avoir à émettre une wCBDC (MNBC de gros) native sur des blockchains privées, la Deutsche Bundesbank a introduit la Solution Trigger. Adoptée par l'Eurosystème pour ses expérimentations de gros, cette passerelle d'interopérabilité relie les réseaux DLT aux systèmes RTGS existants via une API.
La Solution Trigger n'émet pas de monnaie de banque centrale directement sur la DLT. Au lieu de cela, lors d'une transaction sur le réseau DLT (ex. transfert d'obligation de la BEI), le smart contract bloque l'actif et émet un événement. L'Oracle Trigger intercepte cet événement, le traduit en message ISO 20022 et le transmet à TARGET2. T2 exécute le règlement en espèces (débit du compte de l'acheteur et crédit du vendeur). Une fois le règlement finalisé, T2 envoie une confirmation à l'oracle, qui déclenche la libération et le transfert de l'obligation sur la DLT.
Cette approche évite les questions juridiques complexes liées au statut de dépositaire de la monnaie de banque centrale sur les registres décentralisés. Cependant, elle dépend fortement de la sécurité de l'oracle, introduit une latence potentielle liée aux APIs, et ne permet pas nativement de supporter des contrats intelligents complexes (comme des pools de liquidité multi-parties on-chain) puisque la liquidité cash reste isolée dans une base de données centralisée.
3. API Trigger BCE / Flux de Travail DvP TARGET2
Le schéma ci-dessous détaille le flux technique étape par étape de la Solution Trigger de la BCE, reliant une transaction d'actif DLT (par exemple, des émissions d'obligations numériques de la Banque Européenne d'Investissement sur HSBC Orion ou Canton Network) avec un règlement en espèces sur TARGET2.
4. L'hypothèse du Unified Ledger (BRI)
La Banque des Règlements Internationaux (BRI) a proposé un cadre conceptuel alternatif : l'hypothèse du Unified Ledger. Dans ce modèle conceptuel, la monnaie de banque centrale de gros (wCBDC), les dépôts tokenisés des banques commerciales et les actifs réels tokenisés (RWAs) coexistent sur une même plateforme de base de données partagée et programmable.
L'hypothèse du Unified Ledger élimine la latence de traduction et les risques de sécurité inhérents aux modèles de trigger/oracles. Puisque la monnaie et les actifs partagent le même registre, le règlement atomique est natif. Cela permet la mise en place de structures financières sophistiquées—telles que des séquestres programmables, des appels de marge de garantie dynamiques et des compensations multi-parties automatisées—sans exposer les participants à des délais de règlement ou à des failles de ponts DLT.
Cependant, l'hypothèse du Unified Ledger se heurte à des défis politiques et d'infrastructure majeurs. Elle exige que les banques commerciales et les banques centrales s'intègrent dans un registre commun multi-tenants, soulevant des questions de souveraineté nationale, de gouvernance du système et d'indépendance opérationnelle des institutions commerciales.
5. Matrice Comparative des Rails de Règlement
Comparaison technique détaillée des trois modèles de cash tokenisé ou de règlement interbancaire disponibles pour les acteurs financiers institutionnels. Les écarts opérationnels et réglementaires asymétriques reflètent l'état réel de structuration du marché.
| Dimension | Monnaie de Banque Centrale (Trigger BCE / wCBDC) | Cash Commercial Tokenisé (JPM Coin / Fnality) | Stablecoins de G-SIB (USDC / PYUSD) |
|---|---|---|---|
| Actif de règlement & Risque de crédit | CeBM sans risque Passif direct de l'Eurosystème. Risque de crédit et de liquidité nul. | Monnaie de Banque Commerciale (CoBM) Exposé au risque de crédit de l'émetteur (JPM) ou garanti par des comptes de réserve à la banque centrale (Fnality). | Passif de Réserve Non Noté Exposé au risque de crédit du dépositaire des réserves et à la liquidité des Bons du Trésor. Risque de Réserve |
| Vitesse de règlement & Caractère définitif | LcP Atomique (T+0) Règlement définitif instantané dès validation TARGET2. Protection légale absolue. | Temps Réel Intra-Réseau Règlement atomique au sein du registre fermé. Le caractère définitif dépend des accords de réseau. | Vitesse liée au Protocole Dépend du temps de validation de la blockchain (ex. Ethereum vs Solana). Statut légal non unifié. |
| Fenêtre de règlement & Heures d'ouverture | Restreint (Heures TARGET2) Fermé les week-ends et jours fériés. Traitements nocturnes limités. Friction Week-end | Continu 24/7/365 Actif en continu au sein du registre DLT privé propriétaire. Rails 24/7 | Continu 24/7/365 Disponibilité des blockchains publiques. Soumis aux variations des frais de gaz du réseau. Rails 24/7 |
| Accessibilité Systémique | Très Restreinte Limité aux institutions financières éligibles aux opérations de politique monétaire de l'Eurosystème. | Accès par Niveaux Réservé aux clients de l'émetteur ou aux membres institutionnels autorisés. | Sans Permission / Global Accessible à tout détenteur de clé privée, sous réserve des dispositifs de listes noires. |
| Gouvernance Réglementaire | Contrôle Direct Eurosystème Régulé sous mandat public et soumis aux contraintes de capital de Bâle III. | Régulation Bancaire Supervisé par les autorités bancaires de tutelle (ex. BCE, OCC). | Régulation MiCA / État Soumis à MiCA (régime EMT) dans l'UE ou aux régimes d'émetteurs de stablecoins locaux. |
6. Liquidité Intrajournalière & Implications HQLA
L'intégration de réseaux DLT fonctionnant 24/7/365 avec des systèmes RTGS classiques comme TARGET2 (fermé le week-end) provoque une **fragmentation de la liquidité** et une **friction de transition**.
Lorsqu'un actif DLT est échangé le samedi, le règlement espèces en monnaie de banque centrale ne peut être finalisé via TARGET2 que le lundi matin suivant. Pour assurer un règlement LcP (DvP) continu durant ces périodes, les banques doivent choisir entre deux approches sous-optimales :
- Le Pré-financement : Mobilisation et blocage de liquidités cash sur des comptes RTGS spécifiques avant la fermeture du week-end, réduisant l'allocation optimale des ressources.
- La Collatéralisation HQLA : Mise en gage d'actifs liquides de haute qualité (HQLA) comme des obligations souveraines pour obtenir des lignes de crédit intrajournalières auprès de la banque centrale, ce qui immobilise les garanties.
Ce blocage de liquidité diminue la vélocité globale du capital et engendre un coût d'opportunité significatif pour le trading institutionnel en continu. Tant que les banques centrales ne fourniront pas de wCBDC rémunérée et active 24/7/365, la vélocité de la liquidité restera bridée.
7. Contraintes Opérationnelles & Structurelles
Le déploiement de structures de monnaie souveraine numérique introduit des compromis fondamentaux entre sécurité des systèmes, conformité réglementaire et adoption.
A. Confidentialité vs. Conformité (RGPD & ZKPs)
Les règlements de gros sur des registres partagés doivent garantir une stricte confidentialité pour protéger les stratégies de trading et respecter le secret bancaire (RGPD). Cependant, les autorités exigent une traçabilité pour lutter contre le blanchiment d'argent (LCB-FT). L'utilisation de preuves à divulgation nulle de connaissance (ZKPs) est étudiée pour masquer les montants et les contreparties tout en prouvant cryptographiquement la conformité. Cependant, ces techniques imposent une charge de calcul élevée et une latence incompatible avec les cadences requises pour un RTGS.
B. Défis du Règlement Hors Ligne
Pour le volet de détail, l'euro numérique doit fonctionner sans connexion réseau (pannes de courant, zones blanches). Cela nécessite l'utilisation de composants physiques sécurisés (puces HSM ou enclaves sécurisées sur mobile) capables de valider et d'enregistrer localement les transactions. Résoudre le risque de double dépense sans registre central accessible en temps réel demeure un verrou cryptographique important, contraignant les premières phases de déploiement à un fonctionnement connecté.
C. Désintermédiation Bancaire & Fuite vers la Qualité
En période de crise financière, les déposants institutionnels et de détail pourraient être tentés de convertir instantanément leurs dépôts bancaires commerciaux (fractionnaires) en monnaie de banque centrale numérique de gros ou de détail (sans risque). Pour éviter des paniques bancaires et un assèchement du crédit bancaire, la BCE prévoit des limites strictes de détention (ex. 3 000 € maximum par citoyen) et restreint fortement l'accès des entités de gros, limitant ainsi la portée systémique de ces nouveaux rails.
Références Infrastructurelles Primaires
- Banque Centrale Européenne (BCE) : Rapports sur les travaux exploratoires concernant les nouvelles technologies de règlement en monnaie de banque centrale de gros.
- Banque des Règlements Internationaux (BRI) : Projet Agorá : Initiative conjointe des banques centrales et des G-SIB pour explorer l'intégration des dépôts tokenisés.
- Banque de France : Série d'expérimentations sur la MNBC de gros et travaux de recherche sur la finalité systémique.
- Deutsche Bundesbank : Architecture de la Solution Trigger & spécifications du pont de messagerie ISO 20022.
- Banque Européenne d'Investissement (BEI) : Structure d'émission obligataire et profils d'infrastructure DLT Canton/HSBC Orion.