User roles and permissions

Ripple Custody (Wallet) provides six user roles. Assign each user the role with the least privilege needed for their responsibilities. To assign or change a user's role, see Manage users.

Contact Ripple for more information on these roles, or if your organization requires a more bespoke role structure.

Owners and administrators share nearly identical permissions. The key difference is that only owners can update organization settings, such as single sign-on (SSO) and the Travel Rule connection, and create backups.

If a procedure mentions a button or menu item you can't see, your role probably doesn't include that task. Ask an owner or administrator in your organization. Each procedure states the roles that can do it, and the actions table at the top of each task page has a Console role column.

API credentials don't have roles. Each credential has a type and the permissions you grant when you create it. See Manage API credentials.

An owner has full control over all aspects of the system. They can perform all actions across all users, vaults, wallets, devices, transactions, API credentials, counterparties, addresses, policies, approval groups, and organization settings.

Example: The CEO of a company who needs full control over all aspects of the system, including creating and managing users, vaults, wallets, and approving high-level changes.

Similar to owner, but with slightly fewer privileges. Can manage most aspects of the system, including users, vaults, wallets, devices, and transactions, but can't update organization settings, such as single sign-on, or create backups.

Example: A member of the C-suite that has executive power and is responsible for day-to-day business operations, including handling user accounts, configuring vaults and wallets, and managing devices and API credentials.

Can create and manage vaults, wallets, and transactions, and approve requests as a member of an approval group. Can't manage other users or perform administrative tasks such as configuring policies, approval groups, or the address book.

Example: A finance team member who needs to create transactions and manage vaults and wallets but requires approval for specific actions, such as finalizing/sending transactions.

Primarily focused on approving transactions and some policy rules. Can view many areas of the platform but has limited creation or modification rights.

Example: A senior finance officer responsible for reviewing and approving transactions, address book entries, and policy rules proposed by others.

Has the most restricted access. Can view vaults, wallets, and transactions, but cannot create, modify, or approve most items.

Example: A junior team member or finance admin who needs to view transactions and basic information but doesn't have permission to make changes or approvals.

Designed for oversight. Can view most aspects of the system, including users, vaults, wallets, devices, and transactions. The only change an auditor can make is to freeze or unfreeze a transaction. Has access to view organization settings.

Example: An internal or external compliance or security officer who needs comprehensive view access to conduct audits and ensure regulatory compliance without the ability to change configuration.

The following tables show the permissions and related actions each role can perform. In the tables, Admin is the Administrator role.

An Approve permission lets a user act on an approval request only when they're a member of the approval group for that request type. See Configure approval flows.