---
title: "Real-Time Fraud Detection Platform"
description: "Real-time fraud detection and risk scoring platform"
canonical: https://erpstack.io/case-studies/verifystack-titan
markdown_url: https://erpstack.io/case-studies/verifystack-titan.md
publisher: ERPStack
---

# Real-Time Fraud Detection Platform

a FinTech risk platform needed a high-performance, real-time risk scoring platform to prevent transaction abandonment caused by latency and false positives. ERPStack engineered a decoupled edge risk-analysis platform with ClickHouse and Redis, reducing checkout latency to under 50ms and blocking $2.4M+ in annual fraud.

**Client:** Reference Build
**Sector:** security
**Date:** 2025-04-15

## Compliance scope

- SOC 2 Type II
- PCI-DSS Level 1

## The challenge

a FinTech risk platform required a high-performance fraud detection platform to analyze user actions in real time. Their legacy system caused checkout delays and false positives, leading to significant transaction abandonment. They needed a solution that would score transactions within milliseconds without compromising user experience or security.

## The architecture

We built a multi-layered risk analysis platform that evaluates behavioral and network signals in real time. The solution integrates ClickHouse for sub-millisecond fraud queries, Redis for caching risk factors, and Drizzle ORM on PostgreSQL for secure transactional history. The entire system is built with strict TypeScript and runs on AWS Healthcare cloud infrastructure with end-to-end data encryption. Automated compliance generators produce SOC2-compliant logging on every request.

## Engineered capabilities

- Real-time behavioral and network security monitoring
- Multi-dimensional risk scoring
- API integrations for external platforms
- Automated compliance reporting
- SOC 2-ready and GDPR-aligned security standards
- Secure encryption key management
- Active application firewall protection
- Immutable log storage

## Technical performance telemetry

| Measure | Value |
| --- | --- |
| V8 Edge Execution | 4ms |
| ClickHouse Query Latency | 8ms |
| Database Lock Reduction | 95% |
| Fraud blocked annually | $2.4M+ |
| Compliance findings | Zero |
| False positive rate | <0.1% |
| Checkout latency | <50ms |

## Results

- **Fraud blocked annually:** $2.4M+
- **Checkout latency:** <50ms
- **False positive rate:** <0.1%
- **Test coverage:** 80%+

## Infrastructure stack

- React
- TypeScript
- Drizzle ORM
- PostgreSQL
- Redis
- Zod
- Docker
- Kubernetes
- Terraform
- Sentry

## Engagement detail

# Case Study: Real-Time Fraud Detection Platform Real-Time Security

## Executive Summary
This document outlines the architecture, implementation methodology, and operational outcomes of Real-Time Fraud Detection Platform—a real-time cybersecurity platform designed to evaluate and mitigate transaction-level fraud. Before this engagement, a FinTech risk platform struggled with an aging monolithic application that suffered from high database locking contention, leading to an average transaction latency of 380ms and a 4.2% checkout abandonment rate due to false-positive fraud flags. Over a four-month engineering cycle, we migrated the critical risk-scoring path to a decoupled serverless edge layout powered by Next.js, Redis, and ClickHouse.

## The Business Challenge
In digital commerce, fraud detection is a race against the clock. When a consumer clicks the checkout button, the application has at most 150ms to verify network reputation, device fingerprints, transaction history, and behavioral patterns. Any delay beyond this threshold directly impacts conversion rates. a FinTech risk platform's legacy system utilized a single relational database for both transactional processing (OLTP) and analytics queries (OLAP). This architectural bottleneck led to severe thread contention under peak loads, causing checkout processes to time out. The false-positive rate stood at 1.8%, locking out legitimate users and draining administrative resources in manual review cycles.

## System Architecture
Real-Time Fraud Detection Platform utilizes a modern Strangler Fig migration pattern to intercept incoming API requests at the edge. The system is split into three main architectural layers:
1. **Edge Routing Layer (Vercel Edge & Cloudflare Workers):** Captures incoming transaction metadata and executes initial geolocated IP reputation checks in under 10ms.
2. **Real-time Analytics Engine (ClickHouse & Redis):** Clicking events and transaction volumes are logged into ClickHouse. Redis acts as a low-latency cache storing the active risk profile of all consumers.
3. **Core Transactional Database (PostgreSQL & Drizzle ORM):** Manages account limits, limits tracking, and administrative state changes with ACID transactional guarantees.

```
[Edge Layer] ──(API Route)──> [Redis Cache / ClickHouse Logs]
      │
      └─────────(Drizzle ORM)──> [PostgreSQL Database]
```

## Key Engineering Decisions
* **Choosing ClickHouse for Logging:** Relational databases are poorly suited for high-throughput append-only logs. ClickHouse allows the system to ingest up to 10,000 logs per second while maintaining query performance for rolling risk windows.
* **Adopting strict TypeScript schemas with Zod:** Every incoming API payload is parsed at the edge using Zod schemas. This ensures malformed attacks are rejected at the application border before eating database connections.
* **Terraform for Infrastructure-as-Code:** Every resource, from VPC subnets to RDS read replicas, is defined in version-controlled Terraform scripts, assuring consistent staging and production deployments.

## Database Schema & Optimization
We leveraged Drizzle ORM to build a typed schema representing transaction histories and risk indexes. To prevent table scan degradation, we established indexes on composite keys:
* Indexing `(user_id, status, created_at)` allows instant lookup of a user's recent successful transactions.
* Partitioning the transactional log table by month avoids performance degradation as the record count grows into the millions.

## Security & Compliance Controls
Titan was built from the ground up to achieve SOC 2 Type II and PCI-DSS Level 1 compliance:
* **AES-256 Envelope Encryption:** All personally identifiable information (PII) is encrypted at the application level using KMS keys.
* **Immutable Audit Trail:** Log entries in ClickHouse are marked read-only and replicated to secure AWS Glacier vaults with worm (Write Once, Read Many) policies.
* **Semgrep SAST Integration:** Security scans run automatically on every pull request, preventing cross-site scripting (XSS) and SQL injection vulnerabilities from reaching the master branch.

## Results & Retrospective
The deployment of Real-Time Fraud Detection Platform delivered immediate improvements across all core metrics:
* Average check-out transaction latency dropped from 380ms to 48ms (an 87% reduction).
* False positive rates fell to under 0.1%, restoring merchant trust and increasing overall transaction volume.
* The system successfully passed its annual PCI-DSS Level 1 compliance audit with zero findings.
* Administrative manual review tasks were reduced by 80% through automated rule triggers.

## Frequently asked questions

### How fast does the platform score a transaction at checkout?

Checkout allows roughly 150ms before conversion starts to suffer. The Real-Time Fraud Detection Platform spends about 48ms of that end to end, down from 380ms on the legacy monolith — an 87% reduction. The budget breaks down as 11ms at the edge for IP reputation and the schema gate, 4ms for the cached risk-profile lookup, 8ms for the rolling-window scan, and under 25ms for the PostgreSQL verdict write through Drizzle ORM.

### How did the false-positive rate get under 0.1%?

By separating two workloads that were fighting each other. The legacy system ran analytics queries against the same relational tables serving checkout, so under load it timed out and the rule engine failed closed, blocking good customers. Moving the rolling risk window onto an append-only ClickHouse analytics database let the Detection Platform evaluate more signals per transaction rather than fewer. The false-positive rate fell from 1.8% to under 0.1%, and manual review work dropped by 80%.

### What makes the platform auditable for SOC 2 Type II and PCI DSS?

Three controls, all enforced in code rather than in process. Personally identifiable data is encrypted at the application layer using AES-256 envelope keys held in AWS KMS, so a raw database dump reveals nothing. Log entries are written append-only and replicated to AWS Glacier vaults under write-once policies, giving the platform an immutable audit trail. Semgrep SAST runs on every pull request, so injection and scripting defects fail the build instead of reaching production.

### Why split the analytics store from PostgreSQL instead of using one database?

Because the two access patterns are incompatible. Checkout needs single-row ACID compliance with strict locking; risk scoring needs to scan millions of append-only events per rolling window. Running both against one relational instance produced the 210ms of lock contention that dominated the old 380ms budget. Splitting them lets the Detection Platform ingest up to 10,000 log events per second while cutting database lock contention by 95%, with Drizzle ORM and TypeScript keeping the transactional side type-safe.