Reference
Policy Coverage & Governance
How the Policies section shows what's actively covered, what needs attention, and what evidence you can hand an auditor — without ever letting one click change live screening behavior.
Verified against the live /cabinet/policies pages while writing this page — section names, statuses and button labels are real, not illustrative.
1. What This Covers
Policies (/cabinet/policies) is where an organization sees how the platform actually applies compliance controls to it — not source IDs or JSON, but which workflows are covered, what needs attention, and what evidence can be handed to an auditor. It's read-oriented by design: an organization can request a change, but nothing here flips live screening behavior with one click.
Who this is for: compliance managers, operations owners, internal auditors and business-process owners who need to know what's active, what's changing, and what they can prove.
2. What An Organization Can And Cannot Do
An organization can:
- view active policies and coverage;
- download evidence packets;
- see the attention queue;
- submit a governed policy change request;
- track a request's full lifecycle;
- view review packets;
- view open exceptions and their expiry;
- see which policy version actually ran in recent case and item screenings.
An organization cannot:
- turn a source on or off directly;
- publish a platform-wide policy;
- activate its own policy version itself;
- approve its own exception without platform review;
- change live screening behavior with a single click.
This is deliberate. A policy change can affect legal risk, blocks, customer onboarding, payments or trade operations — every change goes through governed review before it reaches production.
3. Reading The Policy Posture Dashboard
Opening /cabinet/policies shows the organization's current posture at the top:
| Card | What it tells you |
|---|---|
| Workflow coverage | How many workflows have an active policy |
| Source coverage | How many obligation groups and sources are included |
| Governance queue | How many actions need attention right now |
| Exceptions | How many exceptions are open or expiring soon |
All green means the organization has clear, active coverage. Any warning means there's something to open in the attention queue or the evidence library before moving on.
4. Active Workflow Policies
This section answers one question: which workflows have an active screening policy right now? Typical workflows: payment screening, customer onboarding, beneficial-owner review, supplier onboarding, goods import, goods export, trade transactions, manual review.
For each workflow you see whether a policy is active, its name and version, the configured risk appetite, how many groups/sources/rules it compiles, and whether it currently carries any warnings.
Workflow: Payment screening
Policy: Baseline - Payment screening
Coverage: 18 groups / 21 sources / 3 decision rules
Warnings: 0
A workflow doesn't run "on its own" — it runs against one specific, compiled policy version that can be explained, inspected and shown to an auditor on request.
5. The Attention Queue
The attention queue surfaces everything that needs an organization's action: a source's health degrading, a review packet ready for review, a policy exception expiring soon, an organization request still pending, or a workflow with no coverage at all.
Working an item: open the card, read why it matters, open the linked evidence or detail page, and either submit a policy change request or — for a review packet — save the evidence and complete the internal review.
An empty queue is a genuinely good signal: it means everything that happened has already been handled, not that nothing happened. Nothing here is lost to email — it stays in the evidence trail.
6. The Evidence Library
A quick index of the documents and links an organization is most likely to need for an audit conversation: current posture, the latest source notice, the latest review packet, the latest policy request, and any open exception.
Opening or downloading anything here is read-only — it never changes the live policy. It's confirmation material, ready to hand to a compliance committee, an auditor, or an internal process owner.
7. Requesting A Policy Change
Click Request policy change. The form asks for: a template (or manual entry), the workflow, the policy area, the requested action, a risk level, the requested change itself, and a business or legal reason.
A concrete request is one the platform can actually act on:
Workflow: Payment screening
Policy area: Sanctions lists
Requested action: Activate coverage
Requested change: Expand sanctions and restricted-party source coverage
for payment screening.
Business/legal reason: Bring payment screening in line with internal
risk appetite and counterparty jurisdiction exposure.
Compare that with "add more sources" — a request with no workflow, no reason and no risk level gives the platform nothing to review against.
Submitting creates an audit record immediately. The live screening policy does not change yet — the platform reviews the request and, if it approves, moves it into a governed implementation: a tenant policy draft, a source rollout, or a policy exception.
8. Request Templates
Four templates cover the requests that come up most:
| Template | Use when |
|---|---|
| Expand sanctions coverage | Sanctions/restricted-party screening needs to be strengthened for payments or onboarding |
| Review goods controls | Import/export controls, licensing signals or restricted-goods coverage need checking |
| Strengthen PEP / EDD | Enhanced due diligence needs to be stronger for onboarding or beneficial-owner review |
| Temporary exception | A time-bound relief or manual-review step is needed, not a permanent policy change |
A PEP/EDD request should surface as a review signal, never an automatic sanctions block — and a temporary exception must always carry an end date; there's no such thing as a permanent one.
9. Tracking A Request
Every submitted request lands in the policy request history with one of four statuses:
| Status | Meaning |
|---|---|
| Submitted | Waiting for platform review |
| Approved | Platform agreed to plan the implementation — live policy has not changed yet |
| Applied | Linked to an activated tenant policy version or another governed object |
| Rejected | Kept in the audit history; will not be implemented without a new request |
Opening a request shows its status, implementation status, workflow, the exact requested change, the business/legal reason, who reviewed it and when, and — once implemented — the specific runtime policy version it's linked to. That's the difference between "we submitted a request" and being able to show the full path: review, implementation planning, activation, evidence.
10. Review Packets
A review packet is a read-only snapshot of policy state over a period — built for annual or quarterly compliance review, board reporting, internal audit, a source-change review, or confirming that workflow coverage is complete.
Workflow coverage: 8/8
Tenant sources: 28
Exceptions: 0 active
Evidence window: 50 review items
Recommended actions: no open findings
Working a packet: open the latest one, check workflow coverage, tenant sources, exceptions, the evidence window, and any recommended actions, then save it. Generating or opening a packet never changes the live policy — it's a portable, self-contained evidence bundle ready for an auditor.
11. Policy Exceptions
A policy exception is a temporary departure from the standard policy: manual review instead of an automated action, a temporary source exclusion, an operational hold, or a threshold override within an already-approved process.
Opening an exception's detail shows its status, risk level, scope, effective window, expiry, business/legal reason, and review evidence.
The rule that matters: a requested, rejected, revoked or expired exception is not active relief at runtime. To affect a live process, an exception has to be approved and currently inside its effective window — anything else is exactly the same as no exception at all.
12. Source Notices
A source notice tells the organization that a source, or its coverage, may affect it — for example, a source was added to an obligation group the organization's policy already draws from.
Working a notice: open it, check the source, target group and affected workflows, open the linked evidence packet, and either acknowledge it (if no action is needed) or submit a policy change request (if the coverage should change). Acknowledging or opening a notice is how the organization proves the change was actually reviewed, not silently missed.
13. Runtime Policy Usage — What Actually Ran
This section answers a different question than everything above it: not what's configured, but what actually ran in recent screenings. It shows recent policy snapshots, a breakdown by workflow, whether the organization's own policy or the platform's fallback baseline was used, and links back to the underlying case or item evidence.
Working it: open the runtime usage panel, check whether the platform fallback was used for any workflow, open recent snapshots, and follow through to case evidence when needed. This is what actually lets an organization explain a specific screening decision — not just what's configured today, but which policy version was in force the moment that decision was made.
14. Recommended Rhythm
| Cadence | What to check |
|---|---|
| Daily | Attention queue, new source notices or policy requests, high/critical warnings |
| Weekly | Active workflow coverage, source health, exceptions expiring soon |
| Quarterly | Generate or review a review packet, save evidence, confirm every critical workflow has active coverage |
| Before an audit | Download current-posture evidence, relevant review packets, implemented-request evidence, and exception evidence for anything that was actually used |
15. Related Material
- Entity Screening Algorithms — the scoring engine that runs underneath every entity-screening workflow a policy covers
- Export-Control Coverage — the goods-side control layers a goods policy's source coverage draws from
- AI Assistant User Guide — how the same screening runs from a slash command or an MCP client, and where its evidence ends up