RTGS Reform in Guinea: Connecting Core Banking to BCRG Without a New Module

An ISO 20022 RTGS in Guinea

The BCRG is modernising its real-time gross settlement system and migrating to a platform compliant with the ISO 20022 standard. For local banks, the consequence is direct: exchanges with the central bank no longer go through legacy formats, but through pacs (payments), camt (reporting) and admi (administration) messages, electronically signed and exchanged via secure APIs. This shift isn't unique to Guinea. Following SWIFT's CBPR+ migration and projects led by several central banks in the region, ISO 20022 is becoming the common language of payment infrastructure. For every bank, the question is no longer "if" but "how" — and at what cost.

• pacs messages for payment orders.
• camt messages for account and transaction reporting.
• admi messages for system administration exchanges.

The challenge: connecting without transforming the core banking system

The bank we supported runs on a widely used international core banking platform, in a configuration that included neither a payment hub nor an MX messaging interface. Deploying those additional components is a project in itself — procurement, installation, skills ramp-up — hard to reconcile with the migration timeline set by the central bank. The specifications themselves left no room for compromise: electronic message signing (XAdES), full MT ↔ MX conversion, secure REST APIs (OAuth2, mutual TLS), integration with AML screening, end-to-end monitoring — with a target date only weeks away. The entire ISO 20022 complexity had to be moved outside the core banking system, asking it only to do what it already does well: generate transfer batches and record movements.

• Electronic signing of messages (XAdES).
• Full MT ↔ MX conversion.
• Secure REST APIs: OAuth2, mutual TLS.
• Integration with AML screening and end-to-end monitoring.

A payment middleware between core banking and the central bank

Our middleware sits between the core banking system and the BCRG's RTGS platform. The core banking system submits a transfer batch — a simple delimited file pushed to a REST API — and the middleware handles everything else. On the outbound side: batch validation and unbundling, construction of the pacs.008 — a single GrpHdr, N transactions for bulk transfers, accounts carried in Othr/Id since Guinea doesn't use IBAN — XAdES-BES envelope and signature, OAuth2 authentication, submission to the RTGS, then status retrieval via long polling. Settlement is final and immediate: once the ACSC status is received, the operation is irrevocable. Rejections come back with their codes — structure, transaction type code, value date — and are traced back to the faulty transaction. On the inbound side, the core RTGS principle applies: when another bank credits a customer, settlement is finalised at the central bank before any notification. The middleware verifies the incoming signature against the central bank system's certificate, routes each message type to its processing routine (customer transfer, interbank transfer, credit confirmation), deduplicates on the trace reference — and nothing is posted to the core banking system without a valid signature.

• Validation and unbundling of the transfer batch.
• Construction of the pacs.008 (one GrpHdr, N transactions for bulk transfers) and XAdES-BES signing.
• Submission to the RTGS, status tracking, and full traceability down to the transaction in case of rejection.

In production

The middleware now processes the bank's customer transfers and bulk transfers in production, in both directions. The time between contract signature and go-live was measured in weeks, not quarters — because the platform already existed, proven on instant payment projects, and only needed to be adapted to the ISO 20022 catalogue of Guinea's RTGS and its local specifics.

Key takeaways

Three lessons for banks approaching an ISO 20022 migration. First, the core banking system is not the right place to carry message complexity: a dedicated middleware isolates formats, signing, and catalogue changes, and lets the core banking system do its job. Second, local details make the project — the absence of IBAN, transaction type codes, deduplication rules — that's where compliance is won, not in the XSD. Finally, the irrevocability of RTGS settlement demands end-to-end discipline: validation before submission, upstream AML screening, full traceability — no going back once settlement has occurred. Is your bank preparing to connect to an ISO 20022 RTGS — in Guinea or elsewhere in the region? Let's talk: the same approach adapts to other core banking systems and other central banks.

• The core banking system isn't built to carry message complexity: a dedicated middleware isolates formats, signing, and catalogue changes.
• Local details make the project — no IBAN, transaction type codes, deduplication rules — that's where compliance is won.
• RTGS settlement irrevocability demands end-to-end discipline: validation before submission, upstream AML screening, full traceability.