KYC and AML alert triage
Evidence gathered
- 14 incoming transfers in 48 hours from 3 new jurisdictions
- Expected monthly volume $20k, actual $184k
- No match on sanctions or internal watchlists
Drafted disposition
Escalate for suspicious activity review: volume nine times the customer profile, funds routed through new jurisdictions.
In short
A compliance agent triages KYC and AML alerts against your policies, tracks regulatory changes across the sources you follow, and drafts the writeup an analyst reviews. Nothing is closed or filed without a person's sign-off, and every step, from the data it queried to the policy it cited, is recorded in a trace your auditors can follow. Built for financial crime, compliance and risk teams working under strict recordkeeping requirements.
The problem
Financial crime and compliance teams triage a steady stream of alerts from transaction monitoring and screening systems, most of which turn out to be false positives, and a smaller number of which need real investigation. Analysts spend more time gathering the same supporting data for every alert than they spend actually deciding on it, and regulatory bulletins that should change a policy can sit unread for weeks. A team also has to reconstruct, months later, exactly why an alert was closed the way it was.
What it moves
- Alert triage time
- How long it takes to move an alert from flagged to a drafted assessment.
- Analyst review time
- How long an analyst spends reviewing a drafted assessment before sign-off.
- False-positive share
- How much of the queue turns out not to need escalation.
- Regulatory change lag
- Time from a bulletin publishing to your policy knowledge base reflecting it.
How the agent works
Step 1
Alert arrives
A flagged transaction or screening hit enters from your monitoring system, on a schedule or as an event.
Step 2
Gather supporting data
The agent queries transaction history and case systems with read-only, per-analyst credentials, and retrieves the relevant policy passages from your compliance knowledge base.
Step 3
Draft the assessment
The agent drafts a writeup: what was flagged, what it found, and which policy section applies, citing its sources.
- Human review
Step 4
Analyst sign-off
The draft pauses for an analyst to approve, edit or reject before anything is closed, filed or reported, with reasons captured if it is sent back.
Step 5
File and report
Approved assessments are filed to your case system, and recurring reporting is compiled from the same traced runs.
Controls
Self-host in your own AWS, Azure, GCP, IBM Cloud, OpenShift or Kubernetes environment, or run fully isolated with our engineers when the workload cannot reach the public internet. Every credential is scoped to a project and every run is traced and replayable for your auditors.
- Per-analyst credentials
- Each analyst's queries run under their own database role, so access follows the same grants and row-level rules your database already enforces.
- Runtime scoping the model never sees
- Values such as a desk or entity identifier come from the caller, not the model, so a query cannot be steered by anything in the alert text.
- Sign-off before anything closes
- No alert is closed, filed or reported without a person's approval, and a rejection sends the draft back with feedback attached.
- Builder and operator separation
- The workflow and connections live in a private project; analysts and approvers only ever touch the deployed app, never the underlying workflow.
- Full audit trail
- Every run is traced and replayable, exportable in bulk for periodic compliance archiving.
Systems it connects to
- Transaction monitoring and screening systems, over API
- Case management (Jira, ServiceNow-style ticketing)
- Sanctions and watchlist data feeds, over API
- Regulatory bulletins and policy sources (websites, SharePoint, Confluence)
- Slack and Microsoft Teams for analyst sign-off
- Reporting databases (PostgreSQL, ClickHouse), over SQL
Built with
- Agent BuilderDesign an agent on a visual canvas or in the open-source Python SDK. Both compile to the same engine, so what you build ships either way.
- Guardrails and approvalsDetect PII and prompt injection before a model sees them, enforce content policies, and pause tool steps for a person to approve.
- ObservabilityEvery run is traced and replayable, node by node, with the cost, latency and tokens each step used.
- KnowledgeA knowledge base converts your documents into searchable context: ingestion, chunking, embedding and storage, managed for you or pointed at your own vector store.
Industries
- Financial servicesBack-office automation, customer service by phone and chat, and KYC and AML work, on one governed platform your compliance team can audit.
- InsuranceAnswer policyholders by phone and chat, prepare claims and underwriting files, and keep an adjuster or underwriter approving every decision.
Questions and answers
Does the agent close alerts on its own?
No. It drafts the assessment and gathers supporting data; an analyst approves, edits or rejects before anything is closed or filed.
How does it avoid widening database access?
Each analyst's queries run under their own database credentials at run time, so the database's own grants and row-level rules decide what comes back, not the model.
Can we reconstruct why an alert was closed?
Yes. Every run is traced and replayable, including the data queried, the policy cited, and the analyst's decision, exportable in bulk for compliance archiving.
How does regulatory change monitoring work?
The agent watches the sources you point it at, such as regulator bulletins and internal policy pages, and flags changes for a person to fold into the policy knowledge base.
Can this run fully isolated from the internet?
Yes, our engineers deliver fully isolated or air-gapped deployments for environments that require them.
See this agent on your data.
Talk to our team. We will walk through how it works in your environment, with your systems.