A Feature Engineering Approach for Business Impact-Oriented Failure Detection in Distributed Instant Payment Systems

TL;DR

The paper tackles the problem of bridging infrastructure observability and business-process visibility in distributed instant payment systems, where strict latency and uninterrupted operation are critical. It introduces a feature engineering method that computes processing times between consecutive ISO 20022 messages, represented as $\delta_1$, $\delta_2$, and $\delta_3$, and transforms transaction streams into a real-time multivariate time series $S^{\eta}$ for anomaly detection. An explainable framework pairs a detector with a rules-based explainer to achieve failure localization, incident severity classification, and business impact assessment, enabling rapid and interpretable response in a distributed SCT Inst setting. Validation on the TARGET Instant Payment Settlement (TIPS) platform using a real Network Service Provider incident and controlled simulations demonstrates effective detection across failure modes, reduced investigation time, and actionable explanations that bridge technical metrics with business outcomes. The approach offers a lightweight, algorithm-agnostic pipeline that can integrate with existing AIOps ecosystems and scales to real-time operations, potentially extending to other SCT Inst actors beyond the CSM. The work advances practical trust and operational efficiency in high-stakes financial infrastructures by delivering explainable, domain-specific observability that connects processing-state signals to business impact.

Abstract

Instant payment infrastructures have stringent performance requirements, processing millions of transactions daily with zero-downtime expectations. Traditional monitoring approaches fail to bridge the gap between technical infrastructure metrics and business process visibility. We introduce a novel feature engineering approach based on processing times computed between consecutive ISO 20022 message exchanges, creating a compact representation of system state. By applying anomaly detection to these features, we enable early failure detection and localization, allowing incident classification. Experimental evaluation on the TARGET Instant Payment Settlement (TIPS) system, using both real-world incidents and controlled simulations, demonstrates the approach's effectiveness in detecting diverse anomaly patterns and provides inherently interpretable explanations that enable operators to understand the business impact. By mapping features to distinct processing phases, the resulting framework differentiates between internal and external payment system issues, significantly reduces investigation time, and bridges observability gaps in distributed systems where transaction state is fragmented across multiple entities.

Figures (4)

• Figure 1: The core message flow of the SCT Inst process showing the three processing phases identified in the SEPA Instant Credit Transfer process, whose durations constitute the proposed features for anomaly detection.
• Figure 2: Real-time feature extraction pipeline architecture. Application nodes generate message traces, which are collected by Beats agents and processed by Logstash nodes. Messages flow through Kafka for buffering, where ksqlDB correlates messages to compute processing times. The processed features are then indexed in Elasticsearch for both storage and real-time analysis.
• Figure 3: Architecture of the instant payment experimental testbed. External simulators representing the originator and beneficiary banks connect to the TIPSnet testing environment. Payment messages flow through the message queue and router to the core components. Anomalies can be injected at various points in the processing flow.
• Figure 4: Time series with corresponding anomaly scores for processing times $\delta_1$, $\delta_2$, $\delta_3$, and payment volume $v$ during the Network Service Provider incident. The plots illustrate changes in $\delta_2$ (external response time) and payment volume during the incident period, while internal processing times ($\delta_1$ and $\delta_3$) remain stable.