Stand-In Processing
Stand-in processing is the card network's approval or decline of transactions on an issuer's behalf when the issuer's authorisation system is unreachable — applying limits and rules the issuer set in advance, so that cardholders can keep paying during an outage. The issuer carries the risk of what the network approved; the network carries the availability. For a neobank on a modern processor it is also what happens when the fintech's own real-time authorisation endpoint fails to answer.
- Also known as
- STIP, Stand-in authorisation, Network stand-in
- Used at
- issuer outages, planned maintenance, network timeouts, and — for fintechs on just-in-time funding models — any failure of the fintech's authorisation service to respond within the network's window
- Binding
- the scheme rules require issuers to configure stand-in parameters and hold them liable for stand-in approvals; processors implement the same idea at their layer
- Typical parameters
- per-transaction and cumulative limits by card type and merchant category, velocity limits, lists of blocked cards, negative files, and rules for online versus offline PINs; the network approves within the parameters and declines outside them
- Typical exposure
- an issuer whose stand-in limits are generous approves transactions it would have declined — an empty account, a stolen card reported minutes earlier — and pays for them; one whose limits are tight declines its own customers during the outage
- Parties
- the issuer and its processor (which set the parameters), the network (which stands in), the acquirer and merchant (who see approvals as usual), and the cardholder
How stand-in processing works in practice
An issuer's authorisation host goes down at 03:00 for a database failure. Transactions on its cards keep arriving at the network; instead of timing out and declining them all, the network applies the issuer's stand-in parameters — approve purchases up to €150 at most merchant categories, up to €500 cumulative per card, decline cash withdrawals and gambling, decline any card on the hot list — and answers the acquirers itself. When the host returns at 04:20, the network sends the issuer an advice of every stand-in decision; the issuer posts them, and finds it has approved €40,000 of transactions on 1,200 cards, of which 14 were on accounts with no funds and 2 on cards reported stolen at 03:30. Those are the issuer's losses; the alternative was 9,000 declined customers.
Neobanks meet this differently. On a just-in-time funding model the processor asks the fintech's system, in real time, whether to approve each transaction — the balance lives at the fintech. If the fintech's endpoint is slow or down, the processor stands in with the fintech's parameters, and the fintech's outage becomes approvals it must fund. The parameters are therefore a product decision with a risk budget: how much the neobank will lose to keep cards working while its system is down.
For a buyer of a card issuer or a neobank: the stand-in parameters, the outage history, and the losses they produced are one line of technology diligence and one line of risk.
Example
A neobank's authorisation service suffers a 45-minute outage during a Saturday lunchtime. Its processor's stand-in parameters, set two years earlier: approve up to €100 per transaction, €300 cumulative per card, decline ATM and online gambling, decline cards flagged in the last 24 hours. 38,000 transactions are approved in stand-in, €1.9m; 11,000 declined. When the service returns, reconciliation finds €62,000 approved on accounts whose balances were below the amount — a loss the neobank absorbs — and 400 cardholders whose legitimate €120 grocery shops were declined. The risk committee resets the parameters: €150 per transaction, €400 cumulative, a per-account balance snapshot pushed to the processor hourly so stand-in can check it. The next outage, four months later, costs €9,000.
Common mistakes
- Stand-in parameters set at launch and never revisited as the card base and the limits changed. - No balance snapshot at the processor, so stand-in approves against nothing. - Parameters so tight that every outage is a customer-service event. - Treating stand-in approvals as the network's problem; they are the issuer's. - A neobank whose authorisation endpoint has no failover, so stand-in is its uptime plan.