STIP
Mitigations in cards and payments real-time infrastructures
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
Hello and welcome back to our ongoing 'Payments Concepts' series! We're thrilled to have you join us for another session. Today, we're diving deep into the world of card networks, focusing on one of the most crucial mitigation strategies: STIP or "Stand-in Processing".
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. Before we dive deeper into STIP, let's take a moment to revisit the fundamental authorization mechanism within a card network.
When a cardholder makes a payment using their card, the transaction goes first through an authorization process where the card issuer checks if the card status is in good standing, has sufficient funds and if the transaction is legitimate. If the transaction is authorized, the cardholder will typically see an immediate deduction or hold on their account for the transaction amount.
As we just saw, 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. When the issuing bank can't give a real-time response to the card network because of scheduled or unexpected disruptions or network issues, the network steps in for the issuer to either green-light or reject a transaction. The network (like Visa or Mastercard) temporarily takes over the decision-making process for transaction approvals or declines when the issuer is unavailable.
The rules applied during STIP are typically more conservative, aiming to minimize risk.
This decision is made using the authorization guidelines (specific rules) previously established by the issuer. In STIP mode, the network system uses predefined parameters and rules to automatically approve or decline transactions without connecting to the primary authorization system of the issuer.
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. Here are some typical rules that might be applied:
Transaction Amount Limit: There might be a lowered transaction amount threshold during STIP. Any transaction exceeding this amount could be automatically declined.
Frequency Limit: The number of transactions allowed for a card within a specific timeframe might be restricted.
Geographic Restrictions: Transactions originating from regions or countries with high fraud rates might be declined.
Merchant Type Restrictions: Certain merchant categories known for higher risk (like gambling or adult entertainment) might be blocked during STIP.
Unusual Activity or velocity block: If a card has an unusual spike in activity in a short period, subsequent transactions might be declined.
Previous Declines: If a card has had recent declined transactions, further transactions might be halted during STIP.
Offline Data: The card network might use the last available data from the issuer before the outage to make decisions. For instance, if an account was nearing its limit before the issuer went offline, transactions might be declined during STIP.
Fallback to Chip: If a chip transaction fails, and the terminal attempts a magnetic stripe transaction, it might be declined during STIP due to the higher risk associated with magnetic stripe transactions.
It's essential to understand that these rules are predefined by the issuer and are based on their risk appetite and customer base. The primary goal during STIP is to balance customer convenience with risk management, ensuring that genuine transactions go through while minimizing potential losses. Limitations of rule-based STIP:
Based on BIN level: All accounts under the same issuer BIN receive identical treatment, irrespective of their past records.
Static predefined rules: Not dynamically adjustable to varying circumstances
Since issuing banks are not available, they usually set very cautious static rules. This approach leads to a drop in approval rates by over 25% during STIP incidents.
Beyond STIP rule models
To enhance the efficiency of the STIP process, Visa crafted a machine learning model designed to grasp the issuer's decision-making strategies and logic for transactions. This model then replicates these strategies during outages, ensuring approval/decline decisions align closely with the issuer's likely choices. It's important to highlight that Smarter STIP isn't solely a fraud detection model due to issuers consider various factors, such as credit risk and account balance, beyond just fraud when authorizing a transaction. While a fraud detection model primarily aims to identify fraudulent activities, the main goal of Smart STIP is to forecast approvals or declines when the issuer is offline. It's crucial to understand that most declined transactions result from reasons like activity limits or insufficient balance, rather than fraud.
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. You can delve into the press article from two years ago when Visa's smart STIP system was officially launched.
In a previous article of The Engineer Banker,
we've highlighted that ISO20022 real-time infrastructures possess a mechanism akin to STIP. When banks connected to RT1 or UK’s FPS undergo maintenance, they can switch their gateway to stand-in mode. This ensures the gateway remains connected to the payment scheme on behalf of the entire organization, albeit rejecting transactions during this period. The participant's payment gateway can enter in 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 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.
Possibly, if a bank gateway possesses an internal 'store and forward' capability, stand-in can also be implemented by accepting transactions without immediate posting. Later, the internal queue can be replayed to process these transactions. The stand-in mode provides a valuable tool for participants to manage their operational requirements efficiently, since it's far more effective and safe to proactively reject transactions at the entry point than to allow them to fail unpredictably as they traverse the participant's internal systems. Neglecting to do so could lead to partial failures and inconsistent clearing states.
An alternative to gateways toggling between regular functions and stand-in mode, the central hub can facilitate participants to join or leave the network. For instance, 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.
Now, over to you, do you know other payments system with similar mitigation properties?