Un RTGS ISO 20022 en Guinée
La BCRG modernise son système de règlement brut en temps réel et migre vers une plateforme conforme au standard ISO 20022. Pour les banques de la place, la conséquence est directe : les échanges avec la banque centrale ne passent plus par les formats historiques, mais par des messages pacs (paiements), camt (reporting) et admi (administration), signés électroniquement et échangés par API sécurisées.
Ce mouvement n'est pas propre à la Guinée. Après la migration CBPR+ de SWIFT et les projets menés par plusieurs banques centrales de la région, l'ISO 20022 devient la langue commune des infrastructures de paiement. La question pour chaque banque n'est plus « si » mais « comment » — et à quel coût.
- Messages pacs pour les ordres de paiement.
- Messages camt pour le reporting compte et transactions.
- Messages admi pour les échanges d'administration système.
Le défi : se connecter sans transformer le core banking
La banque que nous avons accompagnée tourne sur un core banking international largement répandu, dans une configuration qui n'incluait ni hub de paiement ni interface de messagerie MX. Déployer ces briques additionnelles est un projet en soi — acquisition, installation, montée en compétence — difficilement compatible avec le calendrier de migration fixé par la banque centrale.
Le cahier des charges, lui, ne transigeait pas : signature électronique des messages (XAdES), conversion MT ↔ MX complète, API REST sécurisées (OAuth2, mutual TLS), intégration au filtrage AML, supervision de bout en bout — avec une date cible à quelques semaines. Il fallait donc déporter toute la complexité ISO 20022 hors du core banking, et ne demander à celui-ci que ce qu'il sait déjà faire : produire des remises de virements et enregistrer des mouvements.
- Signature électronique des messages (XAdES).
- Conversion MT ↔ MX complète.
- API REST sécurisées : OAuth2, mutual TLS.
- Intégration au filtrage AML et supervision de bout en bout.
Un middleware de paiement entre le core banking et la banque centrale
Notre middleware s'insère entre le core banking et la plateforme RTGS de la BCRG. Le core banking dépose une remise de virements — simple fichier délimité poussé sur une API REST — et le middleware fait tout le reste.
À l'émission : validation et dégroupement du lot, construction du pacs.008 — un seul GrpHdr, N transactions pour les virements multiples, comptes portés en Othr/Id puisque la Guinée n'utilise pas l'IBAN — enveloppe et signature XAdES-BES, authentification OAuth2, envoi au RTGS, puis récupération des statuts par long polling. Le règlement est ferme et immédiat : une fois le statut ACSC reçu, l'opération est irrévocable. Les rejets reviennent avec leurs codes — structure, code type transaction, date de valeur — et sont tracés jusqu'à la transaction fautive.
À la réception, le principe clé du RTGS s'applique : quand une autre banque crédite un client, le règlement est finalisé côté banque centrale avant toute notification. Le middleware vérifie la signature entrante avec le certificat du système de la banque centrale, route chaque type de message vers sa routine de traitement (virement client, virement interbancaire, confirmation de crédit), déduplique sur la référence de trace — et rien n'est injecté dans le core banking sans signature valide.
- Validation et dégroupement de la remise de virements.
- Construction du pacs.008 (un GrpHdr, N transactions pour les virements multiples) et signature XAdES-BES.
- Envoi au RTGS, suivi des statuts et traçabilité jusqu'à la transaction en cas de rejet.
En production
Le middleware traite aujourd'hui en production les virements clients et les virements multiples de la banque, dans les deux sens. Le délai entre la contractualisation et le go-live s'est compté en semaines, pas en trimestres — parce que la plateforme existait déjà, éprouvée sur des projets de virements instantanés, et qu'il restait à l'adapter au catalogue ISO 20022 du RTGS guinéen et aux spécificités locales.
Ce qu'il faut en retenir
Trois enseignements pour les banques qui abordent une migration ISO 20022. D'abord, le core banking n'est pas le bon endroit pour porter la complexité des messages : un middleware dédié isole les formats, la signature et les évolutions du catalogue, et laisse le core banking faire son métier. Ensuite, les détails locaux font le projet : absence d'IBAN, codes type transaction, règles de déduplication — c'est là que se joue la conformité, pas dans le XSD. Enfin, l'irrévocabilité du règlement RTGS impose une discipline de bout en bout : validation avant émission, filtrage AML en amont, traçabilité complète — aucun retour en arrière une fois le règlement effectué.
Votre banque prépare sa connexion à un RTGS ISO 20022 — en Guinée ou ailleurs dans la région ? Parlons-en : la même approche s'adapte à d'autres core bankings et à d'autres banques centrales.
- Le core banking n'est pas fait pour porter la complexité des messages : un middleware dédié isole formats, signature et évolutions du catalogue.
- Les détails locaux font le projet — absence d'IBAN, codes type transaction, règles de déduplication — c'est là que se joue la conformité.
- L'irrévocabilité du règlement RTGS impose une discipline de bout en bout : validation avant émission, filtrage AML en amont, traçabilité complète.
