System Roles

• System administrator: Manages the entire system.
• System creator: Creates tokens. After a creation request is submitted, it is sent to the system manager, who either approves or rejects the request. After the minting request is approved, tokens are credited to the system creator's account. The creator can then transfer these tokens to a system issuer.
• System manager: Approves or rejects requests for minting, burning, and holding tokens. Hold request approvals are used for transfers between organizations.
• System issuer: Transfers tokens to financial institution officers or to the system retirer for burning. Users in this role receive tokens from the system creator and financial institution officers. The system manager must approve any transfers between organizations.
• System auditor: Has read-only access to all organizational data in the system.
• System retirer: Burns tokens. This role receives tokens from the system issuer. After a burn request is submitted, it is sent to the system manager.

Organization Roles

• Organization administrator: Manages their specific organization.
• Organization officer: Receives tokens from the system issuer. They can transfer these tokens to users in any organization or return tokens to the system issuer. All transfers must be approved by the organization approver.
• Organization user: Receives tokens from the officers of their respective organizations. They can transfer these tokens to users and officers in any organization. All transfers must be approved by the organization approver.
• Organization manager: Approves or rejects hold requests for their specific organization. Hold requests and approvals are used for all transfers between or within organizations.
• Organization auditor: Has read-only access to data that is specific to their organization.

Onboarding

After you install, configure, and stage the application, complete the following steps to access the application.

1. After the application is staged, navigate back to the home page.
2. On the application dashboard, locate the staged application. The status is shown as Staged next to the application name.
3. Click the drop-down menu under Staged and select the application name.
4. Copy the link or open the staged application in a new browser tab or window to test and review the application.

In generic mode, all accounts are displayed and tracked by user IDs. In confidential mode, accounts are displayed and tracked by bank account IDs. Bank account IDs are random alphanumeric strings that are generated when the account is created. In confidential mode, the bank account ID replaces the user ID in the application interface.

In confidential mode, account balances are calculated on-demand using a consolidation method (consolidateRunningBalanceInTransactions), which is defined in the chaincode. When consolidation runs, all pending transactions are processed and the account balance is updated. Account balances are available only after consolidation is run for an organization. If consolidation has not run for an organization, account balances are shown as Reconciliation Pending.

The consolidateRunningBalanceInTransactions method consolidates account balances for the caller's organization. This method can be called by a Token Admin or Org Admin. System owners must authenticate using the SYSTEM_ADMINS user account that is associated with the tokenAdmin token role. Participant organizations must authenticate using their respective ORG_ADMINS user accounts, each of which is associated with the orgAdmin token role.

To keep account balances accurate across the network, the consolidation method must be run at regular intervals. You can use the scheduleTransactions REST API endpoint in Oracle Blockchain Platform to run consolidation automatically. For best results, set the scheduler to run every two minutes, and set the expiry string to a high value such as 120M (ten years). For more information, see Schedule Transaction to Run.

Invalid Account. Please Contact Admin

The first time that any user attempts to log in to the application, no user accounts have been created yet. Only users from the System_Admins group who also have the tokenAdmin role assigned to them can log in. All other login attempts will fail. The following section includes more information about the exception for the SYSTEM_ADMINS persona.

System_Admins Exception

The login process is different for users with the SYSTEM_ADMINS persona. Users in the System_Admins group can log in even if their account has not yet been created, but these users must have the tokenAdmin role.

When you deploy the chaincode, ensure that users in the System_Admins group have the tokenAdmin role. The parameters that are passed during chaincode initialization must include the system administrator users as having the tokenAdmin role. This allows the System_Admins group to log in to the application for the first time to create the other user accounts.

If you log in to the application as a user in the System_Admins group, and that user was not included as an initialization parameter when the chaincode was deployed, you must manually assign the tokenAdmin role to the user. You can manually assign the tokenAdmin role by using a Postman collection.

Application Workflow

The following steps show the actions of the various roles in a complete application workflow. The first seven steps must be completed to use the application.

1. The system administrator logs in.
2. The system administrator initializes the token.
3. The system administrator creates their own bank account and then reloads the home page to see the updated network details.
4. The system administrator creates bank accounts for all CBDC personas, as shown in the following table.

   Application Group	Role
   System_Admins	Token Admin
   System_Auditors	Token Auditor
   System_Creators	Minter
   System_Managers	Escrow
   System_Issuers	none
   System_Retirers	Burner

5. The system administrator creates organization administrator bank accounts, which have the Org Admin role.
6. Confidential mode only: The system administrator and organization administrators configure the scheduler to run consolidation automatically. This ensures that displayed account balances are accurate. For more information, see Schedule Transaction to Run.
7. The organization administrator logs in and creates accounts for users of their organization.
8. The system administrator assigns roles to the new organization users, as shown in the following table.

   Application Group	Role
   Org_Admins	Org Admin
   Org_Users	none
   Org_Officers	none
   Org_Managers	Escrow
   Org_Auditors	Org Auditor

9. The system creator logs in and requests that tokens be minted.
10. The system manager logs in and approves or rejects the minting request. If the request is approved, the tokens are credited to the system creator.
11. The system creator transfers the tokens to the system issuer.
12. The system issuer logs in and transfers the tokens to an organization officer. If the transfer is approved by the system manager, the tokens are transferred. Alternately, the system issuer can transfer the tokens to the system retirer for burning.
13. The system auditor logs in, selects auditing policies, and reviews the relevant transaction data.
14. The system retirer logs in and requests that tokens be retired. If the system manager approves, the tokens are burned.
15. The system manager logs in and approves or rejects the request to issue tokens. If the transfer is approved, tokens are credited to the organization officer, who can then transfer them to organization users.
16. The organization officer logs in and transfers tokens to organization users, other organization officers, or back to the system owner. All transfers require the approval of the organization manager.
17. The organization manager logs in and approves or rejects transfer requests.
18. organization users log in and transfer tokens to other organization users at any organization.
19. The organization auditor logs in, selects auditing policies, and reviews the relevant transaction data.