Data Lineage, Retention and Auditability

Data lineage records the full journey of every field in a payment, from its source to its final destination. It shows that the debtor name came from the online banking session of Emma Wilson at 9 42 in the morning on 5 November 2026, that the BIC was derived from the IBAN by the enrichment service, and that the exchange rate came from the treasury rate feed at 9 43 in the morning. It also shows every transformation, such as the conversion of a date from 06/11/2026 to 2026-11-06, and every system that touched the payment. When a payment is questioned, lineage lets an investigator follow the value backwards instead of guessing which system changed it. The audit trail records who did what, when, and why, for every material event in the life of a payment. It records the customer who created the instruction, the operator who released it, the second approver who authorised a payment above GBP 50,000, the sanctions officer who cleared a false alert, and the system that rejected a payment for an invalid IBAN. Each entry carries a timestamp with the time zone, the user identifier, the channel, and the before and after values for any change. An audit trail that only records the final state is not enough, because it cannot explain how the payment reached that state or who was responsible at each step. Retention rules decide how long payment data must be kept, and they vary by country and by record type. In the United Kingdom, payment records and anti money laundering evidence are commonly kept for at least five years after the end of the customer relationship, and many banks keep them for seven to ten years to cover tax, dispute, and litigation needs. Transaction records, screening decisions, and customer instructions must all be kept together, because a screening decision without the payment it relates to is meaningless. Retention applies to the canonical record, the source message, and the target message, so the bank can prove what it received and what it sent. A complete audit trail makes incident investigation fast and factual. Suppose a creditor in Singapore reports that a payment of USD 48,200.50 arrived as USD 48,175.50, a difference of USD 25.00. The investigator opens the canonical record, sees the instructed amount, the charge of USD 25.00, the charge bearer, and the time the charge was applied. The lineage shows that the charge came from the agreed tariff for that customer, and the audit trail shows that no operator changed the amount after release. The bank can answer the creditor in minutes, with evidence, instead of opening a case that takes days of manual searching across five systems. Auditability must be designed into the model from the start, not added after the system is built. That means every field has an owner, every change has a reason code, every derived value records its source, and every message sent to another bank is stored exactly as it was sent. It also means that corrections are made by creating a new version of the record, never by overwriting the old one, so the history remains visible. A bank that can show the original instruction, the enriched record, the released message, and the settlement confirmation for a payment of EUR 250,000 will pass an audit with confidence, while a bank that can only show the final message will struggle to explain its own decisions.