Roles & Permissions

Roles control what users can do within a Channel Partner client account. RiskOS™ provides system-defined roles as starting points and lets you create custom roles with granular permissions tailored to your organization's needs.

Access the Roles tab from Settings > Users in the Channel Partner sidebar.

Why it matters

Roles are the building blocks of your access control model. A poorly designed role can either block users from doing their work or grant more access than intended. Understanding the permission categories and designing roles around job functions keeps your client accounts secure and functional.

Before you begin

Roles table

The Roles tab displays all roles available in the current account.

Search roles

Use the search field above the table to filter roles by name.

System-defined vs. custom roles

📘

Note:

System-defined roles cannot be edited or deleted. To see exactly what each one grants, review the system-defined roles section.

System-defined roles

Channel Partner client accounts include the same system-defined roles as every other RiskOS™ account. These roles are identical across all accounts, and you cannot edit or delete them. The following tables list the permissions each system-defined role grants in Production and Sandbox.

The Account Owner is the most powerful administrative role in RiskOS™ and you should assign it to a limited number of users. The role has full access to the primary account and sub accounts in your organization, including access to transaction data, including PII, and user information.

When a Socure account is created, we provision the Account Owner role to a designated user in your organization. After the registration and provisioning are complete, the Account Owner can begin assigning additional user roles.

The Administrator role can create sub accounts and has full access to each sub account's transaction data, including PII access, and user information. Every account and sub account must have at least one Administrator for user management and account configuration.

The Fraud Analyst role has full access to PII but limited or no access to other features in RiskOS™. You can assign this role to multiple users in your account.

The Developer has full access to the Developers page and limited or no access to the other features in RiskOS™, including no access to PII. You can assign this role to multiple users in your account.

Compliance Case Management

The following section lists the system-defined roles available for Compliance Case Management.

Compliance roles receive cases based on the Case Management workflow your organization configures:

• One-step workflow (Step 1): Cases are auto-assigned to the Compliance Officer. See Watchlist One-Step Workflow.
• Two-step workflow (Step 2): Cases are auto-assigned round-robin to the Compliance Analyst, then escalated to the Compliance Supervisor for approval. See Watchlist Two-Step Workflow.

📘

Note:

In a one-step workflow, only the Compliance Officer can act on a case. If Compliance Analyst or Compliance Supervisor roles remain assigned during a transition, they are included in round-robin assignment but cannot act on cases.

You don't have to remove a role before switching workflows. To reassign a case that the system auto-assigned to you during a transition, remove your own permission and the system reassigns the case automatically. A Workforce Manager can also remove an individual from the auto-assignment mechanism on a short-term basis.

The Compliance Supervisor role allows users to review cases, add comments, evaluate them, and assign them to other Compliance Analysts.

The Compliance Officer role enables users to review cases, add comments, evaluate and approve them, and assign them to other Compliance Analysts.

The Compliance Analyst role gives the user the ability to review and add comments to compliance cases.

Permission categories

Each role is configured with permissions across several categories. Most categories use a single access level — you pick one option, such as No Access, Can View, or Can Edit (the highest level, which grants every permission in that category). Workflows and Fraud Case Management are multi-select: instead of one access level, you choose any combination of granular actions. The following diagram shows how permissions flow from role to user:

Role

Permission categories

Single access level
(most categories)

Multi-select actions
(Workflows, Fraud Case Management)

No Access

Can View

Can Edit

Any combination of
granular actions

📘

Note:

The categories and actions available when you create or edit a role depend on your account configuration and enabled products, so the role dialog may show a different set. The granular actions offered for Workflows and Fraud Case Management are also configuration-driven — the examples earlier in this topic are illustrative, not an exhaustive list.

Create a custom role

1. On the Roles tab, click Add Role.
2. Enter a Role Name (required). Use a descriptive name based on the job function (for example, "Case Reviewer", "Workflow Admin").
3. Set the permissions for each category. For single access level categories, select one option ( No Access, Can View, or Can Edit). For Workflows and Fraud Case Management, select any combination of granular actions from the multi-select dropdown.
4. Click Save to create the role.

What happens after saving

Global custom roles

A custom role you create in the Management account is a Global role: it becomes available in every client account automatically, so you don't re-create it in each one. This lets you centrally manage roles for all your clients from a single account.

📘

Note:

Create a role in the Management account when every client needs it. Create a role inside a specific client account when only that client needs it.

Delete a custom role

1. On the Roles tab, locate the custom role you want to remove.
2. Click the Delete button in the Actions column.
3. Confirm the deletion in the dialog.

⚠️

Important:

System-defined roles cannot be deleted — only custom roles can be removed. Before deleting a custom role, reassign any users currently assigned to it. Deleting a role that is still assigned to users removes those permissions immediately.

Role design best practices

For a comprehensive access review process, see Access Governance Best Practices.

Troubleshooting