AML Agentic Review Engine

The AML agent that moderates sanctions, PEP, and adverse-media screenings runs on a multi-role agentic review engine. Rather than a single AI loop that both reasons and acts, the engine separates the work into distinct phases: three analytic roles assess the case, a deterministic (non-AI) guard decides whether the result may be cleared, and a tool-constrained actuator carries out exactly one outcome. Every decision is recorded against a versioned policy and written to the audit trail.

This page describes how the engine works and how the AML Agent Mode you pick on the flow step controls it.

info

You do not configure the review engine directly. It is driven by the AML Agent Mode on the step that produced the screening (Disabled, Suggest, or Auto-pilot). This page describes what happens behind that setting.

When a review runs

A scheduled dispatcher looks for AML results that are ready for agent review. Candidates are non-deleted screenings that produced at least one hit (PEP, sanctions, or adverse media), have passed a short grace period after the check, are not yet moderated by a human, and do not already carry an agent-review marker for the current screening revision.

The agentic mode is resolved from the flow step that produced the screening (document verification for person checks; KYB for company and UBO checks). Missing or unparseable configuration is treated as Disabled, fail closed, with no deployment-wide default. The mode is captured when the job is enqueued so a mid-flight config change cannot alter what dispatch decided.

Only results whose mode is Suggest or Auto-pilot are enqueued. At most one review runs per result at a time. After a completed evaluation, an agentReview marker is stored on the result so the dispatcher will not re-review an unchanged screening. A re-screen that bumps checkedAt past the marker makes the result eligible again.

How a review runs

When a candidate is claimed, the engine builds a case file from the full AML risk result and runs it through the pipeline below. Each phase has a single responsibility, and the analytic phase cannot mutate any record.

The case file

The case file is the full parsed screening result, including:

• Entity hits with match scores, sanctions and topics, date of birth, countries, and sources
• The submitted identity query that was screened
• Adverse-media articles, when present
• Prior moderation history
• Subject type (person or company)

The three analytic roles

The analytic phase runs three roles in sequence: one raises concerns, one answers them, and a third weighs the two. None of them can change the stored record.

Role	Responsibility	Notes
Prosecutor	Argues each hit is genuine and emits structured risk findings.	LLM with structured (schema-constrained) output.
Defender	Runs false-positive analysis per finding (name-only match, DOB / nationality / jurisdiction mismatch, stale source, homonym) and emits mitigations.	LLM. Skipped when the Prosecutor returns zero findings.
Judge	Weighs findings against mitigations and issues a verdict with a rationale and a residual risk score.	LLM. Its decision is one of Approve (clear), Escalate, or RequestClarification.

Each role uses a provider-agnostic, strict-mode structured-output schema and is driven by a versioned prompt policy for the AML domain.

The deterministic guard

The Judge's verdict does not decide a clear on its own. On an Approve verdict, a deterministic guard, written in Rust and running no LLM, has the final say on whether the screening may be cleared. The guard is a hard floor that vetoes auto-clear when any of the following is true:

• A human verdict is already in force (Escalated or Rejected). The agent may never overturn a human decision.
• The screening produced hits but lacks minimum identity discriminators. For a person: first name, last name, and date of birth. For a company: name plus country or registration number. A name alone is not enough to clear a hit.
• Any hit is a high-confidence sanctions match (exact match, or match score at or above the high-confidence threshold).
• Overall risk level is Critical.

A guard Deny downgrades the enacted decision to Escalate while preserving the Judge's original verdict for the audit trail. An LLM verdict cannot override the guard.

Request clarification becomes escalation

AML subjects have no applicant clarification channel the way a KYB case does (for example, a UBO pulled from a register has no contact path in this pipeline). A RequestClarification verdict is therefore normalized into an escalation that carries the missing-data request for a human reviewer. The agent does not open a clarification loop with the end user.

The actuator

The actuator runs only after the guard, and it can take only one action. The enacted decision maps to a constrained tool allowlist over read and mutate operations (get_aml_result, clear_aml_result, escalate_aml_result). That allowlist is the intersection of the Judge's decision and the Agent Mode gate:

• For an escalate path, clear is not in the allowlist and cannot be called.
• Under Suggest, a clear is recorded as a suggestion and the clearing actuator does not run; an escalation still enacts so high-risk cases reach the human queue without waiting.
• Under Auto-pilot, a clear may also enact when the guard allows it.
• The mutating tools are idempotent (already cleared or already escalated is a no-op), so a retry re-runs the same evaluation instead of producing a second, independent action.
• clear_aml_result re-runs the same deterministic guard server-side as a backstop, so even a misbehaving actuator cannot clear what the guard denies.

When an action tool is allowed, a second, minimal LLM agent is started with the tool allowlist restricted to exactly the plan's tools and is prompted to enact the panel's already-made decision. It fills tool arguments; it does not re-decide the case.

How Agent Mode controls the engine

The AML Agent Mode on the flow step determines how far the actuator is allowed to go:

Mode	Engine behavior
Disabled	The pipeline does not run for that step. Operators moderate every hit manually.
Suggest	The full pipeline runs. Escalations are enacted so cases reach the human queue. Clears are recorded as suggestions only; a human confirms or rejects.
Auto-pilot	The actuator may enact the decision automatically. An Approve (clear) is enacted only when the deterministic guard also passes; anything the guard vetoes is escalated to the human review queue.

Guarantees

The engine enforces the following, independent of the LLM's output:

• The guard is final on clear. Auto-clear is blocked when a human verdict is in force, identity discriminators are insufficient, any hit is high-confidence sanctions, or overall risk is Critical. An LLM verdict cannot override the guard.
• The allowlist is decision ∩ mode. The actuator cannot clear on an escalate path, and under Suggest a clear does not run the clearing actuator at all.
• The guard runs again server-side. clear_aml_result re-runs the strict guard when it is called; the engine-side guard passing is not sufficient on its own.
• Human decisions are sticky. The agent never overturns an in-force human Escalated or Rejected verdict.
• Retries are safe. All mutating actions are idempotent. A retryable actuator failure re-runs the evaluation; terminal failures are recorded and not retried.
• The engine can be switched off. A hot-reloadable kill switch stops dispatch of new candidates so results fall back to the human review queue without a redeploy.
• Missing mode fails closed. An absent or unparseable mode on the flow step is treated as Disabled.
• Re-screens reset agent review. An agentReview marker is scoped to the current screening revision; a new check that advances checkedAt makes the result eligible for review again.

Audit trail

Every completed run writes an AML_AGENT_REVIEWED entry attributed to the agent bot identity. The entry records both the model's verdict and the action the system took:

Field	Meaning
Findings count	How many risk findings the Prosecutor raised.
Judge verdict	Approve, Escalate, or RequestClarification (the latter is enacted as escalate).
Guard outcome	Whether the deterministic guard was not consulted, allowed, or vetoed, and why.
Enacted decision	The action the actuator took (or a recorded suggestion under Suggest for clear).
Policy version	The versioned AML policy the decision was made under.
Actuator status	Success, or a retryable failure that will re-run the evaluation.
Decision narrative	Structured decision context for the audit trail (operational logs omit free-text model rationale to avoid PII leakage).

Related

• AML overview and AML Agent Mode
• Risk scoring, how hits become a score and level
• Monitoring, when screening runs again
• KYB Agentic Review Engine, the parallel multi-role engine for business-information moderation
• Manual review
• Statuses and codes