Reviews and decisions

A review is the unit of decision. Everything before it gathers evidence; the review is where a human commits to an outcome.

Lifecycle

open ──> in_progress ──> completed
              │
              └────────> escalated ──> completed

cancelled is also available. Opening a review sets it in progress and stamps started_at.

Two purposes:

Purpose	For
initial	A new merchant. Requires the intake checks to have completed before it can be started.
periodic	A merchant already onboarded. Can be created regardless of intake posture.

The cockpit

The review page leads with What's blocking a decision — the outstanding items, each with the action that resolves it. Below that: verification coverage and findings, the evidence attached to this review, assignment, notes and workflow history.

Decision buttons sit in the panel on the right, with Approve disabled while anything blocks it and the count stated beside it.

What blocks approval

Approval is refused — not merely discouraged — while any of these hold:

1. A standing bar on a strong identifier. Somebody already decided this merchant, or a person behind it, should not be accepted. Only a national ID, registration number or IBAN blocks; a name match warns.
2. An unadjudicated blocking screening match. Every blocking match must be adjudicated first.
3. A configured intake check that has not completed. Whatever the country configuration requires.
4. A failed provider fetch run. A failed call is not evidence.

These are enforced server-side, in the model. They were once enforced only in the view, which meant a direct POST could approve a review the product said was blocked.

Periodic reviews are not a bypass

A periodic review can be created without the intake checks, but approving it still runs the same blockers. The looser creation rule exists for monitoring an onboarded merchant, not for skipping verification.

Who may decide

Normally, anyone with the relevant permission — entity.review.approve, .reject or .escalate.

Once a review is escalated to AML, only someone who can adjudicate screening matches may decide it. Escalation means a specialist was asked; letting the original analyst then approve it themselves would make the escalation decorative. Attempting it is refused with an explicit error.

Recording a decision

Approve — outcome approved. If a PEP match is present, the approval is stamped with that fact and the names, so the record shows the decision was made knowing.

Reject — needs a reason code, and a note is recommended. Rejecting does not bar the merchant from returning; that is a separate, deliberate act — see Standing bars.

Escalate — hands the review to AML with a note.

Every decision writes an audit event and fires an outbound webhook to subscribed endpoints.

Assignment

entity.review.assign lets you set the assignee. Assignment changes are audited and notify the new assignee — except when you assign a review to yourself, which does not notify you.

Notes

entity.review.notes.create. Notes are append-only and appear in workflow history with their author and timestamp. They are the place to record judgement that the structured fields cannot hold.

The queue

Queue shows the reviews awaiting attention across the account, so work can be picked up without going entity by entity.