What a decline is trying to tell you.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Meridian FX has sent Northbank a complaint. Deposit declines are "up 30 per cent" and their traders are "being blocked by your fraud rules". Tomas has pulled the week's declines and is looking at a column of codes he half recognises. Before anyone adjusts a rule, there is a prior question: who declined these, and what were they looking at when they did?

What is actually being decided.

A declined authorisation is a message, and the first thing to establish is who sent it. In a card payment there are at least three places a decline can originate. Your own rules, or Northbank's, can refuse to send the authorisation at all. The acquirer can refuse it on its own checks. The issuer, who holds the account and sees the cardholder's whole history, can refuse it with a response code that travels back through the chain. Each of those three saw something different, and each tells you something different about what to do next.

The decision on the desk is therefore not "loosen the rules or not". It is: for each family of decline, who is the sender, is the message actionable, and what does acting on it cost? The two costs are the ones the Volume 01 lesson on measuring errors names: a genuine trader interrupted, and a fraudulent deposit allowed. Google's crash-course definitions of precision and recall are the plain vocabulary for that trade and we use them deliberately: a decline is a positive prediction, and the question is how many of those predictions were right.

Sort by sender before sorting by code.

Response codes vary by scheme, acquirer and integration, and the authoritative list for your traffic is your acquirer's integration guide, not a blog post. What does not vary is the structure. a working desk groups declines into four families it can act on, and resists acting on individual codes.

The first family is our decision: the transaction never reached the issuer because a rule at the merchant or PSP stopped it. These are the only declines Meridian's complaint could be right about, and they are fully within your control. If they are a small share of the total, the complaint is aimed at the wrong party.

The second is cannot be completed: the issuer or acquirer reports a structural problem, such as an expired card, an invalid number, a card not enabled for this type of transaction, or a restricted account. A retry with the same details will fail again. Retrying these is not a kindness to the customer; it is a cost, and OWASP’s automated-threat descriptions is blunt that attempts can incur costs under the merchant’s processing contract, including unsuccessful ones.

The third is not now: insufficient funds, limits exceeded, issuer temporarily unavailable. The same card may succeed later. These are retryable, with care, and they are also where genuine customers live. A trader whose deposit bounces for insufficient funds on Friday and succeeds on Monday is not a risk signal.

The fourth is authenticate first. Under the SCA regime set out in Delegated Regulation 2018/389, an issuer that does not accept an exemption request can decline the authorisation and ask that the transaction be sent through 3-D Secure; EMVCo's overview describes the protocol that carries the retry. this soft decline is the single most misread message on the desk. It is not a refusal. It is a request. A checkout that treats it as a refusal loses the sale and records a decline that nobody caused. The companion piece on who carries the risk when 3DS is skipped covers the exemption side of that exchange.

There is a fifth message that belongs to no family: the generic "do not honour", where the issuer declines and gives no reason. It is the issuer's right to say nothing. Treat it as opaque and follow the current provider retry contract; do not infer permission to retry from this label alone.

Compared with what, exactly.

"Up 30 per cent" is an observation about a ratio, and both halves of the ratio deserve a look. Suppose, in this synthetic illustration, Meridian's deposits last week were 10,000 attempts with 1,300 declines, and this week 13,000 attempts with 2,210 declines. The decline count is up 70 per cent. The decline rate is up from 13 to 17 per cent. Both are true; neither tells you who sent the declines.

Now split by family. Say the "our decision" family went from 200 to 210: flat. "Cannot be completed" went from 300 to 320: flat. "Not now" went from 600 to 700: up with volume. "Authenticate first" went from 200 to 980. The whole movement is in one family, and it is the one family that is not a refusal. The inference, which we would state as an inference, is that something changed in how exemptions are being requested or accepted for Meridian's traffic, and the right conversation is with the integration team and the acquirer, not the rules engine.

The alternative explanation to keep alive: the 3,000 extra attempts might not be Meridian's traders. A burst of attempts with a high structural-decline rate and many distinct cards is the shape of enumeration, and the article on BIN attacks describes what to do with it. The split by family would show that too: "cannot be completed" would rise, not "authenticate first". Look before you infer.

Either way, the baseline matters more than the delta. The piece on baselines and seasonality is about choosing a comparison that means something, and the decision study The missing denominator walks through a decline spike that turns out to be a denominator problem.

Retries have a price and a pattern.

A retry policy needs the provider’s current response-code contract. Determine whether the result is final, requires changed details or authentication, or leaves the outcome uncertain. Unchanged rapid retries can create avoidable costs and duplicate-payment risk. Use documented limits and reconciliation; do not turn a generic decline label into permission to retry automatically.

So write the retry policy per family, and write it down. "Retry once after 30 seconds on 'not now'; retry with authentication on 'authenticate first'; do not retry 'cannot be completed'; do not retry 'do not honour' automatically." That is four sentences. It is also the kind of rule the article on rules you can explain would call a claim: each sentence can be tested against the following month's outcomes.

A failure mode to watch.

A consequential mistake is to read a decline-rate movement as a verdict on the fraud rules. Decline rate is a sum of messages from several senders, and the contribution of each source needs to be measured. A team that reacts to the sum by loosening thresholds has made the one family it controls more permissive in order to fix a movement that lives in a family it does not control. The approval rate barely moves, the fraud rate does, and a month later the complaint is about chargebacks. Sort by sender first. Measure how long this takes in your own workflow and preserve the breakdown.

A way to work it.

1. Pull the period's declines with the raw response code and the point of decline: merchant or PSP rule, acquirer, issuer.
2. Map codes into the four families plus "opaque", using your acquirer's integration guide as the reference.
3. Compare each family's count and rate with a comparable baseline: same weekday, same campaign state, same merchant mix.
4. Name the family that moved. State the observation, then the inference, then one alternative.
5. Act within the family. Rules for "our decision"; integration or acquirer for "authenticate first"; nothing for "cannot be completed".
6. Write the retry policy per family and give it an owner and a review date.

Take it to the desk.

Of our top five decline reasons last month, which were sent by us, which by the issuer, and which do we honestly not know? The third category is usually larger than anyone expected, and it is where the next improvement is.

Try it: The silent rule, and the Volume 01 case Card testing. Read also: the Volume 01 note Card testing beyond declines. Look up: decline code, step-up.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.

Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.