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.

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:

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.