How to Build Reliable Monitoring for Low‑Frequency Financial Services

1. Introduction

Having spent over two years moving from e‑commerce to finance, the authors encountered many pitfalls in monitoring due to differing business models and traffic patterns. Early lack of monitoring caused several production incidents, prompting the development of a set of practical monitoring methods tailored for financial scenarios.

2. Common Monitoring in E‑commerce

E‑commerce monitoring typically focuses on two aspects: traffic monitoring (API requests) and key‑node monitoring (e.g., registration, order placement). The usual technique is to emit a “point” for each request or key‑node event and compare today’s point count with yesterday’s.

When today’s point count drops more than 50% compared with the same time yesterday, an alarm is triggered.

This approach works in e‑commerce because traffic volume is high, making percentage‑based alerts reliable, and because the number of critical nodes is limited (e.g., add‑to‑cart, checkout), keeping the monitoring scope short.

3. Challenges in Financial Monitoring

Financial services are low‑frequency: daily active users are dozens of times lower than in e‑commerce, so a key‑node may generate only a few points per hour, often zero for many minutes. Consequently, percentage‑based alerts become ineffective.

4. Overview of Financial Business

The discussed product is a cash‑loan (assist‑loan) platform that matches borrowers with funding partners. The platform does not issue loans directly; it leverages its acquisition and post‑loan management capabilities to connect borrowers with lenders and earns fees.

Each borrower is matched with a funding partner, whose risk‑control policies differ, leading to varying approval and loan‑grant rates. After matching, the process consists of three stages:

Pre‑loan : Credit assessment based on personal information such as ID and education.

During loan : Borrower requests the loan after credit approval.

Post‑loan : Repayment phase.

Because each stage contains many critical nodes, the overall funnel is long and the point count per node can be very low, making raw point‑based alerts noisy.

5. Reliable Monitoring Techniques for Finance

1) Monitor Success Counts/Success Rates per Lender and Process

Instead of tracking every node, the team monitors the final success metrics for each funding partner: credit‑approval success, loan‑grant success, and their respective rates. Hourly success totals are recorded, and the most recent X‑hour window is compared against the average of the same time window over the past week.

If the current total falls below half of the weekly average, an alarm is raised. The value of X is dynamically chosen: start with a 1‑hour window; if the count is below a threshold (e.g., 20), expand to 2 hours, then 3, until the count reaches the threshold, reducing false‑positive noise.

For high‑performing lenders, hourly counts are sufficient; for low‑performing lenders, the window is extended to 8 hours, and a zero count triggers an alarm.

2) Aspect‑Oriented Exception Capture for Lender Errors

Each lender integration has its own API client, leading to many places where request failures could be missed. By using an AOP aspect that intercepts all exceptions thrown by lender request classes, the team centralizes alert logic without modifying each client.

// Interface call
String result = httpPost();
Response response = JSON.parseObject(result, Response.class);
// If the response code is not success
if (!response.getCode().equals(SUCCESS_CODE)) {
    // Throw an exception containing the lender's error message
    throw new Exception(ErrorCodeEnum.ERROR_REQUEST_EXCEPTION, response.getMessage());
}

The aspect logs the exception and sends a DingTalk alert:

@Aspect
public class LoggingAspect {
    // Capture all methods in lender request packages
    @AfterThrowing(pointcut = "execution(* com.howtodoinjava.app.service.impl.*(..))", throwing = "ex")
    public void logAfterThrowingAllMethods(CustomException ex) throws Throwable {
        // Send the error message to DingTalk
        sendDingWarning(ex.getMessage());
    }
}

To avoid noisy alerts from expected failures (e.g., account frozen, repayment not allowed on due date), a whitelist is maintained. When a failure matches the whitelist, the alert is suppressed.

The whitelist is stored in QConf, a Zookeeper‑based distributed configuration service, allowing dynamic updates without code changes.

3) Circuit Breaking and Degradation with Sentinel

Because a single lender failure can cascade and bring down the entire request flow, the team employs Alibaba Sentinel for circuit breaking. When the exception count for a lender exceeds a threshold within one minute, Sentinel degrades the service, causing immediate failures and preventing downstream impact.

Degraded calls throw a DegradeException, which is also captured by the AOP aspect and sent to DingTalk.

6. Summary

The article presents several monitoring solutions for low‑frequency financial services, including point‑based success metrics, dynamic hourly alerts, aspect‑oriented exception handling with whitelist filtering, and Sentinel‑based circuit breaking. While these methods have proven effective (100% alert accuracy reported), the authors note that machine‑learning‑driven behavior prediction could further improve timeliness once expertise becomes available.