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.

Plan for the small team: you need two approvers, not one

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:

1. 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).
2. Let an analyst or senior analyst draft reports, so either MLRO can approve them.
3. 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.

Notes are shown as written

Pseudonyms replace names in the fields SpeculaPro fills in: the subject, the case title and the counterparty on each transaction. Comments and closing notes are shown exactly as people wrote them, to everyone who can open the case. Don’t write a customer’s ID number or phone number into a note.

Related

• Roles
• Managing people
• Workspaces and tenancy
• Rules and versions
• Escalation and SLAs
• Audit trail