Central bank participant access control testing verifies that each institution and its authorised users can perform only the actions permitted by their assigned roles, entitlements and participant scope. It checks both allowed and denied operations across relevant interfaces, such as a participant portal, application programming interface (API) or real-time gross settlement (RTGS) system, and confirms that access decisions are enforced and recorded consistently.

What to include in central bank participant access control testing

Start with the system’s access rules and identify the protected resources and actions. These may include submitting a payment, viewing a settlement position, managing user entitlements, changing settlement instructions or administering another participant’s account. Confirm the scope with product owners and system security teams; central bank platforms differ in their operating models and permissions.

Build an access matrix that maps participant types and user roles to actions and data scopes. For example, a participant operator may submit payment instructions for their own institution, while a participant administrator may manage that institution’s users. A central bank operations role may have a separate, controlled set of administrative permissions. Include read, create, amend, approve, cancel and export actions where they exist.

Role-based access control (RBAC) assigns permissions through roles. Some systems also apply attributes or entitlements, such as participant identifier, account, currency, payment type or transaction limit. Test the complete decision: a user must have the required role and any required scope or entitlement. Authentication establishes who the user is; authorization determines what that identity can do.

Prepare identities and test data

Use a controlled test environment with representative participant records and non-production credentials. Provision at least two participant organisations and users with different roles. Include an unauthorised user, a user with a valid role but the wrong participant scope, and a user whose entitlement has expired or been revoked. Keep identifiers distinct so a test can detect data leakage between participants.

Check dependencies that influence access decisions. These can include identity-provider group mappings, entitlement services, API gateways, session or token claims, and cached permissions. Confirm that test configuration reflects the intended production rules. Environment drift can make results misleading, especially when a role mapping or permission cache differs between environments.

Execute positive and negative checks

For each access-matrix rule, exercise the permitted action and a nearby prohibited action. Test through the user interface and directly through the API when both are available. A hidden button is insufficient evidence of access control: the server must reject an unauthorised request even when a user sends it directly.

An illustrative test case is:

  • Given: User A belongs to Participant A and has payment-submission permission.
  • When: User A submits a valid payment for Participant A.
  • Then: The system accepts the instruction and records User A and Participant A in the audit trail.
  • When: User A submits an otherwise equivalent instruction for Participant B.
  • Then: The system denies the request, creates no payment, and records the denied attempt according to the audit requirements.

Also test role changes, revocation, expired sessions, direct object references and attempts to change participant identifiers in requests. Check that an API response does not disclose another participant’s data in error messages or returned fields. For high-impact actions, verify any required approval or separation of duties independently from the user’s ability to initiate the action.

Verify outcomes and investigate failures

Assert the response, resulting system state and audit evidence. A denial should leave no unintended transaction or entitlement change behind. Check that the correct identity, participant, requested action, decision and timestamp are recorded where the system’s audit design requires them. Confirm that logs avoid exposing credentials or sensitive data.

Watch for failures caused by stale tokens, cached permissions, inconsistent identity mappings, fail-open behaviour during dependency outages, or checks applied only in the interface. A test that receives an error response may still have failed if the operation was partially committed. Reconcile relevant records and downstream events to establish whether the denied request had any effect.

Trace each test back to its access rule and record the identity, role, participant scope, environment, request, expected result and observed evidence. Re-run affected positive and negative cases after changes to roles, identity integration, API policy or participant configuration. This links access control testing with wider [banking role-based access control testing] and [banking audit trail testing] activities.

Frequently asked questions

Can central bank participant access control tests run in production?

Routine access control tests should run in a controlled non-production environment with representative identities and data. Production validation requires explicit approval, a defined operational window and safeguards that prevent test requests from creating or changing real settlement activity.

How should service accounts be tested?

Test each service account as a distinct identity. Verify its permitted interfaces, participant scope, actions, credential rotation and behaviour after access is revoked, and confirm that it cannot inherit a human user’s broader permissions.

How should emergency access be covered?

Test the emergency access process against its documented approval, time limit, scope and monitoring requirements. Verify that access is granted only to the intended identity, that its use is auditable, and that access ends when the authorised period or incident response ends.