The Number You Were Given

28.0 What this chapter gives you#

1. You will be able to name the four identifiers a card payment leaves behind, say who created each one, where it appears and how long it lives.
2. You will be able to explain why searching on a system trace audit number alone returns every terminal’s 004821 for every day in the retention window, and what the composite key should be instead.
3. You will be able to say why the approval code on a customer’s receipt is corroboration and never a lookup key.
4. You will be able to tell a customer whether they were charged twice or are looking at one charge and one hold, and why refunding an uncleared authorisation leaves them net up.
5. You will be able to say which number to quote to your acquirer, which to the scheme, which to the issuer, and which never to ask a customer for.
6. You will be able to store each identifier at the width and type its specification demands, and say why twenty-three digits will not fit in a 64-bit integer.
7. You will be able to explain why an acquirer reference number exists if and only if the transaction cleared, and what that means for the commonest class of complaint.
8. You will be able to say why both major schemes had to invent identifiers of their own, and why Mastercard’s has to be assembled from three fields.
9. You will be able to contrast a card payment’s identifiers with a UETR, and say why a Swift payment can be tracked end to end and a card payment cannot.
10. You will be able to read a signature from a pair of records — sequential trace numbers seconds apart, two terminal identifiers, an incremental authorisation, a tip adjustment, a late reversal — and name the cause.

The plain version#

Imagine a school trip. Forty children, one coach, one museum, one long day.

Before the coach leaves, the teacher walks down the aisle handing out numbers. “You’re fourteen today.” It is written on a sticker. It is used all day for one purpose only: counting heads. Every time the coach stops, the teacher calls the numbers and waits for forty voices. Number fourteen is not who you are. It is where you sit in the count. Next week, on the next trip, somebody else will be fourteen. On the coach going home, you might even be given a different number, because a different teacher is counting.

At the museum door you are given a wristband. It has a code printed on it, something like M-3040-118. It goes on at nine in the morning and stays on until you cut it off at home. It is yours for the whole day, and no other child in the building has the same one. If you get lost, the wristband is what the staff read out over the radio.

Inside, at the gift shop, you buy a keyring. The person at the till presses a button, a machine thinks for a second, and a small slip prints with a code on it: 07B4C1. That code means the shop’s bank said yes. It does not say what you bought, or how much, or who you are. It only says: at this moment, a machine said yes to something.

Then, a week later, the school office does the accounts. Somebody sits down with a stack of receipts and writes each one into a ledger, giving each line its own long reference. That reference did not exist on the day. It was born a week later, in a different building, made by a different person, for a different purpose: settling up. But if you later ring the school and say the gift shop charged you twice, that ledger reference is the only number that gets you anywhere, because it is the one attached to actual money that actually moved.

Four numbers. The coach number, the wristband, the till slip code, the ledger reference. They are not four copies of the same thing. They have four different owners, four different lifetimes, and four different jobs, and if you ask the wrong person for the wrong one you get a shrug.

A card payment works exactly like this.

Say you buy lunch at a café in Leeds on Tuesday 3 March. The bill is £42.60. You tap your card. Between the tap and the receipt printing, four numbers come into existence, or will do shortly.

The first is the card machine’s own counter. The terminal has been sitting there all morning ticking upward: 004819, 004820, and now yours, 004821. It puts that number in the message it sends off, and when the answer comes back, that answer carries 004821 too. That is the entire point of it. It is how the terminal knows the reply that just arrived is the reply to your lunch, and not to the person behind you buying a coffee. It is the coach number. It counts up to 999999 and then rolls back round to the beginning and starts again. Yesterday’s 004821 was somebody else’s sandwich.

The second is a longer reference, twelve characters, something like 506201304821. The café’s bank makes this one. Unlike the counter, it is meant to last. It is the wristband. It goes onto the request, it comes back on the answer, and it stays attached to the record of your lunch when that record is filed away at the end of the day. If, six weeks later, somebody has to go and find the exact transaction in the café’s bank’s systems, this is the number they search on.

The third is the approval code: 07B4C1. Six characters. Your own bank makes this one, and only makes it if the answer was yes. It appears on the paper receipt, which is why it is the number a customer is most likely to be holding when they ring you up. It is the till slip code from the gift shop. It proves that a yes happened. On its own it does not prove what the yes was for.

The fourth does not exist yet. At the end of the day the café’s card machine closes its batch and sends the day’s takings off to be paid. Somewhere in that process, a twenty-three digit reference is created for your £42.60 specifically: something in the shape of 74530045062001234567890. That is the ledger line. It is the number the card networks use to talk about your lunch as money that moved, rather than as a question that was asked. If you dispute the charge, this is the number the dispute is filed under.

Now the useful part. Suppose you look at your banking app on Wednesday and see £42.60 twice.

If you ring the café and read out the counter number, they can do nothing with it, because every card machine they own has been through 004821 many times. If you read out the approval code, they can look, but approval codes are short and get reused, so they may find several. What actually settles the question is the twenty-three digit ledger reference, one per movement of money. Two of those means two payments and one needs refunding. One of those, plus one leftover approval that never became a ledger line, means you were charged once and are looking at a hold that will fall off your statement in a few days.

Same event. Four numbers. Only one of them answers the question you actually asked.

Where the plain version stops being true#

The wristband is not unique for ever, and it is not necessarily a number. The twelve-character reference is defined in the card message standard as twelve alphanumeric characters, not twelve digits. It can contain letters. It can begin with zeros. Any system that stores it as an integer will silently destroy it, and a great many systems do. It is also only unique within the organisation that issued it and within a time window that organisation chooses. Two different acquiring banks can and do produce the same twelve characters on the same day for two completely unrelated transactions. It is a good search key inside one estate. It is not a global identifier, and treating it as a primary key across parties is how reconciliation breaks.

The till slip code does not name the purchase. The six-character approval code says that an approval occurred. It does not encode the amount, the card, the merchant or the time. Issuers generate them cheaply and reuse them freely. Matching two records on approval code alone will produce false matches at any real volume, and it will produce them most often exactly when you are under pressure, because the customer with a problem is the one who has the receipt in front of them and nothing else. The approval code is a corroborating field. It is never a lookup key on its own.

The ledger reference is not the same journey. The twenty-three digit reference is created during clearing, which is a separate, later, batch-shaped process from the authorisation that happened at the till. An authorisation that is never cleared never gets one. A declined transaction never gets one. A hold that is left to expire never gets one. So there is a whole class of customer complaint, arguably the most common one, where the correct answer is “there is no ledger reference, because there is no charge”, and the analogy of one wristband per child breaks down entirely: some children never went into the museum.

The numbers do not travel unchanged. The coach analogy implies one teacher counting. In reality the message crosses a terminal, a gateway, an acquirer’s switch, the scheme’s network, perhaps an issuer processor, and finally the issuer, and several of those nodes are entitled to replace the counter with one of their own before passing the message on, keeping a private map from the number they received to the number they sent. Your 004821 may be somebody else’s 771903 two hops later. This is not a bug. It is how a switch keeps its own outstanding requests straight. It does mean there is no single number that is guaranteed to be present, unchanged, at every point in the chain, which is precisely the gap the card schemes later tried to close with identifiers of their own.

The technical version#

The message these numbers live in#

Card authorisation messages are ISO 8583 structures. The message type indicator is four digits: position one is the standard version (0 for the 1987 edition, 1 for 1993, 2 for 2003), position two the message class (1xx authorisation, 2xx financial, 3xx file actions, 4xx reversal and chargeback, 8xx network management), position three the function (0 request, 1 request response, 2 advice, 3 advice response) and position four the origin (0 acquirer, 2 issuer, 4 other). An authorisation request is therefore 0100, its response 0110, a financial request 0200, a reversal request 0400 and a network management request 0800.

After the MTI comes the primary bitmap, sixty-four bits indicating whether data elements 1 to 64 are present. Bit 1, when set, signals a secondary bitmap covering elements 65 to 128. Everything discussed below is a data element addressed by that bitmap.

Four of them matter for tracing, and they are not interchangeable.

Two supporting elements do most of the disambiguating work and are frequently forgotten: DE41, card acceptor terminal identification, ans 8, and DE42, card acceptor identification code, ans 15. Alongside them sit DE7 transmission date and time, DE12 local transaction time (n 6, hhmmss), DE13 local transaction date (n 4, MMDD), DE4 amount, DE49 currency code as an ISO 4217 numeric code, DE39 response code (an 2) and DE55 for the EMV data.

Note DE13 carefully. In the 1987 catalogue the local transaction date is four digits, MMDD. There is no year in it. Every date-range query you write against a store of raw ISO 8583 must derive the year from somewhere else, normally DE7 or the acquirer’s own receipt timestamp, and every year-end produces a fresh crop of reconciliation breaks in systems that did not.

DE11: the system trace audit number#

DE11 is six numeric digits. It is assigned by whichever node originates the message, and it must be returned unchanged in the corresponding response so that the originator can pair the two. That is its whole function. It is a correlation key.

The consequences of that follow directly from the size of the field. Six digits gives you one million values before the counter wraps to zero and starts again. A busy terminal estate exhausts that in a day. A switch handling scheme traffic exhausts it in minutes. So a STAN is unique only within one originator, within one wrap cycle, and the sequence is very often per terminal rather than per estate, which means STAN 004821 exists simultaneously on every terminal you own.

This produces the single most common analytical error in card operations: searching for a STAN. A bare STAN search across an estate returns every terminal’s 004821 for every day in the retention window. The correct key is composite. In practice you need the STAN together with the acquiring institution or terminal identity (DE41 or DE42), the local date (DE13, plus a year from DE7), and usually the amount (DE4) and currency (DE49) as a sanity check. Only then does the tuple identify one transaction, and even then only within one processing estate.

DE11 has one hard operational obligation attached to it. A reversal — a 0400 — must carry the STAN of the original message it is reversing, so that the issuer can find and release the hold it placed. Systems that generate a fresh STAN for the reversal and put the original nowhere in the message are the direct cause of authorisation holds that sit on customers’ statements for a week. If you build a terminal application, store the original STAN in a durable local record before you send the request, not after you get the response, because the case in which you most need to reverse is the case in which no response arrived.

Mastercard’s single-message system uses DE11 in exactly this way and names it accordingly. In Mastercard’s fraud submission interface the identifier TRC is defined as “Trace Id (DE 11 in Single Message Authorization Message)”, with a minimum and maximum length of 6 and a numeric data type. That is the STAN, promoted to an externally quotable identifier, and it is never quoted alone: Mastercard requires it in combination with SER, the Switch Serial Number, DE63 subfield 3, nine numeric digits. Two fields, because one is not enough. That is the standard telling you, in its own documentation, that a STAN is not a transaction identifier.

DE37: the retrieval reference number#

DE37 is twelve alphanumeric characters, an 12. The name is the specification: it is the number you quote when you retrieve a transaction later, which historically meant asking the acquirer to pull the paper draft out of a filing cabinet.

Two things about it are routinely got wrong.

First, it is alphanumeric. Worldpay’s published ISO 8583 reference guide records a change history entry to the effect that field 37 was corrected from numeric to alphanumeric, which tells you how easy the mistake is to make even inside a large processor. Store it as a fixed-width character field of exactly twelve. Do not trim it. Do not cast it. Leading zeros in a retrieval reference number are load-bearing.

Second, ISO 8583 does not specify any internal structure for DE37. It says twelve characters and stops. Everything you have read about what the characters mean is convention, and the convention belongs to whoever generated the value. Industry material describes one layout more often than any other, in which the leading characters carry a date and an hour, commonly a single digit of year, three digits of day-of-year and two digits of hour, with the remaining six characters a sequence that is often just the STAN. Acquirers do generate values of exactly that shape. But no published specification requires it, none of the public sources that set it out is a primary one, and so you must not write a parser that assumes it for traffic you did not generate. Some acquirers pack a terminal identifier in there instead. Some emit an opaque sequence. Some processors’ own integration guides tell the merchant it may put whatever it likes in the field so long as the value comes back unchanged. A parser that assumes structure will one day interpret a letter as a month.

What DE37 buys you that DE11 does not is persistence. The retrieval reference number is generated once and carried forward, so the same value appears on the authorisation, on the advice, and typically on the acquirer’s own clearing record and in the merchant’s settlement report. That makes it the natural join key between the operational world of authorisations and the financial world of settlement, from the merchant’s and acquirer’s point of view. It is the best single number a merchant can hold, and it is the one your gateway should be surfacing to you in its API responses.

It is not, however, an identifier the issuer will necessarily accept as authoritative, and it is not unique across acquirers. Twelve characters and no registry of who may use which range means collisions between institutions are not merely possible but arithmetically inevitable at scheme volumes. Within your acquirer it identifies a transaction. Outside it, it is a strong hint.

India is the clearest illustration of DE37’s second life. The retrieval reference number that appears in an IMPS or UPI transaction — the “UPI reference number” that Indian consumers are told to quote — is a twelve-digit RRN in the ISO 8583 lineage. Oracle’s India IMPS payments documentation states plainly that the system “auto generates the RRN (Retrieval Reference Number) on authorization of the payment transaction” and that “this is a 12-digit number”. The identifier a customer in Bengaluru reads off a UPI app screen and the identifier in DE37 of a card authorisation in Manchester are the same field, from the same standard, doing the same job.

DE38: the authorisation identification response#

DE38 is six alphanumeric characters. It is generated by the issuer, or by the scheme acting on the issuer’s behalf during stand-in processing, and it is present only when the transaction was approved. It travels back in the 0110 response alongside DE39, the response code, which in the 1987 catalogue is two alphanumeric characters, with 00 conventionally denoting approval. (The 2003 edition of the standard renames the field altogether: ISO’s own published contents for ISO 8583-1:2003 list bit 39 as the action code, and dialects built on the later editions generally carry three-digit code values rather than two.)

DE38 is the number printed on the customer’s receipt, labelled “auth code” or “approval code”, which makes it the number you will most often be handed at the start of an investigation. It is also the weakest of the four.

Six alphanumeric characters is a small space. Issuers do not coordinate their generation, and there is no requirement that a given issuer’s codes be unique across time, across cards or across merchants — only that the code be usable by the issuer to identify the approval it granted. The practical rule that follows is that an authorisation code is only meaningful in the presence of the card, the amount and the date. A support agent searching a transaction database on approval code alone, with no other predicate, is running a query that becomes less reliable as the business grows.

There are two further seams worth knowing. When an issuer is unavailable and the scheme approves on its behalf under stand-in processing, the approval code in DE38 was generated by the scheme, not the issuer, and the issuer may have no record of it until the advice reaches them. And in a partial approval, the amount approved is not the amount requested, so an approval code paired with the requested amount rather than the approved amount will not reconcile. DE38 tells you that a yes happened. DE4, DE49 and DE39 tell you what the yes was.

The acquirer reference number#

The acquirer reference number is the one identifier in this chapter that is not created at the point of sale. It comes into existence during clearing, when the acquirer assembles the day’s approved transactions into a settlement file and submits them to the scheme.

On Visa’s side, the BASE II clearing system’s own glossary defines it exactly: “Acquirer Reference Number: A 23-digit identification number associated with every draft and voucher. It consists of a Format Code, BASE Identification Number (BIN), Capture Date, Film Locator, and Check Digit.” Five components, twenty-three digits, and the vocabulary tells you the history — a “film locator” is where the microfilm image of the paper sales draft was filed. The capture date is expressed as a Julian date, which Visa’s glossary defines as “a date expressed as the day’s position in a year rather than in a particular month. The format is YDDD or YYDDD.”

On Mastercard’s side the field is called Acquirer Reference Data and lives in DE31 of the clearing message. Mastercard’s own developer documentation for fraud submission specifies the constraint precisely: the identifier ARN is “Acquirer Reference Number (DE31 in Clearing Message)” and for it “Min Length is 23, Max Length is 23 and Data Type is N”. Exactly twenty-three, numeric, no exceptions.

The check digit at the end is the practically useful part. It is computed from the preceding digits by a defined formula, which means a malformed ARN can be rejected before it costs anyone a research request. It also means that if you are validating ARNs you did not generate, you should validate the check digit rather than the semantics: do not try to parse the BIN and the date out of an ARN and reason about them, because the format code in the first position exists precisely to signal that the remaining layout may differ.

Two properties of the ARN follow from its birth at clearing rather than at authorisation, and both matter enormously in customer support.

The ARN exists if and only if the transaction cleared. No clearing, no ARN. Authorisations that expired, holds that were reversed, declines, and transactions still inside the acquirer’s capture window all have no ARN and never will.

The ARN is the key the dispute process runs on. When an issuer initiates a chargeback, when an acquirer represents it, when a refund is traced across the network, the ARN is what identifies the item. It is also the number a merchant can give a customer that the customer’s own bank can actually act on, which is why “please ask the merchant for the ARN” is the standard advice issuers give. It travels, in a way that a STAN never does.

The scheme’s own key, and why it had to be invented#

By this point the shape of the problem should be obvious. The acquirer owns a number. The issuer owns a number. The terminal owns a number. The clearing file owns a number. Nobody owns a number that is present, unchanged, at every hop, in both the authorisation and the clearing worlds. Card networks worked around this for decades with fuzzy matching on card number, amount, date and merchant.

Both major schemes eventually created an identifier of their own to close the gap.

Visa assigns a Transaction Identifier to each authorisation. As the Merchant Risk Council summarises it, it is “a numeric value up to 15 digits that uniquely identifies the original authorization”, and the industry commonly calls it the Network Transaction Identifier or NTI. Its purpose is to let a later transaction point back at an earlier one — the classic case being a merchant-initiated recurring payment that must reference the original cardholder-authenticated authorisation.

Mastercard’s equivalent is built from the Banknet reference number. In Mastercard’s own field definitions, BRN is the “Banknet Reference Number (DE63, subfield 2 in Dual Message Authorization Message)”, with a minimum length of 6 and maximum of 9, alphanumeric, and the documentation warns explicitly that “DE63, subfield 1 (Financial Network Code) is NOT to be appended”. The composite identifier Mastercard asks merchants to store and echo — the Trace ID — is fifteen positions: positions 1 to 3 the Financial Network Code, positions 4 to 9 the Banknet Reference Number, positions 10 to 13 the settlement date as MMDD, and positions 14 to 15 blank.

Look at what that construction admits. To get an identifier that is stable enough to quote, Mastercard has to combine a network code, a reference number and a date. Three fields, because the reference number alone is six characters and six characters is not enough to be unique. This is the same lesson as the STAN, at a higher level of the stack: identity in payments is almost always composite, and any system that stores a single “transaction ID” column and believes it has captured identity is storing a correlation key and calling it a name.

The complete picture for one card payment#

Putting it together for the £42.60 lunch in Leeds on Tuesday 3 March. These values are illustrative, not real.

That last row is the one merchants forget to design. Your own order identifier is the only number in the table you control, the only one guaranteed to be unique in your own system, and the only one you can attach to a customer record. Every investigation that goes well starts there and moves outward. Every investigation that goes badly starts with a number somebody read off a bank statement.

A customer says they were charged twice#

Here is the order to work in, and why.

Step zero: establish whether there are two charges or one charge and one hold. This resolves the majority of cases and costs nothing. An authorisation that has not cleared appears in a banking app as a pending item and has no ARN. Ask the customer whether both lines are pending, or whether one is pending and one has posted, or whether both have posted. If both are pending and the amounts are identical, the likely cause is a double authorisation at the terminal or an unreversed retry, and the remedy is a reversal, not a refund. Refunding an uncleared authorisation creates a credit that settles while the hold quietly expires, and the customer ends up net up. This mistake is common and expensive.

Step one: collect what the customer actually has. Date, amount, currency, last four digits of the card, the descriptor as it appears on their statement, and the approval code if they have a receipt. Do not ask them for an ARN. Most issuers do not show it in the app, and asking is how a support conversation becomes a complaint.

Step two: find the order in your own system. Search on your merchant order identifier, or on amount plus date plus card token or last four. You are looking for how many order records exist and how many authorisation attempts each one made. This is where genuine double-submits, retried API calls without idempotency, and repeated tap events reveal themselves.

Step three: get the gateway or acquirer record for each attempt. For each attempt you now want DE37, the retrieval reference number, DE38, the approval code, DE39, the response code, and the local date and time. Two approved attempts with different retrieval reference numbers is two authorisations. Two approved attempts with different approval codes and different STANs one minute apart is almost always a terminal double-tap or a customer who tapped again after a slow response.

Step four: check clearing. For each authorisation, does an ARN exist? One ARN means one charge and the second authorisation is a hold. Two ARNs means two charges and one of them needs refunding. Zero ARNs on a same-day query means nothing has cleared yet and you should not conclude anything until the batch closes.

Step five: escalate with the right number to the right party. To your acquirer, quote the ARN if the item cleared and the retrieval reference number if it did not. To the scheme, via your acquirer, the ARN. To the issuer, if the customer is doing the asking, the ARN plus the date and amount. The approval code goes along as corroboration in all three cases and as the primary key in none of them.

What not to do at any step: do not search on STAN alone; do not match on approval code alone; do not assume the gateway’s transaction identifier means anything to the acquirer, because it is the gateway’s private key and typically does not appear in any ISO 8583 field at all; and do not tell the customer a number is “the transaction ID” when it is a correlation key that will be reused by teatime.

The underlying causes are a short list, and each has a signature. Two authorisations seconds apart with sequential STANs: terminal double-submit. Two authorisations minutes apart with different terminal identifiers: the customer tried a second till. An authorisation followed by a larger authorisation with the same retrieval reference lineage: an incremental authorisation, common in hotels and car hire, entirely legitimate. An original amount posting alongside a slightly larger cleared amount: a tip adjustment, where the cleared figure exceeds the authorised one within scheme tolerance. A charge and a matching credit landing days apart: a reversal that arrived after clearing rather than before, which looks like a double charge for as long as it takes the credit to post.

Bank transfers: the reference is not an identifier#

Everything above concerns card rails. Account-to-account transfers have a parallel set of identifiers, and one important structural difference: the field the customer types is not the field the system traces on.

In the United Kingdom, a Bacs Direct Credit or Direct Debit is carried in a Standard 18 file. Open Banking Limited’s mapping of its payment API onto the scheme formats, which cites the Bacs Electronic Funds Transfer file structures document PN5011 and its section on credit and debit payment instructions for bank grade users, lists the Standard 18 fields: field 1 destination sorting code, six characters; field 2 destination account number, eight; field 5 originating sorting code, six; field 6 originating account number, eight; field 8 amount in pence, eleven; field 10 service user’s reference, eighteen; field 11 destination account name, eighteen.

That eighteen-character service user’s reference is the entire space you have to say what a Bacs payment is for. It is what a building society roll number goes in. It is what an invoice number goes in. It is not unique, not validated, not guaranteed to reach any particular system at the far end, and if the sending customer types it wrong nothing anywhere will notice. Eighteen characters is also less than the thirty-five that ISO 20022 allows in a structured remittance reference, so a payment initiated through a modern API with a full-length reference must be either truncated or rejected at the boundary. Open Banking’s specification says exactly that: it is for the account servicing institution “to decide whether to reject the payment-order consent or truncate the field”.

Faster Payments is, perhaps surprisingly to anyone who has only worked on cards, also an ISO 8583 system — a different dialect, using the private-use data elements for its own purposes. Open Banking’s mapping gives the field numbers: field 62 carries the end-to-end reference at 31 characters, field 120 the reference information at 18, field 121 the remittance information at 140, fields 42 and 43 the originating credit institution and customer account number, fields 95 and 35 the beneficiary equivalents, field 118 the beneficiary customer account name at 40, field 61.1 the payment sub-type and field 122 regulatory reporting. Pay.UK publishes an ISO 20022 standards library for FPS describing the recommended conversion of those ISO 8583 messages into ISO 20022.

Note what this does to your mental model of data element numbers. Data element 62 in a card authorisation is a private reserved field that Visa uses for its own purposes. Data element 62 in a Faster Payments message is the end-to-end reference. The number is not the meaning. The number plus the dialect is the meaning, and any library that decodes ISO 8583 without being told which specification it is decoding against is guessing.

CHAPS took the other road. It carried MT103 messages, in which the beneficiary reference sits in field 70 across up to four lines of thirty-five characters, with the code /ROC/ introducing the ordering customer’s reference and /RFB/ introducing a reference for the beneficiary, the latter limited to sixteen characters in practice. In June 2023 the CHAPS high-value payment system migrated to ISO 20022, as the Bank of England records in its own policy statement on mandating enhanced data.

That migration matters here because ISO 20022 finally provides what card rails still lack. A pacs.008 customer credit transfer carries a payment identification block containing several distinct identifiers: an instruction identification, which is point-to-point between one pair of institutions; an end-to-end identification, which the debtor supplies and which must be passed unchanged all the way to the creditor; a transaction identification; and the UETR, the unique end-to-end transaction reference. The UETR is a thirty-six character UUID version 4 as defined by IETF RFC 4122, now superseded by RFC 9562. It is carried in field 121 of the user header block of an MT message and in the payment identification block of a pacs.008, and it has been mandatory on customer credit transfers over Swift’s FIN network since 18 November 2018.

A UETR is what the card world does not have: one value, generated once, unchanged at every hop, unique by construction rather than by convention, and long enough that no two payments will ever collide. If you have wondered why a Swift payment can be tracked end to end and a card payment cannot, the answer is a hundred and twenty-eight bits of randomness against six digits of a wrapping counter.

India: UTR, RRN and what a customer can actually trace#

India runs several rails and each stamps its own identifier, which is why the question “what is my UTR” has more than one correct answer.

For RTGS, the Reserve Bank of India’s own FAQ is unambiguous: “Unique Transaction Reference (UTR) number is a 22-character code used to uniquely identify a transaction in RTGS system.” Twenty-two characters, alphanumeric, generated by the sending bank. The RBI is equally clear about who may use it, noting that customers do not have the facility to track the transaction themselves — the UTR is what the bank quotes to the central bank when it asks about status on the customer’s behalf.

Indian payments material consistently describes a decomposition in which the first four characters are the sending bank’s IFSC prefix, followed by a character denoting the RTGS system, a channel or message-type character, the date, and a sequence. That description is convention rather than published rule: the RBI’s FAQ gives the length and says nothing about the layout, no primary specification of the internal structure is public, and you should not parse it. NEFT references are commonly quoted as sixteen characters with a similar bank-code-then-date-then-sequence shape, again by convention rather than by published rule.

For IMPS and UPI the identifier consumers are told to quote is the twelve-digit retrieval reference number. It is the same DE37 discussed above, because the National Payments Corporation of India’s switch is ISO 8583 derived. A UPI payment additionally carries a transaction identifier assigned by the payment service provider, which is the identifier your app uses internally and which the receiving bank generally cannot resolve.

The practical guidance for anyone building support processes for Indian payments is therefore the mirror image of the card guidance. The twelve-digit RRN is the number both banks can see. The PSP’s transaction identifier is the number only your own systems can see. The UTR is the number that exists for RTGS and NEFT and not for UPI. And in every case the RBI’s structural point holds: the identifier is an input to a request made by a bank, not a self-service tracking code. When a customer says “I have the UTR, why can’t you find it”, the honest answer is that the number identifies the payment inside a system they do not have access to, and so do you unless you are a bank.

Design rules that follow#

Store every identifier you are given, and never overwrite one with another. The STAN, the retrieval reference number, the approval code, the ARN when it arrives, the scheme transaction identifier, the gateway’s own key and your own order identifier are seven different columns, not one. The cost of seven columns is nothing. The cost of having only the one you thought you needed is a research request per customer.

Store them as text, fixed width, with the specification’s width. an 12 means twelve characters, letters permitted, leading zeros significant. n 23 means twenty-three digits, and twenty-three digits will not fit in a 64-bit integer.

Make every lookup key composite by default. STAN plus terminal plus date plus amount. Retrieval reference number plus acquirer. Approval code plus card plus amount plus date. If a query in your support tooling takes a single identifier and returns a single row, ask which identifier it is, because for three of the four in this chapter that query is lying to you.

Generate your own identifier at the earliest possible moment, before the first network call, and put it everywhere you are allowed to. Where the rail gives you a durable customer-visible reference field — the eighteen characters of a Bacs service user’s reference, the thirty-five of an ISO 20022 end-to-end identification — spend it on something you can look up, not on a description of the goods.

And be careful what you tell customers a number means. The one on their receipt is an approval code and it proves that a bank said yes. The one that proves money moved is created hours later by a different institution, and until it exists there is nothing to trace. Both of those statements are true simultaneously, and explaining the difference clearly is most of the job.

28.98 Common wrong ideas#

Wrong: the retrieval reference number is twelve digits. Right: it is an 12, twelve alphanumeric characters whose leading zeros are load-bearing, and any system that stores it as an integer silently destroys it.

Wrong: the leading characters of a retrieval reference number encode a year, a day and an hour, so you can parse them. Right: ISO 8583 specifies no internal structure at all; the common layout is a convention belonging to whoever generated the value, and some acquirers pack a terminal identifier or an opaque sequence in there instead.

Wrong: the approval code identifies the purchase. Right: six alphanumeric characters generated without coordination between issuers say only that a yes happened, and matching on them alone produces false matches at any real volume.

Wrong: the system trace audit number is the transaction identifier. Right: six digits wrap at a million, the sequence is very often per terminal, and Mastercard’s own documentation requires the trace identifier to be quoted alongside the switch serial number because one is not enough.

Wrong: a reversal can carry a fresh trace number. Right: a 0400 must quote the original message’s trace number so the issuer can find and release the hold, and failing to do so is the direct cause of authorisation holds sitting on customers’ statements for a week.

Wrong: every transaction has an acquirer reference number. Right: the ARN is created during clearing, so declines, expired authorisations, reversed holds and anything still inside the capture window have none and never will, and “there is no reference because there is no charge” is often the correct answer.

Wrong: you can parse the bank identification number and the capture date out of an ARN and reason about them. Right: the format code in the first position exists precisely to signal that the remaining layout may differ, so validate the check digit rather than the semantics.

Wrong: data element 62 means the same thing in every ISO 8583 message. Right: it is a private reserved field on card rails and the end-to-end reference in Faster Payments; the number plus the dialect is the meaning, and a decoder not told which specification it is decoding against is guessing.

Wrong: the reference a customer types into a bank transfer is an identifier the system traces on. Right: the eighteen characters of a Bacs service user’s reference are unvalidated free text, shorter than the thirty-five ISO 20022 allows, and the receiving institution may truncate or reject them.

Wrong: a UTR is a self-service tracking code and every Indian payment has one. Right: RTGS has a twenty-two character UTR that a bank quotes on the customer’s behalf, IMPS and UPI use the twelve-digit retrieval reference number, and a UPI payment’s own service-provider identifier is visible only inside that provider.

28.99 Chapter summary in 20 lines#

1. A card payment leaves behind four numbers with four owners, four lifetimes and four jobs, and asking the wrong party for the wrong one gets you a shrug.
2. The system trace audit number in DE11 is six digits assigned by whichever node originates a message and returned unchanged so that the originator can pair the answer with the question.
3. Six digits wrap at a million and the counter is often per terminal, so the same trace number exists simultaneously on every terminal in an estate and was somebody else’s transaction yesterday.
4. Searching on a trace number alone is the commonest analytical error in card operations; the key must be composite, adding terminal or acquirer identity, the local date, and usually the amount and currency.
5. A reversal must quote the original trace number, and because the case in which you most need to reverse is the case in which no response arrived, the original must be stored durably before the request is sent.
6. The retrieval reference number in DE37 is twelve alphanumeric characters created by the acquirer and carried forward into the advice, the clearing record and the merchant’s settlement report.
7. Its leading characters often look like a year, a day of the year and an hour, but no published specification requires that layout, and a parser assuming it will one day interpret a letter as a month.
8. DE37 is the best single number a merchant can hold, but it is unique only within one acquirer, and collisions between institutions are arithmetically inevitable at scheme volumes.
9. The same field has a second life in India, where the twelve-digit retrieval reference number is what an IMPS or UPI customer is told to quote.
10. The authorisation identification response in DE38 is six alphanumeric characters generated by the issuer, or by the scheme standing in for it, and only when the answer was yes.
11. It is the number printed on the receipt and therefore the one a customer hands you first, and it is also the weakest of the four, encoding nothing about the amount, the card, the merchant or the time.
12. The acquirer reference number is not created at the point of sale at all: it is born during clearing, twenty-three digits made of a format code, a bank identification number, a capture date, a film locator and a check digit.
13. Validate that check digit rather than the semantics, because the format code exists to warn that the rest of the layout may differ.
14. The ARN exists if and only if the transaction cleared, and it is the key on which the entire dispute process runs, which is why issuers tell customers to ask the merchant for it.
15. Nobody owns a number that is present, unchanged, at every hop, which is why Visa created a Transaction Identifier and Mastercard assembled a fifteen-position Trace ID from a network code, a Banknet reference and a settlement date.
16. That construction admits the general rule: identity in payments is almost always composite, and a system with one “transaction ID” column is storing a correlation key and calling it a name.
17. When a customer reports being charged twice, establish first whether there are two charges or one charge and one hold, because refunding an uncleared authorisation creates a credit that settles while the hold quietly expires.
18. Then work outward from your own order identifier, the one number you control, through the gateway or acquirer record for each attempt, through clearing, and only then escalate with the right number to the right party.
19. Account-to-account rails have the same problem in different clothes, from an eighteen-character Bacs reference that nothing validates to a Faster Payments dialect in which data element 62 means something entirely different from what it means on card rails.
20. ISO 20022 and Swift’s UETR are what the card world lacks — one value, generated once, unchanged at every hop, unique by construction — which is the whole reason a Swift payment can be tracked end to end and a card payment cannot.

Sources: ISO 8583 data element definitions; Visa BASE II Clearing System Overview glossary; Mastercard Developers field definitions for ARN (DE31), Banknet Reference Number (DE63.2), Trace ID (DE11) and Switch Serial Number (DE63.3); Merchant Risk Council guidance on Visa Transaction Identifier and Mastercard Trace ID; Worldpay ISO 8583 Reference Guide; Open Banking Limited Domestic Payment Message Formats (FPS ISO 8583, Bacs Standard 18 per Bacs PN5011, CHAPS MT103); Pay.UK Faster Payment System ISO 20022 standards library; Bank of England policy statements on ISO 20022 in CHAPS; Reserve Bank of India RTGS FAQ; Oracle India IMPS Payments User Guide; IETF RFC 9562.