Roles

In short

You give people access by giving them roles. Every workspace starts with nine built-in roles, designed so that no single person can both do something important and approve it. A person can hold several roles, and gets every permission from all of them.

Choose the fewest roles that let each person do their job. You assign roles when you add a person, and change them on the People tab.

What each permission means, and why the roles are split the way they are, is explained in Roles and permissions.

The built-in roles

These are the roles you can tick when adding a person. The summary is the line shown under each role on screen.

Role	Summary on screen	Typical holder
Analyst	Works alerts and cases; can’t close cases	Level 1 investigator
Senior analyst	Closes cases; sees full customer details	Level 2 investigator, team lead
L2 investigator	Takes escalated cases; approves other people’s closures	An experienced investigator who confirms closures, so the MLRO isn’t the only approver
MLRO / Compliance officer	Approves closures, rules and suppressions; files reports	The MLRO and their deputy
Rule author	Drafts rule changes for approval	Someone who tunes detection, often in compliance analytics
Rule approver	Approves and deploys rule changes	A second reviewer for rules, such as the head of compliance
Auditor (read-only)	Read-only across the workspace, including the audit log; no personal data	Internal audit, external examiners during a review
Data protection officer	Runs data protection: retention, legal holds, data subject requests and the breach register	The DPO and their deputy
Administrator	Manages people, API keys and settings	IT or operations

Built-in roles can’t be deleted or edited. When none fits, create a custom role, for example by cloning one of these and removing what the job doesn’t need.

Permission matrix

✓ means the role holds the permission. This is the exact set every new workspace is given, and that existing workspaces get when they upgrade (migration 00022 adds the L2 investigator role and the approval permissions; 00030_privacy adds the Data protection officer role and the privacy permissions).

Permission	Analyst	Senior analyst	L2 investigator	MLRO	Rule author	Rule approver	Auditor	DPO	Admin
alerts.view	✓	✓	✓	✓	✓	✓	✓
cases.view	✓	✓	✓	✓			✓
cases.work	✓	✓	✓	✓
cases.close		✓	✓	✓
cases.approve			✓	✓
rules.view	✓	✓	✓	✓	✓	✓	✓		✓
rules.author					✓
rules.approve				✓		✓
rules.backtest				✓	✓	✓
rules.packs_downgrade				✓
suppressions.create	✓	✓	✓
suppressions.approve				✓
entities.view	✓	✓	✓	✓	✓		✓	✓
entities.view_pii		✓	✓	✓				✓
designations.manage		✓	✓	✓
lists.manage				✓
lists.approve				✓
reports.view				✓			✓
reports.draft		✓	✓	✓
reports.approve				✓
reports.submit				✓
users.manage									✓
users.approve									✓
api_keys.manage									✓
api_keys.approve									✓
settings.manage									✓
settings.approve				✓					✓
settings.view							✓	✓	✓
webhooks.manage									✓
webhooks.approve									✓
sso.manage									✓
support_access.manage				✓					✓
sso.approve									✓
datasources.manage									✓
datasources.approve									✓
screening.view	✓	✓	✓	✓			✓		✓
screening.review	✓	✓	✓	✓
screening.manage				✓					✓
screening.accept_removal				✓					✓
screening.approve				✓
models.view				✓	✓	✓	✓		✓
models.manage					✓
models.approve				✓		✓
privacy.view				✓			✓	✓
dsr.handle								✓
privacy.manage								✓
audit.view				✓			✓	✓	✓

A few things in this table surprise people:

• The MLRO can’t propose a suppression, only approve one. Analysts and senior analysts propose; the MLRO confirms. That keeps the two steps with different people.
• The rule approver doesn’t see names. Without entities.view, alerts show a pseudonym such as Customer 3f9a1c. Approving a rule change doesn’t need to know who the customers are.
• The administrator sees no alerts, cases or customers at all. See Administering a workspace.
• The auditor can read the audit log but can’t work or close anything. With settings.view they can open every Settings tab read-only (controls are disabled or hidden, and no key, password or signing secret is shown), and with audit.view the audit log and every change request. Still refused: a webhook delivery’s payload, a data source file’s results download and the licence usage report.
• The administrator approves other administrators’ changes. Admin holds the ….approve permissions for its own areas, so in a workspace with two administrators each approves what the other proposes. See Approvals.
• The MLRO approves workspace-settings and list changes (settings.approve, lists.approve). With one administrator and one MLRO, an administrator’s change to the decision policy waits for the MLRO, and an MLRO’s change to the reporting settings waits for the administrator.
• In a default workspace only the MLRO decides a sanctions match, because only that role holds screening.approve. Analysts still assign, comment and decide PEP and adverse-media matches.
• Analysts screen names, but not through a provider. With screening.view, an analyst reads potential matches and screens any name against the lists. Screening one customer or counterparty on demand, and sending a name to a screening provider, need screening.manage, which only the MLRO and the Administrator hold: those calls record potential matches and go to a third party that may bill each one. See Sanctions and PEP screening.
• The analyst can’t draft a report. Reports carry identity in full, so drafting needs entities.view_pii as well as reports.draft. The Senior analyst, L2 investigator and MLRO draft. See Regulatory reporting.
• The data protection officer sees customers but not investigations. The DPO needs customers’ personal data to answer their requests, but has no alerts, cases or rules. Requests from customers under investigation go to the MLRO first, through reports.approve. See Data subject requests.
• Retention changes and legal holds are approved by another DPO. Both sides need privacy.manage, so with a single DPO they apply straight away. Give the role to a deputy to put them under dual control.

How to choose roles for each person

Person	Give them	Why not more
A new level 1 investigator	Analyst	They don’t need to close cases or see full ID numbers yet
An experienced investigator who closes routine cases	Senior analyst	High and critical closures still go to the MLRO
A team lead who confirms other investigators’ closures	L2 investigator	They don’t approve rules, suppressions or reports
The MLRO	MLRO / Compliance officer
The MLRO’s deputy	MLRO / Compliance officer as well	So each can approve what the other proposes. See the caution below
Someone who tunes rules	Rule author	They can’t put their own change live
The person who signs off rule changes	Rule approver, or the MLRO role	They can’t write the changes they approve
Internal audit or an examiner, for a review	Auditor (read-only), then disable the account when the review ends	Read-only, including the audit log
The data protection officer, and a deputy so retention changes and legal holds can be approved by a second person	Data protection officer	They don’t need alerts, cases or rules
IT, who add and remove staff	Administrator	They don’t need to see investigations
A second administrator, to approve the first one’s changes	Administrator as well	See Approvals
Anyone whose job doesn’t match a built-in role	A custom role

You need two people for every approval

Four-eyes rules are enforced by the database: whoever approves a rule version, a suppression, a high-risk case closure or a report must be a different person from whoever drafted it. With the built-in roles, most approvals belong to the MLRO role (the L2 investigator can also approve case closures). If only one person holds it, nothing they draft themselves can ever be approved. Give the MLRO role to a deputy as well, and check the second approver is reachable during holidays. See the 4-eyes principle.

Don’t combine administration with compliance

If an administrator also holds a compliance role, such as MLRO, they can both control accounts and approve investigations, which defeats separation of duties. SpeculaPro stops anyone changing their own roles, but it doesn’t stop two administrators granting each other extra roles. Keep administrators and compliance staff separate, and review role assignments regularly.

Reviewing access

Good practice, and something examiners commonly ask for:

1. Every quarter, open Settings › People and check each person still needs each role they hold.
2. When someone changes job, change their roles the same day.
3. When someone leaves, disable their account on their last day.
4. Look for people marked No 2FA or never signed in, and follow up.

Every role change is recorded in the audit log as user.roles, with the roles before and after, so you can show an examiner who had which access, and when.

Related

• Roles and permissions
• Managing people
• Administering a workspace