Benny Duah
Back to Work
1 min read
Automation & AI
Documentation

Serverless Security & Fraud Automation

Next.js
Tailwind CSS
Python
Scikit-Learn
AWS Lambda
Amazon DynamoDB
AWS SAM
Key Impact250MBML Bundle Size
Cover image for Serverless Security & Fraud Automation
Project Overview

A single automated platform that secures your cloud infrastructure and catches credit card fraud simultaneously.

What it is

BankGuard is a unified cloud security and fraud detection platform. Instead of buying two separate enterprise tools to audit cloud settings and monitor transactions, I built a single automated system that handles both. It constantly inspects cloud infrastructure for vulnerabilities and uses AI to scan thousands of transactions for fraud, displaying everything on a live dashboard.

The BankGuard live security overview dashboard

What it does

  • Audits cloud compliance: Runs automated checks against 12 CIS benchmark rules to ensure root accounts, storage buckets, and firewalls are locked down.
  • Catches suspicious money: Evaluates uploaded transactions using both hardcoded heuristic rules and a machine learning model to flag anomalies.
  • Learns dynamically: Retrains its AI model in-memory the moment you upload a new dataset, instantly adapting to new fraud patterns.
  • Unifies the data: Logs all security and fraud alerts into a single database for easy auditing.

How it works

Think of BankGuard as having two different brains. The first brain is a team of automated security guards (AWS Lambdas) that wake up on a schedule to inspect the bank's digital doors and windows. If they find an unlocked door, like a public storage bucket, they record an alert.

The second brain is a fraud investigator. When a file of transactions is dropped into the cloud, it runs them through a set of human-defined rules (like flagging unusually high amounts). Simultaneously, it runs them through an "Isolation Forest" AI model. The AI visualizes normal transactions as a dense forest and looks for the weird, isolated anomalies standing far apart. Both brains report their findings to a single, high-speed database that feeds a live web dashboard.

The fraud monitoring pipeline actively streaming anomalies

Why it matters

Financial institutions often suffer from tool fatigue and siloed data. By combining infrastructure security and transaction monitoring into one serverless pipeline, BankGuard dramatically reduces overhead and surfaces critical risks in milliseconds.

View the code on GitHub ?

Technical Documentation

Architecture / System design

BankGuard relies on a fully serverless, event-driven architecture built on AWS. For compliance, EventBridge triggers a suite of Python Lambdas on a schedule to evaluate AWS environment configurations against CIS benchmarks. For fraud, an S3 upload triggers a pipeline that routes CSV data through a dual-engine evaluation layer. An API Gateway (following the Lambda-lith pattern) serves a Next.js frontend, reading from a centralized DynamoDB table using a Single-Table Design pattern.

Implementation details

  1. Dynamic Model Retraining: Unlike static models, BankGuard's Isolation Forest model dynamically refits itself in Lambda's temporary disk (/tmp) when a new dataset is uploaded. It hot-reloads in memory to score the batch against the newly learned baseline.
  2. Single-Table Design: Both compliance and fraud findings are stored in the same DynamoDB table using findingType as the Partition Key and a timestamp-prefixed findingId as the Sort Key. This enables zero-compute chronological sorting when querying (ScanIndexForward=False).
  3. Lambda-Lith API: A single Lambda function sits behind API Gateway to handle all routing (summary data, paginated findings, and processing status) to minimize cold starts and infrastructure complexity.
  4. Presigned Uploads: The API generates an S3 Presigned POST ticket, allowing the Next.js frontend to upload up to 1GB transaction files directly to S3, bypassing API Gateway payload limits.
  5. Silence on Success: Compliance workers only write to the database when a failure is detected, saving database write costs and keeping logs clean.

Engineering Challenges & How We Solved Them

  1. Squeezing Scikit-Learn into Lambda's 250MB Limit: The machine learning dependencies exceeded the hard size limit for AWS Lambda. The fix: We pruned non-essential libraries like boto3 (which is natively provided by the runtime) and targeted specific Linux wheels to drastically reduce bloat.
  2. Preventing "False Assurance" in Security Dashboards: If a network failure occurs, most dashboards default to showing "0 Critical Risks," which is dangerous. The fix: We built strict error boundaries that display clear failure banners instead of assuming false safety, forcing operators to retry.
  3. S3 Presigned POST Quirks Across Operating Systems: Windows machines often uploaded CSVs with alternative MIME types (like application/vnd.ms-excel), causing strict S3 upload policies to reject them. The fix: We relaxed the Content-Type enforcement at the S3 edge and moved strict validation to the Lambda processing handler.
  4. Calibrating Isolation Forest Anomaly Scores: Scikit-learn outputs negative raw anomaly scores that don't translate cleanly to a dashboard percentage. The fix: We implemented a custom scaling formula to accurately bound raw scores between 0.0 and 1.0, establishing a precise 0.40 anomaly alert threshold.

Infrastructure / Deployment

The entire architecture is defined as code using the AWS Serverless Application Model (SAM). The template.yaml blueprint handles the provisioning of all Lambdas, S3 buckets, DynamoDB tables, API Gateways, EventBridge rules, and SNS topics.

Next.js
Tailwind CSS
Python
Scikit-Learn
AWS Lambda
Amazon DynamoDB
Amazon S3
Amazon EventBridge
Amazon API Gateway
AWS SAM
Found this technical breakdown useful?Share it with your team or network.