Card Authorization Switch and Issuer Processing Architecture

Every time a card taps a terminal, a distributed system has roughly the length of a held breath to say yes or no. The card authorization switch and the issuer processing stack behind it must ingest a message, resolve which account it belongs to, price the risk of approving it, check that the money is really there, place a hold, and return a verdict — usually inside a few hundred milliseconds, at five-nines availability, on the worst shopping day of the year. There is no queue the cardholder will tolerate. The architecture that delivers this is one of the most quietly demanding real-time systems in commercial computing, and almost none of it is visible from the checkout screen. This post walks the real-time path an authorization takes, layer by layer, and shows where the hard engineering actually lives.

What this covers: the four-party model, the switch’s routing and BIN logic, the ISO 8583 request/response cycle, the issuer processor core (card, account, ledger, limits), stand-in processing, inline fraud scoring, ledger holds and open-to-buy, reversals and idempotency, and the failure modes that break reconciliation.

This is a systems and architecture analysis. It is not financial, investment, or trading advice, and it is not payment-security or compliance guidance for any specific deployment.

Context and Background

Card payments run on a four-party model, and the whole authorization architecture is easier to reason about once those four parties are fixed in mind. The cardholder holds an instrument — a physical card, a provisioned token in a wallet, a card-on-file credential. The merchant wants to be paid and presents the transaction. The acquirer (and its processor) is the merchant’s bank-side entity: it captures the transaction at the point of interaction and injects it into a card network. The issuer is the cardholder’s bank, which actually owns the account, the funds, and the credit line, and which ultimately approves or declines. Sitting between acquirer and issuer is the card network — Visa, Mastercard, and their peers — operating a global switch that routes messages by card number to the correct issuer.

The distinction that trips people up is between the issuer as a bank and the issuer processor as a system operator. Many banks do not run their own authorization stack; they outsource it to an issuer processor (Marqeta, Galileo, FIS, TSYS, Global Processing Services, and others), which operates the switch endpoint, the card and account master, the ledger, and the decisioning that produces the approve/decline. When this article says “issuer processing architecture,” it means that operational stack, whether a bank runs it in-house or rents it. The processor is where authorization latency budgets are won or lost.

Authorization is only the first of three separable phases. Authorization confirms funds and reserves them. Clearing exchanges the definitive transaction records between acquirer and issuer, typically in batch. Settlement moves the actual money between banks. Conflating these is the single most common source of confused mental models, because a cardholder sees “authorization” and thinks money moved — it did not. Only a hold was placed. The network’s own documentation, such as the Visa Core Rules and Visa Product and Service Rules, formalizes these obligations. For a deeper look at how the money-movement layer is being modernized, see our companion analysis of ISO 20022 migration in payments architecture.

The Reference Architecture

A card authorization switch is a low-latency message router with a decisioning brain bolted to it. In the reference shape, an inbound network message lands on the issuer’s front door, gets normalized and enriched, is fanned out in parallel to fraud scoring and to the account/ledger core, is resolved into an approve-or-decline within a strict time budget, and is returned to the network — with a stand-in path ready to answer if the core cannot. Everything else is detail on top of that spine.

Figure 1: Reference layers from cardholder to issuer decisioning core, including the stand-in path.
Long description: A top-down flow shows the cardholder device and merchant on top, feeding the acquirer processor, then the card network switch, then the issuer switch front door. The front door fans out to a risk and fraud scoring engine, the authorization decision core, and a stand-in STIP engine. The decision core reads the card and account master and the ledger and limits open-to-buy store, then returns the response back up through the switch.

The layers matter because each one has a different failure and scaling profile. Squashing them into a monolith is where fragile systems come from.

The switch front door and message normalization

The front door terminates the network connection and speaks the network’s exact dialect. Card networks use ISO 8583 variants that differ in field usage, so the first job is normalization: parse the raw bitmap-and-fields message, validate structure, and translate it into an internal canonical representation that the rest of the stack can reason about without caring which network it came from. This layer is deliberately thin and brutally fast. It also enforces the connection-level contract — message authentication, sequence handling, and echo/heartbeat management that keep the network link declared “up.”

Critically, the front door is where the latency budget starts ticking. Networks impose response-time expectations; if the issuer does not answer within the window, the network stops waiting and invokes stand-in on the issuer’s behalf. Every millisecond the front door spends is a millisecond the decisioning core does not have.

BIN routing and account resolution

The leading digits of a card number form the BIN/IIN (Bank Identification Number / Issuer Identification Number). At the network level, the BIN is what routes the message to the right issuer. Inside the issuer processor, a finer-grained routing happens: the specific BIN range maps to a product, a program, a processing configuration, and ultimately to the account behind the card. In modern token-heavy flows the inbound identifier is often not the real card number (PAN) at all but a network token (DPAN); resolving that to the underlying account is its own step, discussed below.

Account resolution turns “this card number” into “this ledger, these limits, this cardholder, this program’s rules.” It is a lookup that must be correct and fast, which is why the card and account master is engineered as a low-latency, highly-replicated store rather than a general-purpose relational system doing joins under load.

Latency budgets and availability targets

Two non-functional numbers dominate every design choice above: a latency budget and an availability target. The latency budget is the wall clock the issuer has to answer before the network gives up and invokes stand-in. End to end, from tap to receipt, the industry norm is well under a second; the issuer’s own internal slice is frequently held to a sub-100ms budget so there is margin for network transit on both legs. That budget is not aspirational — the front door measures against it and the whole hot path is built backward from it. It is why fraud features are precomputed, why the account master is cache-resident, and why nothing on the critical path performs synchronous heavy computation or unbounded fan-out.

The availability target is usually expressed as five-nines (99.999%), which translates to roughly five minutes of unavailability per year. No single component hits that alone, so the number is achieved through redundancy at every layer — multiple front-door instances, replicated data stores, active-active data centers — and, crucially, through the stand-in path that keeps answering during the seconds or minutes when the core is degraded. Availability and latency are in tension: the more carefully you check something, the longer it takes and the more that can fail. The reference architecture resolves that tension by making the fast, high-availability path the default and pushing everything heavier off the critical path.

The decisioning core

The decisioning core is where approve or decline is actually decided. It gathers the account state, the current available balance or open-to-buy, the applicable limits and velocity rules, the fraud score, and the program logic, and it produces a response code. It is also responsible for the side effect of approval: placing a hold against available funds so a second transaction cannot spend the same money. The core is the part of the stack that must be both fast and transactionally careful, and the tension between those two properties is the defining engineering problem of issuer processing.

Deeper Walk-through

The ISO 8583 authorization round-trip

The lingua franca of card authorization is ISO 8583, a message standard dating to the 1980s that is still the backbone of card processing worldwide. An ISO 8583 message has a Message Type Indicator (MTI), a bitmap declaring which data elements are present, and the data elements themselves. For authorization, the request is an MTI of the 0100 family and the response is 0110. Data elements carry the primary account number (DE 2), processing code (DE 3), transaction amount (DE 4), point-of-service entry mode (DE 22), and — carrying the verdict on the way back — the response code (DE 39). This is not trivia; the exact elements present shape what the issuer can decide.

Figure 2: The 0100 request and 0110 response round-trip across the four-party model.
Long description: A sequence diagram shows the cardholder tapping at the merchant, the merchant sending an auth request to the acquirer, the acquirer sending an ISO 8583 0100 to the network, the network forwarding the 0100 to the issuer, the issuer running risk scoring and limit checks, then returning a 0110 to the network, which returns it to the acquirer, which returns approved or declined to the merchant, which prints a receipt for the cardholder.

Walk the round-trip concretely. The cardholder presents the card. The merchant terminal, via its acquirer, composes a 0100 authorization request and sends it into the network. The network reads the BIN, routes to the issuer endpoint, and delivers the 0100. The issuer processor normalizes it, resolves the account, scores it for fraud, checks limits and available funds, places a hold, and composes a 0110 authorization response carrying DE 39. The network relays the 0110 back to the acquirer, which tells the terminal approved or declined. On a card-present tap, the cardholder often sees the result before their hand has left the reader. That entire chain typically completes in well under a second end to end, with the issuer’s own processing slice frequently held to a sub-100ms internal budget.

One subtlety worth internalizing is that DE 39, the response code, is doing more than saying “yes” or “no.” Its value distinguishes an approval from a soft decline (try again later, issuer unavailable) versus a hard decline (do not honor, pick up card), and merchants and networks treat those classes very differently — a soft decline may be retried, a hard decline should not be. The response code is also what drives downstream retry logic and dunning in card-on-file scenarios, so an issuer that returns imprecise codes creates noise that ripples far past its own boundary.

The industry is also on a long arc toward ISO 20022, a richer, XML/data-dictionary-based standard already dominant in the high-value and instant-payment worlds. Card authorization has been slower to migrate because ISO 8583 is deeply entrenched and latency-optimized, but the direction of travel is clear: structured, extensible messages that carry far more context (richer merchant data, structured remittance, better fraud signals) than a bitmap allows. The migration is non-trivial precisely because the bitmap format is terse and fast while ISO 20022 is verbose and self-describing; issuers will run translation layers between the two for years rather than flip in one step. Treat ISO 20022 as the destination and ISO 8583 as the still-load-bearing present.

Dual-message versus single-message

There are two structural models for how authorization relates to clearing. In a dual-message system — classic credit-card processing — authorization (0100/0110) and clearing (the 0200/0220 financial presentment) are separate messages sent at different times. You authorize now, and the definitive financial record arrives later, often in an end-of-day batch. In a single-message system — common in PIN debit and many ATM flows — authorization and the financial transaction are effectively the same message, so the debit is posted in one shot. This distinction ripples through the whole architecture: dual-message systems must reconcile an authorization against a later clearing record and handle the gap between them, while single-message systems collapse that gap but demand the funds move decisively at authorization time. The reconciliation machinery, the hold model, and the reversal semantics all differ between the two.

Stand-in processing and its risk envelope

No core is up 100% of the time, and the network will not wait. Stand-in processing (STIP) is the mechanism that answers authorizations when the primary decisioning core is unreachable or too slow. STIP can live at the issuer processor (a local, degraded-mode decision engine that answers when the main core is down) and also at the network itself (the network approves or declines on the issuer’s behalf against a set of issuer-supplied parameters when the issuer endpoint times out). Either way, the principle is the same: better to answer within policy than to fail the cardholder at the terminal.

Figure 3: Inbound authorization detokenizes, then either runs the full core path or falls through to STIP.
Long description: A flow shows an inbound 0100 arriving from the network, then detokenizing the DPAN to a PAN, then checking whether the issuer core is reachable. If yes, it runs inline fraud scoring, places a ledger hold against open-to-buy, and decides approve or decline. If no, it routes to the STIP engine running local rules, which also produces an approved or declined 0110 response.

The catch is that STIP decides with a thinner picture of the world. It typically does not see the freshest balance, the full fraud model, or the exact current limits — it works from cached parameters and conservative rules (approve under a floor limit, decline high-risk categories, respect a cached available balance). That is the risk envelope: STIP trades decision quality for availability. Set the envelope too generously and you approve transactions the live core would have declined, creating overdrafts, over-limit exposure, and fraud losses. Set it too tightly and you decline good customers during an outage. Tuning STIP parameters is a genuine risk-management exercise, not a config afterthought, and every STIP-approved transaction must later be replayed to the core (often via advice messages) so the real ledger catches up.

Inline fraud and risk scoring

Modern authorization scores risk inline — inside the latency budget, before the response goes out. The scoring engine consumes the transaction plus context (recent velocity, device and terminal signals, merchant category, geography, historical behavior) and returns a risk score or decision the core folds into its verdict. The engineering constraint is savage: this must happen in a handful of milliseconds without blocking the response. That forces feature stores and models to be pre-computed and cache-resident, with the online path doing lookups and a fast model evaluation rather than heavy computation. Where 3-D Secure or step-up authentication is in play, higher-risk transactions can be challenged rather than declined outright, but the initial scoring still happens in the authorization window.

Tokenization and network tokens

Increasingly the identifier arriving in the 0100 is not the PAN but a network token (DPAN) — a surrogate provisioned by the network’s token service and bound to a specific device or merchant. Wallet taps and card-on-file credentials ride on DPANs so the real PAN is never exposed at the merchant or in transit. During authorization the processor must map the DPAN back to the funding PAN and account, validate the token’s cryptographic assurance and domain controls, and then decide. This raises the security floor (a stolen DPAN is far less useful than a stolen PAN) and adds a resolution step to the critical path. Tokenization also interacts with the issuer’s own vaulting of card data; we cover that surface in depth in card tokenization and PCI DSS vault architecture.

The ledger hold and open-to-buy model

When the core approves, it does not move money — it reserves it. It places a hold (an authorization hold, or “pending” amount) against the account, reducing the open-to-buy (the spendable balance: credit limit or available funds minus current holds and pending activity). This is the mechanism that stops a cardholder from spending the same $100 twice across two fast transactions. The hold sits on the ledger until the matching clearing record arrives and converts it into a posted transaction, or until it expires, or until a reversal releases it. Getting the open-to-buy arithmetic exactly right under concurrency — two authorizations racing for the same available balance — is the transactional heart of issuer processing, and it is where a naive design silently allows overspend. This is why the ledger is engineered for correct concurrent decrements, not just fast reads.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes of authorization systems cluster around time, duplication, and the gap between “held” and “cleared.” Understanding them is understanding why the architecture is shaped the way it is.

Figure 4: The unhappy paths — timeouts trigger reversals, STIP triggers advice replay, and everything must reconcile against clearing.
Long description: A left-to-right flow shows a 0100 auth request sent, then a check whether a response was received. If yes, a 0110 approved places a hold. If no, a timeout with no 0110 triggers a 0400 reversal that releases the hold and loops back. Separately, a STIP-approved transaction emits a 0120 advice that replays to the core. Both the held transaction and the advice feed into reconciliation, which matches against the clearing records.

Network timeouts and phantom holds. If the acquirer sends a 0100 and never receives the 0110 within the window — because the issuer was slow, or the response was lost in transit — the transaction is ambiguous. The issuer may have approved and placed a hold while the merchant saw a timeout and treated it as failed. That stranded hold reduces the cardholder’s open-to-buy for a purchase that never completed. The corrective mechanism is the reversal: the acquirer sends a 0400 reversal request (with 0420 as the advice variant), and the issuer releases the hold. Reversals are not an edge case; they are load-bearing plumbing, and an issuer stack that handles them lazily accumulates phantom holds and angry customers.

Idempotency and double-auth. Retries are inherent to any networked system, so the same logical authorization can arrive more than once. Without idempotency — keyed on retrieval reference numbers, STAN/system trace numbers, and other correlation fields — a retried 0100 becomes a second hold for the same purchase, halving the customer’s available balance. Correct issuer processing treats these correlation keys as first-class and deduplicates rather than blindly re-authorizing.

STIP overhang and reconciliation breaks. Every STIP-approved transaction is a decision the core did not make with full information. When the core comes back and the advice messages replay, the ledger must absorb them and the picture must reconcile against clearing. If advices are lost, or if a STIP-approved transaction never produces a matching clearing record, reconciliation breaks — the authorization and the money-movement records disagree, and someone has to investigate the exception. Five-nines availability targets exist precisely to keep the STIP window small, because the STIP window is where reconciliation risk concentrates.

Capacity for card-present spikes. Authorization load is not uniform; it spikes hard around peak retail moments, and card-present taps cannot be shed or queued the way a background job can. The stack must be provisioned for peak, not average, with headroom — which is why the front door and decisioning core are horizontally scalable and the hot data is cache-resident rather than sitting behind a contended database.

Practical Recommendations

Reasoning about an authorization stack is easier if you treat latency, availability, and reconciliation as three separate budgets that must all be satisfied simultaneously rather than traded off casually. Latency discipline means the critical path does lookups and fast evaluations, never heavy synchronous computation; anything that can be precomputed (fraud features, limit state, token mappings) is precomputed and cached. Availability discipline means every dependency on the critical path has a defined behavior when it is slow or down — most importantly a STIP path with an explicitly reasoned risk envelope, not a default. Reconciliation discipline means every authorization, hold, reversal, STIP advice, and clearing record can be matched end to end, because the moment those records diverge you have money-truth ambiguity that is expensive to unwind.

A short checklist for evaluating or reasoning about an issuer authorization stack:

Latency budget is explicit and enforced. There is a stated internal budget (often sub-100ms) and the front door measures against it.
STIP risk envelope is deliberate. Floor limits, cached-balance rules, and category declines are set as risk decisions, with advice replay guaranteed.
Idempotency keys are first-class. Retrieval reference numbers and trace numbers dedupe retries so no transaction produces two holds.
Reversal handling is prompt and complete. 0400/0420 reversals release holds quickly; phantom-hold monitoring exists.
Open-to-buy is concurrency-safe. Racing authorizations cannot overspend the same available balance.
Reconciliation closes the loop. Auth, hold, STIP advice, and clearing records reconcile, with an exception queue for breaks.
Capacity is sized for peak taps, not average throughput, with the hot path cache-resident.
Token resolution is on the happy path, with DPAN-to-PAN mapping and domain controls validated inline.

For where this stack sits inside a broader payments estate — routing, retries, and multi-processor strategies — see our overview of payment orchestration platform architecture.

Frequently Asked Questions

What is a card authorization switch?

A card authorization switch is the low-latency routing and decisioning layer on the issuer side that receives an inbound authorization message from a card network, resolves it to the correct account, coordinates fraud scoring and funds checking, and returns an approve-or-decline within a strict time budget. It is the front door to the issuer processing stack. Depending on the design it also manages the network connection, message normalization across ISO 8583 dialects, and the stand-in path that answers when the core cannot respond in time.

How does the ISO 8583 authorization flow work?

The acquirer composes an ISO 8583 request in the 0100 message family, carrying data elements such as the account number, processing code, and amount. The network routes it by BIN to the issuer, which decides and returns a 0110 response carrying a response code in data element 39. Reversals use the 0400/0420 family to release a hold when a transaction is abandoned or times out. The bitmap-and-data-element structure is compact and latency-optimized, which is one reason card authorization has stayed on ISO 8583 while other payment rails migrate to ISO 20022.

What is stand-in processing (STIP)?

Stand-in processing is the mechanism that answers authorizations when the issuer’s primary decisioning core is unreachable or too slow. It can run at the issuer processor or at the network, deciding against cached parameters and conservative rules — floor limits, cached balances, category restrictions — rather than the live core’s full picture. STIP trades decision quality for availability, so its rules form a risk envelope that must be tuned deliberately. Every STIP decision is later replayed to the core via advice messages so the real ledger and reconciliation catch up.

What is a ledger hold and open-to-buy?

When an authorization is approved, the issuer places a hold — a pending, reserved amount — against the account rather than moving money. Open-to-buy is the spendable balance: the credit limit or available funds minus current holds and pending activity. The hold reduces open-to-buy so the same funds cannot be spent twice, and it persists until the matching clearing record posts the transaction, the hold expires, or a reversal releases it. Computing open-to-buy correctly under concurrent authorizations is the transactional core of issuer processing.

How does real-time fraud scoring fit in the latency budget?

Fraud scoring happens inline, inside the authorization window, before the response is sent. To fit in a handful of milliseconds, the system relies on precomputed features held in a fast, cache-resident feature store and a model evaluation designed for speed, so the online path does lookups rather than heavy computation. The resulting score folds into the decisioning core’s verdict. Higher-risk transactions may be challenged through step-up authentication rather than declined, but the initial scoring still occurs within the sub-second authorization path.

Why are authorization, clearing, and settlement separate?

They answer different questions at different times. Authorization confirms funds are available and reserves them with a hold, in real time. Clearing exchanges the definitive transaction records between acquirer and issuer, usually in batch, and converts holds into posted transactions. Settlement moves the actual money between the banks. Separating them lets the real-time path stay fast and lightweight while the heavier accounting and money movement happen asynchronously — but it also creates the gap between “held” and “cleared” that reversals and reconciliation exist to manage.

Card Authorization Switch and Issuer Processing Architecture (2026)