🔒 System messages
A guide to the ISO20022 real-time infrastructures operational messages
Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace
Say hi to another exciting episode of our Real-Time Payments Series! Today, we'll take a closer look at the crucial role of system messages. These non-value messages (in contrast value messages have monetary value associated like pacs.008, pacs.004, pacs.009, …) have multiple operational purposes:
Notifications to propagate the status of various conditions, such as participant liquidity warnings and participant status change. When a participant faces liquidity issues or undergoes a change in its operational status, the central infrastructure immediately sends out these broadcast notifications to all relevant stakeholders. These notifications can be targeted at specific participants or broadcasted to the entire community of stakeholders, depending on the nature and scope of the event. This ensures that relevant stakeholders receive critical updates tailored to their specific needs, while also fostering transparency and collaboration within the payment ecosystem. This ensures that all participants stay informed about critical updates and can take appropriate actions if necessary.
Technical rejections when the message exchanged is not well formatted as opposed to pacs.002 or cam.029 that account for business rejections. Technical rejections are a result of issues related to the structure, syntax, or compliance of the message itself, leading to the system's inability to process it correctly. These rejections are typically automatic and occur before any business validation takes place.
To ensure continuous and seamless connectivity among participants, the system employs keep-alive notifications. These notifications act as a form of regular communication between the central infrastructure and the participants, serving as a way to detect any potential disruptions in connectivity. By periodically exchanging these keep-alive messages, the system can promptly identify and address any issues that may arise, ensuring that all participants remain consistently connected and operational. This proactive approach to connectivity detection contributes to the overall stability and reliability of the real-time payment system, minimizing the risk of interruptions and facilitating smooth and efficient payment processing
System notifications and broadcast
One prime exemplification of system messages is the admi.004 message, firmly established within the ISO20022 framework, as it assumes a pivotal role in expediting crucial administrative processes and upholding the system's integrity. This system notification message serves the crucial task of communicating operational information, such as planned downtimes and maintenance windows, to the participating entities. The versatility of this feature allows it to be utilized in two distinct ways: as a broadcast message disseminated to the entire community of participants, or as a unidirectional message directed specifically to a particular participant. This flexibility enables seamless communication within the network, providing the ability to broadcast important information, updates, or alerts to all stakeholders simultaneously, while also facilitating targeted communication to address specific needs or concerns of individual participants. In general a system notification does not require a response from the participant.
Planned downtimes
By notifying the network's stakeholders of any scheduled disruptions, the admi.004 message ensures transparency, efficient planning, and seamless coordination across the real-time infrastructure.
The participant takes the responsibility of notifying the entire community regarding planned maintenance activities and the anticipated duration of unavailability. This proactive communication allows other participants to avoid sending transactions to the affected party, thus preventing transaction failures. Additionally, if a participant fails to update its local routing data to reflect the maintenance window, the central infrastructure will detect and reject any transactions directed towards that participant during the specified timeframe. This robust coordination and adherence to maintenance notifications not only safeguard the integrity of the payment ecosystem but also ensure the uninterrupted flow of transactions by proactively managing potential disruptions and minimizing any adverse impact on the overall network performance.
In both RTP and FedNow, when a participant is marked as offline, either manually or through an automatic process, the central hub will promptly reject any incoming transactions directed to that participant. This preemptive response ensures that transactions are not erroneously sent to an offline participant, enhancing efficiency and accuracy in the payment process. However, the approach is different in RT1, where the participant itself needs to implement a rejection mechanism to handle transactions when it is offline. This is usually done leaving the participant’s gateway in “stand-in mode” rejecting all transactions during the maintenance period.
To enhance operational flexibility, the participant's payment gateway can activate the stand-in mode by enabling a specific feature flag. This activation triggers the stand-in mode's logic, resulting in the rejection of all incoming traffic directed towards the participant. By implementing this stand-in mode, the participant effectively suspends its regular transaction processing, allowing for maintenance or other operational activities to take place without any live transactions being impacted. Once the maintenance activities are completed, the feature flag is then disabled, automatically restoring the flow of traffic back to the screening service, where normal transaction processing resumes seamlessly. The stand-in mode provides a valuable tool for participants to manage their operational requirements efficiently and without disrupting real-time transaction processing, ensuring continuous service availability and smooth operation during critical maintenance windows or other necessary updates. It's important not to confuse this mechanism with the STIP mechanism commonly used in card networks.
STIP stands for "Stand-in Processing" in the context of card networks. It is a feature used by card issuers to ensure a seamless payment experience for cardholders when the primary authorization system is unavailable or experiences a delay. When a cardholder makes a payment using their card, the transaction goes through an authorization process where the card issuer checks if the card has sufficient funds and if the transaction is legitimate.
In normal circumstances, the authorization is performed by the card issuer's main authorization system. However, in cases where the main system is down or encounters a delay, the STIP mode comes into play. In STIP mode, the card issuer's system uses predefined parameters and rules to automatically approve or decline transactions without connecting to the primary authorization system.
The predefined parameters are typically conservative to minimize the risk of fraud. This means that in STIP mode, some legitimate transactions might get declined to prevent potential fraud. The card issuer monitors transactions processed in STIP mode and later reconciles them with the main authorization system once it is back online. If any discrepancies or fraudulent activities are identified during reconciliation, appropriate actions are taken by the issuer to rectify the situation.
STIP mode is a contingency measure implemented by card networks to ensure that cardholders can continue using their cards even when the main authorization system experiences technical difficulties. It helps maintain a smooth payment experience while ensuring a certain level of security for the cardholder and the card issuer.
RTP offers its participants the flexibility to sign off the network temporarily in order to conduct essential system upgrades.
During this period of planned maintenance, participants can ensure their systems are up-to-date and optimized for optimal performance. Once the necessary upgrades are completed, the participant can seamlessly sign back on to the RTP network, resuming their active participation in real-time payment transactions.
Unplanned downtimes
Keep reading with a 7-day free trial
Subscribe to The Engineer Banker to keep reading this post and get 7 days of free access to the full post archives.