# How Issuers Decide to Approve or Decline
Source: https://paymentsandrisk.com/docs/fraud/detection/authorization-decisioning

Last updated 24 October 2026.

TL;DR

-   The issuer decides in milliseconds, on very little data
-   Rules, ML models and velocity checks, same as your own fraud stack
-   Key signals: cardholder history, transaction patterns, **your merchant reputation**
-   **"Do Not Honor" usually means fraud suspicion.** Nobody will confirm that
-   You can lift approvals with cleaner traffic, richer data and 3DS

The issuer approves or declines in under 100 milliseconds. It runs rules, ML models and velocity checks to get there. It sees almost none of your fraud signals. So it leans on cardholder history, transaction patterns and your reputation as a merchant. This page covers what those signals are, why good transactions still get declined, and which levers you hold.

Where to go next

-   [My good customers keep getting declined](https://paymentsandrisk.com/docs/playbooks/fix-declining-auth-rates/)
-   [What does this decline code mean?](https://paymentsandrisk.com/docs/reference/decline-codes/)
-   [How do I raise my approval rate?](https://paymentsandrisk.com/docs/payments/auth-optimization/)

Related: The Issuer Perspective

This page is the technical decisioning process. For the wider view of what issuers see, read [Why Issuers Decline and Dispute](https://paymentsandrisk.com/docs/fraud/issuer-perspective/). For disputes specifically, read [Why Chargebacks Favor Cardholders](https://paymentsandrisk.com/docs/chargebacks/issuer-side/).

## What Happens During Authorization

From outside it's one step. Inside the issuer it's a whole decision tree, and it runs in under 100 milliseconds.

```mermaid
flowchart TD
    A[Auth Request\nReceived] --> B{Account\nValid?}
    B -->|No| C[Decline:\nInvalid Card]
    B -->|Yes| D{Sufficient\nFunds/Credit?}
    D -->|No| E[Decline:\nInsufficient Funds]
    D -->|Yes| F{Fraud\nCheck}
    F -->|High Risk| G[Decline:\nDo Not Honor]
    F -->|Medium Risk| H{Step-up\nAuth?}
    H -->|Yes| I[Request 3DS]
    H -->|No| J{Velocity\nCheck}
    F -->|Low Risk| J
    J -->|Exceeded| K[Decline:\nVelocity Limit]
    J -->|OK| L[Approve]
    I -->|Pass| L
    I -->|Fail| G
```

The fraud check is where merchant transactions get caught.

## Signals Issuers Use

Issuers weigh a mix of factors. Roughly these.

### Cardholder History

-   Typical spending patterns (amounts, frequencies, categories)
-   Geographic usage patterns (where has this card been used before?)
-   Previous fraud claims filed by this cardholder
-   Account age and status

### Transaction Characteristics

-   Amount (unusually large for this cardholder?)
-   Merchant category (high-risk MCC?)
-   Time of day (consistent with cardholder behavior?)
-   Card-present vs. card-not-present

### Merchant Signals

-   Merchant reputation (historical fraud and [chargeback](https://paymentsandrisk.com/docs/chargebacks/) rates)
-   [AVS](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/) result (address match?)
-   [CVV](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/) result (code match?)
-   [3DS](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) authentication result

### Device and Location

-   IP geolocation (does it match cardholder's typical locations?)
-   Distance from last transaction (impossible travel?)
-   Device fingerprint (if available through enhanced data sharing)

## Rules vs. Models

Issuers mix rules with machine learning, same as you do.

**Rules-based checks:**

-   Hard limits: "Decline if card has been used more than 10 times in 1 hour"
-   Category restrictions: "Decline if merchant is in blocked MCC list"
-   Geographic rules: "Decline if transaction is in country where cardholder has never been"

**ML models:**

-   Pattern recognition across the cardholder's full history
-   Comparison to similar cardholders' behavior
-   Real-time scoring (typically 0-1000 scale)

Visa Advanced Authorization and Mastercard Decision Intelligence score at the network level. They read hundreds of signals and hand back a number in under a millisecond. Issuers fold that score into their own decision.

## Velocity Limits

Velocity checks matter most to issuers. They're the brake on a card that just got stolen.

The amounts and counts below illustrate possible issuer controls. They're not published issuer limits, and your merchant rules don't override the cardholder's bank.

| Velocity Type | Example |
| --- | --- |
| Transaction count | Max 5 transactions per hour |
| Daily spend limit | Max $2,000 per day |
| Geographic velocity | Can't transact in two distant cities within an hour |
| Decline count | Too many declines in short period triggers lockout |
| MCC velocity | Unusual concentration in high-risk categories |

See "card\_velocity\_exceeded" and the cardholder has hit one of these. It isn't negotiable. They'll have to call their bank.

## Decline Reason Codes

Issuers send back a response code. Most of them hide behind the generic ones.

| Code | Meaning | What's Really Happening |
| --- | --- | --- |
| 05 | Do Not Honor | Could be anything: fraud suspicion, velocity, internal policy |
| 14 | Invalid Card Number | Card number doesn't exist or has a typo |
| 41 | Lost Card | Cardholder reported card lost |
| 43 | Stolen Card | Cardholder reported card stolen |
| 51 | Insufficient Funds | Not enough balance available |
| 54 | Expired Card | Card is past expiration date |
| 57 | Transaction Not Permitted | Card restricted for this MCC or transaction type |
| 61 | Exceeds Withdrawal Limit | Hit a daily or transaction limit |
| 65 | Exceeds Activity Count | Hit a velocity limit |

Code 05 is a huge share of all declines. It's a catch-all. The issuer reaches for it when it doesn't want to name the reason. Usually the reason is fraud suspicion, and naming it would tip off the fraudster.

**Important:** 05 can reflect different issuer decisions. Check the processor's retry advice for that payment and response. A generic retry count isn't permission to resubmit.

## Soft vs. Hard Declines

Not all declines are equal.

**Soft declines** are temporary and can be retried:

-   Insufficient funds (customer might add money)
-   Velocity exceeded (limit might reset)
-   Issuer system unavailable (try again later)

**Hard declines** are permanent and shouldn't be retried:

-   Invalid card number
-   Lost or stolen card
-   Account closed
-   Fraud confirmed

Retrying a hard decline wastes money. You're still paying the network fee. Do it often enough and you trip fraud flags of your own.

**Retry guidance:** Follow your processor's response-specific advice, network restrictions and the customer's permission. Stop when further attempts aren't permitted. Space allowed retries to the stated reason; don't run a generic loop.

## Improving Authorization Rates

You do have levers here.

### Send Better Data

More context, better decision.

-   Full billing address for AVS
-   CVV for every first-time transaction
-   Merchant name that matches your billing descriptor

### Use Enhanced Data Sharing

Some networks, processors and acquirers run data-sharing programs. Your risk scores, model output and 3DS results go straight to the issuer. An issuer that can see somebody trusted already vetted the transaction approves more of them.

VAA and Mastercard Decision Intelligence are the network versions. Some acquirers and PSPs run their own issuer-linking programs.

### Authenticate When Appropriate

3D Secure shifts liability. It also lifts approval rates. An issuer that authenticated the cardholder itself has no reason to doubt the transaction.

### Keep Credentials Updated

Account updater refreshes expired and reissued card numbers for you. Network tokens help too. A token survives a reissue. A raw PAN doesn't.

### Don't Hammer Declines

Aggressive retry logic looks like fraud. Issuers track retry patterns. Ignore their first answer often enough and they start declining you on sight.

## What You Can't Control

Some of this isn't yours to fix.

-   Cardholder's account status (frozen, closed, restricted)
-   Cardholder's available balance
-   Issuer's global risk policies
-   International restrictions

When one of these declines you, the customer has to call their bank. Or pay another way.

## Do next

-   [Velocity Rules](https://paymentsandrisk.com/docs/fraud/detection/velocity-rules/) - Rate limiting patterns
-   [Card Testing](https://paymentsandrisk.com/docs/fraud/types/card-testing/) - Understanding retry abuse

## Look up

-   [Fix retry strategy](https://paymentsandrisk.com/docs/reference/decline-codes/#soft-vs-hard-declines) - Don't hammer declines
-   [Network Programs](https://paymentsandrisk.com/docs/chargebacks/reference/network-programs/) - Fraud thresholds