Near Real-Time Fraud Detection with Graph Neural Networks on AWS

This case study documents an AWS-native fraud detection platform for fintech companies processing payments at scale. The architecture uses Graph Neural Networks (GNNs) — a class of machine learning model that reasons over relationship graphs rather than isolated data points — to detect fraud rings, synthetic identity clusters, and account takeover chains that are invisible to per-transaction models.

The system operates on two parallel paths: a real-time inference path that scores each transaction in under a second using a live Amazon Neptune graph and a SageMaker-hosted GNN endpoint, and an offline training pipeline that continuously retrains the GNN model against evolving fraud patterns using Step Functions, Glue, Fargate, and SageMaker Training Jobs. The result is a fraud detection capability that both responds to known patterns in real time and adapts to new fraud tactics through automated model retraining.

Payment fintechs — BNPL providers, neobanks, digital wallets, and crypto exchanges — face fraud rates 3–5x higher than traditional banks. They onboard customers with lower friction, serve younger demographics with limited credit history, and operate novel financial products that attract novel attack vectors. The three structural problems with legacy fraud detection at fintech scale are:

The architecture has two cooperating paths: a real-time inference path that scores live transactions, and an offline training pipeline that continuously produces updated GNN models. Both paths share Amazon Neptune as the graph store — the inference path queries it for neighbourhood context; the training pipeline reads it to construct the training graph.

Path 1 — Real-Time Inference

• CloudFront provides TLS termination and DDoS protection at the network edge, reducing the attack surface of the fraud scoring API before requests reach the origin
• API Gateway enforces rate limiting, OAuth 2.0 authentication, and request throttling — preventing volumetric abuse of the scoring endpoint by compromised clients
• Lambda (with provisioned concurrency to eliminate cold-start latency) receives the transaction payload, enriches it with cached account features, and orchestrates the Neptune graph query and SageMaker inference calls
• Amazon Neptune Serverless stores the heterogeneous transaction graph — nodes for users, cards, merchants, devices, and IP addresses; edges for transaction relationships, shared attributes, and login events. Lambda queries the graph to retrieve the k-hop neighbourhood of the transaction participants
• Amazon SageMaker Endpoint hosts the trained GNN model. Neptune neighbourhood data is passed as input features; the GNN performs message-passing aggregation across the graph and returns a fraud probability score with confidence interval
• Amazon DocumentDB stores the prediction result, the evidence graph snapshot, and the model version used — creating a complete audit trail for regulatory review and model governance
• Amazon SQS receives downstream alerts for high-confidence fraud scores, triggering case management workflows, customer notifications, and card blocking actions asynchronously without adding latency to the scoring response

Path 2 — GNN Training Pipeline

• S3 stores the raw transaction event stream (sourced from the payment processing platform via Kinesis Firehose or direct API ingestion), partitioned by date and account for efficient Glue access
• AWS Step Functions orchestrates the training pipeline as a DAG — triggering ETL, graph construction, model training, evaluation, and conditional deployment steps in the correct order with retry logic and failure handling
• AWS Glue performs feature engineering on the raw transaction records — computing aggregate features (transaction velocity, amount percentiles, merchant category ratios), joining with account master data, and outputting a cleansed feature dataset
• AWS Fargate (containerised workloads) executes the graph construction step — converting tabular transaction rows into the node-edge format required by Amazon Neptune and the Deep Graph Library (DGL), then loading the updated graph into Neptune
• Amazon SageMaker Training Job trains the GNN using the Deep Graph Library against the updated Neptune graph. The model learns to propagate fraud signals across the graph topology — a node adjacent to known-fraudulent nodes receives a higher fraud prior during inference
• Trained model artifacts are stored in S3 with version metadata, then registered in SageMaker Model Registry. A blue/green deployment updates the SageMaker Endpoint — the new model version receives a canary traffic split before full promotion

The key innovation in this architecture is the heterogeneous transaction graph constructed in Amazon Neptune. Unlike homogeneous graphs (where all nodes are the same type), a heterogeneous graph models different entity types and relationship types — capturing the multi-dimensional structure of payment fraud.

Graph Schema

How GNN Message Passing Detects Fraud Rings

During inference, the GNN performs multiple rounds of message passing across the neighbourhood of the transaction being scored. In each round, each node aggregates feature information from its neighbours, then updates its own representation. After several rounds, a node's representation encodes information from its extended neighbourhood — not just its immediate connections.

• Round 1: the transaction node aggregates features from the merchant and card nodes it is directly connected to
• Round 2: the card node aggregates features from all other users who have recently used the same card — detecting card sharing patterns common in synthetic identity fraud
• Round 3: the merchant node aggregates from all recent transactions — detecting merchants with an abnormally high proportion of first-time cards or unusual geographic dispersion
• Output: the final transaction node representation is passed to a classification head that outputs a fraud probability score. This score reflects not just the transaction itself but the fraud signals accumulated across its graph neighbourhood

The architecture is designed to meet the audit and explainability requirements that financial regulators impose on automated decision systems. In the UK and EU, automated decisions that significantly affect customers (including fraud blocks) must be explainable and subject to human review.

• Audit trail completeness: every fraud score stored in DocumentDB includes the transaction ID, the model version used, the graph neighbourhood snapshot at inference time, the top contributing graph features, and the timestamp — providing a complete forensic record for dispute resolution
• Human review queue: transactions scored above a configurable confidence threshold (e.g. 0.85 fraud probability) are sent via SQS to a case management system for human review before card blocking, meeting the right-to-human-review requirements under GDPR Article 22 and UK GDPR
• CloudTrail: all API calls to Neptune, SageMaker, and DocumentDB are logged via CloudTrail — providing a complete record of data access for information security audits and regulatory examinations
• Model governance: SageMaker Model Registry maintains a versioned registry of all trained models with training metadata, evaluation metrics, and approval status — enabling regulators to inspect which model version was in production on any given date
• PSD2 SCA alignment: the real-time scoring capability supports PSD2 Strong Customer Authentication exemption logic — high-confidence low-risk transactions can be exempted from SCA friction based on real-time fraud risk assessment, improving conversion rates for compliant fintechs

The architecture uses serverless and managed services throughout, meaning costs scale with transaction volume rather than reserved capacity. The following is indicative for a mid-scale fintech processing 1 million transactions per day.