Building an Agentic, Real-Time Fraud Detection System on AWS
Learn how to design a scalable, real-time fraud detection system on AWS that combines streaming transaction data, machine learning, knowledge graphs, and agentic AI to detect suspicious activity, investigate complex fraud patterns, and support faster decisions.
Building an Agentic, Real-Time Fraud Detection System on AWS
Fraud is becoming increasingly sophisticated. Attackers can use stolen identities, compromised accounts, multiple devices, unusual transaction patterns, and coordinated fraud networks to bypass traditional rule-based systems.
A modern fraud detection platform therefore needs to do more than simply flag suspicious transactions. It should process events in real time, understand relationships between entities, investigate suspicious activity, and provide actionable recommendations.
In this article, we explore how to build an agentic, real-time fraud detection architecture on AWS using streaming data, serverless services, graph intelligence, and generative AI.
Why Agentic Fraud Detection?
Traditional fraud detection systems generally follow a fixed pipeline:
Transaction → Rules → Risk Score → Approve/Reject
Although this approach can be effective for known fraud patterns, it can struggle when fraudsters change their behavior.
An agentic system introduces an additional layer of intelligence:
Transaction → Real-Time Analysis → Risk Assessment → AI Investigation → Decision
AI agents can analyze context, retrieve additional information, investigate suspicious relationships, and generate explanations for their decisions.
Instead of treating every suspicious transaction independently, the system can investigate questions such as:
- Is this device associated with other suspicious accounts?
- Has this customer recently changed their location or device?
- Are multiple accounts using the same phone number or address?
- Does the transaction resemble previously identified fraud?
- Is there an unusual transaction velocity?
- Should this transaction be approved, blocked, or escalated for human review?
High-Level Architecture
A possible AWS architecture can be organized into the following stages:
Transaction Sources → Amazon Kinesis → AWS Lambda → Fraud Detection Layer → Amazon Neptune/DynamoDB → Amazon Bedrock Agents → Decision & Alerting
1. Transaction Ingestion
Transaction events can originate from:
- Banking applications
- E-commerce platforms
- Payment gateways
- Mobile applications
- ATM systems
- Digital wallets
Each transaction can contain information such as:
1
2
3
4
5
6
7
8
9
transaction_id
customer_id
amount
timestamp
merchant_id
device_id
ip_address
location
payment_method
These events can be streamed into AWS using Amazon Kinesis, allowing the system to process transaction data continuously rather than waiting for batch processing.
Real-time streaming is particularly valuable for fraud detection because a delayed decision can allow fraudulent activity to continue.
2. Real-Time Processing with AWS Lambda
AWS Lambda can process incoming transaction events without requiring servers to be continuously managed.
A Lambda function can:
- Validate the transaction.
- Normalize the event.
- Enrich it with customer information.
- Calculate basic risk indicators.
- Query historical information.
- Send suspicious events to the investigation workflow.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def calculate_risk(transaction):
risk_score = 0
if transaction["amount"] > 100000:
risk_score += 30
if transaction["new_device"]:
risk_score += 20
if transaction["unusual_location"]:
risk_score += 20
if transaction["high_velocity"]:
risk_score += 30
return risk_score
This initial layer does not need to make the final decision. Instead, it provides useful signals to the downstream AI system.
3. Storing Transaction and Customer Information
Different types of data can be stored using different AWS services.
Amazon DynamoDB can store fast-access operational information such as:
- Customer profiles
- Recent transactions
- Device information
- Risk scores
- Fraud investigation status
Amazon S3 can be used for larger historical datasets, logs, analytical data, and model-related data.
This separation allows the system to keep frequently accessed information available for low-latency operations while retaining historical information for deeper analysis.
4. Building a Fraud Graph with Amazon Neptune
Fraud is often about relationships rather than individual transactions.
Consider the following scenario:
1
2
3
4
5
6
7
8
9
Customer A
|
+---- Device X
|
+---- Phone Number P
|
+---- Customer B
|
+---- Device X
A traditional transaction database may show these as separate records.
A graph database can expose the relationship between them.
Amazon Neptune can be used to represent relationships between:
- Customers
- Accounts
- Transactions
- Devices
- IP addresses
- Email addresses
- Phone numbers
- Merchants
- Locations
This makes it possible to investigate fraud rings, account takeovers, shared devices, and other connected patterns.
For example:
1
Customer → Account → Transaction → Device → Other Customer
A suspicious transaction can therefore be investigated in the context of its surrounding network.
5. Introducing Amazon Bedrock
Once a transaction is identified as potentially suspicious, Amazon Bedrock can provide the generative AI layer.
An AI agent can receive structured information such as:
1
2
3
4
5
6
Transaction Risk Score: 82
Transaction Amount: ₹125,000
New Device: Yes
Location Change: Yes
Device linked to suspicious accounts: 3
Recent transaction velocity: High
The agent can then analyze this information and determine what additional investigation is required.
Instead of simply returning:
High Risk
the system can generate an explanation such as:
The transaction is considered high risk because it originates from a newly observed device, occurs from an unusual location, and the device is associated with multiple previously flagged accounts.
This makes the system more useful to fraud analysts.
6. Creating Specialized AI Agents
The system can be designed as a multi-agent workflow.
Fraud Detection Agent
The first agent analyzes the transaction and identifies suspicious signals.
Its responsibilities can include:
- Transaction analysis
- Behavioral analysis
- Risk assessment
- Anomaly identification
Investigation Agent
When the risk level exceeds a threshold, the investigation agent can retrieve additional information.
It can investigate:
- Customer history
- Device relationships
- Previous fraud cases
- Transaction patterns
- Geographic anomalies
- Connected accounts
Decision Agent
The decision agent combines the available evidence and recommends an action:
1
2
3
LOW RISK → Approve
MEDIUM RISK → Additional Verification
HIGH RISK → Block / Human Review
Reporting Agent
The reporting agent can generate a structured investigation summary for fraud analysts.
A report could contain:
1
2
3
4
5
6
7
Transaction ID
Risk Level
Detected Signals
Related Accounts
Investigation Findings
Recommended Action
Reasoning
This reduces the amount of manual work required from fraud investigation teams.
7. Agent Tools and Controlled Actions
An important principle of agentic architecture is that agents should not have unrestricted access to systems.
Instead, provide specific tools or APIs.
For example:
1
2
3
4
5
6
get_customer_profile()
get_transaction_history()
check_device_relationships()
search_fraud_cases()
calculate_risk_score()
create_investigation_case()
The agent can decide which tool is appropriate based on the investigation.
This approach provides better control, security, and observability.
For production deployments, Amazon Bedrock AgentCore can also provide infrastructure capabilities for deploying and operating agents securely at scale.
8. Real-Time Decision Flow
A complete transaction flow could look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1. Customer initiates transaction
↓
2. Transaction enters Amazon Kinesis
↓
3. AWS Lambda processes the event
↓
4. Basic fraud signals are calculated
↓
5. Customer/device/transaction data is retrieved
↓
6. Fraud graph relationships are checked
↓
7. Risk score is generated
↓
8. High-risk transaction is sent to AI agent
↓
9. Agent investigates additional context
↓
10. Decision is generated
↓
11. Customer/system receives the appropriate response
↓
12. Investigation is stored for future analysis
This architecture allows fraud detection to happen while the transaction is still being processed.
9. Handling False Positives
One of the biggest challenges in fraud detection is false positives.
Blocking every unusual transaction can create a poor customer experience.
For example, a customer traveling to another country may suddenly make a large purchase from a new device.
A rule-based system might classify this as suspicious.
An AI-powered investigation agent can examine additional context before recommending an action.
Instead of immediately blocking the transaction, it could recommend:
1
2
3
4
5
6
7
8
9
10
Risk: Medium
Reason:
New device + unusual location
Additional evidence:
Customer has previously traveled to this region.
Recommendation:
Request additional authentication instead of blocking.
This allows organizations to balance fraud prevention with customer experience.
10. Security and Governance
Fraud detection systems process highly sensitive information, so security should be designed into the architecture from the beginning.
Important practices include:
- Use IAM policies with least-privilege permissions.
- Encrypt sensitive data.
- Protect APIs and endpoints.
- Maintain audit logs.
- Monitor agent activity.
- Restrict agent tools to approved operations.
- Avoid exposing sensitive customer information unnecessarily.
- Establish human approval for high-impact actions.
AI agents should also operate within clearly defined guardrails.
For example, an agent may be allowed to investigate a transaction but not directly close a customer account without human approval.
11. Monitoring with Amazon CloudWatch
A production system needs visibility into both the infrastructure and AI workflow.
Amazon CloudWatch can be used to monitor:
- Lambda execution
- Processing latency
- Error rates
- Transaction throughput
- Investigation failures
- API activity
- System health
Useful metrics include:
1
2
3
4
5
6
7
Transactions/second
Average fraud decision latency
High-risk transactions
False-positive rate
Agent investigation time
Lambda errors
Failed investigations
Monitoring these metrics helps teams identify bottlenecks and continuously improve the system.
12. Example Decision Scenario
Imagine a customer normally makes transactions below ₹10,000 from India using a known device.
Suddenly, the system receives:
1
2
3
4
Amount: ₹180,000
Device: New
Location: Different country
Transaction velocity: High
The real-time pipeline immediately evaluates the event.
The fraud detection layer identifies multiple risk indicators.
The investigation agent then checks the customer's transaction history and the fraud graph.
It discovers that the new device is associated with several previously suspicious accounts.
The system increases the risk level and recommends additional verification or blocking.
The fraud analyst receives an explanation rather than simply receiving a numerical score.
Benefits of the Architecture
This architecture provides several advantages:
Real-Time Detection
Streaming infrastructure enables suspicious transactions to be analyzed as they occur.
Context-Aware Decisions
The system can combine transaction information with customer, device, location, and relationship data.
Automated Investigation
AI agents can perform repetitive investigation tasks before escalating complex cases to analysts.
Better Explainability
Agents can produce human-readable explanations of the evidence behind a risk decision.
Scalability
AWS managed and serverless services can scale with transaction volume without requiring organizations to manually manage every component.
Continuous Improvement
Investigation results can be stored and analyzed to improve future detection strategies.
Conclusion
Fraud detection is evolving from static rule-based systems toward intelligent, context-aware platforms.
By combining real-time streaming, serverless computing, graph relationships, and agentic AI, organizations can build fraud detection systems that not only identify suspicious transactions but also investigate why they are suspicious.
AWS provides the building blocks required for this architecture. Services such as Amazon Kinesis, AWS Lambda, Amazon DynamoDB, Amazon Neptune, Amazon S3, Amazon Bedrock, and Amazon Bedrock AgentCore can work together to create scalable and intelligent fraud detection workflows.
The key idea is simple:
Detect → Investigate → Reason → Decide → Learn
Agentic AI can transform fraud detection from a system that simply generates alerts into a system that actively investigates risk and provides actionable intelligence to humans and applications.
As transaction volumes and fraud techniques continue to evolve, architectures like this can help organizations build faster, smarter, and more adaptable fraud prevention systems on AWS.
Next Steps
To experiment with this architecture:
- Create a sample transaction event generator.
- Stream transaction events into Amazon Kinesis.
- Process events using AWS Lambda.
- Store customer and transaction information in DynamoDB.
- Create relationships between entities using Amazon Neptune.
- Connect an Amazon Bedrock-powered agent to approved investigation tools.
- Implement risk-based decision thresholds.
- Add CloudWatch monitoring and logging.
- Introduce human approval for high-impact actions.
- Test the system using synthetic fraudulent and legitimate transactions.
With these components in place, you can progressively evolve a basic fraud detection pipeline into a complete agentic fraud investigation platform on AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article