Designing Business‑Focused Monitoring for Banking Systems: Metrics, Alerts, and Implementation Challenges

Three Stages of Monitoring Development

Monitoring evolves through three stages. In the first stage operators manually define metrics, rules, and runtime parameters, often using scripts and threshold‑based alerts (e.g., Zabbix). The second stage moves metric and rule definitions to the monitoring platform, aiming for uniformity across heterogeneous systems while operators still maintain runtime parameters. The third stage lets the monitoring system automatically compute optimal parameters from both monitoring data and production behavior, minimizing manual intervention.

Business Monitoring Metrics and Alert Rules

Transaction Success Rate

Success rate is the most basic metric. System success rate counts only technical failures (e.g., network errors). Business success rate distinguishes logical failures reflected by specific return codes (e.g., “account on hold”). Monitoring both rates enables alerts that trigger when a transaction’s business outcome deviates from the expected pattern.

Service System Transaction Success Rate

Each transaction is associated with a calling system and a service system. By grouping all transactions that invoke the same service system, the service system’s overall success rate can be calculated, and the rate can be further broken down by individual transaction codes.

No Transaction on Node

If a high‑frequency transaction does not occur on a specific node within a defined statistical window, an alert can be raised. The rule can be refined with “busy” and “idle” periods to account for different patterns during peak hours, weekdays, and holidays.

Transaction Volume Sudden Change

Under normal conditions, transaction volume for a given code and time slot is relatively stable. A sharp increase or decrease is detected by computing the ratio c = a / b, where a is the current volume and b is the baseline volume. Configurable thresholds (e.g., 0.8–1.2) define the normal range; values outside trigger an alert.

Abnormal Transaction Count per Period

For low‑frequency or ultra‑high‑frequency transactions, success‑rate alerts are ineffective. Instead, set a threshold on the number of abnormal transactions within a monitoring window (e.g., >10 failures for a high‑volume code, >1 failure for a critical low‑volume code). A dedicated view can list node, serial number, request system, transaction code, service system, and return codes for each abnormal transaction.

Response Time Timeout Count per Period

When a system degrades, response times may lengthen without exceeding the monitoring timeout, making rate‑based alerts insufficient. Define a timeout threshold (e.g., 600 ms) and count transactions exceeding it within each period. Exceeding a configurable count triggers an early‑warning alert.

End‑of‑Day and Reconciliation

End‑of‑day processes must start and finish within a defined window and return success. Reconciliation steps are monitored by ensuring the number and amount of mismatched records stay within historical variance.

Challenges in Implementing Business Monitoring

Acquiring Basic Transaction Information

Effective monitoring requires detailed transaction data: request system, transaction code, importance flag, service system, processing node, start/end timestamps, serial number, institution, amount, service‑system response code, local response code, and message. Many production systems do not expose all fields, especially if they were not designed with monitoring in mind. Collecting this data at scale generates massive volumes, demanding high‑performance processing and concurrent calculations at the transaction‑code level.

Production System Development Standards

Uniform transaction‑code specifications are essential. Overloaded codes that perform multiple functions or ambiguous return codes prevent reliable business‑level monitoring. Standardizing return‑code meanings and enforcing single‑function transaction codes are critical for accurate metric calculation.

Massive Runtime Parameter Settings

Each transaction code requires a set of parameters, such as business success‑rate thresholds, system success‑rate thresholds, sudden‑change upper/lower bounds, abnormal‑transaction count thresholds, timeout thresholds, and aggregation windows. Large systems may need tens of thousands of such parameters. Once rules are defined, algorithms can automatically adjust parameters based on baseline behavior, but maintaining and tuning this parameter set remains the primary operational difficulty.