There can be cases where an already processed transaction changes in its attributes, e.g.
counter_party. For example a credit card transaction for a car rental is listed as processed but is only fully processed 2 weeks after it was first listed. This will likely result in a new
If you update the transaction history and come across a new
transaction_id in a date range you previous already processed then this can either be
- a newly processed transaction or
- an already processed transaction with a changed
The best way to distinguish between these two cases is to compare the apparently new transaction with already processed transactions on your side from the same day (
Say you compare the new transaction (
new) with an existing transaction (
existing) from the same day based on the
- recipient (
- amount (
- bank references (
existing.amount but the
transaction_id is different the transactions might still be the same. This follows the idea that a transaction on the same date to the same recipient for the same amount is rather unlikely. You can further compare
existing.bank_references and search for a match amongst the 3 different types of references (note: not all types are always available). If that is the case you can almost certainly say that
new is an already existing transaction with a changed
transaction_id. We recommend to transform any reference into lower case and remove white-spaces before comparing them.
Therefore you should replace or merge the existing transaction with the new transaction.
Banks do not always provide consistent ids for their transactions and so we try our best to compensate for that by generating a
transaction_id. But since we don't store transaction data, we can't compare them across requests, sessions or consents. The
transaction_id we provide is generated on-the-fly and mostly based on the
transaction.reference and therefore changes if the reference changes.