Verification & Evidence Control Layer
This page defines the shared S010 review and control layer used by TCAML operation workflows. It explains how a workflow moves from intake to a analyst-reviewable case file with declared data, source checks, evidence, discrepancies, risk triggers, stagegate status and audit trail.
Why this layer exists#
TCAML separates three things:
Operation workflow = what AML task is being performed.
Source workflow = where and how the agent checks.
Control layer = how the review is documented, challenged and handed over.
The control layer makes every operation evidence-first. The agent must preserve search inputs, identifiers, source limitations, result status, evidence references, gate state and escalation state instead of producing a loose summary.
Shared operation lifecycle#
Every practical operation can follow the same control sequence:
case setup
→ declared-data inventory
→ subject classification
→ verification plan
→ source checks
→ evidence capture
→ discrepancy handling
→ risk trigger mapping
→ case file assembly
→ analyst handover
→ audit trail preservation
This sequence can be used for a customer, company, UBO, director, supplier, employee, bank counterparty, wallet, website/domain, transaction, vessel or other relevant object.
Stagegate-supervised execution#
S010 is designed to run as a stagegate-supervised workflow. The purpose is to stop an AML agent from rushing through intake, source checks, evidence capture, discrepancy handling and handover as a single uncontrolled narrative answer.
In strict mode, the runner pauses at each gate and waits for the exact confirmation keyword entered by a AML analyst. Generic replies such as ok, yes, continue or go ahead do not advance a gate.
In draft mode, an agent may prepare an unconfirmed working draft, but the output must remain marked as draft or unconfirmed and must not be released as a final handover.
| Gate area | Control purpose |
|---|---|
| Case setup | Confirm case ID, subject type and review purpose. |
| Declared-data inventory | Confirm what was declared before treating it as verified. |
| Subject classification | Confirm who or what must be checked. |
| Verification plan | Confirm approved sources and fallback logic. |
| Source checks | Confirm that checks are complete and auditable. |
| Evidence capture | Confirm that material results have evidence references. |
| Discrepancy handling | Confirm that mismatches are classified. |
| Risk mapping | Confirm that triggers are mapped and not ignored. |
| Case assembly | Confirm that the file is review-ready and no final decision is pre-filled. |
| Routing / handover | Confirm release to review or escalation to the responsible reviewer. |
S010 output contract#
The TCAML Framework repository includes a formal S010 output schema, gate keyword registry, abstract output example and gate behaviour tests. The wiki explains the AML control meaning; the repository provides machine-readable contracts and executable demo paths.
| Artifact | Purpose |
|---|---|
STAGEGATES.md |
Defines gate states, exact keywords, reopening logic and escalation override behaviour. |
tcaml-s010-output.schema.json |
Defines the structured verification output expected from S010-controlled workflows. |
| Gate keyword registry | Keeps gate keywords machine-readable and consistent. |
| Local runner | Demonstrates deterministic stagegate execution and case-folder generation. |
| LLM bridge | Validates model-generated content drafts without allowing the model to confirm gates. |
The schema preserves the reviewer decision boundary by keeping the agent-produced decision status as Pending analyst review. The agent may prepare evidence, summaries and escalation materials, but the final decision remains with the responsible compliance team, MLRO or authorized reviewer.
Control pillars#
| Pillar | Analyst meaning | Required output |
|---|---|---|
| Case setup | Create the review context before checking sources. | Case ID, subject type, relationship type, review purpose, policy context. |
| Declared-data inventory | List the facts provided by forms, documents, emails, chats or previous case files. | Declared facts table and missing information list. |
| Subject classification | Decide who or what is being checked. | Individual, legal entity, UBO, director, supplier, employee, FI, wallet, domain or connected party. |
| Verification plan | Choose approved sources and checks for the subject and risk context. | Source plan, source order, source limitations. |
| Source checks | Run sanctions, PEP, adverse media, registry, ownership and other approved checks. | Source check records with query, identifiers, result status and confidence note. |
| Evidence capture | Save proof during the check, not after the narrative is drafted. | Evidence index, screenshots, PDFs, URLs, timestamps, file references. |
| Discrepancy handling | Separate mismatches from risk conclusions. | Discrepancy register with status and next action. |
| Risk factor mapping | Map findings to risk factors, EDD triggers and escalation rules. | Risk trigger summary and manual review flags. |
| Analyst handover | Prepare a review-ready output without final decision-making. | Review summary, escalation memo or open-questions memo. |
| Audit trail | Preserve who/what/when/why for the case. | Action log, gate event log and reproducible evidence pack. |
Required case artifacts#
A practical AML/KYC/KYB operation should produce or update:
- case metadata;
- subject and connected-party list;
- declared-data inventory;
- verification plan;
- source check records;
- evidence index;
- discrepancy register;
- missing information list;
- risk factor and trigger summary;
- review summary or MLRO escalation memo;
- audit trail;
- gate status and gate event log where stagegate control is used.
Human-supervised boundary#
The agent may collect, compare, summarize, document, draft and route. The agent must not approve or reject a subject, make final legal/regulatory/sanctions conclusions, suppress uncertainty, invent missing facts, bypass manual review triggers or release a gated case without the required confirmation.
Relation to TCAML Framework#
In the TCAML Framework, this page corresponds to TCAML-S010 — Verification & Evidence Control. Operation workflows should load this control logic before running client onboarding, counterparty screening, supplier review, employee screening, periodic review or MLRO escalation support.
See Also#
References#
- TCAML Framework public reference pages and local implementation boundary.
- Source Register for authoritative source hierarchy.
- Editorial & Source Policy for AI/RAG use and reviewer-accountability rules.