This page describes how bank transactions are identified in various banking protocols and data formats.
Why is transaction identification necessary? When a client downloads the transaction history from some data source, it has to know whether a transaction is new, or whether the transaction is already part of the client’s local records.
The camt52/53/54 messages defined by ISO 20022 do not have a mandatory transaction identifier. Instead it defines a handful of optional references.
Two identifiers seem to be used in practice: The Account Servicer Reference and the Entry Reference. Of these, only the Account Servicer Reference seems to be useful for transaction identification.
The Account Servicer Reference is assigned by the bank to a transaction. In practice, all banks assign the same Account Servicer Reference to the same transaction showing up in camt52 (the account report), camt53 (the account statement) and camt53 (credit notifications).
The Account Servicer Reference is assigned by the bank that reports the transaction, and does not serve as a globally unique identifier for the transaction.
However, in rare cases, a transaction can be reported that does not yet have an Account Servicer Reference assigned to it by the bank yet. This can happen when the bank only received a (SWIFT) pre-notification for the transaction, but decides to already pass on this information to the customer. In this case, banks seem to assign an Entry Reference to the corresponding entry.
Most other transactions, however, do not have an Entry Reference assigned to it. Some banks document that the Entry Reference is only unique within one report for one account.
OFX assigns a transaction identifier to each reported transactions, allowing the client to know which transactions it has already seen.
Sometimes the same bank can offer multiple ways to download transactions. In Germany, most banks offer EBICS and FinTS access, which delivers transactions in the camt.52/53 format. However, some also offer access via PSD2 APIs and completely custom APIs.
Two APIs from the same bank do not necessarily need to support the same transaction identification scheme. This could lead to the same transaction showing up multiple times in the account transaction history, which is clearly bad!
LibEuFin intends to solve this problem in the following ways:
In the future, this might be extended to be less restrictive: