AI-Powered Multi-Agent System for Global Compliance Screening at Scale
amazon · E-commerce · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Global sanctions and compliance screening
Amazon needed to screen billions of daily transactions across many businesses while preserving regulatory accuracy, reducing manual investigation bottlenecks, and escalating only cases that truly require human judgment.
Constraints:
- sanctions screening must maintain very high recall so potential prohibited transactions are not missed
- manual review cycles can take days and harm customer experience through delayed transactions, account holds, and fulfillment disruptions
- the system operates across many businesses, jurisdictions, languages, scripts, address formats, and entity types
- investigations must follow compliance SOPs and remain auditable
- human investigators should focus on edge cases with insufficient evidence or exceptional circumstances
- agent execution order and tool quality are compliance-critical
Architecture
Amazon Compliance Screening uses a three-tier funnel. Tier 1 applies fuzzy matching and custom SageMaker vector-embedding models to compare input entities against sanctions and government lists with high recall. Tier 2 applies traditional ML to filter low-quality matches and reduce false positives. Tier 3 routes remaining high-quality cases to an AI-powered investigation system built with Strands agents, Bedrock-hosted LLMs, and Bedrock AgentCore Runtime. Specialized agents handle name matching, address matching, entity-type inference, verified customer information, recommendations, and orchestration. Tools connect agents to Amazon data, external systems, and SOP-guided investigation evidence. The recommendation agent produces risk assessment, confidence, false/true-positive classification, and final rationale; humans review rare inconclusive or exceptional cases.
Diagram confidence: explicit (topology described by the source).
flowchart LR screening-engine["screening-engine"] --> intelligent-automation-engine["intelligent-automation-engine"] intelligent-automation-engine --> case-router["case-router"] case-router --> orchestration-agent["orchestration-agent"] orchestration-agent --> name-matching-agent["name-matching-agent"] orchestration-agent --> address-matching-agent["address-matching-agent"] orchestration-agent --> entity-type-agent["entity-type-agent"] orchestration-agent --> vci-agent["vci-agent"] name-matching-agent --> data-aggregator-tool["data-aggregator-tool"] address-matching-agent --> data-aggregator-tool entity-type-agent --> data-aggregator-tool vci-agent --> data-aggregator-tool name-matching-agent --> recommendation-agent["recommendation-agent"] address-matching-agent --> recommendation-agent entity-type-agent --> recommendation-agent vci-agent --> recommendation-agent recommendation-agent --> human-investigation-queue["human-investigation-queue"] agentcore-runtime["agentcore-runtime"] --> orchestration-agent agentcore-runtime --> name-matching-agent agentcore-runtime --> address-matching-agent agentcore-runtime --> entity-type-agent agentcore-runtime --> vci-agent agentcore-runtime --> recommendation-agent
Components
| Component | Role | Interacts with |
|---|---|---|
screening-engine |
Tier 1 fuzzy matching and custom vector embedding layer for high-recall sanctions matching. | intelligent-automation-engine |
intelligent-automation-engine |
Tier 2 traditional ML layer that filters low-quality matches and reduces false positives. | screening-engine, case-router |
case-router |
Creates and routes remaining high-quality matches into the AI investigation system. | intelligent-automation-engine, orchestration-agent |
orchestration-agent |
Coordinates agent workflow, dependencies, execution sequence, parallelism, progress, and exceptions. | case-router, name-matching-agent, address-matching-agent, entity-type-agent, vci-agent, recommendation-agent |
name-matching-agent |
Analyzes name variations, transliterations, aliases, nicknames, maiden names, and multilingual name order. | orchestration-agent, data-aggregator-tool, recommendation-agent |
address-matching-agent |
Resolves address variations, abbreviations, geospatial data, international formats, and obfuscation. | orchestration-agent, data-aggregator-tool, recommendation-agent |
entity-type-agent |
Infers whether an entity is an individual or organization from internal systems and naming patterns. | orchestration-agent, data-aggregator-tool, recommendation-agent |
vci-agent |
Examines verified customer information such as identification documents, registrations, and account verification records. | orchestration-agent, data-aggregator-tool, recommendation-agent |
recommendation-agent |
Synthesizes findings, applies risk weighting, classifies cases, and generates final recommendation rationale. | name-matching-agent, address-matching-agent, entity-type-agent, vci-agent, human-investigation-queue |
data-aggregator-tool |
Bridge from AI agents to Amazon internal systems and evidence sources. | name-matching-agent, address-matching-agent, entity-type-agent, vci-agent |
human-investigation-queue |
Escalation path for insufficient-evidence or exceptional cases outside standard parameters. | recommendation-agent |
agentcore-runtime |
Production runtime for Bedrock/Strands investigation agents. | orchestration-agent, name-matching-agent, address-matching-agent, entity-type-agent, vci-agent, recommendation-agent |
Data flow
A customer or transaction entity first enters the Tier 1 screening engine, where fuzzy matching and custom vector embeddings compare it against sanctions lists. Tier 2 machine-learning models reduce false positives by filtering low-quality matches. If a match remains, a case is created for Tier 3. The orchestration agent manages investigation order and dependencies. Name, address, entity-type, and VCI agents gather and analyze specialized evidence through tools. The recommendation agent aggregates those findings, applies risk-weighted analysis, and emits a case summary, risk assessment, confidence, and final recommendation. Human investigators handle cases where agents cannot reach a conclusive determination.
4 supporting quotes
Why this architecture
Amazon uses a staged architecture because compliance screening has asymmetric risk: Tier 1 favors recall even with false positives, Tier 2 reduces noise, and Tier 3 reserves expensive agentic investigation for high-quality matches. The agent system is specialized because name, address, entity-type, VCI, and recommendation reasoning require different evidence and tools. Orchestration uses graph-based deterministic order where required for auditability, while individual agents retain model-driven reasoning for complex transliteration, address, and case-evidence scenarios. Human review remains only for insufficient evidence or exceptional cases.
4 supporting quotes
Models used: Amazon Bedrock hosted large language models · Amazon Bedrock AgentCore Runtime · Strands agent framework · Amazon SageMaker custom vector embedding models · traditional machine learning models
Scale
- Amazon screens approximately 2 billion transactions daily across more than 160 businesses.“Amazon Compliance Screening, which screens approximately 2 billion transactions daily across 160+ businesses globally to prevent prohibited transactions.”article, stated
- US regulators imposed $2 billion in penalties since 2023, raising compliance stakes.“Sanctions enforcement continues to intensify, with US regulators alone imposing $2 billion in penalties since 2023.”article, stated
- Manual review at this scale would require thousands of human experts and can take days.“Managing compliance at this scale requires thousands of human experts to review flagged transactions and conduct investigations”article, stated“manual review cycles can take days, directly impacting customer experience through delayed transactions, account holds, and order fulfillment disruptions.”article, stated
- The agent system achieved 96% accuracy, 96% precision, and 100% recall for historical decisions.“They achieve 96% overall accuracy with 96% precision and 100% recall rates for historical decisions”article, stated
- Agents automate decision-making for over 60% of case volume.“automate decision-making for over 60% of our volume.”article, stated
Alternatives considered (roads not taken)
Human-intensive compliance investigation
Rejected because: At Amazon's transaction scale it requires thousands of experts and days-long review cycles.
Tier 1 matching alone
Rejected because: High recall at Tier 1 intentionally creates false positives, so Tier 2 and Tier 3 are needed to reduce noise and investigate.
Deploy all agents at once
Rejected because: The team started with name matching, validated it, and progressively added complexity to build confidence.
Rigid rules for every agent decision
Rejected because: Some agents require model-driven reasoning for complex transliteration and naming patterns impossible with rigid rules.
Patterns
multi-agent-orchestration (orchestration)
Amazon coordinates specialized name, address, entity-type, VCI, recommendation, and orchestration agents for compliance investigations.
human-in-the-loop-gate (governance)
Human investigation is reserved for inconclusive or exceptional cases where agents cannot make a standard determination.
confidence-thresholding (governance)
The recommendation agent classifies cases with confidence levels and escalates only where evidence is insufficient or outside standard parameters.
tool-use-orchestration (orchestration)
Agents use Strands tools and custom data tools to retrieve Amazon internal evidence and interact with external systems.
eval-driven-development (evaluation)
Amazon progressively validated the name-matching agent before adding more agents, using historical-decision metrics for accuracy, precision, and recall.
guardrails-io-filtering (governance)
Tiered filtering progressively narrows high-recall fuzzy matches into agent investigations and human edge cases.
Tradeoffs
Use high-recall screening first.
Chose Tier 1 fuzzy matching and embeddings optimized for recall over narrow initial matching that might miss sanctions risks.
Rationale: Compliance risk favors capturing all potential matches even when that creates false positives.
Reserve agentic investigation for high-quality matches.
Chose Tier 2 filtering before Tier 3 agents over running agents on every fuzzy match.
Rationale: Traditional ML reduces noise so compliance teams and agents focus on genuine risks.
Use deterministic graph orchestration where auditability matters.
Chose Strands Graph Multi-Agent Pattern over fully model-decided agent order.
Rationale: The orchestration agent needs deterministic execution order for SOP compliance and audit trails.
Allow reasoning autonomy in name matching.
Chose model-driven approaches for complex linguistic cases over rigid rule-only matching.
Rationale: Transliteration, script variation, nicknames, aliases, and cultural name order need flexible reasoning.
Gotchas (what bit them)
High-recall matching creates false positives.
Root cause: Tier 1 must capture all potential sanctions matches, even at the cost of noisy candidates.
Resolution: Add Tier 2 ML filtering and Tier 3 agent investigation to reduce noise while preserving recall.
Agents are only as good as the investigation procedures they follow.
Root cause: Compliance reasoning depends on well-defined SOPs, evidence requirements, and formal investigation steps.
Resolution: Document and formalize SOPs with compliance teams before implementing agents.
Too much deterministic control can reduce agent effectiveness.
Root cause: Name matching across transliterations, scripts, and cultural conventions requires dynamic reasoning that rigid rules cannot cover.
Resolution: Use deterministic graph order for orchestration/audit paths, but allow model-driven reasoning for specialized agents like name matching.
Poor tool design degrades agent performance.
Root cause: Agents rely on tools to access data and external systems; unclear interfaces or weak error handling make them unreliable.
Resolution: Design tools with clear interfaces, comprehensive error handling, and detailed documentation.
Evaluation
Amazon evaluated agents against historical decisions, reporting accuracy, precision, recall, automation volume, and progressive validation of agents as the system grew.
Metrics: 96% overall accuracy · 96% precision · 100% recall · over 60% autonomous decision volume · historical-decision comparison · progressive agent validation
3 supporting quotes
Outcomes
- the agent system achieved 96% accuracy, 96% precision, and 100% recall for historical decisions
- agents automate over 60% of case volume
- human investigations are reserved for edge cases requiring nuanced judgment
- the system analyzes hundreds of data points simultaneously
Amazon screens approximately 2 billion transactions daily across 160+ businesses globally; the agent system automates over 60% of case volume after the initial screening and filtering tiers.