Building an AI-Powered Fraud Detection System on AWS
A production fraud platform can combine real-time event processing, behavioral features, machine learning,
deterministic controls, anomaly detection and agentic AI.
On AWS, such a platform can be built using services including:
- Amazon API Gateway
- Amazon Kinesis Data Streams
- AWS Lambda
- Amazon S3
- Amazon SageMaker AI
- SageMaker Feature Store
- Amazon DynamoDB
- Amazon Aurora
- Amazon Athena
- Amazon Bedrock
- Amazon Bedrock AgentCore
- Bedrock Knowledge Bases
The central architectural principle is simple:
SageMaker predicts. Rules enforce. Bedrock investigates and explains.
The large language model should therefore not become the system directly authorizing or rejecting financial transactions.
Instead, machine learning and deterministic policies remain in the transaction decision path while generative AI assists
fraud analysts with investigation, correlation and explanation.
1. High-Level AWS Fraud Detection Architecture
TRANSACTION SOURCES
|
v
Amazon API Gateway
|
v
Amazon Kinesis Streams
|
+-----------+-----------+
| |
v v
AWS Lambda Amazon S3
| Data Lake
v
SageMaker Feature Store
|
v
SageMaker Model
|
v
Fraud Score
|
+------+------+
| | |
v v v
APPROVE REVIEW HOLD
| |
+---+--+
|
v
Bedrock AgentCore
|
v
AI Fraud Investigator
|
+---------+----------+
| | |
v v v
Customer Transaction Fraud
History History Knowledge
| | |
+---------+----------+
|
v
Investigation Report
|
v
Fraud Analyst
2. Real-Time Transaction Ingestion
Transactions can originate from many systems:
- Credit-card payments
- ACH payments
- Wire transfers
- Mobile banking
- Online banking
- Account-profile changes
- Login events
- Device telemetry
- IP-address and geolocation telemetry
Amazon API Gateway can expose transaction APIs, while Amazon Kinesis Data Streams provides a scalable mechanism
for streaming the events through the fraud platform.
AWS Lambda can perform lightweight enrichment before the transaction is evaluated by the machine-learning model.
3. Feature Engineering: Where Much of the Fraud Intelligence Lives
A fraud model should rarely evaluate a transaction using the transaction amount alone.
The important information often comes from how the transaction differs from the customer’s historical behavior.
Consider a transaction for $7,500 when the customer’s typical transaction is approximately $310.
Current transaction = $7,500 Average transaction = $310 7,500 / 310 = 24.2
The transaction is therefore more than 24 times the customer’s normal transaction size.
That derived value may be substantially more useful to the model than the original transaction amount.
Useful fraud features might include:
amount_deviation transaction_velocity_10m transaction_velocity_24h distance_from_last_transaction new_device new_beneficiary ip_country_changed failed_logins_24h password_changed_recently account_age merchant_fraud_rate historical_average_spend device_risk_score
These features can be stored and managed through Amazon SageMaker Feature Store.
4. The SageMaker Fraud Model
For many financial-fraud problems, an excellent place to begin is a supervised model such as
XGBoost.
Fraud data is usually highly structured and tabular, making boosted decision-tree models particularly appropriate.
More sophisticated neural architectures can be introduced later if the problem and data justify the additional complexity.
A transaction presented to the model might contain features similar to:
fraud_features = {
"amount": 7500,
"account_age_days": 840,
"transactions_last_10_min": 8,
"distance_from_last_location": 1800,
"new_device": 1,
"new_beneficiary": 1,
"merchant_risk_score": 0.74,
"average_transaction": 310
}
The SageMaker model could return:
{
"fraud_probability": 0.932,
"risk": "HIGH"
}
5. Combine Classification with Anomaly Detection
Fraud systems do not necessarily need to rely on a single model.
A supervised fraud classifier can be combined with an anomaly-detection model.
Transaction
|
+-----------+-----------+
| |
v v
Classification Model Anomaly Model
| |
Fraud .91 Anomaly .84
| |
+-----------+-----------+
|
v
Combined Risk
|
v
.93
The first model detects patterns learned from previously identified fraud.
The anomaly model helps identify behavior that is simply unusual, including patterns the supervised model may never
have encountered before.
6. Keep the Real-Time Decision Engine Deterministic
The high-speed transaction path should remain relatively simple and deterministic.
Transaction
|
v
API Gateway
|
v
Lambda
|
v
Retrieve Features
|
v
SageMaker Endpoint
|
v
Fraud Probability
|
v
Decision Engine
A simple policy could look like this:
if fraud_score >= 0.90:
decision = "HOLD"
elif fraud_score >= 0.70:
decision = "MANUAL_REVIEW"
else:
decision = "APPROVE"
A production decision engine could combine several independent signals:
Machine-Learning Score
+
Business Rules
+
Anomaly Score
+
Device Risk
+
Account Risk
|
v
Final Risk Score
7. Add an AI Fraud Investigation Agent
Once a transaction crosses a fraud threshold, the case can be routed to an agentic AI investigation layer built
with Amazon Bedrock and Amazon Bedrock AgentCore.
Suppose the fraud engine reports:
Transaction: TX-88121 Fraud Probability: 93.2% Risk Level: HIGH
The fraud investigation agent can collect evidence from multiple systems.
Fraud Investigation Agent
|
+-- Retrieve transaction details
|
+-- Retrieve transaction history
|
+-- Retrieve customer behavior
|
+-- Retrieve device history
|
+-- Retrieve IP/geolocation history
|
+-- Retrieve model explanation
|
+-- Search similar fraud cases
|
+-- Retrieve relevant fraud policies
The agent can then convert technical signals into a concise investigation report.
FRAUD INVESTIGATION REPORT Risk: HIGH Fraud Probability: 93.2% Primary Indicators 1. Transaction amount is 24x the customer's normal transaction. 2. The device has never previously accessed the account. 3. The transaction originated approximately 1,800 miles from the customer's previous transaction location. 4. A new beneficiary was created 11 minutes before the transfer. 5. Eight transactions were attempted during the previous ten minutes. 6. Similar patterns exist in previously confirmed fraud cases. Recommended Action: HOLD TRANSACTION Require step-up authentication and analyst review.
8. Give the Agent Tools, Not Direct Database Access
One of the most important AI-security controls is preventing the LLM from having unrestricted database access.
The agent should instead receive narrowly scoped tools such as:
get_transaction() get_customer_profile() get_transaction_history() get_device_history() get_ip_history() get_fraud_score() retrieve_similar_cases() retrieve_fraud_policy() create_investigation()
These tools can invoke Lambda functions or controlled services that enforce authorization before accessing
DynamoDB, Aurora, Athena, SageMaker or internal APIs.
The preferred pattern is:
LLM | v Agent Tool | v Authorization | v Retriever / Data Access Layer | +-- RBAC / ACL enforcement | +-- Sensitive-data filtering | +-- Query validation | +-- Audit logging | v Enterprise Data
This is effectively the traditional Data Access Layer pattern applied to enterprise AI.
9. Build a Fraud Knowledge Base with RAG
Fraud investigators require more than transactional data.
They also need institutional knowledge.
A Bedrock Knowledge Base can contain information such as:
- Fraud policies
- Historical fraud investigations
- Known attack patterns
- Investigation playbooks
- AML procedures
- Device-risk guidance
- Regulatory guidance
- Internal security procedures
Fraud Knowledge Base
|
+-------------+-------------+
| | |
v v v
Fraud Policies Past Cases Regulations
| | |
+-------------+-------------+
|
v
Bedrock RAG
|
v
Investigation Agent
Retrieval-Augmented Generation, or RAG, allows the model to reason against enterprise information instead of relying
entirely on the information embedded in the foundation model.
10. Explainable Fraud Detection
A fraud analyst needs more than a score.
Instead of returning only:
Fraud Probability = 93%
the system should capture the factors that contributed to that probability.
| Risk Feature | Contribution |
|---|---|
| New device | +21% |
| New beneficiary | +18% |
| Transaction velocity | +17% |
| Geographic anomaly | +15% |
| Transaction amount anomaly | +13% |
| IP risk | +6% |
The generative AI layer can then translate these model signals into an explanation understandable by a fraud analyst,
customer-service representative or investigator.
11. The Fraud Analyst Interface
The analyst should receive a consolidated view of the case rather than searching across numerous systems.
--------------------------------------------------
FRAUD INVESTIGATION
Transaction: TX-88121
Fraud Score 93%
Risk HIGH
Recommended Action HOLD
--------------------------------------------------
Top Risk Indicators
New Device HIGH
Geo Anomaly HIGH
Transaction Velocity HIGH
New Beneficiary HIGH
Amount Anomaly MEDIUM
--------------------------------------------------
AI Investigation
The transaction differs significantly from the
customer's historical behavior...
[View Evidence]
--------------------------------------------------
APPROVE HOLD CONFIRM FRAUD
--------------------------------------------------
12. Create a Continuous Fraud-Learning Loop
The fraud analyst’s decision should not disappear after the investigation is complete.
It represents extremely useful labeled training data.
AI Prediction
|
v
Analyst Decision
|
v
Confirmed Fraud
or
Legitimate Transaction
|
v
Training Dataset
|
v
Model Evaluation
|
v
SageMaker Retraining
Over time, analyst decisions create a feedback mechanism through which the fraud model can learn from new attack
techniques and changing customer behavior.
13. The Complete AWS Architecture
BANKING / PAYMENT SYSTEMS
|
v
Amazon API Gateway
|
v
Amazon Kinesis Streams
|
+-------------+-------------+
| |
v v
AWS Lambda Amazon S3
| Data Lake
v |
SageMaker Feature Store |
| |
v v
SageMaker Endpoint Glue / Athena
|
v
Fraud Probability
|
v
Decision Engine
|
+-------+--------+
| | |
v v v
APPROVE REVIEW HOLD
| |
+---+----+
|
v
Amazon Bedrock AgentCore
|
v
Fraud Investigator
|
+-----------+------------+
| | |
v v v
Agent Tools Knowledge SageMaker
Base Explanation
|
+----+-----+------+
| | |
v v v
DynamoDB Aurora Athena
|
v
Investigation Report
|
v
Fraud Analyst
|
v
Analyst Decision
|
v
Training Data
|
v
SageMaker Retraining
14. Three Layers of Fraud Intelligence
Perhaps the most useful way to understand the architecture is as three separate intelligence layers.
Layer 1: Deterministic Rules
New Beneficiary + Large Transfer + Recently Changed Password = Require Additional Verification
Rules provide predictable security controls for conditions the institution already understands.
Layer 2: Machine Learning
Customer Behavior
+
Transaction History
+
Device Signals
+
Velocity
+
Geography
|
v
SageMaker
|
v
Fraud Probability = 93%
Machine learning identifies combinations of signals that are too complex to represent through manually maintained rules.
Layer 3: Agentic AI
Fraud Alert
|
v
Bedrock Agent
|
+-- Why is this suspicious?
|
+-- What evidence supports the alert?
|
+-- Have we seen similar cases?
|
+-- What policy applies?
|
+-- What should the analyst investigate?
This layer is not intended to replace the fraud model.
Its role is to investigate, correlate, retrieve, summarize and explain.
15. Why the LLM Should Not Directly Approve Financial Transactions
It may be tempting to place a generative AI model directly in the transaction-decision path.
That would usually be a poor architecture.
Generative models are probabilistic systems.
Financial authorization controls frequently require deterministic behavior, clear thresholds, explainability,
auditability and repeatability.
A safer separation of responsibilities is:
| Technology | Primary Responsibility |
|---|---|
| Business Rules | Enforce known fraud and financial controls |
| Amazon SageMaker | Predict fraud probability and detect anomalies |
| Amazon Bedrock | Reason over evidence and enterprise knowledge |
| Bedrock AgentCore | Orchestrate investigation workflows and tools |
| Fraud Analyst | Make high-risk investigation decisions requiring human judgment |
16. Moving Toward a Multi-Agent Fraud Platform
The architecture can eventually evolve beyond a single fraud agent.
A financial institution could create specialized agents responsible for different categories of fraud.
FRAUD SUPERVISOR AGENT
|
+---------------+---------------+
| | |
v v v
Transaction Account Identity /
Fraud Agent Behavior Takeover Agent
Agent
| | |
+---------------+---------------+
|
v
Correlated Risk View
|
v
Fraud Investigation
For example:
- Transaction Fraud Agent: Investigates unusual payments, transfers and merchant activity.
- Account Behavior Agent: Looks for changes in transaction velocity, beneficiaries and account behavior.
- Identity/Account-Takeover Agent: Investigates device, login, authentication and geolocation anomalies.
- Fraud Supervisor Agent: Correlates findings and produces a unified case for the investigator.
This transforms the architecture from a traditional fraud-scoring system into an
agentic fraud operations platform.
Conclusion
The next generation of fraud detection is unlikely to be built around a single AI model.
Instead, it will combine multiple forms of intelligence.
Rules + Machine Learning + Anomaly Detection + Enterprise Data + RAG + Agentic AI + Human Investigation
Amazon SageMaker can determine whether a transaction resembles fraudulent behavior.
Traditional rules can enforce known financial controls.
Amazon Bedrock and AgentCore can investigate why the transaction was flagged, correlate evidence,
retrieve relevant institutional knowledge and explain the case to an analyst.
The architectural principle remains:
SageMaker predicts. Rules enforce. Bedrock investigates.
That separation creates a system that can take advantage of modern generative and agentic AI without placing
a probabilistic language model directly in control of financial authorization decisions.
Leave a Reply