Roles and permissions

What you can see and do in SpeculaPro depends on the roles you hold. A role is a named set of permissions; a permission allows one kind of action, such as closing a case or approving a rule. You can hold more than one role, and you get every permission from all of them.

Administrators give people their roles on the People tab of Settings; see Managing people. Changes apply to the person’s very next action.

Why roles are split the way they are

Anti-money-laundering controls rely on separation of duties: the person who does something important should not be the person who approves it. That protects the institution against honest mistakes and against an insider quietly switching off a rule or burying a case.

SpeculaPro’s built-in roles follow that principle:

Rule authors cannot approve rules. Approvers cannot write them.
Analysts cannot close cases. Closing needs a senior analyst or the MLRO.
Analysts can propose suppressions, but cannot approve them.
Auditors can look at everything relevant but change nothing.
Administrators manage people and settings, but do not see cases or customers.

On top of the roles, the database itself refuses to let the same person both create and approve a rule version, a suppression, a case closure or a report, and your workspace can require a second person for sensitive administrative changes too. See the 4-eyes principle below.

The built-in roles

Every new workspace gets these nine roles. They are marked as system roles and cannot be deleted or edited. When none fits a job, an administrator can create a custom role, for example by cloning a built-in one.

Role	Who it is for	In short
Analyst	Level 1 investigators	Works alerts and cases, drafts reports, proposes suppressions. Cannot close cases or see personal data in clear.
Senior analyst	Level 2 investigators	Everything an analyst does, plus closing cases, seeing personal data, and managing risk designations.
L2 investigator	Investigators who take escalated cases	Everything a senior analyst does, plus approving case closures someone else proposed.
MLRO / Compliance officer	The money laundering reporting officer and their deputies	The final say: approves case closures, rules, suppressions and reports, submits reports, manages lists, reads the audit log, and approves workspace-settings and deny/allow-list changes someone else proposed.
Rule author	People who write and tune rules	Creates and edits draft rule versions. Cannot approve them.
Rule approver	A second reviewer for rules	Approves or rejects rule versions. Cannot write them.
Auditor (read-only)	Internal audit, external examiners	Reads alerts, cases, entities, rules, settings, change requests and the audit log, and the report register when also given `entities.view_pii`. Cannot change anything.
Data protection officer	The DPO and their deputy	Runs the Privacy area: retention and the purge, legal holds, data subject requests, the registers and the breach register. Sees customers and their personal data (to find them and export their data), reads the audit log and workspace settings. Has no access to alerts, cases or rules.
Administrator	IT or operations	Manages people, roles, API keys, webhooks, data sources, single sign-on and settings, approves those changes when another administrator proposes them, and reads the audit log. Has no access to alerts or cases.

The permissions

Permission	Allows you to
`alerts.view`	See the alert queue, each alert’s hits and transactions, the workspace summary counts, the real-time decision log and the Analytics page
`cases.view`	List and open cases, and read their alerts, hits and timeline
`cases.work`	Dismiss an open alert with a disposition, or several at once, open a case from an alert, comment, take or unassign a case, start work, escalate, put a case in a team’s queue, add evidence files and remove your own, ask the AI assistant about an open alert, for a summary of a case, or about the whole queue in a batch (asking also needs `entities.view`), and label a real-time decision as fraud or legitimate
`cases.close`	Close a case with a disposition, or propose its closure when a second person must approve
`cases.approve`	Approve or reject a proposed case closure (never your own), reopen a closed case, and assign cases to other people
`rules.view`	See rules, versions and their parameters, and each rule’s precision on real-time decisions. Read the AI assistant’s tuning suggestions on a rule
`rules.author`	Create and edit draft rule versions and submit them for approval. Ask the AI assistant for tuning suggestions on a rule, where the workspace uses it
`rules.approve`	Approve or reject a submitted rule version
`rules.backtest`	Run and cancel backtests: replay a rule version over past data before it is approved. Seeing backtests and their results needs only `rules.view`
`rules.packs_downgrade`	Force a signed rule-pack file older than the installed version (a pack downgrade). Its rule changes still go for approval like an update. See Signed pack updates
`suppressions.create`	Propose a suppression
`suppressions.approve`	Approve a suppression proposed by someone else
`entities.view`	See customers, accounts, counterparties and devices, including names. Without it, alerts and cases show a pseudonym such as `Customer 3f9a1c` instead of a name, and a case’s evidence files are listed as `File 1.pdf` and can’t be downloaded
`entities.view_pii`	See protected personal data in clear — ID numbers, phone numbers, email addresses and full account numbers
`designations.manage`	Add and revoke risk designations such as PEP or sanctioned
`lists.manage`	Create and edit allow, deny and reference lists. Changes to deny and allow lists may need a second person’s approval
`lists.approve`	Approve changes to deny and allow lists someone else proposed. See Approvals
`reports.view`	Read the report register. Reports carry identity in full, so this also needs `entities.view_pii`
`reports.draft`	Draft an STR from a case, edit drafts and send them for approval. Also needs `entities.view_pii`. With both, ask the AI assistant for a draft of the narrative
`reports.approve`	Approve or send back a report drafted and sent by someone else; export and download the report file in the FIU’s format (goAML, or the national declaration); change the reporting settings; void a report that must not be filed. Also needs `entities.view_pii`
`reports.submit`	Export and download the report file, and record that it was filed with the FIU and the FIU’s answer. Also needs `entities.view_pii`
`users.manage`	Add people, change their roles, disable and re-enable accounts, reset two-factor and issue temporary passwords, and create, change and delete custom roles
`users.approve`	Approve role grants, re-enabled accounts, credential resets and custom-role changes someone else proposed
`api_keys.manage`	Create, rotate and revoke API keys
`api_keys.approve`	Approve a new API key someone else requested
`webhooks.manage`	Add, change, test and remove webhooks, rotate their signing secrets and resend deliveries
`webhooks.approve`	Approve a new webhook endpoint, or a changed address, someone else proposed
`datasources.manage`	Set up data sources: Kafka topics, SFTP / S3 file drops and change data capture sources, their connection tests, runs, file history and mappings
`datasources.approve`	Approve a new data source or changed connection settings someone else proposed
`screening.view`	See the Screening settings, the sanctions lists and their versions, re-screens and providers; read potential matches; screen a name on demand against the lists (not the providers). Every such check is written to the audit log
`screening.review`	Take, assign and comment on potential sanctions and PEP matches, and resolve them as a true match or a false positive. Reading the queue also needs `screening.view`. A match against a sanctions list needs a second person’s approval, or, while that approval is not in effect, `screening.approve` itself
`screening.manage`	Choose lists and providers, set the match threshold, import the workspace’s own lists and start re-screens; screen one customer or counterparty on demand, and send a name to the screening providers on demand (both call a third party that may bill the call). Source, threshold, provider and import changes may need a second person’s approval
`screening.accept_removal`	Import a signed list bundle through the API although it removes more of a list than a bundle may by itself (self-hosted). Every use is audited
`screening.approve`	Approve a list, threshold, provider, list import or signed-bundle import, or a decision on a potential match, that someone else proposed. While approval for sanctions matches is not in effect, also needed to confirm or clear a match against a sanctions list
`models.view`	Open the Models page: every risk model version, its model card, its score distribution and its drift, and the retraining schedule
`models.manage`	Train a risk model, move it to shadow, propose that it goes live and retire it, and set the retraining schedule. Going live always needs someone else’s approval
`models.approve`	Approve a risk model going live, or the live model being retired, that someone else proposed
`sso.manage`	Set up single sign-on: the identity-provider connection, email domains, group-to-role mapping, multi-factor rules, enforcement and break-glass administrators, and create and revoke the SCIM tokens an identity provider provisions people with. Roles that hold administration, approval or security permissions (Administrator, MLRO, L2 investigator, Rule approver, Data protection officer, and custom roles holding one) are not given or removed over SCIM unless the workspace allows it: see Privileged roles
`support_access.manage`	Approve, narrow, deny or revoke SpeculaPro support staff’s requests to look inside the workspace, and set the support access policy. Hosted service only
`sso.approve`	Approve single sign-on changes someone else proposed
`settings.manage`	Change workspace settings, teams, escalation policies, the AI assistant (its key, provider and model, and asking the service provider for more calls) and the approval policy, and import customers and transactions from a file (Settings → Data import)
`settings.approve`	Approve workspace-settings, escalation-policy, reporting-settings and approval-policy changes someone else proposed
`settings.view`	Open every Settings tab read-only: workspace and reporting settings, people, roles, the approval policy, API keys, webhooks and their delivery history, data sources, single sign-on, screening and the licence. Nothing can be changed, and keys, passwords and signing secrets are never shown (the Auditor’s view of configuration)
`privacy.view`	Read the Privacy area: retention, dry runs and purges, legal holds, data subject requests, the registers and the breach register
`dsr.handle`	Register and work data subject requests. Downloading a person’s data also needs `entities.view_pii`
`privacy.manage`	Change retention periods and switch the purge on or off, place and release legal holds, change the data protection settings and registers, and record breaches. Retention and hold changes can need a second person with `privacy.manage`
`audit.view`	Read the audit log, under Settings → Audit log or through the API, and every change request

Every reporting permission works only together with entities.view_pii, because reports carry identity in full. The built-in Analyst doesn’t hold reports.draft.

Who can do what

The exact permissions of each built-in role, in one table, and advice on which roles to give each person, are in Roles. The menu only shows the sections your roles can open; see What you see in the menu.

The 4-eyes principle

Some actions are only complete when a second, different person confirms them. SpeculaPro enforces this in the database, so no screen, API call or script can get around it.

Action	Done by	Confirmed by	Must be different people
Rule version	The author	An approver with `rules.approve`	Yes
Suppression	The person proposing it	Someone with `suppressions.approve`	Yes
Case closure, for high and critical cases (or every case, if your workspace requires it)	The person closing	Someone with `cases.approve`	Yes
Regulatory report	The person drafting it	Someone with `reports.approve`	Yes

Your workspace can also put administrative changes under the same rule: giving someone administrator or approver powers or access to personal data, resetting someone else’s two-factor, switching off the two-factor requirement, creating an API key or a webhook, changing the decision policy and more. Such a change becomes a change request that a different person with the matching ….approve permission must approve before anything changes. Several are on by default once two people can approve them. See Approvals.

With the built-in roles, only the MLRO role holds reports.approve and suppressions.approve, and only the MLRO and the L2 investigator hold cases.approve. This is deliberate. Four eyes are enforced in the database: the person who approves must be a different user from the person who drafted or closed. No setting switches this off, and an administrator can’t override it.

So an MLRO working alone cannot approve their own report. Before you go live:

Assign the MLRO role to a second person, such as a deputy MLRO or compliance manager, or give a second person another role that holds reports.approve (and cases.approve and suppressions.approve if they should confirm those too).
Let an analyst or senior analyst draft reports, so either MLRO can approve them.
Make sure the second approver is reachable during holidays and absences. Otherwise high-risk closures, suppressions and reports wait until someone is back.

People and API keys

Roles are for people. Your other systems connect with API keys, which have scopes instead of roles:

Scope	Allows the key to
`ingest:write`	Send transactions, customers, accounts, account events and FX rates, and report outcomes
`decide`	Call the real-time decision API and report outcomes

An API key can never work cases, approve anything or read personal data. Administrators create keys on the API keys tab of Settings; see Managing API keys and the security model.

Names, personal data and the two “view” permissions

SpeculaPro protects personal data at two levels:

Level	What it covers	Permission	Without it you see
Who it is	Customer and counterparty names, your own customer reference, segment and KYC tier	`entities.view`	A stable pseudonym, such as `Customer 3f9a1c`, and no reference or details
How to reach or identify them	Phone numbers, email addresses, national ID numbers and dates of birth. These are stored encrypted	`entities.view_pii`	Masked values, such as `+233•••••••89`, or nothing

The pseudonym is the subject type plus the last six characters of its internal ID. It is the same every time, so someone without entities.view can still tell that three alerts concern the same customer, without learning who it is. In the default roles, only the rule approver and the administrator lack entities.view; the administrator also can’t see alerts or cases at all.

Masked values are enough to investigate patterns. Seeing the clear values, for example to fill in an STR, needs entities.view_pii. The customer API returns them only to people with that permission, and every such view is written to the audit log as customer.view_pii. The customer’s page works the same way: it shows the clear values only to people with that permission, and records the view.