RTGS.global Operating Models
RTGS.global SaaS Offering and Future Closed-Network Model
This article describes RTGS.global's current managed SaaS offering and its future closed-network model for central-bank and comparable high-governance financial-market-infrastructure environments. The future model is subject to regulatory designation and the establishment of relevant jurisdictional frameworks.
Applies to: The RTGS.global SaaS Offering, and the future Closed Network model for central-bank environments.
Context: The SaaS Offering is RTGS.global's current production offering. The closed-network model describes an intended future configuration, subject to regulatory designation, product scope and jurisdiction-specific operating requirements.
Introduction
Modern financial systems operate across diverse regulatory, technical, and commercial landscapes. Rather than applying a one-size-fits-all approach, RTGS.global is designed to accommodate these differences through two distinct operating models.
While these operating models serve different settlement and integration needs, they share common principles: trusted participant interaction, message integrity, and clear operational boundaries.
This is a conceptual introduction, not a detailed security, deployment, or service specification.
The RTGS.global SaaS Offering
The RTGS.global SaaS Offering is designed for SaaS delivery and public API integration. It provides a platform layer for connecting participants and coordinating payment workflows, intended to operate alongside the relevant external settlement arrangements.
The SaaS Offering supports predictable, interoperable integration. Participants can access relevant RTGS.global services through the Participant API, including:
- FX Quotes: communicating and agreeing FX trade terms between participants before settlement.
- Payaway: FI-to-FI customer credit transfers.
- Link and Settle: coordinated cross-currency settlement flows that make use of the Funds Controller settlement arrangements in context.
The SaaS Offering follows cloud-agnostic design principles. Deployment, availability, and resilience profiles can be configured and provisioned to meet the requirements of an agreed service and operating environment.
Future closed-network model: PvP via Central Bank Funds
As part of its ongoing regulatory work, RTGS.global is developing a closed-network model for central banks and comparable financial-market-infrastructure environments. This future configuration is intended to be available subject to obtaining the relevant regulatory designation and establishing the applicable jurisdictional, account-structure and operating frameworks.
PvP via Central Bank Funds is intended for controlled, closed-network environments where participation and settlement arrangements are explicitly defined for a particular jurisdiction or trust context.
This model is intended to support Payment-versus-Payment (PvP) workflows. The related legs of a currency exchange would be coordinated so that the intended settlement outcome is achieved in line with the rules of the relevant environment. This approach is designed to help manage principal settlement risk.
Participation would be governed by the requirements of the relevant environment, which may include defined eligibility criteria, relationship controls, and appropriate governance boundaries.
The platform is compatible with programmable-token patterns. Specific token capabilities may be introduced subject to product scope, regulatory approval, and the requirements of a given deployment.
Within this future model, the following services are intended to be available, subject to the applicable regulatory and operating framework:
- FX Quotes: communicating and agreeing FX trade terms between participants before settlement.
- Payaway: FI-to-FI customer credit transfers.
- Link and Settle: coordinating linked settlement flows using the relevant central-bank settlement infrastructure.
Shared platform principles
Although the operating models serve different contexts, they are shaped by common platform principles.
Trusted participant interaction
RTGS.global supports the establishment of participant identity and relationship context. During onboarding, participants can establish an RTGS.global ID and the information needed for trusted interaction within the relevant network.
Where appropriate to the use case, the platform can use decentralised identity and verifiable credential patterns to support the exchange and verification of participant information. These patterns operate within defined governance and trust boundaries.
Message integrity and traceability
The platform is designed to support message flows in which the origin and integrity of relevant information can be checked. Signed-message patterns may be used where applicable to provide evidence of message authenticity and integrity.
This supports clear records, traceability, and operational review across payment workflows.
Participant API and message standards
The Participant API uses ISO 20022-based message structures represented in JSON for inbound participant interactions. Outbound connectivity to Funds Controller APIs in the SaaS Offering uses those institutions' published APIs and their required formats, authentication and security controls. In the future closed-network model, outbound connectivity would similarly use the relevant central bank's published integration requirements. RTGS.global does not mandate a format for outbound integrations.
Clear settlement boundaries
The operating models have different settlement contexts. The SaaS Offering coordinates payment workflows alongside the relevant external settlement arrangements. The future closed-network model is intended for a controlled operating environment, subject to regulatory designation.
In both cases, it is important that participants understand where responsibilities sit, what evidence is available, and how the relevant settlement process is governed.
How the operating models differ
| Consideration | Current — RTGS.global SaaS Offering | Future — Closed Network / PvP via Central Bank Funds |
|---|---|---|
| Operating context | SaaS delivery and public API integration contexts | Intended controlled, closed-network and high-governance environments, subject to regulatory designation |
| Integration emphasis | API-led and interoperable integration | Intended governed participation, controlled connectivity and trusted relationships |
| Settlement context | Coordinated alongside relevant external settlement arrangements; RTGS.global is not the final settlement record | Intended PvP settlement in central-bank money, subject to jurisdictional and regulatory framework |
| Deployment approach | Cloud-agnostic principles with configurable deployment profiles | Intended dedicated deployment and controlled network boundary, determined by the relevant operating environment |
| Capability evolution | Subject to agreed product scope and service requirements | Subject to regulatory designation, agreed product scope and operating requirements |
What this means for technical evaluators
A useful starting point is to consider:
- the required settlement and operating context;
- how participants will integrate and establish trust;
- the governance and assurance requirements of the environment;
- the expected service, deployment, and resilience profile; and
- the capabilities needed for the intended use case.
These questions help identify whether the current RTGS.global SaaS Offering meets the intended use case, and whether the future closed-network model may be relevant as regulatory and jurisdictional frameworks develop.
Next steps
For definitions of key terms, see the Technical Articles Glossary.
For service-specific API information, see the Product Services guides.