T2 Business Description

2022
La consolidation des plateformes TARGET2 et

TARGET2-Securities : le futur service T2
Blueprint – Version 3 – Novembre 2022
Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

1
SOMMAIRE
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 ............................................ 9

2.1. PRINCIPES GÉNÉRAUX..................................................................................... 9
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......................................................................................................... 12
2.4. IDENTIFICATION DES COMPTES ET DES PARTICIPANTS .......................... 13
2.5. DÉNOMINATION DES COMPTES .................................................................... 14
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é .......... 18
3.2. GESTION DES PAIEMENTS DANS LE RTGS ................................................. 21
3.3. INTERFAÇAGE AVEC LES SYSTÈMES EXOGÈNES ..................................... 22
3.3.1. Principes généraux ............................................................................. 22
3.3.2. Procédures de règlement des systèmes exogènes (SE) ................ 23
3.4. INTERACTIONS AVEC LA BANQUE CENTRALE ........................................... 25
3.4.1. Principes généraux ............................................................................. 25
3.4.2. Opérations de politique monétaire ................................................... 25
3.4.3. Autres opérations de banque centrale ............................................. 27
4. LE RÉFÉRENTIEL COMMUN (CRDM) ET LA CONSTRUCTION DE L'ANNUAIRE

RTGS ......................................................................................................................... 28
5. REPORTINGS............................................................................................................ 30
6. BROADCASTS .......................................................................................................... 30
7. CALENDRIER ET JOURNÉE OPÉRATIONNELLE ................................................. 30

7.1. JOURNÉE OPÉRATIONNELLE ........................................................................ 30
7.2. CALENDRIER .................................................................................................... 33
8. MODULE DE CONTINGENCE .................................................................................. 34
9. FACTURATION ......................................................................................................... 34
2 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

10. TARIFICATION .......................................................................................................... 35
11. ENTREPÔT DE DONNÉES (DATA WAREHOUSE) ................................................ 35
12. CONNECTIVITÉ......................................................................................................... 36
12.1. MODALITÉS D’ACCÈS DE CONNECTIVITÉ POUR LES
PARTICIPANTS ................................................................................................. 36
12.1.1 ESMIG - une passerelle d’accès unique ........................................... 36
12.1.2 L’accès en mode A2A : abandon du mode Y-Copy ........................ 37
12.1.3 L’accès en mode U2A ........................................................................ 37
12.2 CONFIGURATION DES DROITS D’ACCÈS SUR LA PLATEFORME
CONSOLIDÉE.................................................................................................... 37
13 GESTION DE LA MIGRATION.................................................................................. 38
13.1 MIGRATION EN « BIG BANG » ........................................................................ 38
13.2 FORMATION ET INFORMATION DES FUTURS UTILISATEURS .................. 39
13.2.1 Organisation des relais de formation par la Banque de France .... 39
13.2.2 Diffusion et mise à disposition de l’information ............................. 39
14 GESTION DES ADHÉSIONS .................................................................................... 39

14.1 FORMULAIRES ................................................................................................. 39
14.2 TESTS ET CERTIFICATION ............................................................................. 39
14.3 MODIFICATION DE LA DOCUMENTATION D’ADHÉSION À TARGET-
BANQUE DE FRANCE ...................................................................................... 40
15 CE QUI CHANGE POUR TARGET2 ......................................................................... 40

15.1 CONNECTIVITÉ : CHOIX DES PRESTATAIRES DE SERVICE RÉSEAU,
ABANDON DU Y-COPY ET SUPPRESSION DE L’ACCÈS INTERNET .......... 40
15.2 SUPPRESSION DES COMPTES HAM ET PM ................................................. 41
15.3 SUPPRESSION DE LA FONCTIONNALITÉ VIRTUAL ACCOUNT .................. 41
15.4 ABANDON DU FORMAT DE MESSAGE ISO 15022........................................ 41
16 CE QUI CHANGE POUR T2S ................................................................................... 41

16.1 JOURNÉE OPÉRATIONNELLE ........................................................................ 41
16.2 APPORT / RETRAIT DE LIQUIDITÉ ................................................................. 42
16.3 DONNÉES DE RÉFÉRENCE ............................................................................ 42
16.4 ADAPTATIONS À ESMIG .................................................................................. 42
17 EXEMPLES DE CONFIGURATIONS POSSIBLES .................................................. 42

17.1 EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE À CARACTÈRE
CENTRALISÉ..................................................................................................... 42
17.2 EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE À CARACTÈRE
DÉCENTRALISÉ................................................................................................ 43
17.3 EXEMPLE DE CONFIGURATION POUR UNE STRUCTURE MUTUALISTE . 44
18 CONTACTS ............................................................................................................... 44

3
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.
L’ensemble de la documentation de référence publié par l’Eurosystème sur le projet de consolidation est
disponible sur le site Internet de la Banque centrale européenne.Les informations communiquées dans ce
document reposent sur les dernières versions disponibles :
 de l’ User Requirements Document (URD) v.3.0
 de l’User Detailed Functional Specifications (UDFS) v.3.0
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, et a été actualisée en janvier 2021 suite au
premier report du « go-live » du 22 novembre 2021 au 21 novembre 20221. 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 second report de 4 mois du « go-live », du 21 novembre 2022 au 20 mars 2023 2 ;
 d’apporter des précisions sur la documentation juridique et contractuelle pour devenir participant à la
nouvelle plateforme.,
1 https://www.ecb.europa.eu/paym/intro/news/html/ecb.mipnews200728.en.html
2 Eurosystem reschedules start of renewed wholesale payment system (europa.eu)

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 20183.
 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 prestataires 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 mars 2023.
 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.
3
TIPS a fait l’objet d’un Blueprint dédié, disponible sur le site de la Banque de France à cette adresse.

5
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 prestataire 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’Eurosystème a en l’occurence agrée
en 2019 deux prestataires de service réseau SIA-COLT et SWIFT. L’accès sera possible soit en mode manuel
U2A (User to Application), soit en mode automatisé A2A (Application to Application), et les fournisseurs
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 ;

7
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 a été décalée au 20 mars4 2023 sur
un mode « big bang ».
Les tests utilisateurs ont débuté en décembre 2021, et portent sur l’ensemble des fonctionnalités de la
plateforme. Suite au décalage de la mise en production, un nouveau calendrier a été présenté (cf. Schéma 3).
Schéma 2 – Macro-planning du projet de consolidation avant le décalage au 20/03/2023
4 Le Conseil des gouverneurs de la Banque centrale européenne (BCE) a décidé le 20 octobre 2022 de reporter le lancement de la
consolidation de quatre mois, du 21 novembre 2022 au 20 mars 2023 (cf communiqué de presse). La décision a été motivée par la
nécessité de laisser aux utilisateurs plus de temps pour terminer leurs tests dans un environnement stable.

Schéma 3 – Macro-planning du projet de consolidation après le décalage au 20/03/2023
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 4).
 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).

9
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 4 - Modèle de base de centralisation de la liquidité autour du Main Cash Account :

Crédit intrajournalier (ligne de crédit)
Facilité de prêt marginal / facilité de
dépôt
Opérations de banque centrale, y
Main compris retraits espèces
Cash
Account
T2S RTGS TIPS

DCA DCA DCA
Règlement-livraison Paiements en temps- Paiements instantanés

de titres réel interbancaires et
clients, déversement
des systèmes
exogènes
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 Accès RTGS multi-

indirect/BIC adressable destinataires
Émettre et recevoir des Directement Via le participant direct Directement

paiements RTGS
Possède son propre DCA Oui Non Non

RTGS
Approvisionnement en Sur son DCA RTGS Via le participant direct Via le participant direct
liquidité RTGS RTGS
Contrôle de la liquidité En propre Via le participant direct Via le participant direct

RTGS RTGS
Accès U2A (via le GUI) Oui Non Non
Adressabilité Directement adressable Adressable via le Directement adressable

participant direct RTGS5
Publication dans le RTGS En tant que participant En tant que participant En tant qu’accès RTGS
Directory direct RTGS RTGS indirect/BIC multi-destinataires
adressable
5 Pour ce faire, les participants indirects disposent d’un BIC11 qui leur est propre (cf. 2.4).

11
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 devise6. 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.
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.
6 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.

 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ération7.
 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.
Schéma 5 - Exemple d’un participant CLM avec deux MCA :
7 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.

13
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 TIPS 8. 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.
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é.
8 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.

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

15
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 RTGS9. 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.
Schéma 6 - Exemple d’articulation entre LTG et AMG au niveau international
Source : BCE, Business Description Document
9 À noter que pour le MCA, la fonction prend uniquement en compte le solde espèces, et non la ligne de crédit disponible.

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…).

17
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’attente 10 (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.
Business purpose Ordre de tirage de la liquidité

MCA
MCA RTGS DCA
Réservé aux Réservé aux Réservé aux
opérations de paiements paiements
banque centrale Non réservé "Urgent" "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
RTGS DCA
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
*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.
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.
10 Le concept de file d’attente a le même sens dans ce document que pour TARGET2 actuellement.

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
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 :

19
 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 7 - 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

21
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 8 - 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 :

23
Procédure Ancienne Description
procédure
ASI
Procédure A 4 Le SE envoie simultanément (sur un mode batch, avec des fichiers dédiés –
« debit first » 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 5 Comme pour la procédure A, le SE envoie simultanément (sur un mode batch, avec des
« all or fichiers dédiés – ASTransferInitiation) l’ensemble des transactions au débit et au crédit
nothing » 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 6 Interfacée Les paiements bilatéraux sont réglés de manière brute.
règlement via Les banques de paiement doivent ouvrir un sous-compte DCA RTGS par SE utilisant
« sous- cette procédure, et l’alimenter en liquidité. Le SE peut initier des transactions entre le
compte » sous-compte de la banque de règlement et son compte technique, via des paiements
unitaires ou par batch.
Procédure D 6 Temps réel Les paiements bilatéraux sont réglés de manière brute.
préfinance- Les banques de règlement doivent alimenter depuis leur DCA RTGS le compte
ment de technique du SE. Les livres du SE reflètent dans le compte miroir de la banque de
compte règlement les fonds déposés sur le compte technique du système exogène.
technique
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 Le SE envoie simultanément (sur un mode batch, avec des fichiers dédiés –
unitaire en ASTransferInitiation) l’ensemble des transactions au débit et au crédit entre les DCA
temps réel) RTGS des banques de règlement. Le SE peut aussi régler les soldes multilatéraux via
et 3 son compte technique, en réglant les crédits après les débits.
(règlement Cette procédure correspond à l’actuelle procédure 3, notamment utilisée en France
bilatéral) 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 ECMS11. L’application
Banque de France POOL3G assurera dans l’intervalle les mises à jour en temps réel des lignes de crédit
intrajournalier associées aux comptes MCA désignés par les établissements de crédit.
Toute modification de la ligne de crédit associée à un MCA en lien avec un paiement se matérialisera par
l’initiation par la banque centrale d’un connected payment, qui viendra simultanément débiter ou créditer le
compte du participant et modifier sa ligne de crédit. Ces paiements seront traités avec le plus haut niveau de
priorité par rapport à toutes les autres opérations/transactions/paiements sur le MCA (y compris les autres
opérations de banque centrale – autrement dit, il y a ici une catégorisation plus fine entre des opérations qui ont
le même degré de priorité), et seront exécutés immédiatement.
11 Le projet ECMS démarrera un an après le projet de consolidation T2-T2S, soit en novembre 2023.

25
Dans l’hypothèse où une modification à la baisse de cette ligne de crédit entraînerait la nécessité de rembourser
tout ou partie du crédit intrajournalier dont aurait bénéficié un établissement, la liquidité serait
automatiquement retirée du DCA RTGS défini par défaut pour les paiements interbancaires et de clientèle en
temps réel, d’abord de la partie non-réservée, puis de la partie réservée. Si la liquidité disponible a sur ces deux
comptes, MCA et DCA RTGS par défaut, est insuffisante pour couvrir ce remboursement, tout afflux de liquidité
sur chacun de ces deux comptes sera prioritairement affecté à celui-ci, jusqu’à remboursement total.
Facilités de prêt marginal et de dépôt

Le recours aux facilités de prêt marginal (contre actifs éligibles) et de dépôt (« standing facilities ») nécessite,
pour la contrepartie de politique monétaire souhaitant y avoir recours :
 d’une part, d’être participant CLM en étant titulaire d’un compte MCA ;
 d’autre part, d’être titulaire respectivement d’un compte dédié à la facilité de prêt marginal et d’un
compte dédié à la facilité de dépôt (toujours dans le CLM).
Facilité de prêt marginal

Pour ce qui est de la facilité de prêt marginal, les workflows peuvent être de deux types :
 Conversion automatique des soldes débiteurs en fin de journée : en fin de journée comptable, après le
cut-off des opérations, le CLM détermine la position espèces globale du participant en sommant les soldes
de fin de journée de l’ensemble de ses MCA et DCA. Si la position est globalement débitrice (crédit
intrajournalier non-remboursé), le module convertira ce solde en facilité de prêt marginal.
Le règlement de celle-ci se matérialise par l’imputation d’un connected payment (crédit du compte MCA,
débit du compte dédié, et diminution concomitante de la ligne de crédit). En début de journée comptable
suivante, le CLM procèdera au remboursement de la facilité de prêt en cours (débit du MCA, crédit du
compte dédié) et à la perception des intérêts courus associés (débit du MCA du participant, crédit du
compte de la banque centrale).
 Facilité de prêt marginal à la demande : les participants peuvent par ailleurs adresser des demandes
d’overnight credit à leur banque centrale qui, s’ils disposent de la ligne de crédit idoine, enverra une
demande au CLM (A2A via le système de gestion du collatéral, ou U2A). À la réception de cette demande,
le CLM procédera à la génération des ordres (pour la mise en place de la facilité d’une part, puis pour son
remboursement incluant les intérêts associés d’autre part).
Facilité de dépôt
Les participants ont la possibilité de déposer des fonds overnight sur un compte CLM dédié auprès de leur banque
centrale nationale. Ils peuvent modifier le solde de ce compte soit en transférant de la liquidité depuis le MCA,
soit en procédant à des reverse transactions en sens inverse pour réduire le montant déposé overnight (avant le
cut-off pour les standing facilities).
Les demandes peuvent être initiées en mode U2A ou A2A, dès le début de la journée comptable. Ces dernières
seront traitées au fil de l’eau par le CLM qui initiera des ordres de transfert de liquidité (débit du MCA en
contrepartie du crédit du compte dédié aux overnight deposits). Le système tentera de régler ces ordres
immédiatement après leur soumission, et ces ordres peuvent être révoqués tant qu’ils ne sont pas exécutés. Si
la liquidité est insuffisante dans CLM, les transferts de liquidité vers le compte dédié sont rejetés et les ordres de
transferts de liquidité ne sont pas placés dans une file d’attente (pas de règlement partiel) ; en revanche, la
liquidité présente sur les DCA RTGS peut être utilisée pour suppléer la liquidité manquante sur le MCA.
Après calcul des intérêts associés à ce dépôt overnight, le CLM renvoie automatiquement en début de journée
comptable suivante les fonds déposés vers le MCA du participant, sur lequel il crédite les intérêts dus (ou débite,
en cas de taux négatifs).

Réserves obligatoires
Aux fins d’évaluation du respect de la cible de réserves obligatoires par un établissement, les soldes présents sur
l’ensemble des comptes MCA et DCA (RTGS, TIPS, T2S) de cet établissement sont considérés.
Comme c’est le cas actuellement, les réserves pourront être constituées (de manière exclusive) :
- soit directement, sur les comptes que détient l’établissement auprès de la banque centrale ;
- soit indirectement, via un intermédiaire résidant dans le même état membre et lui aussi soumis à
obligation de constitution des réserves obligatoires. Dans ce cas, le montant total des réserves
obligatoires des deux établissements est pris en compte dans le calcul de la cible, mais les fonds
considérés pour juger de son respect sont uniquement ceux présents sur les comptes de l’intermédiaire
(quand bien même l’entité qui constitue ses réserves de manière indirecte aurait un ou des comptes
auprès de la banque centrale) ;
- soit sur un mode pooling pour des entités appartenant à la même entité monétaire et financière au sens
statistique : sont alors considérés dans l’appréciation de l’atteinte de la cible les soldes présents sur
l’ensemble des MCA et DCA des entités du groupe. À noter que la consolidation n’est pas possible en
cross-border. Au terme de la période de maintenance, les intérêts éventuels sont versés (ou débités) sur
le MCA désigné par le leader du groupe.
Au terme de la période de constitution des réserves, la banque centrale responsable entre le montant cible en
mode U2A ou A2A.
Après traitement de l’ensemble des opérations de facilités de prêt marginal et de dépôt, le système vérifie que
les institutions monétaires et financières (IMF) remplissent leurs obligations de constitution du montant de
réserves obligatoires (ci-après, « RO ») adéquat, par consolidation des soldes espèces de fin de journée dont ces
institutions disposent sur l’ensemble des MCA et DCA ouverts auprès d’une même banque centrale.
Ainsi, une fois reçus les fichiers de fin de journée du CLM, du RTGS, de T2S et de TIPS, le CLM :
 calcule les soldes de fin de journée de l’IMF ainsi que les moyennes de soldes mobiles ;
 vérifie le respect quotidien des exigences en RO pour chaque IMF et calcule le solde ajusté pour le reste
de la période de maintenance ;
 calcule l’intérêt à verser aux IMF après la fin de la période de maintenance ;
 calcule les pénalités liées au manquement aux obligations de constitution des RO qui sont soumises à la
validation de la banque centrale à la fin de la période de constitution des RO ;
 calcule les intérêts négatifs sur les réserves en excès à la fin de la période de constitution des RO ;
 notifie la banque centrale du respect des exigences en RO, de l’intérêt dû et des éventuelles pénalités
relatifs à l’IMF en fin de période de constitution des RO ;
 crée automatiquement les instructions de crédit et débit pour les versements d’intérêts relatifs au
respect des exigences en RO et les envoie à CLM à la fin de la période de constitution des RO.
3.4.3. Autres opérations de banque centrale

Les opérations de banque centrale (opérations d’open market, perceptions des frais, opérations fiduciaires de
retrait/dépôts d’espèces) se matérialisent par des opérations initiées par les banques centrales de débit ou de
crédit du MCA des participants, avec comme contrepartie le compte de la banque centrale concernée. À noter
que les opérations de numéraire pourront aussi se réaliser à partir des DCA du RTGS.

27
4. Le référentiel commun (CRDM) et la
construction de l'annuaire RTGS
Le référentiel commun (CRDM) permet de centraliser l’ensemble des données de références (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 les incohérences entre les différents services TARGET (ex. si les numéros de compte
sont erronés). Le CRDM est accessible à la fois en mode U2A et A2A (pour un sous ensemble de fonctions).
Afin d’assurer une diffusion rapide et cohérente des données de référence communes aux différents services
TARGET, CRDM permet à chacun d’eux de souscrire à leur réception quotidienne. Par ailleurs, lorsque certaines
actions sensibles sont effectuées sur ces données référentielles (ex. : blocage par la banque centrale d’un compte
ou d’un participant), CRDM permet une diffusion et une mise en œuvre effective en temps réel dans les différents
services/composantes.
Schéma 9 - Interaction de CRDM avec les services
À l’instar de TIPS, RTGS dispose de son propre annuaire qui pourra fournir, en mode A2A ou U2A, les informations
relatives à l’ensemble des parties adressables via T2 RTGS, sur la base des données fournies dans le CRDM. Un
participant peut demander à ce que son BIC 11 ne soit pas publié dans l’annuaire T2 RTGS – dans ce cas, ses
contreparties ne pourront initier des paiements vers le compte lié à ce BIC 11 que si celui-ci leur a été
préalablement fourni.
Compte-tenu de la structure de l’annuaire RTGS, l’adressage d’un paiement s’effectuera en utilisant les BIC
suivants :
- le champ « BIC » servira à identifier de manière unique le participant dans le RTGS (pour tous les types
de participation – directe, indirecte, multi-adresse, adressable) et pour tous les types de participation
le BIC entré dans l’objet « Authorised Account User » sera utilisé ;
- le champ « addressee BIC » servira à identifier le participant émettant ou recevant les messages (il
s’agira soit du BIC du participant direct, soit du BIC du multi-destinataires ;
- le champ « Account BIC » servira à identifier le DCA RTGS sur lequel le règlement doit s’imputer.

Ainsi, par exemple, dans le cas d’un party ABCDFRPPXXX, où ABCDFRPPXX1 est un multi-adresse (stocké dans
Authorised Account User avec « participation type » « 03 multi addressee – Credit Institution » ou « 04 multi
addressee – Branch of Direct participant »), EFGHFRPPXXX est un participant indirect (stocké dans Authorized
Account User comme « 02 indirect »), et ABCDJPTKXX2 est un adressable (stocké dans Authorized Account User
comme (« 05 addressable BIC – Correspondent », « 06 addressable BIC – Branch of Direct participant », « 07
addressable BIC – Branch of Indirect participant », « 08 addressable BIC – Branch of correspondent »), la structure
de compte serait la suivante :
L’annuaire RTGS serait rempli de la manière suivante :

29
5. Reportings
Pour leur permettre d’assurer la surveillance de la liquidité, T2 fournit à ses participants des informations sur
leurs propres comptes (MCA, DCA). Ces informations portent notamment sur les montants réglés, les soldes des
différents DCA, etc.
Pour pouvoir accéder aux informations des parties tierces, les participants doivent avoir été mandatés et
posséder les droits d’accès correspondants.
La fourniture des informations repose sur trois outils distincts : les notifications, les rapports et les requêtes.
 Les notifications sont générées automatiquement, dès survenance de l’événement qui les motive ; si
certaines notifications ont un caractère systématique (par exemple, les notifications d’échec de
règlement), d’autres sont optionnelles et proposées aux participants à la souscription (ex. : confirmation
de règlement).
 Les rapports fournissent des informations prédéfinies concernant un MCA pour CLM, ou un DCA pour
RTGS (« statement of account ») comme les items réglés sur un compte au cours d’une journée
opérationnelle ou le solde de fin de journée. Ces rapports ne peuvent à chaque fois que porter sur un seul
et unique compte (DCA ou MCA) et les UDFS ne prévoient pas la possibilité d’un rapport combinant des
informations du CLM et du RTGS. Le participant doit avoir préalablement souscrit à ces rapports en
paramétrant leur configuration. Il doit en particulier décider des critères d’envoi : le rapport n’est jamais
créé en intrajournalier mais toujours en fin de journée, et peut être envoyé dès sa création en mode A2A,
ou stocké et téléchargé en mode U2A.
 Dans le cadre de la surveillance de la liquidité, les requêtes sont des interrogations en temps réel sur
certaines informations telles que les soldes du compte ou les limites ; elles peuvent être soumises par le
participant en mode U2A ou A2A. Ces requêtes sont, sauf durant la mise en œuvre de la fenêtre de
maintenance, traitées en temps réel. Les participants peuvent par ailleurs formuler des requêtes sur
données historiques à l’aide de rapports prédéfinis dans le Data Warehouse, en mode A2A ou U2A.
6. Broadcasts
CLM et RTGS pourront par ailleurs diffuser à leurs participants certains messages d’information (broadcasts) en
mode U2A ou A2A, de manière automatique lorsque ces messages sont liés au règlement (settlement-related)
sur la base de business cases prédéfinis (ex. : début d’une période d’information d’une procédure de règlement
de système exogène), ou suite à une requête U2A de la banque centrale ou de l’opérateur pour des informations
liées à des opérations (operation-related), afin que les participants puissent intégrer ces informations à leurs
outils de gestion de la liquidité. Les broadcasts sont obligatoirement reçus en mode U2A par les participants (pas
d’opt-out), et sont reçus en mode A2A pour les participants qui ont choisi de recevoir des notifications sur ce
mode (ce choix doit être effectué par service).
7. Calendrier et journée opérationnelle
7.1. Journée opérationnelle

À l’intérieur d’un même service ou d’une même composante, la journée opérationnelle débute et s’achève au
même moment pour toutes les devises traitées (common business day management).
En revanche, le planning de la journée opérationnelle varie selon chacun des différents services (T2, T2S, TIPS,
etc.), et le changement de journée opérationnelle ne s’opère pas nécessairement au même moment entre les

différents services et composantes. Les interactions entre les services et composantes ne sont possibles que si la
journée opérationnelle est la même pour ces services et composantes.
Le planning prévu pour les différents services TARGET et leurs composantes repose notamment sur une
synchronisation du début des traitements de fin de journée comptable, un alignement de la fenêtre de
maintenance de T2 sur celle de T2S (de 3h à 5h du matin en semaine, de 2h30 le samedi à 2h30 le lundi pour le
week-end), et le fait que cette fenêtre de maintenance sera désormais optionnelle en semaine (pour T2 comme
pour T2S) - ce qui signifie qu’à l’exception des fois où elle sera activée, il n’y aura par défaut pas de fenêtre de
maintenance en semaine. Les paiements en date de valeur future pourront être modifiés dans le RTGS jusqu’à
2h30 le samedi, et les paiements interbancaires et de clientèle commenceront à s’imputer à partir de 2h30 le
lundi. À noter par ailleurs une disparition de la distinction entre procédures de jour et procédures de nuit pour
le règlement des systèmes exogènes : hors activation de la fenêtre de maintenance, et hors procédures de
traitement de fin et de début de journées, toutes les procédures de règlement des systèmes exogènes seront
utilisables sans distinction.
Les graphiques suivants reprennent le planning prévisionnel de la journée opérationnelle de CLM et RTGS, en
semaine et le week-end :
Schéma 10 : Planning prévisionnel de la journée opérationnelle de CLM après les jours de fermeture de T2

31
Schéma 11 : Planning prévisionnel de la journée opérationnelle de RTGS après les jours de fermeture de T2
Schéma 12 : Planning prévisionnel de la journée opérationnelle de CLM les jours ne suivant pas un
jour de fermeture de T2

Schéma 13 : Planning prévisionnel de la journée opérationnelle de RTGS les jours ne suivant pas un
jour de fermeture de T2
7.2. Calendrier
À ce stade, il n’est pas prévu de modifier les calendriers T2 et T2S (cf. tableau ci-après).
Rappel du calendrier des jours fermés de T2 et T2S

T2 T2S
1er janvier 1er janvier
Vendredi Saint Vendredi Saint
Lundi de Pâques Lundi de Pâques
1er mai -
25 décembre 25 décembre
26 décembre 26 décembre
Lors d’une journée de fermeture de T2 qui n’est pas une journée de fermeture de T2S, les transactions peuvent
être dénouées en livraison franco de paiement (free of payment) dans T2S ou dans une devise de règlement
autre que l’euro (couronne danoise dans T2S). Chaque service TARGET pourra avoir un calendrier différent par
devise et par ailleurs, pour le règlement dans des devises non-euro, T2S pourra être ouvert durant les jours
mentionnés dans le tableau ci-dessus dès lors que le RTGS de la devise de règlement concernée est ouvert (par
exemple, le 1er mai pour la couronne danoise).

33
8. Module de contingence
La future plateforme continuera à bénéficier d’un module de contingence, qui s’appuiera sur le module ECONS
entré en production avec la v.13.0 de la plateforme TARGET2 le 16 novembre 2019 et qui est venu renforcer sa
résilience opérationnelle. Ainsi, en cas d’incident durable, ECONS peut être utilisé jusqu’à 5 journées comptables
consécutives.
Pour mémoire, à l’instar de l’ancien module de contingence de TARGET2, ECONS fonctionne sur la base d’une
balance nulle à l’ouverture, alimentée sur la base d’injections de liquidité à partir du crédit réservé dans le pool
3G, d’un apport de collatéral supplémentaire et/ou des soldes disponibles sur T2S, le solde disponible dans
ECONS étant rebasculé dans TARGET2 sur le compte PM lorsque le module est fermé.
En revanche, à la différence de l’ancien module de contingence, ECONS est directement accessible aux
établissements accrédités12, en mode U2A, afin de leur permettre de piloter leur liquidité et d’initier leurs
paiements critiques. Comme aujourd’hui, les deux premières heures d’ouverture seront réservées aux
règlements « très critiques » (i.e. CLS, EURO1 et LCH). Au-delà, le règlement d’opérations « critiques » (i.e. tous
les autres SE) est autorisé par défaut. Toute exception à ce principe durant les deux premières heures nécessite
l’accord des « crisis managers T2 », sous réserve de démontrer que l’absence de règlement d’une opération
critique engendrerait un risque systémique.
Les participants pourront aussi obtenir un relevé de compte de leurs opérations réglées en le téléchargeant à
partir du module. La connexion à ECONS est obligatoire pour tous les participants critiques à TARGET2 ainsi que
les banques centrales de l’Eurosystème, et possible pour les autres participants et banques centrales (la
possibilité de rendre la connexion obligatoire pour tous les participants est actuellement à l’étude).
Le module de contingence de la future plateforme s’appellera ECONS II, et ne devrait pas présenter de
changement fonctionnel d’importance par rapport à ECONS. Il permettra l’utilisation des composants communs
(notamment ESMIG et CRDM), et sera lié aux systèmes de gestion du collatéral des banques centrales (et à ECMS
à partir de sa mise en production).
9. Facturation
Le nouveau module de facturation (billing) assure la gestion des factures (création, envoi et annulation) des
différents services TARGET, et permet d’adresser :
 les fichiers de consommation aux BCN / CSD ;
 les factures aux participants intéressés.
L’opérateur surveille le bon fonctionnement du module et est responsable de la confirmation et de l’envoi des
factures créées (et, dans des cas exceptionnels, de leur annulation) ; la BCE gère les factures qui ont vocation à
être envoyées aux banques centrales. Le module permet aux banques centrales comme à leurs participants de
recevoir les factures en mode A2A, et offre en particulier aux banques centrales la possibilité de configurer une
facturation directe à ses participants et un débit direct du montant de leur facture. Les banques centrales
peuvent accéder au module en mode A2A comme en mode U2A, et peuvent effectuer des requêtes ou modifier
les données de facturation de leurs participants.
Pour offrir ces fonctionnalités, le service de facturation collecte et agrège les données brutes de l’ensemble des
services (T2S, TIPS, T2) sur une base quotidienne et produit les factures sur une base mensuelle afin de les
adresser aux banques centrales, aux CSD et aux participants.
12 Dans un 1er temps, l’accès à ECONS sera limité aux participants TARGET2 critiques, aux systèmes exogènes critiques ainsi que leurs banques
de règlement.

Les parties pourront définir, dans le CRDM et pour chaque compte, toute l’information pertinente pour la
facturation (à qui la facture doit être envoyée, quel MCA doit être débité, etc.).
Il sera toujours possible de distinguer trois niveaux dans la facturation :

 le participant qui déclenche un événement facturable ;
 le participant qui est facturé ;
 le participant qui paie la facture.
10. Tarification
Le Conseil des gouverneurs a approuvé le 18 juin 2020 les grandes lignes de la politique tarifaire de T2, qui sera
introduite dans le cadre du projet de consolidation T2-T2S et remplacera celle de TARGET213.
Alors que la tarification de TARGET2 visait à atteindre un objectif de recouvrement total des coûts
(développement et opérations), cet objectif ne sera poursuivi, en ce qui concerne la future plateforme T2, que
pour la partie RTGS (à horizon de 10 ans après le go-live) et non pour la partie CLM. En effet, du fait du lien direct
de cette dernière avec la mise en œuvre de la politique monétaire, ses coûts ne seront pas recouvrés par
l’Eurosystème.
Pour la partie RTGS, le principe général actuellement appliqué pour TARGET2 d’une tarification dégressive avec
les volumes des transactions sera maintenu. Néanmoins, deux évolutions seront introduites : (i) l’ajout de deux
nouvelles tranches supérieures sur les volumes de transaction pour les participants qui atteignent des niveaux
définis (facturation à 0,08 € et 0,05 € par transaction) ; (ii) une hausse des tarifs appliqués aux transactions des
systèmes exogènes, en lien avec les coûts pour l’Eurosystème de la fourniture de services qui leur sont
spécifiques.
11. Entrepôt de données (Data Warehouse)

Le Data Warehouse (DWH) partagé consolide les données sur les transactions transitant par les différents
services et composantes (T2S, CLM, RTGS14) dès la journée opérationnelle suivant la transaction, et permet
notamment aux participants d’accéder à leurs données pour répondre à leurs besoins statistiques et de
reporting, via des rapports ou des requêtes (prédéfinies / ad hoc). Les informations seront stockées dans le DWH
pendant 10 ans au moins (durée par défaut) – à noter que c’est un autre système qui sera en charge de l’archivage
légal. L’accès au DHW sera possible en mode A2A ou U2A.
Les rapports prédéfinis visent à répondre tant aux besoins opérationnels que statistiques (recherche
d’opérations, constitution des réserves obligatoires, utilisation du crédit intrajournalier, utilisation des facilités
permanentes, activité du participant, facturation et surveillance). Ils sont disponibles soit sous forme de rapports
complets, soit sous forme de rapports « delta » où ne figurent que les changements depuis le rapport précédent.
Ils peuvent être générés à la demande ou selon une planification établie par l’utilisateur (horaire ou événement
déclencheur). Une fois constitués, ils peuvent également être envoyés immédiatement en mode « push ».
En sus des rapports prédéfinis, les utilisateurs disposent d’une interface leur permettant de concevoir leurs
propres requêtes ou d’adapter des requêtes existantes. Pour ces requêtes libres, l’utilisateur peut définir le type
de données à afficher, lier des sources de données différentes (ex. T2S, RTGS, CLM), fixer des conditions pour
l’exécution de la requête, appliquer des filtres et des tris, agréger des données, appliquer des fonctions
statistiques et limiter la quantité de résultats. Une fois définies, ces requêtes peuvent être sauvegardées par
l’utilisateur. Leurs résultats peuvent être affichés à l’écran ou exportés sous différents formats (ex.: .xlsx, .txt)
afin de permettre le traitement de ces données dans d’autres applications.
14 Dans un premier temps, l’entrepôt de données n’est toutefois pas disponible pour TIPS.

35
Dans la mesure du possible, l’Eurosystème limitera les ruptures de données consécutives à l’abandon du format
15022 au profit du format ISO 20022.
Au lancement de T2, la DWH sera disponible sur un périmètre limité à 6 rapports prédéfinis. L’intégralité de la
DWH sera livrée après le go-live (cf. Schéma 3 sur le planning)
12. Connectivité
12.1.Modalités d’accès de connectivité pour les participants
12.1.1 ESMIG - une passerelle d’accès unique

Dans le cadre du projet de consolidation une passerelle unique baptisée « ESMIG » (Eurosystem Single Market
Infrastructure Gateway) permet d’accéder aux infrastructures de marché de l’Eurosystème (services TARGET et
composantes communes, ainsi qu’ECMS à partir de 2023), après authentification de l’utilisateur (via l’octroi de
certificats digitaux aux acteurs souhaitant un accès A2A ou U2A) et vérification qu’il dispose des droits d’accès
idoines. ESMIG procède à une validation technique de tous les messages entrants, et à leur routage vers le NSP
(Network service providers)/service idoine.
L’accès via ESMIG est possible en mode U2A (via GUI) et A2A, via des prestataires de service réseau (NSP). La
passerelle est agnostique vis-à-vis du choix du prestataire et les utilisateurs sont ainsi libres de choisir celui-ci,
pourvu qu’il soit conforme aux exigences techniques et de sécurité définies par l’Eurosystème. Au terme d’une
procédure de sélection qui s’est déroulée au cours du 1er semestre 2019, ce dernier a ainsi signé des contrats de
concession d’une durée de 10 ans avec deux NSP, SWIFT et SIA COLT, et leur a confié la tâche de fournir un
ensemble de services de connectivité prédéfinis pour des prix maximum qui ont été publiés 15 et déprendront
des volumes de messages transmis et non du nombre de services TARGET auxquels un participant souscrira.
Autrement dit, les deux prestataires de service réseau auront la même interface de communication vis-à-vis
d’ESMIG. À partir de ces services de connectivité prédéfinis, SWIFT et SIA COLT pourront concevoir, mettre en
œuvre, proposer et exploiter des solutions de connectivité (possibilité de déployer des services réseau et
messagerie additionnels) permettant la connexion de réseau directe à ESMIG.
Les contrats de concession ont été conclus pour une durée de dix ans, à partir de novembre 2021 pour TIPS, juin
2022 pour T2S (expiration de l’actuel Licence Agreement), novembre 2022 pour ECMS.
Par ailleurs, l’Eurosystème insiste sur la nécessité, pour les NSP retenus, de développer une solution économique
et facile d’accès en mode U2A (via GUI), notamment pour les participants ne traitant qu’un faible volume de
paiements.
Par ailleurs, ESMIG :

 doit permettre de faire face à la volumétrie engendrée par les différents services, en garantissant que le
trafic sur un service n’impacte pas le délai de traitement des messages d’un autre service ;
 offre des mesures de continuité d’activité (sites multiples, plusieurs chemins d’accès, etc.) ;
 archive tous les messages émis et reçus. La période de rétention est configurable (jusqu’à 30 jours). Après
cette période, les données sont disponibles via le service d’archivage légal pour une période définie par
la réglementation.

12.1.2 L’accès en mode A2A : abandon du mode Y-Copy
Dans cette logique, avec la mise en œuvre d’ESMIG, l’Eurosystème abandonne l’utilisation du mode Y-copy,
reposant sur une fonctionnalité spécifique à SWIFT, au profit du mode V-shape.
Schéma 10 - Le mode V-shape
Party A Party B
Network Service
Provider
En effet, avec le format Y-copy, le réseau SWIFT jouait un rôle central puisqu’il démembrait le paiement avant
d’envoyer une copie du message (MT096) au module de règlement de TARGET2 pour imputation des comptes.
Après confirmation de l’imputation par la plateforme/SSP (Single Shared Platform) dans le module PM (MT097),
SWIFT reconstituait le message et le transférait à la banque destinataire pour notification.
En mode V-shape, les paiements envoyés par l’émetteur ne sont plus démembrés par le réseau SWIFT mais
transférés au module de règlement de la plateforme T2 qui envoie la confirmation du règlement directement à
la banque destinataire.
La communication en mode A2A entre les participants et T2 (CLM et CRDM) s’appuie sur des messages au format
ISO 20022 et ESMIG ne prévoit ni coexistence avec les messages MT, ni service de conversion.
12.1.3 L’accès en mode U2A

Les utilisateurs peuvent accéder au RTGS, CLM, TIPS, T2S, CRDM et DWH via des interfaces graphiques utilisateurs
(GUI) (chaque service ou composante devrait disposer de son propre GUI 16). Ils pourront se connecter avec un
unique identifiant et un unique certificat, puis choisir la page du service ou de la composante spécifique à laquelle
ils souhaitent accéder.
12.2 Configuration des droits d’accès sur la plateforme

consolidée
Une fois les utilisateurs authentifiés, et leur droit d’accès à un service ou composante vérifié, les modalités de
l’accès dépendront des privilèges applicatifs accordés à chaque utilisateur. Ces privilèges, organisés en « rôles »
permettant d’exécuter des fonctions associées (en mode « lecture seule », ou « action »), sont gérés dans le
CRDM afin d’être rattachés aux utilisateurs U2A / A2A des participants ou banques centrales.
Les rôles utilisateurs sont disponibles :

 en accès U2A, selon la règle des 2 ou des 4 yeux (les actions réalisées par le 1er utilisateur doivent être
confirmées par un second utilisateur) ;
16 À cet effet, l’Eurosystème veillera à l’homogénéité des différentes interfaces déployées, sans toutefois s’engager à une démarche
d’harmonisation totale.

37
 en accès A2A, selon la règle des 2 yeux uniquement. Alors, il relève de la responsabilité de l’application
« externe » souhaitant accéder aux services de l’Eurosystème de s’assurer que tous les contrôles d’accès
et de sécurité préalables à sa requête ont été réalisés avant l’envoi.
Enfin, les rôles sont assignés de manière hiérarchique. Ainsi, à l’instar du fonctionnement de T2S :
 l’opérateur du service se voit assigné le plus grand éventail de rôles possibles ;
 il pourra assigner à l’utilisateur administrateur banque centrale le plus grand éventail de rôles possibles
pour un utilisateur banque centrale, charge ensuite à cet administrateur d’assigner les rôles adéquats aux
autres utilisateurs banque centrale ;
 l’utilisateur banque centrale pourra assigner à l’utilisateur administrateur pour un participant l’éventail
de rôles le plus large possible pour un utilisateur participant, charge ensuite à cet administrateur
d’assigner les rôles adéquats aux utilisateurs chez le participant.
13 Gestion de la migration
13.1 Migration en « big bang »

Les travaux de migration sont prévus à partir du troisième trimestre 2022 et jusqu’en février 2023, et découpés
en trois phases :
1. pré-migration (préparation du static data) ;
2. week-end de migration (18 mars 2023) ;
3. période de stabilisation d’environ 10 semaines (après le week-end de migration du 20/03/2023).
La stratégie retenue pour la migration des données et activités de l’actuelle plateforme TARGET2 vers les futures
composantes de T2 (RTGS et CLM), ainsi que la migration vers les formats de message ISO 20022, est celle d’une
migration en « big bang ».
Cette approche a été retenue pour les raisons suivantes :
 le passage du mode de communication Y-copy vers V-shape implique que tous les messages affectés
soient remplacés en même temps pour chacun des services TARGET. Le maintien en parallèle des formats
de communication actuellement utilisés par TARGET2 et des futurs formats n’est pas jugé possible ;
 une migration préalable de TARGET2 au format ISO 20022 (i.e. migration pour la partie communication),
suivie d’une migration des fonctionnalités vers T2 (RTGS et CLM) est jugée trop coûteuse et risquée ; il en
est de même d’une migration d’abord à CLM (communication et fonctionnalités) puis vers RTGS
(communication et fonctionnalités) ;
 l’impossibilité de faire coexister TARGET2 avec CLM, RTGS et les composantes communes. Cela aurait en
effet impliqué d’opérer deux infrastructures séparées en parallèle, où les participants de l’une n’auraient
pas nécessairement pu accéder à l’autre ; une telle situation n’a pas été jugée acceptable.
Cela implique que les participants doivent impérativement être prêts à migrer lors du week-end de migration,
notamment du point de vue de la connectivité avec leur NSP, de la bascule vers les nouveaux formats de
messages, de la maîtrise des nouvelles modalités de suivi et de gestion de la liquidité.

13.2 Formation et information des futurs utilisateurs
13.2.1 Organisation des relais de formation par la Banque de France

Les formations organisées par la Banque centrale européenne, notamment à destination des banques centrales,
seront relayées par la Banque de France aux participants de la Place française à l’occasion de sessions partagées.
13.2.2 Diffusion et mise à disposition de l’information

La Banque de France diffuse régulièrement, par l’intermédiaire des groupes de Place qu’elle anime ou auxquels
elle participe (NSG AMI-Pay et NSG AMI-SeCo, groupe technique utilisateurs - GTU), des informations sur le
projet, son avancement, la migration et sur les futures conditions d’utilisation de CLM et RTGS.
Elle relaie ainsi les informations diffusées par l’Eurosystème, en les complétant par les éléments propres au
marché français.
Ces informations, et toute la documentation officielle sur ce projet, peuvent être consultées sur la page de
l’extranet T2-T2S de la Banque de France dédiée à la consolidation, et sur le site internet de la Banque centrale
européenne.
Site extranet Banque de France T2-T2S :
https://www.target2bf.fr/consolidation-t2-t2s/consolidation-t2-t2s
Site internet de la Banque centrale européenne :
https://www.ecb.europa.eu/paym/initiatives/html/index.en.html
14 Gestion des adhésions
14.1 Formulaires
Toutes les informations utiles (formulaires, fiches pratiques…) sont disponibles, elles seront présentées aux
participants dans le cadre de séances ad hoc et mises à disposition sur le site extranet T2-BF
(https://www.target2bf.fr/).
14.2 Tests et certification

L’Eurosystème prépare la migration en organisant une campagne de tests qui, pour les « utilisateurs », sont
planifiés pour se dérouler entre décembre 2021 et janvier 2023.
La Banque de France assure la coordination et le suivi de ces tests afin de sécuriser la migration de la Place
française.
Ces tests utilisateur comprennent :
 des tests de connectivité, destinés à vérifier la bonne connectivité A2A entre les systèmes des utilisateurs
et ESMIG via le NSP choisi, et la capacité à se connecter sur la page d’entrée d’ESMIG (U2A) ;
 des tests fonctionnels, destinés à vérifier le bon déroulement des interactions de bout en bout, incluant
des tests d’interopérabilité, de communauté et de journée opérationnelle (simulation de journées
comptables représentatives) ;
 des tests opérationnels, destinés à vérifier les procédures opérationnelles ;
 des tests de migration, destinés à répéter les activités de migration de la plateforme TARGET2 aux futurs
RTGS, CLM et composantes communes. Deux week-end de répétition se sont déroulés en 2022 et un
dernier weekend de répétition est prévu du 3 au 5 février. Pendant et après le test du week-end de

39
migration, les acteurs de la Place vérifient que les données migrées dans la plateforme consolidée sont
correctes et que leur banque centrale opère correctement avec la plateforme consolidée. La Banque de
France fournira un support à ses participants.
L’ensemble de ces tests se déroulent dans un environnement de test dédié qui sera aussi raccordé à T2S (UTEST).
14.3 Modification de la documentation d’adhésion à TARGET-

BANQUE DE FRANCE
Dans le cadre du projet de consolidation T2/T2S, la documentation relative à TARGET est modifiée. L’orientation
BCE/2022/8 (dite « orientation TARGET »), abroge l’orientation BCE/2012/27 (dite « orientation TARGET2 »)17.
Cette orientation est transposée dans la décision du Gouverneur de la Banque de France n°2022-05 du 6 juillet
2022 relative aux conditions harmonisées de participation à TARGET.
Les conventions d’ouverture de compte TARGET-BANQUE DE FRANCE sont modifiées pour prendre en compte
ce nouveau cadre juridique ainsi que les modifications techniques et opérationnelles liées à la consolidation.
La Décision du Gouverneur et les nouvelles conventions TARGET-BANQUE DE FRANCE sont accessibles sur le site
Internet de la Banque de France au lien suivant :
https://www.banque-france.fr/stabilite-financiere/infrastructures-de-marche-et-systemes-de-
paiement/target-banque-de-france/textes-juridiques
15 Ce qui change pour TARGET2

Certaines fonctionnalités actuelles de TARGET2 seront remplacées ou modifiées, d’autres seront abandonnées.
15.1 Connectivité : choix des prestataires de service réseau,

abandon du Y-copy et suppression de l’accès internet
Comme indiqué au chapitre Connectivité, la plateforme unique ESMIG assure la connectivité via des prestataires
de service réseau multiples. ESMIG permet en effet une communication « agnostique » en matière de
fournisseur, permettant ainsi le choix du NSP, et le mode Y-copy sera abandonné au profit du mode V-shape.
Tous les NSP doivent respecter les mêmes spécifications en termes d’interface avec ESMIG mais peuvent
librement utiliser leurs caractéristiques propres en matière de réseaux et messages.
Un autre impact de la plateforme unique ESMIG est qu’il s’agit désormais de l’unique point d’accès pour la
communication externe avec l’ensemble des services TARGET. Pour les participants cela signifie que l’accès
internet à la plateforme TARGET2 va disparaître.
17 Cette orientation, dans sa version française et anglaise, est accessible au lien suivant : https://eur-lex.europa.eu/legal-
content/FR/TXT/?uri=CELEX:32022O0912.

15.2 Suppression des comptes HAM et PM
Il résulte du projet de consolidation des plateformes, et en particulier du mécanisme de gestion centralisé via
CLM, que les comptes HAM et PM existants vont disparaître au profit d’une architecture rationalisée, plus
modulaire, potentiellement multidevises et offrant des outils de centralisation de la liquidité.
En effet, avec CLM les opérations de banque centrale s’effectuent uniquement au niveau du MCA (à noter
cependant que les opérations de numéraire pourront également s’effectuer à partir des DCA RTGS). Celui-ci n’est
pas destiné à effectuer des paiements entre participants, il permet d’effectuer des transferts de liquidité. L’accès
au MCA se veut simple et peu coûteux, afin de permettre aux participants qui disposaient, par exemple, d’un
compte HAM destiné à la gestion des réserves obligatoires et des opérations de numéraire (CNRO dans T2-BF)
de n’ouvrir qu’un MCA (il n’y a pas d’obligation d’ouvrir un DCA). Les opérations de paiement entre participants
et de déversement de systèmes exogènes s’effectueront sur les DCA RTGS.
15.3 Suppression de la fonctionnalité virtual account

L’Eurosystème a analysé les différentes solutions techniques pour faire cohabiter dans la nouvelle architecture
le central liquidity management avec la fonctionnalité de virtual account, mais aucune solution satisfaisante n’a
pu être trouvée.
Compte tenu du faible nombre de participants qui ont manifesté un besoin pour cette fonctionnalité, elle ne
sera pas maintenue. Les fonctionnalités de transfert et de suivi de la liquidité à un niveau groupe seront
néanmoins maintenues et éclatées entre :
- un concept d’Account Monitoring Group, permettant aux participants de lier des comptes (entre
plusieurs services s’ils le souhaitent) pour des besoins de suivi de la liquidité uniquement (et non des
transferts de liquidité notamment). Les comptes peuvent appartenir à des participants différents, et les
comptes peuvent être liés sur une base transfrontalière ;
- un concept de Liquidity Transfer Group, permettant aux participants de lier, au sein d’un même service,
différents comptes d’un même groupe (la liaison est à la main de la banque centrale, sur demande du
participant, afin de permettre des transferts de liquidité entre ces comptes).
En revanche, le concept de file de paiement unique associée au virtual account18 disparaît.
15.4 Abandon du format de message ISO 15022

Le démarrage de la future plateforme consolidée T2-T2S sera l’occasion d’opérer une bascule complète des
infrastructures de l’Eurosystème au format de message ISO 20022. Les messages FIN seront donc abandonnés.
Suite à la décision de report du go-live au 20 mars 2023, SWIFT a décidé de décaler CBPR+ au 20 mars 2023 pour
s’aligner avec le lancement de la plateforme consolidée T2-T2S.
16 Ce qui change pour T2S

Il importe de noter que ni la gouvernance, ni les fonctionnalités T2S ne sont amenées à changer. Les changements
apportés à T2S devront être validés par la communauté T2S.
16.1 Journée opérationnelle

Deux modifications devraient impacter la journée opérationnelle T2S :
18 Compte virtuel permettant de gérer de façon agrégée plusieurs comptes appartenant à un même participant.

41
 la fenêtre de maintenance, qui se déroule de 3h à 5h en semaine (du mardi au vendredi), sera rendue
optionnelle et ne sera activée qu’en cas de nécessité ;
 les déversements (cash sweeps) de fin de journée à partir du DCA T2S ne seraient plus obligatoires dans
le cadre du projet de consolidation des plateformes T2-T2S et pourraient, sous réserve de validation par
la communauté T2S, disparaître. Ainsi :
o le cash sweep automatique du DCA T2S vers le DCA RTGS à 17h45 deviendrait optionnel ;
o le solde de fin de journée du DCA T2S pourrait ne pas être nul ;
o durant la phase de fin de journée (18h15 ou 18h30 le dernier jour de constitution des réserves
obligatoires) T2S devrait produire un état (general ledger file) pour chaque DCA actif.
16.2 Apport / retrait de liquidité

Les échanges de liquidité se feront avec la composante de gestion centralisée de la liquidité (CLM) et non plus
avec le compte PM RTGS.
Des ordres de transfert automatisés (optionnels) fondés sur des événements prédéfinis pourront être introduits
pour les DCA T2S. Le concept de groupe de transfert de liquidité (cf. glossaire) pourra être étendu à T2S.
Les formats des notifications de transferts de liquidité devront être alignés entre les différents
services/composantes TARGET, ce qui pourra entraîner un enrichissement ou de légères modifications aux
messages actuellement utilisés par T2S.
16.3 Données de référence

Les données de référence de T2S vont servir de socle au module commun de gestion des données (CRDM). Avec
l’abandon des comptes PM et la mise en place des MCA, il conviendra de mettre en place de nouveaux liens
entre ces comptes et les DCA T2S.
Le module LTSI (Long Term Statistical Information) sera décommissionné et remplacé par le Data Warehouse,
tandis que l’archivage légal T2S sera remplacé par la composante commune de Legal Archiving mais dont les
fonctionnalités devraient rester inchangées.
Enfin, si le processus de facturation pour les services T2S pour la partie titres reste inchangé, le module de
facturation T2S sera décommissionné et remplacé par la facturation T2-T2S consolidation.
16.4 Adaptations à ESMIG

ESMIG sera le point d’entrée commun depuis l’extérieur vers toutes les infrastructures de marché opérées par
l’Eurosystème, dont T2S. Les caractéristiques d’ESMIG s’appuient largement sur les modalités de connectivité à
T2S.
17 Exemples de configurations possibles
17.1 Exemple de configuration pour une structure à caractère

centralisé
Un groupe qui fonctionnerait aujourd’hui sur la base d’une structure relativement centralisée, par exemple en
regroupant les activités du groupe sur un seul compte PM dans TARGET2 et un seul DCA dans T2S pourrait, dans
la future architecture, retenir par exemple la structure suivante :

17.2 Exemple de configuration pour une structure à caractère
décentralisé
Un groupe qui fonctionnerait aujourd’hui sur la base d’une structure relativement décentralisée, par exemple en
utilisant dans TARGET2 différents comptes PM qui correspondraient aux différentes activités du groupe (ex : une
partie custodian, une partie paiements/fonds propres), avec des comptes DCA ségrégués côté custodian et
faisant usage des fonctionnalités de groupement de comptes offertes par TARGET2 (tel le groupe d’information
consolidé), pourrait retenir par exemple la structure suivante :

43
17.3 Exemple de configuration pour une structure mutualiste
Un groupe qui fonctionnerait aujourd’hui sur la base de plusieurs comptes PM gérés de manière indépendante
par les différentes branches du groupe et faisant usage des fonctionnalités de groupement de comptes (Virtual
Account, groupe d’information consolidé) offertes par TARGET2, pourrait par exemple retenir la structure
suivante :
18 Contacts
Pour les participants à T2-BF, la coordination et le pilotage du projet pour la Place sont assurés par le Service de
Résilience et études sur les Infrastructures de Marché (SRIM) de la Direction des Infrastructures, de l’Innovation
et des Paiements (DIIP), au sein de la Direction Générale de la Stabilité financière et des Opérations (DGSO), et
les questions sont à adresser à l’adresse suivante : [email protected].
Le support est quant à lui assuré par le Service des Règlements Interbancaires (SERI), de la DGSO-DIIP par deux
sections :
 Section Administration des Comptes et des Référentiels (SAR) pour les aspects ouverture de comptes,
formulaires, conventions, gestion des signatures ;
 Section Support T2-Banque de France (ST2BF) pour les aspects tests, certification support, secours.
Les accès de la permanence SERI (boîte aux lettres et téléphone) sont conservés, et leur périmètre étendu à
l’ensemble des services TARGET.
Les procédures de gestion des incidents sont définies par les groupes de travail Eurosystème. Le Support ST2BF
est le point d’entrée pour la déclaration d’incident ou la diffusion d’information relative à un incident.

Permanence SERI BANQUE DE FRANCE
33-2320 SERI
75049 PARIS CEDEX 01
[email protected]
Téléphone : 01 42 92 61 90
Administration (ouverture/fermeture de compte, changement de paramètre)
BANQUE DE FRANCE
33-2320 SERI
Section Administration des Référentiels
[email protected]
Téléphone : 01 42 92 24 82 - Fax : 01 42 92 24 45
Support T2-BF BANQUE DE FRANCE

33-2320 SERI
[email protected]
Téléphone : 01 42 97 79 00 - Fax : 01 42 92 98 58
Support T2BF-Tests BANQUE DE FRANCE

33-2320 SERI
[email protected]
Téléphone : 01 42 97 79 88 - Fax : 01 42 92 63 45
Support BOPM - Opérations de politique monétaire

BANQUE DE FRANCE
021-1157 BOPM
[email protected]
Téléphone : 01 42 92 39 73 - 01 42 92 69 92 - 01 42 92 93 56

45

T2 Business Description

Transféré par

Droits d'auteur :

Formats disponibles

T2 Business Description

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

T2 Business Description

Transféré par

Droits d'auteur :

Formats disponibles

2022

La consolidation des plateformes TARGET2 et

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

2. PRÉSENTATION GÉNÉRALE DU FUTUR SERVICE T2 ............................................ 9

3. PRINCIPALES FONCTIONNALITÉS .......................................................................... 14

4. LE RÉFÉRENTIEL COMMUN (CRDM) ET LA CONSTRUCTION DE L'ANNUAIRE

7. CALENDRIER ET JOURNÉE OPÉRATIONNELLE ................................................. 30

8. MODULE DE CONTINGENCE .................................................................................. 34

2 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

11. ENTREPÔT DE DONNÉES (DATA WAREHOUSE) ................................................ 35

14 GESTION DES ADHÉSIONS .................................................................................... 39

15 CE QUI CHANGE POUR TARGET2 ......................................................................... 40

16 CE QUI CHANGE POUR T2S ................................................................................... 41

17 EXEMPLES DE CONFIGURATIONS POSSIBLES .................................................. 42

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

4 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

1.1. Objectifs : les origines du projet

Cette stratégie comprend, chronologiquement, les trois axes suivants :

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

* GUI = Graphical User Interface

6 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Différentes instances assurent le suivi du projet :

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Schéma 2 – Macro-planning du projet de consolidation avant le décalage au 20/03/2023

8 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

2. Présentation générale du futur service T2

2.1. Principes généraux

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Schéma 4 - Modèle de base de centralisation de la liquidité autour du Main Cash Account :

T2S RTGS TIPS

Règlement-livraison Paiements en temps- Paiements instantanés

DCA = Dedicated Cash Account

2.2. Dispositifs de participation

2.2.1. Dans le CLM

2.2.2. Dans le RTGS

10 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Caractéristiques Participant RTGS direct Participant RTGS Accès RTGS multi-

Émettre et recevoir des Directement Via le participant direct Directement

Possède son propre DCA Oui Non Non

Contrôle de la liquidité En propre Via le participant direct Via le participant direct

Accès U2A (via le GUI) Oui Non Non

Adressabilité Directement adressable Adressable via le Directement adressable

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

12 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

2.4. Identification des comptes et des participants

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

2.5. Dénomination des comptes

3.1. Gestion de la liquidité

3.1.1. Fonctionnalités offertes par CLM et RTGS pour le pilotage de la liquidité

14 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Par ailleurs, les fonctionnalités de suivi de la liquidité s’appuient sur :

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Source : BCE, Business Description Document

16 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

Gestion de la priorité des opérations

Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022

3.1.2. Principes et modalités afférents aux transferts de liquidité

Business purpose Ordre de tirage de la liquidité

18 Banque de France – Blueprint Consolidation T2/T2S – Version 3 – Novembre 2022