Purpose
AML Sentinel assists transaction monitoring and screening operations by assembling case context, highlighting relevant risk signals, and producing structured review material. It is designed to improve triage quality and analyst consistency without converting a model score into an unreviewed customer action.
Operating model
- Receive an alert or transaction event from the institution's monitoring stack.
- Resolve permitted customer, counterparty, transaction, and screening context.
- Apply configured policy, rule, and analytical packs.
- Return structured reason codes, evidence references, confidence, and a recommended route.
- Present the case to an analyst where policy requires review.
- Retain the request, output, analyst action, and policy version for audit.
Structured output
| Field | Meaning |
|---|---|
| risk_level | Normalised severity used for routing |
| reason_codes | Machine-readable reasons supporting the route |
| review_memo | Human-readable summary for analyst review |
| evidence_refs | References to the evidence considered |
| policy_version | Policy or configuration version applied |
| confidence | Model or analytical confidence, where available |
The output contract should remain stable enough for case systems to store and query. Narrative text alone is not an adequate integration contract.
Analyst experience
The analyst should be able to see:
- Why the alert exists.
- Which signals materially changed the assessment.
- Which evidence is missing or contradictory.
- Which policy or configuration was applied.
- Which action is recommended and whether it requires approval.
- What changed after any reprocessing or analyst override.
Deployment choices
Sentinel supports customer-controlled, cloud, and hybrid deployment patterns. Raw KYC or AML data can remain inside the customer's environment when an Edge Agent or customer VPC deployment is used. Cloud services should receive only the data explicitly agreed for the workflow.
See Deployment models for the decision criteria and evidence required for each option.
Controls before production
- Map every recommended route to an accountable internal action.
- Define mandatory human review conditions.
- Test false-positive and false-negative samples.
- Confirm evidence retention and access controls.
- Validate model, prompt, rule, and policy version capture.
- Exercise timeout, retry, duplicate, and degraded-service behaviour.
- Agree incident escalation and change approval ownership.
What Sentinel does not do
Sentinel does not replace the MLRO, file a report without an approved workflow, or make a legal determination about a customer. It does not remove the need to maintain the institution's monitoring rules, risk appetite, and documented governance.