Designing an Ambient AI Agent for Real-Time Anti-Money Laundering (AML) using AWS Strands - Part 1

Introduction
In the evolving landscape of financial crime prevention, traditional approaches to Anti-Money Laundering (AML) are increasingly insufficient against sophisticated criminal networks. Financial institutions need systems that don't just react to suspicious activities but proactively identify and mitigate them in real-time.
Enter Ambient AI - a paradigm where artificial intelligence operates continuously in the background, perceiving events, reasoning about them contextually, and taking appropriate actions without explicit human direction. Unlike conventional automation, ambient AI systems maintain awareness of their environment, understand complex patterns, and make nuanced decisions based on both historical and real-time data.
For AML operations, this shift represents a fundamental transformation from:
Periodic batch processing to continuous monitoring
Rule-based detection to contextual understanding
Manual investigation to autonomous reasoning with human oversight
This article explores how to build a real-time, intelligent AML monitoring system using serverless AWS services, an LLM-powered agent, and modern event-driven design principles.
The Problem with Traditional AML Systems
Traditional AML systems suffer from three critical limitations:
Static Rule Sets
Most legacy AML systems rely on predefined rules to flag suspicious transactions. While these rules are regularly updated, they remain fundamentally reactive, based on known patterns rather than emerging threats. Money launderers continuously adapt their techniques, making static rule sets increasingly ineffective.
Batch Latency
Many AML systems process transactions in batches - daily, weekly, or even monthly. This creates significant time gaps between suspicious activities and their detection, giving criminals ample time to move funds through multiple accounts or jurisdictions before being flagged.
Analyst Fatigue
The high volume of false positives generated by rule-based systems leads to "alert fatigue" among compliance analysts. When 95-98% of alerts are false positives, analysts become desensitized, potentially missing genuine threats amid the noise.
Introducing Ambient AI for AML
An ambient AI system for AML operates on three core principles:
Continuous Perception: The system constantly monitors transaction streams, customer behavior, and external data sources like sanctions lists and news events.
Semantic Reasoning: Rather than applying binary rules, the system uses large language models to reason about transactions in context, considering factors like customer history, transaction patterns, and global risk indicators.
Bounded Autonomy: The system can take certain actions independently (like flagging transactions for review) while escalating more significant decisions (like freezing accounts) to human analysts.
This approach enables financial institutions to detect and respond to suspicious activities in real-time, dramatically reducing the window of opportunity for money launderers while minimizing false positives that burden compliance teams.
Features of Ambient Agents and AWS Tools for Each Layer
Ambient Agents operate across multiple layers, each with specific features and AWS tools that can be leveraged to build a comprehensive AML solution:
1. Perception Layer
Features:
Continuous event monitoring
Multi-source data ingestion
Real-time signal processing
Anomaly detection
AWS Tools:
Amazon Kinesis Data Streams: Captures high-volume transaction data with sub-second latency
Amazon MSK (Managed Streaming for Kafka): Handles complex event streaming from multiple sources
Amazon EventBridge: Routes events based on patterns and schedules
AWS Lambda: Processes events with serverless compute
2. Memory & Context Layer
Features:
Short-term transaction memory
Long-term pattern recognition
Customer profile maintenance
Contextual data enrichment
AWS Tools:
Amazon DynamoDB: Stores customer profiles and recent transaction history with single-digit millisecond access
Amazon OpenSearch Service: Enables complex pattern matching and semantic search
Amazon MemoryDB: Provides ultra-fast in-memory data store for real-time context
Amazon S3: Archives historical transaction data for long-term pattern analysis
AWS Glue: Transforms and enriches data from multiple sources
3. Reasoning Layer
Features:
Semantic understanding of transactions
Multi-factor risk assessment
Contextual pattern matching
Explainable decision-making
AWS Tools:
Amazon Bedrock: Provides foundation models like Claude for semantic reasoning
AWS Step Functions: Orchestrates complex reasoning workflows
Amazon Comprehend: Extracts entities and relationships from unstructured data
4. Action Layer
Features:
Graduated response mechanisms
Human-in-the-loop escalation
Automated documentation
Regulatory reporting
AWS Tools:
AWS Step Functions: Manages decision workflows with human approval steps
Amazon SNS/SQS: Delivers alerts and notifications to analysts
AWS Lambda: Executes actions based on agent decisions
Amazon QuickSight: Provides dashboards for human oversight
5. Learning & Improvement Layer
Features:
Feedback collection
Performance monitoring
Continuous model improvement
Adaptive thresholds
AWS Tools:
Amazon CloudWatch: Monitors system performance and agent decisions
AWS X-Ray: Traces request flows through the system
Amazon SageMaker Model Monitor: Detects model drift and performance degradation
Amazon S3 Analytics: Analyzes historical performance data
Architecture Deep Dive

Let's explore the architecture of an ambient AI agent for real-time AML monitoring:
Event Sources
The architecture begins with real-time transaction data flowing through:
Amazon Kinesis Data Streams: Captures high-volume transaction events from core banking systems, payment gateways, and other financial platforms.
Amazon MQ: Provides message queuing for transactions from legacy systems that may not support direct streaming.
Event Processing
- Amazon EventBridge: Acts as the central nervous system, routing transaction events to the appropriate processing components and triggering the agent on schedule or in response to specific events.
Ambient AI Agent
The heart of the system is the AI agent, built using:
AWS Lambda with Strands SDK: Hosts the agent runtime, managing the execution of reasoning steps and tool calls.
Amazon Bedrock: Provides access to foundation models like Claude or Titan for semantic reasoning about transactions.
AWS Secrets Manager: Securely stores API keys and credentials for external services like sanctions databases.
Data & Alerts
The agent's decisions and supporting evidence are stored in:
Amazon DynamoDB: Maintains a low-latency database of cases, decisions, and risk scores.
Amazon S3: Archives detailed transaction data and reasoning logs for compliance and audit purposes.
Amazon SNS/SQS: Delivers alerts to compliance analysts and queues cases for review based on priority.
Governance & Feedback
The system includes robust governance mechanisms:
Amazon CloudWatch Logs: Captures detailed reasoning steps for auditability and transparency.
Amazon QuickSight: Provides dashboards for analysts to review agent decisions and performance metrics.
AWS Step Functions: Orchestrates complex escalation workflows for high-risk cases.
AWS IAM: Enforces strict security controls and least-privilege access.
Agentic Flow in AML Processing
The following flow chart illustrates how an Ambient Agent processes transactions for AML monitoring:

This flow demonstrates how the Ambient Agent:
Receives and categorizes transaction events
Retrieves relevant context from memory systems
Performs risk assessment using pattern matching and semantic analysis
Makes decisions based on risk level
Integrates human oversight for medium and high-risk cases
Incorporates feedback to continuously improve
How the Agent Thinks (Prompting and Tooling)
The ambient AI agent combines the reasoning capabilities of large language models with specialized tools for AML tasks. Here's a simplified example of the system prompt that guides the agent's reasoning:
You are an AML compliance agent responsible for analyzing financial transactions in real-time.
Your goal is to identify potentially suspicious activities while minimizing false positives.
For each transaction, you will:
1. Analyze the transaction details (amount, parties, timing, etc.)
2. Check relevant context (customer history, risk profile, etc.)
3. Verify against external data sources (sanctions lists, PEP databases)
4. Determine if the transaction exhibits known money laundering patterns
5. Make a decision: IGNORE, FLAG, or HOLD
6. Provide clear reasoning for your decision
You have access to the following tools:
- check_sanctions(entity_name): Check if an entity appears on sanctions lists
- verify_kyc(customer_id): Retrieve KYC information for a customer
- get_transaction_history(account_id, days): Get recent transaction patterns
- evaluate_structuring(account_id): Check for potential structuring patterns
- check_jurisdiction_risk(country_code): Get risk rating for a jurisdiction
Always explain your reasoning process and cite specific factors that influenced your decision.
The tools referenced in the prompt are implemented as Python functions that the agent can call during its reasoning process. Here's an example of how these tools might be implemented using the Strands SDK:
from strands import Agent
import boto3
import json
# Initialize AWS clients
dynamodb = boto3.resource('dynamodb')
s3_client = boto3.client('s3')
lambda_client = boto3.client('lambda')
# Define tools
@agent.tool
def check_sanctions(entity_name: str) -> dict:
"""Check if an entity appears on sanctions lists."""
# Call sanctions API or database
response = lambda_client.invoke(
FunctionName='sanctions-check-service',
Payload=json.dumps({'entity_name': entity_name})
)
return json.loads(response['Payload'].read())
@agent.tool
def verify_kyc(customer_id: str) -> dict:
"""Retrieve KYC information for a customer."""
table = dynamodb.Table('customer-kyc-data')
response = table.get_item(Key={'customer_id': customer_id})
return response.get('Item', {})
@agent.tool
def get_transaction_history(account_id: str, days: int = 30) -> list:
"""Get recent transaction patterns."""
# Query transaction history from database
table = dynamodb.Table('transaction-history')
response = table.query(
KeyConditionExpression='account_id = :aid',
ExpressionAttributeValues={':aid': account_id},
Limit=100 # Reasonable limit for context
)
return response.get('Items', [])
# Initialize the agent with Bedrock
agent = Agent(
model="anthropic.claude-3-sonnet-20240229-v1:0",
tools=[check_sanctions, verify_kyc, get_transaction_history]
)
Decision Paths
The agent follows different decision paths based on its analysis:
When to Ignore
Transactions are ignored when:
They match normal patterns for the customer
No risk indicators are present
The transaction amount is below thresholds for the customer's risk profile
The transaction has clear business purpose and documentation
Example reasoning:
Decision: IGNORE
Reasoning: This $500 payment to an established vendor is consistent with the customer's 2-year history of similar monthly payments. The vendor is not on any sanctions list, and the amount is within normal range for this business account.
When to Flag
Transactions are flagged for analyst review when:
They deviate from normal patterns but don't require immediate action
They involve moderate-risk jurisdictions
They match some but not all indicators of suspicious activity
Additional context is needed for proper evaluation
Example reasoning:
Decision: FLAG
Reasoning: This $9,000 wire transfer is just below the $10,000 reporting threshold. The customer has made three similar transfers in the past week, which could indicate structuring. However, the recipient is a long-standing business partner with no negative history. Recommend analyst review to determine if there's a legitimate business reason for these transfers.
When to Escalate or Hold
Transactions are escalated or held when:
They involve sanctioned entities or high-risk jurisdictions
They match known money laundering patterns with high confidence
They represent significant deviations from expected behavior
They exceed risk thresholds for the customer's profile
Example reasoning:
Decision: HOLD
Reasoning: This $50,000 transfer to an entity in a high-risk jurisdiction shows multiple red flags: 1) The sending account was opened just 15 days ago, 2) The recipient entity shares an address with a recently sanctioned organization, 3) The transaction description is vague ("consulting services"), and 4) This is the first international wire from this customer. Recommend immediate hold pending enhanced due diligence.
Comparing AML Approaches: Manual vs Multi-Agent vs Ambient
| Aspect | Manual Process | Multi-Agent System | Ambient Agent System |
| Detection Time | Days to weeks | Hours to days | Real-time to minutes |
| Coverage | Sample-based | Comprehensive but scheduled | Continuous and comprehensive |
| Context Awareness | Limited to analyst knowledge | Moderate, based on programmed rules | High, with semantic understanding |
| False Positive Rate | 95-98% | 70-80% | 40-60% |
| Investigation Time | Hours per case | 30-60 minutes per case | 5-15 minutes per case |
| Adaptability | Slow, requires training | Moderate, requires reprogramming | High, learns from feedback |
| Scalability | Linear with analyst headcount | Good, but with batch limitations | Excellent, scales with transaction volume |
| Regulatory Reporting | Manual compilation | Semi-automated | Fully automated with human verification |
| Cost Structure | High fixed costs (staff) | Mixed fixed/variable costs | Primarily variable costs |
| Emerging Threat Detection | Poor, relies on published typologies | Moderate, based on programmed patterns | Strong, can identify novel patterns |
Manual Process Workflow:
Batch transaction monitoring (daily/weekly)
Rule-based alert generation
Alert queue assignment to analysts
Manual investigation of each alert
Documentation of findings
Decision making (clear/escalate)
Regulatory filing if required
Periodic rule updates (quarterly/annually)
Multi-Agent System Workflow:
Scheduled data collection from multiple sources
Distributed processing across specialized agents
KYC verification agent
Transaction pattern agent
Sanctions screening agent
Risk scoring agent
Aggregation of agent findings
Rule-based decision making
Analyst review of flagged cases
Automated documentation
Regulatory filing preparation
Periodic agent retraining
Ambient Agent System Workflow:
Continuous event monitoring across all channels
Real-time contextual analysis of each transaction
Dynamic risk assessment using semantic reasoning
Autonomous decisions for low/medium risk cases
Immediate escalation of high-risk cases
Continuous learning from analyst feedback
Automated documentation and audit trail
Streamlined regulatory reporting
Adaptive threshold adjustment
The Ambient Agent approach represents a paradigm shift from reactive to proactive AML monitoring, dramatically reducing the time between suspicious activity and detection while simultaneously decreasing the burden on human analysts through more accurate risk assessment and contextual understanding.
In Part 2 of this series, we'll explore the implementation details, including scaling considerations, guardrails, feedback mechanisms, and the benefits of this approach.
Feel free to reachout to info@dataopslabs.com for full code and working solution github repository.






