Design and Architecture of a Payment Risk Control System

With the rapid development of the Internet, various industries such as gaming, commerce, charity, gambling, and catering have moved online, bringing new payment risks like account theft, false transactions, and financial fraud. A risk control system monitors transactions, channels, products, and users in real‑time, near‑real‑time, or scheduled intervals to identify and mitigate these risks.

Functional requirements

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

Synchronous feedback: receive transaction requests from payment platforms and return risk assessment results to business systems instantly.

Linked control: automatically handle identified risky transactions based on pre‑defined strategies.

Continuous iteration: dynamically update risk‑identification methods via automated collection, manual parameter setting, or external resource sharing.

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

Non‑functional requirements

Flexibility: rules must be frequently added or modified with low cost, and the system should integrate independently with various business applications.

Performance: response time under 100 ms with high throughput, ensuring risk mitigation does not degrade user experience.

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

Common pitfalls

The goal of a risk control system is to lower transaction risk to an acceptable level without affecting normal business; it cannot eliminate risk entirely, so chasing perfect data accuracy or consistency is misguided.

System architecture

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

Real‑time engine

The payment system forwards partial transaction data to the real‑time engine, which returns a risk score (0‑100, where higher means higher risk; -1 indicates insufficient data). The engine must evaluate within 100 ms, built on the Drools rule engine for flexibility.

Near‑real‑time engine

Some fraud patterns are only detectable after analyzing recent data. The near‑real‑time engine consumes transaction messages, stores intermediate data in Redis, and performs multidimensional analysis. It uses Drools, Esper CEP, Spring, and custom Esper extensions to achieve sub‑100 ms latency from detection to data availability.

Complex Event Processing (CEP)

CEP monitors and analyzes event streams to infer complex patterns quickly. 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

Esper offers a rich set of data windows (time, length, batch, etc.) and an EPL language similar to SQL, making it easy to learn. It provides flexible APIs for standalone deployment or integration.

Batch engine

Deeply hidden fraud that cannot be caught in real‑time is identified by the batch engine, which runs on a Hadoop cluster to build credit models and behavior analysis over long‑term data.

Penalty center

The penalty center stores reward and punishment data used by all engines to improve risk identification accuracy. Its domain model is illustrated below.

Implementation phases

Phase 1 – Core tasks: build infrastructure, integrate web and mobile applications, establish monitoring team and processes.

Phase 2 – Enhancement tasks: improve transaction monitoring, refine risk models, strengthen team capabilities.

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

Gradual, stage‑by‑stage construction reduces uncertainty and ensures control over technical and business directions.