ISO 8583 response code: 96

96 is the catch-all for a processing failure somewhere in the chain. It differs from 91 in that a system was reached and something went wrong inside it, rather than nothing being reachable at all — though in practice the two are often used interchangeably by acquirers. It is transient by nature, but a persistent 96 for one message shape usually means that message is malformed in a way the receiving system does not handle gracefully.

• A transient internal failure at the acquirer, network or issuer.
• A message that is structurally valid but semantically unhandled — an unexpected field combination that breaks a parser downstream.
• A field whose declared length disagrees with its contents, which some hosts report as a system error rather than a format error.
• Capacity problems during a traffic peak.

1. Retry with backoff. If it succeeds, it was transient and there is nothing to fix.
2. If it is reproducible for one message shape, it is not transient. Parse that message field by field and look for a length prefix that disagrees with its contents.
3. Compare a failing message against a working one of the same type. A 96 that only ever appears for one transaction type points at how that type is being built.
4. Escalate to your acquirer with the system trace audit number if it persists — a genuine 96 is something on their side that they can see in their logs.

• ISO 8583 91Issuer or switch is inoperative
• ISO 8583 12Invalid transaction

• ISO 8583 message parser
• EMV tag decoder (field 55)

Is a repeatable 96 still an infrastructure problem?

Probably not. Transient failures do not reproduce on demand. A 96 that appears every time for one transaction type is usually a malformed message — most often a length-prefixed field whose declared length does not match what follows, which misaligns everything after it and breaks the receiving parser rather than returning a clean format error.