Trusted Participant Identity
DIDs, Verifiable Credentials and Governed Network Trust
Settlement networks depend on participants being able to establish identity, demonstrate relevant authority, and verify the origin of important messages.
RTGS.global uses decentralised identity and verifiable credential patterns to support these interactions. These patterns enable participants and network services to exchange cryptographically verifiable information without requiring a central directory lookup for every check.
This does not remove the need for governance. Trust still depends on the operating environment: who may participate, which issuers are recognised, what evidence is accepted, and how authorisation is managed. The technology provides evidence; the trust framework determines how that evidence is used.
This article introduces the identity patterns that support an RTGS.global ID, the role of Hyperledger Aries and ACA-Py, and the governance needed for trusted participant relationships.
Applies to: The RTGS.global SaaS Offering and the future closed-network model for central-bank environments.
Context: The identity and credential patterns described here are used in the SaaS Offering and are designed to support a future closed-network model. Credential formats, trust frameworks, governance arrangements and enabled workflows depend on the applicable operating environment.
Identity in a governed network
A participant identity needs to do more than identify an organisation. It must also support the evidence needed to establish whether that organisation is entitled to take part in a particular network or workflow.
Traditional approaches can use directories, certificates, API credentials, and bilateral onboarding processes. These remain useful controls. Decentralised identity patterns add a way to exchange and verify identity-related information between participants and services using standardised cryptographic proofs.
For RTGS.global, this supports a model in which an RTGS.global ID can be associated with the identity information and relationships needed for trusted interaction in the relevant network.
Decentralised Identifiers
A Decentralised Identifier, or DID, is a globally unique identifier associated with cryptographic keys and service information. Its associated DID Document can contain public verification methods and service endpoints that help other parties validate messages or establish an authenticated relationship.
Control of a DID is demonstrated through the corresponding private keys. This allows a participant to prove control of an identifier through cryptographic operations rather than relying solely on a record in a shared directory.
In a settlement context, DIDs can support persistent participant identity and enable services or counterparties to verify signatures against trusted identity information. The governance model remains important: a DID can be technically valid without being recognised or authorised within a particular operating environment.
In the RTGS.global network, RTGS.global acts as the endorser for participant DIDs. During organisation onboarding, each participant's DID is written to a Hyperledger ledger hosted by Indicio. This endorsement step is the mechanism by which network access is controlled — only participants whose DID has been endorsed by RTGS.global can interact on the network. Verifiable Credentials are issued as part of the same onboarding process and held in the participant's private agent wallet.
Verifiable Credentials
A DID helps establish who controls an identity. A Verifiable Credential, or VC, provides signed evidence about an identity.
A credential can contain a specific claim about a participant, such as its membership of a network, its authority within a defined operating context, or other information required by an agreed trust framework. An issuer signs the credential, the holder retains it, and a verifier checks the issuer, signature, and relevant claims when evidence is required.
This gives participants a way to present relevant, machine-verifiable information without requiring the verifier to contact the issuer for every check. It does not mean that all credentials are automatically accepted. The verifier must still apply the network's rules for trusted issuers, accepted schemas, validity, and authorisation.
The precise claims and credential formats used by RTGS.global depend on the agreed operating model and governance requirements.
Aries protocols
Hyperledger Aries defines interoperable protocols for decentralised identity interactions. These protocols cover common exchanges such as establishing a relationship, issuing a credential, and requesting evidence from a credential holder.
The main patterns are:
- DID Exchange: establishes a relationship between parties and allows them to exchange DID information.
- Issue Credential: supports the controlled issue and delivery of a credential from an issuer to a holder.
- Present Proof: allows a verifier to request evidence that a participant meets defined criteria, and allows the holder to provide an appropriate cryptographic presentation.
These patterns provide standard ways for participants and services to exchange identity information. The policy decision remains outside the protocol: the receiving party determines whether the issuer, credential, and claims meet the requirements of the relevant network or workflow.
Hyperledger Aries and ACA-Py
Hyperledger Aries is an open-source project for interoperable decentralised identity. It defines protocols and supporting components rather than a single centralised identity service.
ACA-Py, or Aries Cloud Agent Python, is a server-side agent implementation used to work with these protocols. It provides wallet and agent capabilities for identity workloads, including key management, DID operations, credential handling, and protocol exchanges.
Using open standards and open-source components can support interoperability and technical transparency. It also allows a deployment to use established identity patterns without tying its approach to a proprietary identity protocol.
RTGS.global's implementation approach
RTGS.global uses ACA-Py as part of its identity capability. ACA-Py provides the agent and wallet functions needed to work with keys, DIDs, credentials, and relevant Aries exchanges.
RTGS.global applies a controller pattern. The controller manages the business workflow and policy decisions, while the identity layer provides cryptographic and protocol capabilities through controlled interfaces.
This separation is intentional. Application services can use identity capabilities without managing wallet operations or cryptographic details directly. The controller handles policy; the identity layer handles the cryptographic operations that support it.
As part of the wider RTGS.global sign/verify capability, wallet-backed signing and verification functions are available to the controller layer through HTTP interfaces. Platform services can request a signature or submit an artefact for verification through that controlled interface, rather than coupling directly to the underlying agent implementation.
The identity flow used in a deployment, including the credential format and the conditions under which signing or verification is required, is determined by the relevant operating model and governance requirements.
Trust and governance
Cryptography can establish that a credential or message is technically valid. It can show that a signature matches a known verification method and that information has not changed since it was signed.
It cannot, by itself, establish whether the issuer is trusted, whether the credential is appropriate for a particular activity, or whether a participant remains authorised. Those decisions belong to the governance framework.
A trust framework defines matters such as:
- which organisations may participate;
- which issuers are recognised;
- which credential types and claims are accepted;
- which relationships and permissions are required; and
- how changes to participant status are managed.
For a future PvP via Central Bank Funds operating environment, these rules would be expected to be closely defined by the relevant jurisdictional and governance framework. For the RTGS.global SaaS Offering, they are determined by the applicable service, participant agreements, and published policies.
Credential status and revocation patterns can also be included where required. Their use depends on the credential format, the trust model, and the configuration agreed for a particular deployment.
Practical implications
Trusted participant identity is not a single directory entry or a long-lived API credential. It is a combination of verifiable identity information, controlled relationships, signing and verification capability, and the governance rules that determine what evidence is accepted.
RTGS.global uses standards-based identity and credential patterns to support this model. ACA-Py provides wallet and agent capability, while the RTGS.global controller layer applies policy and integrates identity functions into wider platform workflows.
For technical evaluators, the key questions are therefore not only technical:
- Which participant identities and issuers must be recognised?
- What evidence is required for a participant to perform a given action?
- How are trust, authority, and status governed over time?
- Which signing and verification flows are needed in the intended operating environment?
Answering these questions ensures that identity controls align with the requirements of the settlement network they support.