| STAN (DE11) | RRN (DE37) | |
|---|---|---|
| Full name | System Trace Audit Number | Retrieval Reference Number |
| Length | 6 digits | 12 characters |
| Set by | the originator — whoever sends the request (terminal/acquirer) | the acquirer, and carried unchanged end to end |
| Unique for | one day, per acquirer/host | the life of the transaction, across systems |
| Main use | matching a response or reversal to its request in flight | refunds, disputes, reconciliation — quoting a transaction to a counterparty |
Six digits means 1,000,000 values, and it resets daily. A busy acquirer can wrap within a single day — and at midnight the numbers start again regardless. So a STAN on its own is not a key. Match on STAN combined with the acquirer ID (DE32) and the transmission date (DE7); anything less will eventually pair a response with the wrong request, and the symptom (one customer's approval landing on another's order) is ugly and hard to reproduce.
This is also why a reversal carries DE90 with the original STAN, the original date and the original acquirer ID packed together: any one of them alone would be ambiguous.
When you contact a scheme, an acquirer or an issuer about one specific transaction, give them the RRN. It is the identifier that survives the whole lifecycle — authorization, clearing, settlement, chargeback — and it is what their systems index on. Quoting a STAN will usually get you asked for the RRN anyway.
Some networks encode structure into the RRN (for instance a year digit, day-of-year, and a terminal or trace component), but never parse it for meaning: the layout is scheme-specific and not guaranteed. Treat it as an opaque string.
👉 Related: ISO 8583 field reference (DE11 / DE37).