🎛️ An issuer’s authorization policy

The decision chain, and the order in which checks run

The authorization decision chain is the ordered sequence of checks an issuer runs on an authorization request before approving or declining it. It operates on a message in which the issuer chose none of the fields. The acquirer assembled the amount, the currency, the merchant category code (MCC), the entry mode, and the authentication result, and the network delivered it. The issuer has a few hundred milliseconds to decide, and its answer commits it financially. That time frame rules out calls to any slow system, any human review, and any request for documents from the cardholder.

Three families of checks run in an order dictated by the architecture. The network acts first, because it routes the message before anyone reads it. The processor acts next, on data it holds in its own database and can check without leaving its own systems. The issuer decides last, based on what it knows about the account, the account holder, and the risk it is willing to carry. When a layer fails, the chain stops there, and the downstream checks never run. The same decline can therefore come from different layers, for causes that have nothing to do with one another.

• Routing and format. The network checks that the card number range exists, that the message can be processed, and that the declared endpoint is responding. A failure here never reaches the issuer’s engine, which will have no record of it.
• Card existence and status. Unknown, blocked, expired, or not yet activated. A deterministic check with no computing cost and a final answer.
• Cryptographic verification. Chip cryptogram, PIN, and the verification values tied to the card number. A failure points to the card or the data entry, never to the cardholder’s ability to pay.
• Ability to pay. Available balance or credit line, minus authorizations already approved but not yet settled.
• Limits and counters. Per-transaction amount, cumulative amount over a window, number of transactions, and cumulative amount since the last strong customer authentication.
• Scope rules. Country, MCC, channel, negative lists, and exception lists.
• Fraud score. The only probabilistic check in the chain. It runs last because it is the most expensive and the only one that can be wrong in both directions.

The same engine handles several requests that go by the same name but do not do the same thing. A zero-amount account verification confirms that a card exists before its details are stored. A pre-authorization holds an estimated amount that the gas station or hotel will adjust later. An incremental authorization adds to an existing hold without creating a second one. A partial authorization approves less than the amount requested, typically on a prepaid card. These four requests call for different handling, both in the decision and in the counters. A configuration that lumps them together produces unwarranted declines, and a zero-amount verification that consumes a velocity counter blocks the cardholder before their first purchase.

The rules: available funds, limits, velocity, geography, MCC, lists

An issuer’s rules are the deterministic conditions evaluated before any probabilistic calculation. They cover available funds, limits, velocity, geography, MCC, and lists. The first compares the requested amount with the available balance, meaning the ledger balance minus pending authorizations plus any authorized overdraft. An authorization moves no money. It places a hold on an amount and gives the merchant a promise of payment. The hold is released in one of two ways: when the transaction is presented for settlement, or when the time limit that network rules set for that transaction type expires. Without an expiry mechanism, holds pile up and tie up cardholders’ money for sales that never happened. The problem then surfaces through customer service rather than the issuer’s dashboards.

Article 75 of Directive (EU) 2015/2366 governs transactions whose amount is not known at the time of authorization, such as a car rental or filling a gas tank. The issuer may block funds only if the payer has agreed to the exact amount, and it must release the hold without undue delay once it receives the payment order. These provisions apply in the European Economic Area. They turn the release of holds from a business practice into an obligation with a deadline. A cardholder whose available balance is still reduced three days after returning the car can invoke them.

Velocity is the number of events observed on a single key within a time window. Configuring it involves four dimensions at once: the number of transactions, their cumulative amount, the length of the window, and the grouping key. The choice of key determines what the counter can detect. Counting by card spots a compromised cardholder, counting by merchant spots a point of compromise, and counting by card number range spots enumeration, which is invisible on any single card.

Enumeration is the search for valid card numbers by sending authorization requests on candidate numbers. It needs its own rule, separate from the other counters, because it produces almost no approved transactions. The attacker sends zero-amount account verifications or purchases of a few cents, then reads the declines. Here, the decline is the information the attacker wants: its reason code reveals whether the number tested belongs to a real card. A counter limited to approvals therefore records no trace of this activity. Detection requires counting attempts, declines included, at the card number range level as well as the card level.

Two fields in the authorization message carry geographic information, and they do not describe the same thing. The first gives the acquiring institution’s country; the second, the declared location of the point of sale. A domestic merchant whose acquiring contract was signed abroad therefore looks foreign in the first field and domestic in the second. A blocking rule written on the acquirer field then declines local purchases made in the cardholder’s own country. The decline happens while the cardholder is standing at the register, for a reason that matches nothing they can see.

The merchant category code is the business category declared for a merchant, carried in every authorization request. The acquirer assigns it when it onboards the merchant, and the issuer has no way to challenge it. No later check compares it with the merchant’s actual business. Blocking a category therefore protects only as well as the upstream classification is accurate. MCC manipulation, which disguises a prohibited business under a harmless label, targets exactly this weakness. A category-blocking policy therefore requires monitoring for mismatches between the code received, the merchant name, and the observed spending pattern.

The fraud score and setting the threshold

The fraud score is a numerical value expressing the probability that an authorization request is fraudulent. It is the only check in the chain whose output is a probability; the others establish a verifiable fact. It is computed from the account history, the merchant’s identity, and the amount relative to the cardholder’s usual spending. The time, channel, entry mode, authentication result, and presence of a token feed the same calculation. The networks add their own score, based on a view the issuer does not have: the same cardholder’s activity at every other merchant. Visa delivers it as Advanced Authorization, Mastercard as Decision Intelligence. These scores arrive in the authorization message, and the issuer is free to use them as it sees fit.

A score produces a decision only once it is compared with a threshold that the issuer sets itself. Setting that threshold is an economic decision, even though it looks like a technical setting. Moving the threshold one notch shifts two quantities in opposite directions: fraud stopped and good customers wrongly declined. No setting reduces both at once. Choosing the threshold therefore means putting a price on each of those two errors.

The asymmetry that drives this price is specific to issuers, and it explains many of the declines merchants find absurd. The gain on an approved transaction is measured in basis points of the amount, because interchange is capped in several jurisdictions. The loss on a fraudulent transaction is the full amount, since European law requires the cardholder to be refunded before any loss sharing. The gain per transaction is measured in cents while the loss is measured in euros, so the break-even point sits at a very low fraud rate.

  M   transaction amount
  i   effective interchange earned on an approved transaction
  p   probability that the transaction is fraudulent
  r   share of the loss recovered later (dispute won, guarantee)
  C   full cost of a false decline (call, spend displacement, attrition)

  Approve  =  i * M  -  p * M * (1 - r)
  Decline  =  - (1 - p) * C

  With zero decline cost, approving breaks even when   p * (1 - r) = i

  With i = 0.2% (EEA consumer debit cap) and r = 0:
      the break-even point is p = 0.2%.
      One fraudulent transaction in 500 wipes out the gain on the other 499.

# Line C is the one missing from most setups.
# Until it is measured, it counts as zero in the trade-off,
# and the bar for approval is mechanically set higher than it should be.

In the European Economic Area, the liability regime locks this calculation in place. Article 73 of Directive (EU) 2015/2366 requires the payer’s provider to refund an unauthorized transaction no later than the end of the business day after it is reported. Article 74 caps the payer’s liability at €50 when the instrument was lost, stolen, or misappropriated. The same article removes even that liability when the payer’s provider did not require strong customer authentication, unless the payer acted fraudulently. An issuer that applies an authentication exemption therefore keeps the losses on the resulting unauthorized transactions. The split changes when the exemption comes from the other side: under Article 74, the payee or its provider must compensate the payer’s provider for the loss. An issuer’s exemption policy and its risk appetite are therefore one and the same decision.

Scoring models are trained on transactions labeled as fraudulent or legitimate. Two properties of those labels limit what the model can learn, and few dashboards show them. First, labels arrive late: a fraudulent transaction comes to light only when the cardholder disputes it, several weeks after the fact. A model retrained on last month’s data is therefore working on a population that is partly unlabeled. Second, declined transactions never get a label at all, since nothing happens after a decline. The issuer has no idea how many honest customers it turned away, and the more its metrics reassure it, the longer it stays in the dark. Recorded fraud falls with every tightening, while the cost of false declines, having no label, shows up in none of those metrics.

Seasonal threshold calibration happens before the period in question, never during it. Peak shopping seasons, holiday departures, and the first days of the month shift the distribution of transactions without fraud moving in proportion. A traveling cardholder generates location sequences that the engine treats as impossible, when they simply reflect a long-haul flight. Change freezes imposed by technology teams around activity peaks rule out adjusting a threshold at the very moment its effect becomes visible. The calibration calendar therefore follows the freeze calendar, one step ahead.

• Date every rule and give it a named owner. A rule written for last year’s attack rarely survives a challenge review, and it never does when no one takes responsibility for keeping it.
• Measure the recovery rate of declined cardholders. The same decline costs different amounts depending on whether the customer retries within a minute, comes back the next day, or never comes back.
• Separate rule declines from score declines in the logs. Otherwise, the two populations are managed with a single lever that works properly on neither.
• Track the score by segment, because a threshold set on the average always chokes off the highest-spending segment, which is also the one with unusual amounts.
• Compare the score distribution for authenticated and unauthenticated transactions. If the gap is small, the score is not using the authentication data it receives.

What cardholders control themselves

Cardholder controls are the settings cardholders apply to their own cards through their issuer’s app. They are a layer of the authorization policy, just like the product profile, and they take effect in the engine from the next transaction. The cardholder contributes information no other layer has: context. They know they are about to travel, that they just bought something unusual, or that they will not use the card for a month. The value of these settings lies less in what they block than in that context, which the authorization message does not carry and which the risk engine gets here without having to ask.

A freeze and a permanent block work differently, and confusing them costs a card replacement. A freeze suspends use, can be undone by the cardholder, and keeps the card number alive. A block closes the card for good, triggers a reissue, and breaks the card-on-file records held by subscription merchants. When customer service blocks a card as a precaution, the cardholder is left without a payment method for several days over a doubt that could have been cleared up in five minutes. The block then causes a string of failed recurring charges that the cardholder discovers one by one.

A virtual card is a card number the cardholder creates on demand, separate from their physical card’s number. Control shifts from settings to creation: the cardholder generates a number dedicated to one use, capped in amount, limited in time, and sometimes locked to a single merchant. The lock relies on the merchant identifier carried in the message, and that identifier is not stable. When a merchant changes acquirer, descriptor, or billing entity, it presents a different identifier, and the subscription tied to the card fails without warning. Merchant locks therefore suit one-off purchases, while subscriptions call for an amount cap and an end date.

Push notifications are the only tool that tells cardholders about a decline before they call. An alert received within a second, showing the merchant’s name, the amount, and the reason in plain language, removes the main reason the cardholder had to pick up the phone. The same channel can recover the sale. An issuer that asks in its app whether the cardholder recognizes the transaction, and then acts on the answer, turns a false positive into an approval without the customer having to pay again. Article 79 of Directive (EU) 2015/2366 already requires providers to notify the refusal of a payment order and, where possible, the reasons for it. Whether that article covers the decline of a card authorization request is open to debate. Nothing, however, prevents an issuer from applying this disclosure duty to its own declines.

Stand-in: when someone else makes the decision

Stand-in is a decision on an authorization request made by something other than the issuer, when the issuer does not respond itself. Three mechanisms decide on its behalf, in three different situations, and all three commit the issuer’s balance sheet in the same way. The chip decides offline when the terminal does not go online. The processor responds using its own data when the core banking system stops responding. The network responds for everyone when the processor itself is unreachable. If these three levels are not explicitly configured, defaults apply, and they bind the issuer just as much as settings it chose itself.

Visa runs this service as Stand-In Processing, and Mastercard runs an equivalent. What issuers most often overlook is a piece of data the service does not have: the network does not know the account balance. Every decision made at that level therefore rests on amount and count limits, set by transaction type and merchant category, never on the actual ability to pay. Generous declared limits lead the issuer to fund spending that was never checked against available funds. Limits declared at zero turn a 20-minute outage into visible declines for all the issuer’s cardholders at once.

Recovery costs more than the outage itself. Transactions approved during the outage arrive all at once, as advices, on accounts whose available balance was calculated without them. Three tasks then start at the same time: posting the advices, updating the limit and velocity counters, and handling accounts that went negative without any program rule being broken. That third task is a business decision, best made before the incident rather than during it.

The limits of stand-in play out in three ways. First, stand-in decisions remain binding on the issuer, which cannot dispute a transaction on the grounds that it would have declined it. Second, the tolerated duration of degraded operation and the expected availability thresholds are set out in documents the networks reserve for their members, and the values are not public. Finally, declared parameters can only be verified by exercising them, since a configuration file describes an intent, not observed behavior. Without an outage simulation exercise, the issuer knows its stand-in parameters from their documentation, not from their observed effect.

• The exact list of parameters declared to the network, with the date of the last change and the name of the person who requested it.
• The default behavior applied when nothing is declared, product by product, because a default inherited from an old program silently carries over to a new one.
• Last month’s stand-in rate, measured at the network’s entry point, not in the processor’s data center.
• The procedure for posting advices after recovery, and the deadline after which an unposted advice becomes a reconciliation break.
• The results of the last outage simulation exercise, with the date, the scope, and the gaps found between expected and observed behavior.

The economics of declines, and what the networks now watch

The cost of a decline is the sum of the losses an issuer bears when it rejects an authorization request it could have approved. None of those losses shows up on an invoice, for the issuer or the merchant. No income statement has a line for purchases cardholders never made. Fraud, on the other hand, is recorded in full, with an amount, a date, a case file, and an owner. A system calibrated only on booked losses therefore tightens year after year, without anyone ever making or discussing a decision to tighten it.

The first visible cost is the customer service call. A cardholder declined at the register or at checkout calls their issuer, and each institution knows the fully loaded cost of that call without publishing it. That cost can be compared with the revenue from an approved transaction. Interchange capped at 0.2% brings in €0.20 on a €100 purchase. A call with a fully loaded cost of a few euros therefore wipes out the revenue from several dozen successful transactions.

Multiplying the last two figures gives the issuers’ exposure. Covered issuers bore fraud losses equal to just under five basis points of their transaction value in 2023. The ad valorem component of the Regulation II interchange cap sits at the same level, five basis points, for the same population. The comparison ends there, and it does not show that fraud eats up interchange revenue. The cap also includes a fixed component of 21 cents per transaction, which makes up most of the fee on a typical debit purchase. The same report concludes that interchange revenue exceeds the cost of authorization, clearing, and settlement for the vast majority of covered issuers. Fraud exposure therefore does not measure the margin. It only explains why issuers and merchants value the same transaction differently: the issuer’s loss is the full amount, while its revenue is earned per transaction.

The second cost shows up after the call, and it appears in no fraud report. A cardholder declined once moves the card to the back of their wallet, which takes a few seconds in a digital wallet where the default card can be changed from a settings screen. The loss is the share of spending the issuer will no longer see, not the declined transaction itself. That share never shows up in any metric, because a transaction that does not happen leaves no record to analyze.

The third cost is attrition, meaning the customer leaves for another institution. Like the previous cost, it generates no complaints. A customer unhappy about a decline does not complain, because there is nothing to complain about. They open an account elsewhere, or simply put another institution’s card ahead of the issuer’s. Satisfaction surveys miss this shift, because they only ask customers who are still there and still active.

The networks have extended to issuers the monitoring they used to apply to acquirers and merchants. They have a view no one else has: the same cardholder across all merchants, and the same merchant across all issuers. They compare each issuer’s approval rate with that of its peers, on segments with a comparable mix, and report the gap back to the institution. The resulting performance scorecards and the availability thresholds that go with them circulate in member-only documents. Their values are not public.

Regulators produce the public side of this measurement, which serves a different purpose from the networks’ scorecards. The European Central Bank and the European Banking Authority publish a joint analysis of fraud data reported in the EU, by instrument and by whether the transaction was authenticated. Under Regulation II, the Federal Reserve Board collects cost and fraud data from covered US issuers and publishes it every two years. In France, the Observatoire de la sécurité des moyens de paiement (the payment security observatory hosted by the Banque de France, France’s central bank) does comparable work. None of these publications gives the approval rate of a named institution, and none replaces internal measurement.