Building a Scalable Payment Risk Control System: Architecture & CEP

Introduction

With the rapid development of the Internet, various industries such as gaming, commerce, charity, gambling, and catering have moved online, creating a multitude of money‑related activities. Traditional payment methods cannot keep up with the fast‑paced digital life, leading to the rise of electronic payments. While convenient, electronic payments also introduce risks like account theft, false transactions, and financial fraud. A risk control system monitors transactions, channels, products, and users, analyzing data in real‑time, near‑real‑time, or batch mode to identify and mitigate fraud.

Functional Requirements

Real‑time monitoring – in‑process detection and control of payment transaction risks.

Synchronous feedback – receive payment transaction requests, process them, and return results to business systems instantly.

Linked control – automatically handle identified risks based on pre‑defined strategies.

Continuous iteration – dynamically update risk‑identification methods via system automation, manual parameters, or external resources.

Statistical analysis – allow stakeholders to query and report on system operation, transaction risk, and performance metrics.

Non‑functional Requirements

Flexibility – enable frequent addition and modification of risk rules with low cost and maintain independence for integration with various business systems.

Performance – ensure response time under 100 ms with high throughput to avoid degrading user experience.

Accuracy – maintain a minimum accuracy threshold to prevent excessive false positives that could damage reputation and cause large losses.

Common Misconceptions

The goal of a risk control system is to reduce transaction risk to a reasonable level without disrupting normal business; it cannot eliminate risk entirely, so chasing perfect accuracy is misguided.

Architecture Overview

The system consists of a real‑time engine, near‑real‑time engine, batch engine, penalty center, and rule center.

Real‑time Engine

Payment systems forward partial transaction data to the real‑time engine, which returns a risk score (0‑100) and handling suggestions. Scores above a threshold indicate higher risk; -1 means the engine cannot evaluate the transaction. The engine must complete evaluation within 100 ms to preserve user experience.

Rule Engine Advantages

Frequent rule changes are decoupled from the core system using a rule engine, improving maintainability, readability, and configurability.

Near Real‑time Engine

This engine consumes transaction streams asynchronously, stores analysis results in a risk database, and supplies data to the real‑time engine. It detects fraud that requires short‑term historical analysis (e.g., one‑month user behavior) with a latency under 100 ms.

The engine leverages Drools, Esper, Spring, and a custom Esper Extension to enhance configurability and address Esper limitations.

CEP Overview

Complex Event Processing (CEP) monitors and analyzes event streams to infer complex patterns or threats quickly. It is widely used in workflow automation, financial fraud detection, network monitoring, and sensor networks.

CEP Technology Selection

Open‑source options include JBoss Drools Fusion, EsperTech Esper, and Triceps. Commercial products include Esper Enterprise, IBM ODM, Oracle Stream Explorer, and TIBCO BusinessEvents.

Esper Advantages

Provides a rich set of data‑window mechanisms (≈30 types) and an SQL‑like Event Processing Language (EPL) that lowers the learning curve. Offers flexible APIs for standalone deployment or integration.

Esper Disadvantages

All intermediate data resides in memory, limiting deployment to a single node, causing potential single‑point failures, and losing state on restart.

Batch Engine

Handles deep data mining for hidden fraud patterns that require long‑term analysis (cross‑month or cross‑year). Built on a Hadoop cluster, it supports credit‑scoring and user‑behavior models.

Penalty Center

Accumulates risk data and provides reward/penalty services. Real‑time, near‑real‑time, and batch engines query or store data here, allowing the system to adjust risk decisions based on historical penalties and incentives.

Development Phases

Phase 1 – Core tasks: infrastructure setup, web and mobile integration, and monitoring team establishment.

Phase 2 – Enhancement tasks: transaction monitoring capabilities, risk model refinement, and team skill improvement.

Phase 3 – Future development: continuous optimization and onboarding of new applications.

Gradual, stage‑by‑stage construction ensures controllable risk and aligns team expertise with system complexity.