Transaction Reference Number

A transaction reference number (TRN) is an identifier that a sending party assigns to a payment or other financial message so that it can recognise and trace that transaction in its own records. In SWIFT MT messages it is carried in field 20, which in the MT103 customer credit transfer is labelled the sender's reference. The number is chosen by the sender, must be unique within its own system for the relevant period, and is quoted back by other parties in replies, queries and statements.

A TRN is often confused with the unique end-to-end transaction reference (UETR). The key difference is scope. A TRN is the sender's own reference and normally changes at each step, because every bank in a payment chain sends a new message with a reference of its own. A UETR is a globally unique code created once at the start of a payment and carried unchanged by every bank in the chain, which is what makes end-to-end tracking possible.

When you post a parcel, the counter clerk gives you a receipt number. It is meaningful to that post office: if you go back with a question, they can find your parcel in their system. But if the parcel passes to a courier in another country, the courier may label it with its own number. Each handler has a reference that works for them, and the parcel can collect several along the way.

A transaction reference number is the bank's version of that receipt number. The bank that sends a payment message gives it a reference so it can find the message again and so the receiving bank can quote it back. A separate tracking code that stays the same from start to finish, the UETR, does the job of following the whole journey.

In the SWIFT MT standard, field 20 appears in most message types and carries the sender's reference. In the MT103 it is called the sender's reference; in many other messages, such as the MT202 bank-to-bank transfer, it is called the transaction reference number. Field 20 holds up to 16 characters and must follow formatting rules, for example not starting or ending with a slash. The sending bank decides its own numbering scheme, often encoding the branch, date or system that produced the message.

When a bank replies to or acts on a message, it usually quotes the original reference in field 21, the related reference. A cover payment sent as an MT202 COV, for instance, quotes the field 20 reference of the underlying MT103, which helps the beneficiary bank match the cover to the customer payment. Account statements also show references so that the account holder can match entries against its own records.

ISO 20022 payment messages separate the different jobs a reference can do. In a pacs.008 credit transfer, the main identifiers are:

• Instruction identification. Assigned by the instructing bank for the point-to-point relationship with the next bank, and closest in purpose to the MT field 20 reference.
• End-to-end identification. Assigned by the payer and passed unchanged to the payee, so the payee can match the payment to an invoice or order; see end-to-end transaction reference.
• Transaction identification. Assigned by the first instructing bank and passed unchanged along the interbank chain.
• UETR. A universally unique identifier in a standard 36-character format, carried unchanged from the first bank to the last.

As cross-border payments moved from MT to ISO 20022 messages, banks have had to map their old field 20 references into these fields. The structured approach makes it clearer which reference belongs to whom.

• Investigations. When a payment is delayed or disputed, banks raise a payment investigation quoting the TRN and the UETR so the counterparty can find the message quickly.
• Reconciliation. Operations teams use references to match outgoing messages with confirmations and account entries during payment reconciliation, alongside payment reference matching against customers' own references.
• Cancellations and amendments. A request to cancel or amend a message must identify it, normally by quoting its original reference.
• Record-keeping. TRNs are stored with each message in a payment information repository or archive so that the bank can retrieve it years later.
• Customer tracing. Banks often give customers a reference number for an international wire transfer. Depending on the bank this may be the TRN, the UETR or another internal number, so customers asked to trace a payment are best advised to request the UETR.

Other payment systems have their own equivalents. Fedwire messages carry input message accountability data (IMAD) assigned when the message enters the system, alongside the sender's own reference. Domestic clearing systems and card networks likewise assign identifiers at various stages. In every case the useful question is who assigned a reference and whether it changes along the way. A reference unique only to one bank, like a TRN, serves that bank's own processing; a reference that travels unchanged, like the UETR, is what SWIFT gpi relies on to show payment status across the whole chain.

• Swift
• ISO 20022