Organisation roles and capabilities in Raidiam Connect

An organisation's capabilities within an ecosystem are determined by the roles assigned to it through domains. Roles control which APIs an organisation can publish or consume, which scopes its applications can request, and what certifications it advertises — making the same organisation model work for Open Finance, enterprise data sharing, digital wallets, and more.

---

How roles define capabilities

Trust Framework Administrators assign one or more roles to each organisation. Each role is scoped to a domain and carries a set of technical permissions — OAuth scopes, grant types, and response types — that determine what the organisation's applications are allowed to do.

Because capabilities come from roles rather than a fixed organisation type, a single entity can serve multiple functions simultaneously. An insurance company, for example, might hold an API provider role in the Open Insurance domain and an API consumer role in the Open Banking domain, all within the same ecosystem.

For full details on how roles are configured, linked to OAuth metadata, and assigned to organisations, see Roles.

Common capability patterns

The following patterns illustrate how organisations typically participate in a trust ecosystem. Each pattern corresponds to one or more roles that a Trust Framework Administrator can define within the ecosystem's domains.

API providers

Organisations that expose data or services to other participants. In Open Finance ecosystems these are often called Data Holders or Data Providers — banks, insurers, pension funds, and similar institutions that publish user-permissioned or machine-to-machine APIs.

With Raidiam Connect, an API provider can:

• Publish authorisation servers so that other participants can discover server configuration, register client applications, and obtain access tokens.

• Register API resources using standardised profiles. The platform automatically exposes the required endpoints, ensuring consistency across the ecosystem.

• Prove compliance with security profiles, data profiles, and customer journey requirements through trust marks and role metadata.

• Authenticate incoming requests using certificates issued by the ecosystem's Public Key Infrastructure or validated through OpenID Federation trust chains.

API consumers

Organisations that access APIs published by other participants. In Open Finance ecosystems these are typically called Third Party Providers (TPPs) or Data Receivers — fintechs, payment initiators, account aggregators, and similar entities that build products on top of shared data.

With Raidiam Connect, an API consumer can:

• Register applications and obtain client credentials for secure API access.

• Discover published APIs and authorisation servers through the participant directory.

• Onboard at provider authorisation servers automatically using OAuth Dynamic Client Registration (DCR) with a Software Statement Assertion, or through OpenID Federation automatic registration.

• Obtain certificates trusted by all ecosystem participants for mutual TLS authentication and request signing.

Credential issuers

Organisations that issue verifiable credentials within a digital wallet ecosystem — for example, government agencies issuing identity documents, universities issuing diplomas, or employers issuing proof of employment.

A credential issuer registers in the participant directory, publishes its signing keys and metadata, and can be discovered by wallet providers and credential verifiers through the directory's trust mechanisms.

Wallet providers

Organisations that operate digital wallets on behalf of users, enabling them to store and present verifiable credentials. A wallet provider registers its wallet application in the directory, obtains the necessary certificates, and advertises its capabilities so that credential issuers and verifiers can interact with it securely.

Credential verifiers

Organisations that verify credentials presented by wallet holders — for example, a bank verifying a customer's identity credential before opening an account, or an employer verifying a professional certification. Credential verifiers discover trusted issuers and their signing keys through the participant directory and the ecosystem's trust infrastructure.

Technical service providers

Organisations that provide shared technical services to other participants — such as API aggregation platforms, gateway operators, or compliance monitoring tools. These entities typically hold specialised roles that grant access to platform APIs without directly publishing or consuming end-user data.

Dual-role and multi-role organisations

An organisation is not limited to a single capability. A financial institution can simultaneously act as an API provider (sharing account data) and an API consumer (initiating payments through another provider). A university can be both a credential issuer and a credential verifier.

Multiple roles can be assigned across different domains, and an organisation's applications inherit the combined set of permissions. When registering more than one application, it is recommended to claim only the roles each application needs within its Software Statement.

Where roles are configured

What	Who	Where
Define domains	Trust Framework Administrator	Domains
Create roles within a domain	Trust Framework Administrator	Roles
Assign roles to an organisation	Trust Framework Administrator, Super User, or Data Administrator	Authorities
Claim roles in an application	Organisation Administrator	Software Statements

For a step-by-step walkthrough, see How to onboard organisations.