Reconciliation Data as Audit Trails: What Regulators and Finance Teams Both Need

Reconciliation data and audit trail data are usually treated as separate systems by different teams. Finance owns reconciliation. Compliance owns audit trails. Both generate data about the same transactions, but with different structures, different retention policies, and different query patterns.

The separation made sense when these were manual processes. Finance ran reconciliation at month-end. Compliance kept paper records in binders that got pulled out when an auditor arrived. The two functions did not need to talk to each other in real time.

In a modern payment platform, this separation creates unnecessary work and genuine compliance risk. The data that satisfies a regulator's transaction history request and the data that closes your books come from the same source: the payment system. Designing a single data model that serves both audiences from the start is easier than retrofitting two separate systems into compatibility later.

What finance teams need from reconciliation data

Finance teams need to answer a specific set of questions, reliably, within a predictable time window. Did every transaction that we expected to settle actually settle? Are there discrepancies between what we recorded internally and what the provider reports? What is our open balance at any given moment?

To answer these questions, the reconciliation data model needs to support: matching internal transaction records to external settlement records by identifier, surfacing unmatched records on both sides, tracking the settlement status of each transaction (pending, settled, in dispute), and aggregating across multiple providers into a consolidated view.

The time dimension matters. Finance teams typically run daily close for operational visibility and monthly close for accounting. The data model needs to support point-in-time queries: what was our reconciliation state as of this specific date? This is harder to implement than it sounds, because you need to capture the state of each transaction at a specific moment, not just its final state.

Correctability is also a requirement. Reconciliation records occasionally need to be corrected when an error is identified. But the correction process should preserve the original record. Finance needs to see not just the current state but the history of how the state changed, including who made a change and when.

What regulators need from audit trail data

Regulatory audit trail requirements under the MAS framework focus on a somewhat different set of questions. For a Singapore-licensed payment service provider, MAS examination requests typically ask: show us all transactions above a certain threshold in a given period, show us all transactions involving a specific counterparty, show us your AML screening records for specific transactions, and show us the evidence trail for a specific payment decision.

The key difference from finance reconciliation is that regulatory audit trails must be immutable. Finance reconciliation records can be corrected (with history). Regulatory audit records cannot be altered. They must reflect exactly what was recorded at the time of the event, with a timestamp that is reliable enough to establish sequence of events. The five-year retention requirement under MAS rules means these records need to be stored in a way that is not vulnerable to deletion, even accidental, over that period.

A regulatory audit trail also needs to capture more event types than a reconciliation record. A reconciliation record covers the financial outcome: what was submitted, what settled, and whether they match. A regulatory audit trail covers the decision process: what screening checks were run before submission, what the results were, which provider was selected and why, and what happened at each state transition. This is the data that lets you demonstrate to a regulator that you followed the required procedure, not just that the transaction reached a terminal state.

Where the data models diverge and where they can share

The practical question is how much of the data model can be shared between reconciliation and audit trail functions. The answer is: more than most platforms assume, but not everything.

The core payment event record is shared. Transaction ID, amount, currency, counterparty identifiers, timestamp, provider, and status are fields that both reconciliation and audit trail need. Writing this once and reading it for both purposes is strictly better than writing it twice in different schemas.

The reconciliation match record is primarily a finance concern. When a settlement event arrives from the provider, the match record captures: which internal transaction it matches, what the provider reported (amount, timestamp, their identifier), and whether the amounts reconcile. Compliance needs to know that a settlement occurred, but the detailed match state is more a finance workflow concern than a regulatory one.

The compliance screening record is primarily a regulatory concern. Before a payment is submitted to a provider, it is screened against sanctions lists and AML rules. The screening record captures what was checked, what the input data was, what the result was, and which version of the screening rules was active at the time. Finance does not typically use this data, but a regulator absolutely will.

The state transition history is shared. Every time a transaction changes state, from created to submitted to settled (or failed or disputed), that state change should be recorded as an append-only log entry. Finance uses this to understand what happened to a given transaction. Compliance uses this to establish the sequence of events in an investigation.

Designing for immutability without losing operational flexibility

The tension in the data model is between immutability (required for audit integrity) and the operational reality that records sometimes need correction. Reconciliation records get corrected when a matching error is found. Payment records sometimes have metadata updated when additional information arrives.

The pattern that resolves this is event sourcing for the audit layer, with a materialized view for the operational layer. The event log is append-only and immutable. Every correction is a new event: "at this timestamp, with this reason, the following correction was applied." The operational view reflects the current state after all corrections. But the event log always shows what the original state was and when and why it changed.

This is not a new pattern. It is how accounting ledgers have worked for centuries and how banking core systems implement transaction records. The difference is making it explicit in the data model rather than relying on soft conventions about not updating records.

Query patterns and retention

The data retention and query pattern requirements for regulatory audit trails are more demanding than for operational reconciliation data. Operational reconciliation primarily queries by date range and status. Regulatory audit trails need to support queries by counterparty identifier, by screening result, by transaction amount range, and by state transition type, across potentially years of data.

In practice, this means that what looks like one data store often needs to be two: a hot store for operational reconciliation that supports fast queries over recent data, and a cold store for regulatory audit records that supports broader queries with higher latency. The two stores stay in sync because they consume from the same event log.

The five-year retention requirement for regulatory data under MAS rules does not mean you need five years of data in a fast query tier. It means you need five years of data in a retrievable, queryable format. A well-structured archive that can answer a regulatory request within 48 hours meets the requirement. A fast operational store that auto-deletes records after 90 days does not, even if the data is technically in a backup somewhere.

The one thing not to do

The temptation when building this is to designate reconciliation as the source of truth for regulatory purposes. Finance already has reconciliation data. The data covers the same transactions. Why not just extend it?

The problem is that the reconciliation data model is optimized for matching and discrepancy detection, not for the full event capture that regulatory purposes require. It does not capture pre-submission screening results. It does not capture routing decision logic. It does not naturally support append-only immutability because reconciliation records legitimately change state during the matching process.

Extending reconciliation to serve regulatory purposes tends to produce a data model that serves neither purpose well. The better approach is a shared event log that both the reconciliation system and the audit trail system read from, with each maintaining a view that is appropriate for its specific consumers. The shared foundation is the guarantee that both systems are reading from the same authoritative source of truth about what happened.