2021
La consolidation des plateformes TARGET2 et TARGET2-Securities : le futur service T2
Blueprint – Version 2 – Janvier 2021
S O M M A I R E
1. INTRODUCTION ... 5
1.1. OBJECTIFS : LES ORIGINES DU PROJET ... 5
1.2. PRINCIPALES CARACTÉRISTIQUES ET ARCHITECTURE ... 6
1.3. GOUVERNANCE ... 7
1.4. PLANNING ... 8
2. PRÉSENTATION GÉNÉRALE DU FUTUR SERVICE T2 ... 8
2.1. PRINCIPES GÉNÉRAUX ... 8
2.2. DISPOSITIFS DE PARTICIPATION ... 10
2.2.1. Dans le CLM ... 10
2.2.2. Dans le RTGS ... 10
2.3. PRINCIPES RÉGISSANT LE FONCTIONNEMENT DES COMPTES MCA ET DCA RTGS ... 11
2.4. IDENTIFICATION DES COMPTES ET DES PARTICIPANTS ... 12
2.5. DÉNOMINATION DES COMPTES ... 13
3. PRINCIPALES FONCTIONNALITÉS ... 14
3.1. GESTION DE LA LIQUIDITÉ ... 14
3.1.1. Fonctionnalités offertes par CLM et RTGS pour le pilotage de la liquidité ... 14
3.1.2. Principes et modalités afférents aux transferts de liquidité ... 17
3.2. GESTION DES PAIEMENTS DANS LE RTGS ... 20
3.3. INTERFAÇAGE AVEC LES SYSTÈMES EXOGÈNES ... 21
3.3.1. Principes généraux ... 21
3.3.2. Procédures de règlement des systèmes exogènes (SE) ... 23
3.4. INTERACTIONS AVEC LA BANQUE CENTRALE ... 24
3.4.1. Principes généraux ... 24
3.4.2. Opérations de politique monétaire ... 24
3.4.3. Autres opérations de banque centrale ... 26
4. LE RÉFÉRENTIEL COMMUN (CRDM) ET LA CONSTRUCTION DE L'ANNUAIRE RTGS ... 27
5. REPORTINGS ... 29
6. BROADCASTS ... 29
7. CALENDRIER ET JOURNÉE OPÉRATIONNELLE ... 29
7.1.JOURNÉE OPÉRATIONNELLE ... 29
7.2.CALENDRIER ... 32
8. MODULE DE CONTINGENCE ... 33
9. FACTURATION ... 33
10.TARIFICATION ... 34
11.ENTREPÔT DE DONNÉES (DATA WAREHOUSE) ... 34
12.CONNECTIVITÉ ... 35
12.1.MODALITÉS D’ACCÈS DE CONNECTIVITÉ POUR LES PARTICIPANTS .... 35
12.1.1.ESMIG - une passerelle d’accès unique ... 35
12.1.2.L’accès en mode A2A : abandon du mode Y-Copy ... 35
12.1.3 .L’accès en mode U2A ... 36
12.2.CONFIGURATION DES DROITS D’ACCÈS SUR LA PLATEFORME CONSOLIDÉE ... 36
13.GESTION DE LA MIGRATION ... 37
13.1.MIGRATION EN « BIG BANG » ... 37
13.2 .FORMATION ET INFORMATION DES FUTURS UTILISATEURS ... 37
13.2.1.Organisation des relais de formation par la Banque de France ... 37
13.2.2.Organisation d’ateliers thématiques par la Banque de France .... 38
13.2.3.Diffusion et mise à disposition de l’information ... 38
14.GESTION DES ADHÉSIONS ... 38
14.1.FORMULAIRES ... 38
14.2.TESTS ET CERTIFICATION ... 38
15.CE QUI CHANGE POUR TARGET2 ... 39
15.1.CONNECTIVITÉ : CHOIX DES FOURNISSEURS RÉSEAUX, ABANDON DU Y-COPY ET SUPPRESSION DE L’ACCÈS INTERNET ... 39
15.2.SUPPRESSION DES COMPTES HAM ET PM ... 39
15.3.SUPPRESSION DE LA FONCTIONNALITÉ VIRTUAL ACCOUNT ... 39
15.4.ABANDON DU FORMAT DE MESSAGE ISO 15022 ... 40
16.CE QUI CHANGE POUR T2S ... 40
16.1.JOURNÉE OPÉRATIONNELLE ... 40
16.2.APPORT / RETRAIT DE LIQUIDITÉ ... 40
16.3.DONNÉES DE RÉFÉRENCE ... 40
16.4.ADAPTATIONS À ESMIG ... 41
17.EXEMPLES DE CONFIGURATIONS POSSIBLES ... 41
17.1.EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE À CARACTÈRE CENTRALISÉ ... 41
17.2.EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE À CARACTÈRE DÉCENTRALISÉ... 42
17.3.EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE MUTUALISTE 43 18.CONTACTS ... 44
Précisions
Les informations présentées dans ce document n’ont pas de caractère contractuel et sont susceptibles de modifications, à la suite notamment des évolutions résultant des travaux d’adaptation de la Banque de France ou de changements initiés par l’Eurosystème.
Les informations communiquées dans ce document reposent sur les dernières versions disponibles de la documentation de référence publiée par l’Eurosystème :
User Requirements Document (URD) v.2.1.
User Detailed Functional Specifications (UDFS) v.2.1.
Elles ont pour objectif de présenter aux participants de TARGET2-Banque de France (T2-BF) les enjeux du projet de consolidation T2-T2S, ainsi que les principaux aspects fonctionnels relatifs (i) au règlement brut en temps réel (RTGS pour Real-Time Gross Settlement) en monnaie de banque centrale des paiements montant élevé, (ii) au traitement des opérations de banque centrale et (iii) à la gestion de la liquidité des participants dans ce futur environnement.
Il cible essentiellement les trésoriers, les pilotes de flux et les équipes projet, et fournit des informations notamment sur :
l’architecture générale de la nouvelle plateforme ;
la gestion de la liquidité ;
les composantes partagées avec d’autres plateformes ;
la connectivité ;
les principaux changements pour les utilisateurs de TARGET2 ;
les dates prévisionnelles pour les tests utilisateurs et la phase de migration ;
l’information et les actions de formation assurées par la Banque de France.
Une première version de ce document a été publiée en février 2019, cette nouvelle version vient l’actualiser afin de :
préciser le nouveau calendrier de migration des participants TARGET2 vers la plateforme consolidée T2- T2S qui fait suite au report de 12 mois du « go-live »1 ;
d’apporter des précisions, notamment sur le fonctionnement des comptes MCA (Main Cash Account) et DCA (Dedicated Cash Account) RTGS, la dénomination des comptes, la fonctionnalité de co- management, les procédures de règlement des systèmes exogènes, les réserves obligatoires, l’annuaire RTGS, les messages d’information diffusés (broadcasts), le déroulement d’une journée opérationnelle, le module de contingence, ainsi que sur la tarification et la connectivité.
1 https://www.ecb.europa.eu/paym/intro/news/html/ecb.mipnews200728.en.html
1. Introduction
1.1. Objectifs : les origines du projet
Après près de 10 ans d’existence du RTGS TARGET2, et au moment du lancement de la nouvelle plateforme de règlement-livraison de titres TARGET2-Securities (T2S) en 2015, l’Eurosystème a engagé des réflexions relatives aux infrastructures qu’il possède et utilise dans le domaine du règlement d’opérations en monnaie de banque centrale. Ces réflexions s’inscrivent dans la stratégie dite « Vision 2020 », approuvée par le Conseil des gouverneurs de la Banque centrale européenne (BCE) le 21 septembre 2016.
Cette stratégie comprend, chronologiquement, les trois axes suivants :
Le développement d’une offre de règlement brut en monnaie de banque centrale des paiements instantanés, appelée TIPS (Target Instant Payment Settlement), qui répond à l’objectif de promotion du développement de moyens de paiements innovants à dimension paneuropéenne afin d’éviter une fragmentation du marché européen des paiements instantanés. Ce projet a été approuvé en juin 2017, et est entré en production le 30 novembre 20182.
La consolidation des infrastructures techniques TARGET2 et TARGET2-Securities, afin de réduire les coûts opérationnels, tout en renforçant leur efficacité en recourant notamment à des technologies à l’état de l’art (à l’image de ce que propose T2S : utilisation de la norme ISO 20022, capacité multidevises, accès à la plateforme via différents fournisseurs de service réseau) et en améliorant les outils de suivi et de gestion de la liquidité. Ce projet a été approuvé en décembre 2017 par le Conseil des gouverneurs, et sa mise en production est prévue en novembre 2022.
Le développement d’un outil commun de gestion du collatéral, appelé ECMS (Eurosystem Collateral Management System), permettant de fournir à l’Eurosystème une application de gestion harmonisée du collatéral éligible aux opérations de politique monétaire, en lieu et place de 19 applications domestiques actuellement utilisées, et de ce fait de contribuer à l’harmonisation des modalités de gestion du collatéral. Ce projet a été approuvé en décembre 2017 par le Conseil des gouverneurs, et sa mise en production est prévue en novembre 2023.
Les services concernés par la très grande majorité des changements induits par le projet de consolidation entre TARGET2 et T2S sont ceux offerts aujourd’hui par la plateforme TARGET2, tandis que T2S ne sera impacté qu’à la marge. Toutes les évolutions de T2S résultant du projet de consolidation des plateformes seront soumises à l’approbation de la communauté T2S.
2TIPS a fait l’objet d’un Blueprint dédié, disponible sur le site de la Banque de France à cette adresse.
1.2. Principales caractéristiques et architecture
Schéma 1 : Les services TARGET et leurs composantes communes
* GUI = Graphical User Interface
L’objectif de l’Eurosystème est de réorganiser clairement et de manière modulaire ses activités dans le domaine des infrastructures de marché (cf. schéma 1), en distinguant :
Les services qu’il propose au marché – regroupés sous le nom de « TARGET services », qui désignent : (1) T2, qui comprend dans la nouvelle architecture deux composantes : le dispositif de gestion
centralisée de la liquidité – CLM pour Central Liquidity Management – et le dispositif de règlement brut en temps réel des paiements – RTGS ;
(2) TIPS ;
(3) TARGET2-Securities.
les différentes composantes techniques et fonctionnelles qui lui permettent de fournir ces services, qui peuvent être communes à plusieurs d’entre eux (et qu’il s’agit alors de mutualiser au maximum), ou qui sont spécifiques. Ces composantes communes sont :
(1) la passerelle d’accès aux services (ESMIG) ; (2) le référentiel (CRDM) ;
(3) le module de facturation ;
(4) l’infocentre pour le reporting statistique et règlementaire (data warehouse) ; (5) des services de contingence.
En particulier, pour ce qui est des deux premières composantes communes :
La passerelle commune ESMIG (Eurosystem Single Market Infrastructure Gateway) authentifie et autorise les utilisateurs dûment accrédités à accéder aux différents services TARGET de manière centralisée. Elle est agnostique vis-à-vis du fournisseur de service réseau : les participants pourront se connecter avec le
fournisseur de leur choix, pourvu qu’il ait été agréé par l’Eurosystème. L’accès sera possible soit en mode manuel U2A (User to Application), soit en mode automatisé A2A (Application to Application), et l’ensemble des fournisseurs potentiels devront se conformer aux mêmes spécifications d’interface. La communication se fera via des formats de messages ISO 20022 ou compatibles. Cependant, et afin de préserver les spécificités de chacun des services, ceux-ci disposent chacun de leur propre GUI (Graphical User Interface), accessible par ESMIG.
Le référentiel commun CRDM (Common Reference Data Management) permet de centraliser l’ensemble des données de référence (relatives aux participants, comptes, abonnements aux reportings, etc), dès lors qu’elles sont utilisées dans plus d’un service, afin d’en assurer l’intégrité et d’éviter toute incohérence entre les données utilisées par les différents services pour un même participant. Les données de référence spécifiques à des services particuliers sont en revanche définies et gérées au sein de ceux-ci.
1.3. Gouvernance
Le dispositif de gouvernance de la future plateforme T2-T2S est identique à l’actuel :
au 1 er niveau, le Conseil des gouverneurs de la BCE est responsable de la direction, de la gestion et du contrôle de T2 ;
au 2nd niveau, les banques centrales nationales (BCN) de l’Eurosystème sont chargées d’opérer la composante nationale de T2 ;
au 3e niveau, les BCN prestataires (4CB) de la future plateforme technique développent et exploitent celle-ci au profit de l’Eurosystème.
Différentes instances assurent le suivi du projet :
le Market Infrastructure Board (MIB) est l’instance Eurosystème chargée de conseiller le Conseil des gouverneurs de la BCE en matière de gestion des infrastructures de marché et d’applications dans les domaines de la gestion du cash, du règlement de titres, et dans la gestion du collatéral. Il s’assure que ces infrastructures et applications sont développées et maintenues conformément aux objectifs du Traité européen en ce qui concerne le Système européen de banques centrales (SEBC), aux besoins des métiers, aux avancées technologiques, ainsi qu’aux exigences réglementaires.
l’Advisory Group on Market Infrastructures for Payments (AMI-Pay) est une instance d’échange et de conseil à l’Eurosystème dans le domaine du développement des paiements, associant des représentants du secteur bancaire et financier aux banques centrales de l’Eurosystème. Il peut à ce titre être consulté sur des sujets relatifs au développement de la future plateforme T2.
Au niveau de la Place française, le National Stakeholder Group AMI-Pay (ou NSG AMI-Pay) permet de faire la liaison entre le marché et les équipes projets pour l’évaluation des besoins utilisateurs et la bonne conception des spécifications de la future plateforme.
le Target Consolidation Contact Group (TCCG) est un groupe technique établi par le MIB qui rassemble la BCE, les 4CB, des banques centrales nationales et des acteurs du marché (banques, systèmes exogènes) pour :
o apporter une expertise sur les spécifications techniques et fonctionnelles de la future plateforme T2 ;
o assister les participants dans la phase de préparation et d’exécution des tests, puis de migration ;
o fournir une expertise au MIB sur toute question relative au projet.
Par ailleurs, le MIB a établi :
o un Target Services Working Group (TSWG), composé uniquement de représentants des banques centrales nationales, de la BCE et des 4CB, et destiné à assurer les activités de spécification et de préparation à la mise en production à la fois pour la consolidation T2-T2S et pour TIPS ;
o un Migration Testing and Readiness SubGroup (MTRSG), en charge du suivi de l’état de préparation des différentes communautés ainsi que de la stratégie de test et de migration (calendrier et procédures opérationnelles notamment).
1.4. Planning
La migration des participants TARGET2 vers la plateforme consolidée T2-T2S est prévue en novembre 2022 sur un mode « big bang ».
Les tests utilisateurs débuteront en décembre 2021, une fois la phase de tests internes aux banques centrales achevée, afin qu’ils puissent porter sur l’ensemble des fonctionnalités de la plateforme.
Schéma 2 – Macro-planning de la consolidation
2. Présentation générale du futur service T2
2.1. Principes généraux
Le projet repose sur une redistribution des fonctionnalités actuelles de TARGET2 entre deux modules :
le CLM pour la gestion centralisée de la liquidité ;
le RTGS, dédié aux paiements bruts en temps réel interbancaires et clients ainsi qu’au règlement des systèmes exogènes.
La mise en place du CLM constitue l’évolution majeure du projet de consolidation T2-T2S. Le CLM permet de centraliser le suivi et la gestion de la capacité de paiement en monnaie de banque centrale des participants autour d’un compte espèces principal (MCA, pour Main Cash Account, cf. schéma 3).
Le MCA sert de support à l’ensemble des opérations de banque centrale : constitution des réserves obligatoires, participation aux opérations de politique monétaire, accès au crédit intrajournalier et aux facilités permanentes (de prêt marginal et de dépôt), financement des retraits d’espèces aux guichets et toute autre interaction avec les banques centrales dans leur rôle de banque centrale d’émission. La ligne de crédit intrajournalier d’un participant ne peut être associée qu’à un seul MCA.
Depuis le MCA, les participants pilotent et allouent la liquidité (y compris celle découlant du crédit intrajournalier rattaché au MCA) entre les différents services optionnels de règlement qu’ils utilisent (RTGS, TIPS, T2S), et pour lesquels ils disposent de comptes espèces dédiés (DCA, pour Dedicated Cash Accounts).
Le CLM permet ainsi de ségréguer les interactions avec la banque centrale (en particulier du point de vue de la politique monétaire), de l’usage optionnel des services d’infrastructures de marché, avec pour objectif de moduler les services fournis par l’Eurosystème au plus près des besoins des participants. En particulier, les opérations de paiements bruts en temps réel interbancaires et de clientèle, ainsi que les transactions liées au règlement des systèmes exogènes, ont vocation à être traitées par la fonction RTGS et donc à se régler sur le DCA RTGS du participant.
Les soldes disponibles sur l’ensemble des comptes, MCA et différents DCA, étant en monnaie de banque centrale, ils sont pris en considération de manière globale dans le calcul des réserves obligatoires ainsi que pour le recours à la facilité de prêt marginal le cas échéant.
Schéma 3 - Modèle de base de centralisation de la liquidité autour du Main Cash Account :
Main Cash Account
T2S DCA
RTGS DCA
TIPS DCA
Crédit intrajournalier (ligne de crédit) Facilité de prêt marginal / facilité de dépôt
Opérations de banque centrale, y compris retraits espèces
Règlement-livraison de titres
Paiements en temps- réel interbancaires et clients, déversement des systèmes exogènes
Paiements instantanés
DCA = Dedicated Cash Account
2.2. Dispositifs de participation
2.2.1. Dans le CLM
Les participants au CLM sont des entités détenant en propre un ou plusieurs MCA, et pouvant émettre des ordres en mode U2A ou A2A. À ce stade, il n’est pas prévu d’autre dispositif de participation au CLM (pas de notion de participation indirecte).
Comme actuellement dans TARGET2, les participants au CLM ont la possibilité de confier la gestion de leur compte à un autre participant CLM (fonctionnalité de co-management, décrite au 3.1.1.3).
2.2.2. Dans le RTGS
Les participants directs au RTGS sont des entités détenant un ou plusieurs DCA RTGS, et pouvant accéder à leur(s) compte(s) et émettre des ordres en mode U2A ou A2A.
Les participants directs RTGS peuvent, comme c’est le cas actuellement dans TARGET2, fournir à leur tour un accès à d’autres participants qui pourront donc régler leurs paiements depuis un DCA RTGS du participant direct, en tant que :
participants indirects, enregistrés dans le RTGS via un unique participant direct, et qui ne peuvent émettre et recevoir des paiements depuis/vers le RTGS que via le participant direct. Les participants directs et indirects peuvent être établis dans des pays différents ;
détenteurs de BIC adressable, pour des succursales ou correspondants de participants directs, qui ne peuvent émettre et recevoir des paiements depuis/vers le RTGS que via le participant direct unique. S’il n’y a pas de différence technique entre les participants indirects et les détenteurs de BIC adressables, les conséquences juridiques de ces deux statuts varient, un détenteur de BIC adressable n’étant juridiquement pas considéré comme un participant au système ;
détenteurs d’un accès multi-destinataires (multi-addressee access), pour les cas où un participant direct RTGS autoriserait ses succursales ou autres entités de son groupe situées dans l’EEE à émettre et/ou recevoir des paiements directement depuis son DCA RTGS. Les institutions accédant au RTGS via le mode multi-destinataires ne peuvent le faire que via un unique participant RTGS.
Les BIC des institutions accédant au RTGS seront listés dans l’annuaire RTGS (RTGS Directory) comme étant atteignables (« reachable »).
Caractéristiques Participant RTGS direct Participant RTGS indirect/BIC adressable
Accès RTGS multi- destinataires Émettre et recevoir des
paiements
Directement Via le participant direct RTGS
Directement
Possède son propre DCA RTGS
Oui Non Non
Approvisionnement en liquidité
Sur son DCA RTGS Via le participant direct RTGS
Via le participant direct RTGS
Contrôle de la liquidité En propre Via le participant direct RTGS
Via le participant direct RTGS
Accès U2A (via le GUI) Oui Non Non
Adressabilité Directement adressable Adressable via le participant direct RTGS3
Directement adressable
Publication dans le RTGS Directory
En tant que participant direct RTGS
En tant que participant RTGS indirect/BIC adressable
En tant qu’accès RTGS multi-destinataires
2.3. Principes régissant le fonctionnement des comptes MCA et DCA RTGS
Dans le CLM :
Un même participant peut détenir plusieurs MCA dans le CLM, y compris auprès d’une même banque centrale, en euro ou autre devise4. La ligne de crédit intrajournalier d’un participant ne peut toutefois être associée qu’à un unique MCA.
Le solde intrajournalier d’un MCA ne peut être débiteur que dans la limite de la ligne de crédit intrajournalier qui lui est associée. Le solde des MCA ne disposant pas d’une ligne de crédit est nécessairement créditeur ou nul.
Il n’est pas obligatoire, pour un participant CLM, de détenir un DCA : un participant qui le souhaite pourra ainsi n’ouvrir qu’un MCA (et aucun compte dans le RTGS), si son activité se limite à effectuer des opérations relatives à la politique monétaire, notamment la constitution des réserves obligatoires, et des opérations de numéraire.
Les fonctionnalités offertes par les MCA permettent ainsi de répondre aux besoins de la majorité des détenteurs de comptes gérés dans l’actuel Home Account Module (HAM) de TARGET2.
En revanche, si l’activité nécessite la réalisation d’opérations interbancaires, les participants CLM devront alors ouvrir un DCA dans le RTGS ou bien recourir à la participation indirecte via un détenteur de DCA dans le RTGS, selon des modalités semblables à celles existant actuellement dans TARGET2 (cf. point suivant).
Dans le RTGS :
Si la participation au CLM est indépendante de la participation au RTGS, l’inverse n’est pas vrai : outre le fait que la banque centrale peut imposer à ses participants l’ouverture d’un MCA pour la gestion des réserves obligatoires (le cas échéant), la rémunération des soldes overnight ou encore pour des raisons de facturation, le Conseil des gouverneurs a acté en septembre 2019 le principe que tout détenteur d’un DCA (RTGS, T2S ou TIPS) devrait aussi ouvrir un MCA auprès de la banque centrale où le DCA est ouvert.
Un participant détenant au moins un MCA et un DCA RTGS devra établir un lien un pour un entre l’un de ses MCA et l’un de ses DCA dans le CRDM, condition pour que puissent s’opérer les transferts de fonds automatiques depuis le RTGS vers le CLM déclenchés en cas d’insuffisance des fonds sur le MCA pour régler une opération de banque centrale, et décrits au 3.1.1.4.
Un même participant peut détenir plusieurs DCA RTGS, y compris auprès d’une même banque centrale.
3 Pour ce faire, les participants indirects disposent d’un BIC11 qui leur est propre (cf. 2.4).
4 Aujourd’hui seul l’euro est accepté dans CLM, mais une capacité multidevise est prévue, elle fait partie de la stratégie « Vision 2020 » pour les infrastructures de l’Eurosystème.
Exemple : un DCA RTGS pour le règlement de ses paiements propres, un DCA RTGS pour le règlement de paiements en lien avec un ou plusieurs systèmes exogènes, un DCA RTGS pour le règlement de paiements pour le compte de ses participants indirects, BIC adressables ou multi-destinataires.
Un participant utilisant plusieurs DCA RTGS devra en revanche en définir un comme compte « par défaut » pour l’ensemble de ses paiements interbancaires et clients.
Le solde d’un DCA RTGS est nécessairement créditeur ou nul. Si l’entité dispose d’un MCA auquel est associée une ligne de crédit, elle pourra recourir au crédit intrajournalier associé au MCA pour apporter de la liquidité sur son/ses DCA RTGS depuis ce MCA.
En fin de journée opérationnelle, un DCA RTGS ne doit pas nécessairement être soldé et les fonds demeurant sur ce compte sont pris en compte pour le calcul des réserves obligatoires et soumis à rémunération5.
Par ailleurs, la fonctionnalité d’autocollatéralisation offerte aux participants par les DCA T2S ne peut être utilisée pour allouer de la liquidité en intrajournalier de T2S vers un autre service.
Les autres principes régissant les relations entre MCA et DCA sont les suivants :
Tout DCA doit être lié à au moins un MCA dans la même devise (pas nécessairement ouvert dans la même banque centrale) pour pouvoir être alimenté en liquidité et pour les besoins de facturation.
Si le DCA est lié à plusieurs MCA, le participant doit désigner le MCA à utiliser pour la facturation. De même, un même MCA peut être associé à plusieurs DCA ouverts dans la même devise, détenus dans une même banque centrale ou dans des banques centrales différentes.
Il convient toutefois de garder en mémoire que l’ensemble des comptes appartenant à une même institution financière monétaire doit être ouvert auprès de la même banque centrale domestique pour que leurs soldes puissent être considérés dans le cadre de la constitution des réserves obligatoires et soient rémunérés overnight.
Tous les DCA ouverts par une même personne morale peuvent être liés soit à un seul compte MCA, soit chacun à un compte MCA différent.
2.4. Identification des comptes et des participants
Dans le CLM comme dans le RTGS, les détenteurs de compte sont identifiés par un BIC 11 (« Party BIC »), qui est unique au sein d’un même service (mais pas nécessairement entre plusieurs services différents). La Banque de France est en charge de la gestion des données référentielles des banques de paiement ayant des comptes ouverts dans ses livres.
Les comptes ouverts dans les différents modules (qu’il s’agisse de CLM, RTGS, TIPS ou T2S) sont identifiés : - d’une part, par leur BIC 11 (« Account BIC »), sachant qu’un BIC 11 ne peut être associé qu’à un seul et
unique compte à l’intérieur d’un même service. Ainsi, une entité souhaitant ouvrir plusieurs comptes au sein d’un même module devra identifier chacun de ces comptes par un unique BIC11 (par exemple, une entité désirant ouvrir deux comptes DCA RTGS devra déclarer deux participants « directs » dans l’annuaire RTGS, soit un par DCA). En revanche, un même BIC 11 peut être utilisé sur plusieurs modules ; - d’autre part, par un identifiant de compte (« Account ID »), qui est lui unique, tant au niveau du module
qu’à travers les différents services TARGET.
5 En ce qui concerne les DCA ouverts dans T2S, il reviendra à la communauté T2S de décider de l’opportunité du maintien ou non de l’obligation de rapatrier la liquidité disponible sur les DCA T2S en fin de journée.
Schéma 4 - Exemple d’un participant CLM avec deux MCA :
Par ailleurs, dans le RTGS spécifiquement, les sous-comptes utilisés pour le déversement des systèmes exogènes dans le cadre de la procédure C (actuelle procédure 6 interfacée ; voir infra sur la description des procédures) sont identifiés par un numéro de compte, et directement liés à un DCA RTGS.
La liste des BIC figure dans le BIC Directory publié par SWIFT.
2.5. Dénomination des comptes
Aujourd'hui, une convention de nommage est en place pour les comptes T2S et TIPS6. Une convention harmonisée et structurée a été proposée pour la future plateforme T2. La convention de nommage inclut une lettre suivie du BIC participant.
6 Elle prévoit d’attribuer aux comptes T2S et TIPS les noms suivants :
« C » pour les DCA T2S (compte cash) ;
« S » pour les SAC T2S (comptes titres) ;
« I » pour les DCA TIPS.
Compte Nom BIC
MCA M BIC participant du titulaire du compte
DCA RTGS R BIC participant du titulaire du compte
Compte technique T BIC participant du titulaire du compte
Sous-compte U BIC participant du titulaire du compte
Compte de facilité de dépôt D BIC du participant au nom duquel le compte est ouvert Compte de facilité de prêt
marginal
L BIC du participant au nom duquel le compte est ouvert
3. Principales fonctionnalités
3.1. Gestion de la liquidité
3.1.1. Fonctionnalités offertes par CLM et RTGS pour le pilotage de la liquidité
Le CLM offre deux catégories de fonctionnalités aux participants pour le pilotage de leur liquidité : d’une part, des fonctionnalités destinées à les assister dans le suivi de leur liquidité (monitoring) ; d’autre part, des fonctionnalités destinées à assurer la gestion per se de leur liquidité.
Suivi de la liquidité
Les participants ont la possibilité de grouper des comptes dans un groupe de suivi de comptes (Account Monitoring Group - AMG) pour répondre aux seuls besoins de suivi de la liquidité, ces groupements ne jouant aucun rôle du point de vue des paiements ou transferts de liquidité. Les comptes inclus dans ce groupe peuvent appartenir à plusieurs modules différents (RTGS et TIPS par exemple), être détenus par plusieurs participants différents, être ouverts dans les livres de différentes banques centrales, et un même compte peut appartenir à plusieurs groupes de suivi de comptes différents. Ainsi, ces groupes de suivi permettent de répondre aux besoins de surveillance consolidée intragroupe de la liquidité, en intraservice comme en interservices.
Par ailleurs, les fonctionnalités de suivi de la liquidité s’appuient sur :
Des interfaces graphiques utilisateur (GUI, pour Graphical User Interface), qui permettent un accès aux services sur un mode U2A :
o soit en cas d’accès au niveau du GUI CLM, pour une devise donnée, aux informations (soldes, usage de la ligne de crédit, usage de l’autocollatéralisation pour T2S etc.) relatives à l’ensemble des MCA et DCA liés ou appartenant au même Account Monitoring Group pour lequel les utilisateurs disposent des droits d’accès idoines ;
o soit en cas d’accès au niveau des GUI des différents services de règlement (RTGS, TIPS, T2S), à l’ensemble des informations relatives à leurs DCA au niveau de ce service, dans une devise donnée.
La possibilité, pour le participant, de souscrire à des alertes et des notifications en cas de survenance d’évènements prédéfinis, envoyées par le CLM ou le RTGS via le GUI ou en mode A2A.
La possibilité, pour le participant, de souscrire à des rapports standardisés (ex : relevés de comptes) dans le CLM ou le RTGS, ou de requêter des données historiques sur la base de rapports prédéfinis depuis l’entrepôt de données en mode A2A ou via le GUI.
Gestion de la liquidité
Comme indiqué plus haut, les fonctionnalités de gestion de la liquidité reposent sur une gestion centralisée via le MCA, qui sert à allouer la liquidité entre les DCA affectés aux différents services de règlement (RTGS, TIPS et T2S). L’allocation peut se faire soit de manière manuelle, soit de manière automatisée (voir la partie 3.1.2 pour une description des différents types de transferts possibles).
Le CLM et le RTGS proposent tout d’abord à leurs utilisateurs des outils permettant de réserver de la liquidité pour l’exécution de certaines transactions, ayant un certain niveau de priorité ou une affectation métier particulière :
sur le MCA il est possible de réserver de la liquidité pour les opérations de politique monétaire et de numéraire ;
sur le DCA RTGS il est possible de réserver de la liquidité d’une part pour les ordres auxquels l’utilisateur aura affecté une priorité « high », d’autre part pour des ordres « urgent » liés à des opérations de systèmes exogènes (voir infra).
Cette réservation de liquidité peut être gérée à tout moment de la journée opérationnelle, sauf durant l’exécution des traitements de fin de journée et durant la fenêtre de maintenance. Elle peut prendre effet soit de manière immédiate pendant la journée opérationnelle, soit de manière différée à partir de la journée opérationnelle suivante.
Les utilisateurs peuvent également gérer leur liquidité au moyen de transferts, qui peuvent être :
soit manuels, sur la base d’instructions ponctuelles (immediate liquidity transfer) entrées en mode A2A ou U2A ;
soit automatiques, par des ordres configurés par avance dans le CRDM par le titulaire du compte et déclenchés lors d’évènements prédéfinis de la journée opérationnelle (standing orders liquidity transfer), par exemple en début de journée opérationnelle ou lors de l’occurrence d’évènements prédéfinis (rule- based liquidity transfer) comme le dépassement d’une limite dans le CLM ou le RTGS (voir infra), ou le placement d’un ordre de paiement urgent en file d’attente dans le RTGS.. Ces transferts sont possibles en intraservice, ou en interservices, selon des modalités décrites ci-après.
Le GUI CLM permettra aux participants de définir et modifier les paramètres de gestion automatique de la liquidité pour le MCA, tandis que le GUI RTGS permettra aux participants de définir et modifier les paramètres de gestion automatique de la liquidité pour le DCA RTGS.
Les transferts sur la base d’évènements prédéfinis permettront notamment de gérer automatiquement les surplus ou les besoins de liquidité. En effet :
Les participants ont la possibilité de mettre en place des seuils plafond ou plancher de fonds destinés à demeurer à tout moment sur les comptes MCA ou DCA RTGS7. En cas de franchissement de ces seuils, l’utilisateur peut choisir que le module CLM ou RTGS génère une notification l’en informant, ainsi qu’un ordre de transfert de liquidité interservices.
En cas d’insuffisance de la capacité de paiement (solde espèces + ligne de crédit) disponible sur le MCA pour régler les opérations de banque centrale, de la liquidité est automatiquement transférée du DCA RTGS défini par défaut. Cette fonctionnalité est obligatoire (aucune configuration n’est requise).
À l’exception des transferts automatiques de liquidité entre DCA RTGS et MCA destinés à permettre le règlement d’une opération de banque centrale, tous les autres transferts automatiques entre MCA et DCA RTGS doivent être prédéfinis dans le CRDM.
Par ailleurs, la liquidité peut être gérée entre plusieurs comptes au sein d’un même service au moyen de groupes de transfert de liquidité (Liquidity Transfer Group - LTG), au sein du CLM ou du RTGS. Au sein d’un même service, et à moins que l’un des comptes impliqués dans l’opération ne soit un compte de banque centrale, l’appartenance des comptes entre lesquels des transferts sont instruits à un même groupe de transfert de liquidité est une condition pour que ces transferts soient exécutés.
7 À noter que pour le MCA, la fonction prend uniquement en compte le solde espèces, et non la ligne de crédit disponible.
Schéma 5 - Exemple d’articulation entre LTG et AMG au niveau international
Source : BCE, Business Description Document
Fonctionnalité de co-management
Les comptes CNRO dans T2-BF peuvent actuellement être co-managés, et un participant (co-managé) peut ainsi confier à un autre (le co-manager) la surveillance et la gestion de ses comptes (A2A ou U2A), ce dernier (le co- manager) pouvant ainsi gérer l’infrastructure technique de connexion. Cette fonctionnalité est reconduite dans le CLM, mais pas dans le RTGS.
Concrètement, au moment de la création des MCA dans le CRDM, des « flags » permettront à la banque centrale :
d’identifier que le compte est co-managé et par qui (renseignement du party BIC du co-manager), le co- manager ne pouvant être qu’un autre participant détenteur de MCA dans le CLM ;
de rendre l’ensemble des privilèges/rôles octroyés au co-manager également applicables et sans limitation sur le compte co-managé (i.e. les privilèges/rôles assignés par la BCN au MCA du co-manager sont également valables pour la gestion du MCA co-managé).
À noter que le co-manager et le détenteur du compte co-managé ne doivent pas forcément appartenir au même groupe bancaire, ni dépendre de la même banque centrale (la fonctionnalité est donc disponible sur un mode cross-border).
Gestion de la priorité des opérations
Le RTGS prévoit la possibilité d’affecter trois degrés différents de priorité aux ordres de paiement (comme TARGET2 aujourd’hui, avec un alignement de la terminologie sur la norme SWIFT) :
Urgent : ces ordres sont exécutés de manière prioritaire par rapport aux paiements de priorité « high » ou
« normal », et la file d’attente est gérée selon un principe de « first in, first out » (FIFO). Par défaut, c’est le degré de priorité affecté aux ordres envoyés par des systèmes exogènes (pain.998), ainsi qu’aux ordres de transfert de liquidité (camt.050) ainsi qu’aux règlements de paiements interbancaires ou transferts de liquidité d’un DCA RTGS vers un compte technique de système exogène (pacs.009 contenant le code
« SBTI »). Si le montant de la réservation pour les paiements de type urgent sur le DCA RTGS n’est pas suffisant, les fonds sont retirés de la partie non réservée, puis de la réservation pour les paiements high sur ce même DCA RTGS.
À noter que les transferts de liquidité depuis le RTGS générés automatiquement du fait d’un manque de capacité de paiement dans le CLM pour régler une opération de banque centrale sont automatiquement placés en haut de la file des paiements urgents, du fait de leur haute criticité (voir 3.2. pour la description des files d’attente pour les paiements dans le RTGS).
High : ces ordres sont exécutés prioritairement par rapport aux ordres de paiements normaux. Si le montant de la réservation pour les paiements high est insuffisant, les fonds sont tirés de la liquidité non réservée sur ce même DCA RTGS. Sous réserve que la file d’attente des ordres de priorité « urgent » soit vide, la file d’attente des ordres de priorité « high » est gérée sur une base de FIFO.
Normal : c’est l’affectation par défaut pour tous les ordres qui ne sont pas classés « urgent » ou « high ».
Ces ordres ne sont exécutés que lorsqu’aucun paiement urgent ou high n’est en attente, et le système optimisera l’utilisation de la liquidité pour leur règlement.
Tant qu’un ordre de paiement n’est pas réglé, et sous réserve qu’il ne soit pas classé « urgent », le détenteur du compte RTGS a la possibilité de modifier la priorité de cet ordre – et celui-ci sera alors placé dans la file d’attente correspondant à son nouveau degré de priorité, selon le moment où il a été soumis.
Cette possibilité de gestion de la criticité des opérations n’existe pas dans le CLM. Il existe toutefois un ordre prédéfini de tirage de la liquidité pour les opérations sur le MCA et les paiements et transactions sur le DCA RTGS, tenant compte des différentes sources de liquidité (réservations sur le MCA et DCA RTGS) et affectations fonctionnelles (baisse de la ligne de crédit, opération de banque centrale…).
Gestion du risque
Les participants ont, dans le RTGS, la possibilité de définir des limites bilatérales (vis-à-vis d’un DCA RTGS donné) et multilatérales (vis-à-vis de tous les autres DCA RTGS), chaque jour, en net sur des paiements de priorité normale : lorsque le montant au débit atteint la limite fixée, les ordres de paiement sont placés en file d’attente, et ne sont soumis que lorsqu’un montant suffisant de paiements a été reçu au crédit du compte, pour qu’en net le débit n’entraîne pas de dépassement de la limite.
3.1.2. Principes et modalités afférents aux transferts de liquidité
Ordre de tirage de la liquiditéPour les MCA comme pour les DCA RTGS, les opérations (transferts de liquidité ou paiements) sont effectuées sur une base de « first in first out » ou FIFO (à l’exception des paiements de priorité normale, qui doivent être réglés en optimisant l’utilisation de liquidité). Le système tente de régler les transferts de liquidité dès qu’ils sont soumis ou déclenchés.
Par principe, les transferts de liquidité ne sont jamais placés en file d’attente8 (voir 3.2. pour la description des files d’attente dans le RTGS) : ils sont soit réglés (entièrement ou partiellement) à leur présentation, soit rejetés.
Ce principe connaît toutefois une exception, décrite ci-après, dans le cas où le transfert de liquidité a été initié automatiquement du RTGS vers le CLM du fait d’un manque de capacité de paiement du CLM pour régler une opération de banque centrale.
Le tableau ci-dessous indique les différentes sources de liquidité et, pour chaque type d’opération, l’ordre dans lequel ces différentes sources sont ponctionnées selon la réservation (cf. supra pour la présentation des différents types de réservation) : 1 = première source de liquidité, 2 = deuxième source de liquidité, etc.
Par exemple, pour une opération de type « baisse de la ligne de crédit », la partie non-réservée de la liquidité disponible sur le MCA est utilisée en premier ; viennent ensuite la partie réservée du MCA, la partie non-réservée du DCA RTGS, etc.
8 Le concept de file d’attente a le même sens dans ce document que pour TARGET2 actuellement.
Par exemple, pour une opération de type « baisse de la ligne de crédit », la partie non-réservée de la liquidité disponible sur le MCA est utilisée en premier, viennent ensuite la partie réservée du MCA, la partie non-réservée du DCA RTGS, etc.
Typologie et modalités des transferts entre MCA et DCA RTGS On distingue deux types de transfert de liquidité entre les comptes espèces MCA et DCA, présentés ci-après.
Les transferts de liquidité du MCA vers le DCA RTGS peuvent être initiés par des participants CLM disposant d’un MCA, ou pour leur compte par des tiers autorisés, en mode U2A ou A2A, vers n’importe quel DCA se trouvant dans RTGS, TIPS ou T2S (modèle ouvert). La seule source de liquidité possible pour ce type d’ordre est la partie non réservée du MCA. Ils sont par principe exécutés immédiatement après leur soumission, sur une base FIFO, et ne peuvent être placés en file d’attente (et donc, ne peuvent être annulés). Trois cas de figure sont alors possibles :
1. Ces ordres sont exécutés dans leur totalité par le CLM, si la partie non réservée du MCA dispose de la liquidité suffisante.
2. Ils sont exécutés partiellement, si la partie non réservée du MCA ne dispose que partiellement de la liquidité suffisante, si aucune opération de banque centrale n’est présente en file d’attente, et si l’ordre a été initié via un ordre automatique (déclenché à des horaires ou évènements prédéfinis). L’ordre est alors exécuté à la hauteur du montant qui peut être réglé (zéro, le cas échéant), et aucune tentative de transfert du solde n’est par la suite effectuée par le système.
3. Ils ne sont pas exécutés et sont rejetés, si la partie non réservée du MCA ne dispose pas de la liquidité suffisante et que le transfert a été initié par un ordre ponctuel.
Les transferts d’un DCA RTGS vers un MCA peuvent être initiés par (ou pour le compte de, par des tiers autorisés) des participants RTGS disposant d’un DCA. Ils sont par principe exécutés immédiatement après leur soumission, sur une base FIFO, et ne peuvent être placés en file d’attente (et donc, ne peuvent être annulés), sauf exception décrite ci-dessous. Trois scénarios sont alors possibles:
1. Ces ordres sont exécutés dans leur totalité si la liquidité disponible sur le DCA est suffisante.
2. Ces ordres sont exécutés partiellement si la liquidité disponible sur le DCA n’est pas suffisante et que : i. dans le cas où l’ordre a été initié via un ordre automatique, ou par un système exogène, l’ordre est alors exécuté à la hauteur du montant qui peut être réglé, et aucune tentative de transfert
Business purpose
Réservé aux opérations de
banque centrale Non réservé
Réservé aux paiements
"Urgent"
Réservé aux paiements
"High" Non-réservé
Baisse de la ligne de crédit 2 1 5 4 3
Opérations de banque centrale
(y.c. retraits d'espèces) 1 2 5 4 3
Transferts de liquidité
(intra et inter service) 1
Transferts de liquidité
(intra et inter service) 3 2 1
Transactions de systèmes exogènes 4* 1 3 2
Paiements "high" 3* 1 2
Paiements "normal" 1
MCA RTGS DCA
Ordre de tirage de la liquidité MCA
RTGS DCA
*Sous réserve que le participant ait configuré une règle de transfert de liquidité depuis le CLM vers le RTGS si ces paiements sont placés en file d'attente dans le RTGS.
du solde n’est par la suite effectuée par le système. Si plusieurs ordres de transferts automatiques ont été configurés pour se déclencher au même moment et que le solde sur le DCA RTGS n’est que partiellement suffisant, tous les transferts sont réduits sur un mode prorata ;
ii. si l’ordre a été initié automatiquement du fait d’un manque de liquidité sur le MCA pour régler une opération de banque centrale, le transfert bénéficiera alors du degré d’urgence maximal et sera placé en tête de file des paiements « urgents » (du fait de la priorité des opérations de banque centrale) ; les fonds disponibles sur le DCA RTGS ne permettant pas un règlement complet de l’opération, celle-ci est partiellement réglée dans la mesure des fonds disponibles, et le montant non réglé est placé en file d’attente jusqu’à couverture du besoin en liquidité du MCA (par exception à la règle selon laquelle les transferts de liquidité ne sont pas placés en file d’attente). Tout afflux de liquidité sur le DCA RTGS est alors transféré automatiquement (et prioritairement à tout autre opération) sur le MCA, jusqu’à ce que l’opération de banque centrale soit totalement exécutée.
3. Ces ordres ne sont pas exécutés et sont rejetés si la liquidité sur le DCA n’est pas suffisante et que l’ordre a été initié manuellement.
Par principe, aucun transfert de liquidité du DCA RTGS vers le MCA ne peut donc être bloqué par un paiement en attente d’exécution sur le DCA RTGS.
Typologie et modalités des transferts entre deux MCA Les transferts intraservice entre deux MCA peuvent être initiés :
par des participants au CLM propriétaires du MCA qui sera débité (ou pour leur compte par des tiers autorisés ou une banque centrale) ;
en mode U2A ou A2A ;
à condition que les deux MCA fassent partie du même groupe de transfert de liquidité prédéfini, à moins que l’un des deux comptes n’appartienne à une banque centrale.
Ils sont par principe exécutés immédiatement après leur soumission, et ne peuvent être placés en file d’attente (et donc, ne peuvent être annulés). Enfin, ces transferts ne peuvent s’effectuer que depuis la partie non-réservée de la liquidité du MCA.
Trois scénarios sont alors possibles :
les ordres sont exécutés dans leur totalité si la liquidité disponible sur la partie non réservée du MCA est suffisante ;
ils sont exécutés partiellement si la partie non réservée du MCA ne dispose pas de la liquidité suffisante et que l’ordre a été initié via un ordre automatique (déclenché à des horaires ou évènements prédéfinis) et qu’aucune opération de banque centrale n’est présente en file d’attente. L’ordre est alors exécuté à la hauteur du montant qui peut être réglé (zéro, le cas échéant), et aucune tentative de règlement du solde non réglé n’est par la suite effectuée ;
ils ne sont pas exécutés et sont rejetés, si la partie non réservée du MCA ne dispose pas de la liquidité suffisante et que l’ordre a été initié par un ordre de transfert ponctuel.
Typologie et modalités des transferts entre deux DCA On distingue deux types de transferts de liquidité entre deux DCA :
1. Les transferts entre deux DCA d’un même service de règlement sont possibles dès lors que les deux DCA font partie du même Liquidity Transfer Group ou que l’un des deux comptes appartient à une banque centrale. Pour le RTGS, ils peuvent être initiés manuellement en mode U2A ou A2A, par le participant ou par des tiers autorisés, ou être déclenchés automatiquement par des ordres automatiques de virement.
Trois scénarios sont possibles pour le RTGS et ces ordres :
i) sont exécutés dans leur totalité si la liquidité disponible sur le DCA est suffisante ;
ii) sont exécutés partiellement si la liquidité disponible sur le DCA n’est pas suffisante et que l’ordre a été initié via un ordre automatique ou via un système exogène ;
iii) ne sont pas exécutés et sont rejetés si la liquidité disponible sur le DCA n’est pas suffisante, et que l’ordre n’a pas été initié via un ordre automatique ou un système exogène.
2. Les transferts entre deux DCA de deux services de règlement différents doivent transiter par le CLM, via des « comptes de transit » dédiés à ce type de transferts et tenus par la banque centrale – ces transactions ne transiteront pas via des MCA.
Schéma 6 - Illustration du flux de message entre les différents comptes pour un transfert de liquidité interservices/composantes
Source : UDFS CLM v.2.1.
3.2. Gestion des paiements dans le RTGS
Les paiements (virements de clientèle, interbancaires, débits directs) seront désormais traités au sein d’un module unique RTGS (les paiements dans le CLM ne pouvant être initiés que par les banques centrales) et réglés sur des comptes espèces dédiés, les DCA RTGS.
Par rapport à la plateforme TARGET2 existante, les modifications apportées concernent essentiellement les interfaces et la connectivité. Ainsi, la messagerie FIN 15022 est abandonnée au profit d’un passage vers la norme ISO 20022. Le mode V-Shape, aujourd’hui utilisé pour les échanges avec le module PM de l’actuelle plateforme TARGET2, est abandonné dans la mesure où il repose sur une spécificité propre à SWIFT.
À l’instar de la plateforme existante, les algorithmes mis en œuvre tiendront compte de la priorité attribuée par le participant à l’origine de la transaction financière, afin que les opérations les plus urgentes soient traitées en priorité, suspendant le cas échéant dans une file d’attente le règlement de transactions moins urgentes.
Les utilisateurs ont la possibilité de moduler dans le temps l’exécution des ordres de paiement :
soit pour qu’ils ne soient exécutés qu’à partir d’un moment prédéfini (from time) ;
soit pour indiquer qu’ils devraient être exécutés avant un moment prédéfini, mais en conservant la possibilité qu’ils le soient après si cela n’a pas été le cas (till time) : l’ordre de paiement demeure alors dans la file d’attente et sera rejeté s’il n’est toujours pas réglé au moment du cut-off pour ce type de paiements ;
soit pour qu’ils soient rejetés s’ils ne sont pas exécutés à partir d’un moment prédéfini (reject time).
Les dernières fonctionnalités (till time et reject time) sont exclusives l’une de l’autre : si l’une est utilisée, l’autre ne peut pas l’être.
Par défaut, les transactions de priorité « urgent » ou « high » sont traitées selon le principe FIFO, pour un niveau de priorité donné ; les paiements de priorité « normal » sont traités selon un principe de « FIFO by-passing » permettant de compenser certains transferts entre eux. Le participant peut néanmoins toujours modifier l’ordre de traitement des paiements suspendus dans les files d’attente (une file par niveau de priorité). En effet, lorsqu’un ordre de paiement est, dans le RTGS, placé dans la file d’attente correspondant à sa priorité (ce qui sera automatiquement le cas s’il ne peut être exécuté à la value date), le participant a la possibilité d’effectuer les actions suivantes en mode U2A ou A2A :
modifier l’emplacement des ordres de paiement dans une file d’attente correspondant à une priorité donnée, en plaçant un ou plusieurs ordres en tête ou en fin de celle-ci ;
modifier les modalités de timing d’exécution pour les ordres qui en contiennent (from time, till time, reject time) ;
modifier le degré de priorité affecté à un paiement entre « high » et « normal », dans les deux sens (impossible avec la catégorie « urgent »).
Par ailleurs, tant qu’une instruction de paiement n’est pas réglée dans le RTGS, l’émetteur de l’instruction a la possibilité de révoquer le paiement en mode U2A ou A2A – sachant qu’il est aussi possible de révoquer les paiements en date de valeur future (warehoused). Dans le cas où le paiement a été réglé, la demande de révocation est transférée au détenteur du compte à créditer, qui pourra y répondre négativement ou la confirmer, et retourner les fonds. Il est à noter que cette fonctionnalité de révocation est disponible uniquement pour les paiements de clientèle.
Enfin, pour réduire l’impact d’une éventuelle perte de possibilité d’envoyer des ordres de paiement A2A pour un détenteur de compte RTGS (par exemple, en cas d’incident sur un de ses sites), le RTGS offrira la possibilité de générer des ordres via une fonctionnalité de back-up disponible dans le GUI. Les participants pourront choisir entre l’option de disposer en permanence des écrans complets, ou de disposer d’écrans simplifiés sur activation de la banque centrale.
3.3. Interfaçage avec les systèmes exogènes
3.3.1. Principes généraux
Les règlements des systèmes exogènes seront traités au sein du module RTGS, via l’utilisation des procédures dédiées à ce type d’opérations.
Ces règlements peuvent s’opérer, du point de vue des établissements de crédit :
soit sur le DCA RTGS également utilisé par défaut pour le règlement des paiements. Dans ce cas, les transactions sont traitées avec la catégorie « urgent », pour laquelle les participants peuvent réserver de la liquidité sur leur DCA RTGS : la liquidité réservée est alors utilisée en priorité et, en cas d’insuffisance, le séquencement présenté précédemment s’appliquera ;
soit sur un ou des DCA RTGS dédiés à l’activité avec les systèmes exogènes. Le participant peut choisir d’utiliser un compte dédié au règlement des transactions envoyées par l’ensemble des systèmes exogènes avec lesquels il interagit, ou seulement certains, avec la possibilité d’utiliser un compte dédié par système ou par type de procédure de déversement. À l’intérieur de ces comptes dédiés, toutes les transactions liées aux systèmes exogènes sont traitées avec le même degré de priorité « urgent » ; outre la possibilité pour le participant de transférer de façon ponctuelle ou pré-paramétrée de la liquidité depuis son MCA
ou son DCA RTGS (voir supra), le participant peut autoriser l’initiation de ces transferts par le système exogène ;
soit, pour la procédure C (ex-procédure 6 interfacée), sur un sous-compte par système exogène utilisant cette procédure. Ce sous-compte est associé au DCA RTGS utilisé par défaut pour les paiements, ou dédié au règlement des transactions liées aux systèmes exogènes. Le participant peut initier des transferts de liquidité vers ce sous-compte depuis le DCA RTGS qui lui est associé, de manière manuelle ou en paramétrant des transferts automatiques de liquidité. Le système exogène dont les transactions sont réglées sur ce sous-compte peut enfin envoyer des fichiers dédiés (ASTransferInitiation) pour retirer de la liquidité du DCA RTGS de la banque de règlement auquel le sous-compte est associé.
Schéma 7 - Types de comptes utilisables par un établissement de crédit pour les règlements de systèmes exogènes
Source : UDFS RTGS, v.2.1.
Du point de vue du système exogène, les comptes suivants peuvent être utilisés dans le RTGS :
Les comptes techniques, ouverts au nom du système exogène ou de la banque centrale, et utilisés : o soit comme comptes intermédiaires pour la collecte des débits et crédits résultant du
règlement des transactions liées aux systèmes exogènes dans le cadre des procédures A, B, C, E (cf. infra pour la description des procédures). Les débits étant toujours suivis de crédits, le solde de ce compte en fin de journée doit alors être nul ;
o soit comme compte utilisé pour le préfinancement de la procédure D.
Un compte technique doit être ouvert pour chaque procédure utilisée par un même système exogène, sauf dans le cadre de la procédure E où il est possible de réutiliser le compte ouvert pour la procédure C ou D.
Il est à noter que la notion de compte de liquidité dédié disparaît pour la procédure de liquidité dédiée (temps réel), anciennement ASI6 Real-Time.
Les comptes de fonds de garantie ouverts au nom du système exogène, de la banque centrale ou d’un garant, utilisés dans le cadre des procédures A et B (cf. infra) – sachant que pour un système exogène
utilisant ces deux procédures le compte de fonds de garantie utilisé peut être identique, ou le système exogène peut choisir d’utiliser un compte par procédure.
Les systèmes exogènes communiquent avec le RTGS sur un mode A2A ou U2A.
À noter qu’il n’existe, pour les procédures de règlement des systèmes exogènes, pas de fonctionnalité permettant d’instruire des paiements en date de valeur future.
3.3.2. Procédures de règlement des systèmes exogènes (SE)
La future plateforme prévoit les procédures de règlement détaillées dans le tableau ci-après : Procédure Ancienne
procédure ASI
Description
Procédure A
« debit first »
4 Le SE envoie simultanément (sur un mode batch, avec des fichiers dédiés – ASTransferInitiation) l’ensemble des transactions au débit et au crédit entre le DCA RTGS de la banque de règlement et son propre compte technique ; dans un même batch, la somme des débits est égale à la somme des crédits).
Tous les débits doivent être imputés avant de pouvoir présenter les crédits, et la liquidité est bloquée sur les DCA RTGS impliqués jusqu’à ce que la dernière transaction au débit soit exécutée. Ensuite, toutes les opérations au crédit sont imputées sur les DCA RTGS concernés. Si une transaction créditrice échoue, les autres, si elles sont déjà exécutées, restent dénouées.
Procédure B
« all or nothing »
5 Comme pour la procédure A, le SE envoie simultanément (sur un mode batch, avec des fichiers dédiés – ASTransferInitiation) l’ensemble des transactions au débit et au crédit entre le DCA RTGS de la banque de règlement et son propre compte technique ; dans un même batch, la somme des débits est égale à la somme des crédits.
Les transactions sont placées dans une file d’attente sur le DCA RTGS des banques de règlement et font l’objet d’une optimisation, durant laquelle RTGS cherchera à imputer de manière simultanée tous les débits et les crédits d’un SE, sous une forme « tout ou rien ». En cas d’échec, toutes les transactions demeurent dans la file d’attente, et l’algorithme d’optimisation est à nouveau déclenché.
Cette procédure est notamment utilisée en France pour les règlements CORE(FR) ou GIE CB.
Procédure C règlement via
« sous- compte »
6 Interfacée Les paiements bilatéraux sont réglés de manière brute.
Les banques de paiement doivent ouvrir un sous-compte DCA RTGS par SE utilisant cette procédure, et l’alimenter en liquidité. Le SE peut initier des transactions entre le sous-compte de la banque de règlement et son compte technique, via des paiements unitaires ou par batch.
Procédure D préfinance-
ment de compte technique
6 Temps réel Les paiements bilatéraux sont réglés de manière brute.
Les banques de règlement doivent alimenter depuis leur DCA RTGS le compte technique du SE. Les livres du SE reflètent dans le compte miroir de la banque de règlement les fonds déposés sur le compte technique du système exogène.
Cette procédure est notamment utilisée en France pour les règlements de paiements instantanés dans SEPA(EU).
Procédure E 2 (règlement unitaire en temps réel)
et 3 (règlement
bilatéral)
Le SE envoie simultanément (sur un mode batch, avec des fichiers dédiés – ASTransferInitiation) l’ensemble des transactions au débit et au crédit entre les DCA RTGS des banques de règlement. Le SE peut aussi régler les soldes multilatéraux via son compte technique, en réglant les crédits après les débits.
Cette procédure correspond à l’actuelle procédure 3, notamment utilisée en France pour les règlements de LCH SA ou le prélèvement des garanties individuelles/intérêts de CORE(FR).
À noter que sur la future plateforme, les systèmes exogènes auront l’obligation de régler leurs positions en utilisant l’interface dédiée ASI (Ancillary System Interface).
L’utilisation de DCA RTGS dans T2 par des systèmes exogènes ou l’utilisation de paiements « purs » reste possible sous réserve d’octroi :
- soit d’une dérogation permanente (cas standards : pour la gestion des activités bancaires pour un système exogène qui aurait une licence bancaire, ou pour la gestion d’activités secondaires non liées au règlement des positions des membres comme la gestion de corporate actions ou la collecte et le paiement de frais) ;
- soit d’une dérogation temporaire (ex. : préparation de la migration d’un CSD à T2S ou mise à jour majeure des systèmes internes).
L’utilisation d’un MCA n’est pas en soi soumise à une demande de dérogation. Les systèmes exogènes pourront en particulier en ouvrir dans les cas où ils peuvent bénéficier de crédit intrajournalier, lorsqu’ils ont un DCA (DCA dans T2S pour les CSD pour le règlement de corporate actions en particulier), pour le règlement des factures liées à l’utilisation des services TARGET, pour les paiements d’intérêt (cas d’accumulation d’intérêts négatifs sur le compte technique utilisé dans le cadre de la procédure D), ou encore pour la gestion des activités bancaires pour les systèmes exogènes ayant une licence bancaire.
3.4. Interactions avec la banque centrale
3.4.1. Principes généraux
Pour rappel, l’ensemble des interactions avec la banque centrale est traité dans le CLM, sur le MCA désigné par le participant. En règle générale, l’ensemble des opérations de banque centrale est traité de manière prioritaire par rapport aux autres types d’opération, et ces opérations peuvent être initiées en mode A2A ou U2A.
Le système tente de les exécuter immédiatement après leur soumission (à l’exception des cas où la banque centrale en a instruit autrement, par exemple en configurant un report du règlement) et les opérations qui ne peuvent être immédiatement exécutées dans leur intégralité (pas d’exécution partielle) sont placées dans une file d’attente, depuis laquelle les ordres sont traités sur une base FIFO. Il n’existe aucun mécanisme d’optimisation dans le CLM, ni pour les opérations de banque centrale, ni pour les transferts de liquidité. Enfin, les ordres peuvent être révoqués par la banque centrale tant qu’ils ne sont pas réglés.
Comme indiqué précédemment, le participant a la possibilité de réserver sur son MCA une partie de la liquidité pour le règlement des opérations de banque centrale, la partie non réservée étant notamment affectée à l’exécution des transferts de liquidité ; si la partie réservée est insuffisante, l’ordre de tirage présenté précédemment (voir 3.1.2.1.) s’applique. En l’absence de liquidité dédiée sur le MCA ou si la réservation est insuffisante, le CLM utilisera pour régler les opérations de banque centrale la liquidité « non réservée » disponible sur le MCA.
3.4.2. Opérations de politique monétaire
Gestion et mise à jour de la ligne de crédit d’un établissement
La ligne de crédit assignée à un établissement contrepartie de politique monétaire est associée à l’unique MCA que cet établissement aura désigné. La liquidité générée par cette ligne de crédit peut par la suite être transférée et utilisée par d’autres MCA ou DCA.
S’agissant du pool de collatéral utilisé en garantie des opérations de politique monétaire et du calcul de la ligne de crédit intrajournalier, les modalités restent inchangées jusqu’au démarrage du projet ECMS9. L’application
9 Le projet ECMS démarrera un an après le projet de consolidation T2-T2S, soit en novembre 2023.
