Part 7 of a 9-part series on payment security — from card issuance to disputes.

In Part 6, we saw cardholder data accumulate at scale in clearing files and archives, where the risk was volume and persistence. Now that data leaves the payment infrastructure entirely and flows into the back office - into ERP systems, general ledgers, business intelligence dashboards, and data lakes.

This is Reconciliation & Reporting, and it introduces a risk that is easy to underestimate: spread. Up to this point, payment data lived in systems purpose-built to protect it. Here it fans out into the analytics estate — copied into reports, exported for analysis, replicated across BI tools, and pooled into data lakes accessed by teams who never touch the payment rails. The data has never been further from the controls designed to guard it, and it has never been touched by more people.

As a quick reminder, this series maps each stage of the payment lifecycle to its specific threats, the security controls that mitigate them, and the compliance frameworks that govern it. Having covered how transactions are batched and stored, we now turn to how they are matched, reported, and analysed, and how payment data is protected once it spreads into the enterprise.

Stage 6: Reconciliation & Reporting: Where Payment Data Spreads Furthest

Reconciliation is where the business makes sense of its payments. Settlement confirmations are imported, matched against sales, posted to the general ledger, and turned into the reports that leadership, finance, and regulators depend on. Along the way, payment data is extracted, transformed, copied, and pooled - into BI platforms, data warehouses, and data lakes.

Every one of those copies is a new place the data can leak. And crucially, the people with access here are not payment-security specialists. They are analysts, finance staff, and data scientists whose job is to use the data, not guard it. The threat model shifts accordingly: from external attackers targeting infrastructure to insiders and misconfigurations exposing data that has quietly escaped its original controls.

How the Reconciliation Flow Works

The reconciliation process typically unfolds in five steps:

1. Settlement confirmations are imported: Confirmation data is ingested into the ERP.

2. Deposits are matched against sales: Auto-matching runs, and exceptions are queued for review.

3. Ledger entries are posted: Matched transactions are written to the general ledger.

4. Reports are generated: BI and regulatory reports are produced.

5. Data is archived: Logs and extracts are archived to a data lake.

The defining security principle here is governing data as it proliferates. The challenge is no longer protecting a single system; it is knowing where every copy of the data has gone, who can reach it, and whether it should still exist.

The Threats: Where Reconciliation Goes Wrong

Because reconciliation copies payment data into analytics environments accessed by broad, non-specialist audiences, its threats cluster around leakage, misconfiguration, and insider exposure. The most significant include:

• PII leakage in BI exports: Sensitive data slipping into dashboards, reports, and extracts that were never scoped to hold it.

• Exposed storage buckets from wrong ACLs: Misconfigured access controls on data-warehouse and data-lake storage, opening bulk data to the wrong audiences.

• Insider mass-exfiltration from the data warehouse: A trusted user with broad analytics access extracting payment data at volume.

• Mis-routed data to the wrong recipients: Reports and extracts sent to unintended internal or external parties.

The common thread: at reconciliation, the danger is rarely a break-in. It is data leaking outward through the ordinary machinery of analytics - an over-broad permission, an over-shared report, an over-retained extract. The very openness that makes a data lake valuable is what makes it dangerous.

The Security Controls: What It Takes to Secure Reconciliation

Mitigating these threats requires controls focused on data discovery, access governance, privacy engineering, and monitoring the analytics estate where payment data spreads. Effective controls at this stage include:

• Data discovery and classification across the data lake and BI environments, because in analytics estates, no one can reliably tell you where all the payment data has ended up without looking.

• Continuous vulnerability assessment on data-warehouse and BI hosts.

• Agentic SOC and SOAR-driven monitoring on data-warehouse and BI hosts for real-time detection and automated containment.

• Red teaming simulating mass-exfiltration and wrong-bucket ACL scenarios, to prove whether bulk analytics data could actually be extracted or exposed.

• Privacy services (DPIA, RoPA, and retention policy) to formally govern what data is held, why, and for how long.

• Log exfiltration and tamper testing from the data warehouse, to validate that extraction attempts are both prevented and detectable.

• Threat modelling of mis-routed data to design out the report- and extract-routing errors that quietly send data to the wrong place.

• Court-admissible log pipeline design so that, if data does leak, the evidentiary trail holds up under scrutiny.

The Compliance Frameworks Governing Reconciliation

Reconciliation is where privacy regulation becomes as important as payment-specific standards, because the data now includes personal information spread across general-purpose systems. Teams operating at this stage typically need to satisfy:

• PCI DSS v4.0: The foundational standard for protecting cardholder data wherever it resides, including analytics environments.

• GDPR: Governing the processing of personal data of EU data subjects, with strict requirements on purpose, minimisation, and retention.

• India DPDP Act 2023: India's Digital Personal Data Protection Act, governing personal data processing and obligations to data principals.

• SOC 2 (Security & Confidentiality): Attesting to the controls protecting data within service environments.

• PCI S3 v1.2.1: The Software Security Framework governing the software that processes and reports on payment data.

The takeaway is that reconciliation compliance is privacy-centric. This is the stage where GDPR and the DPDP Act carry as much weight as PCI DSS, because payment data has now mingled with personal data across systems built for insight, not protection, and the obligations around minimisation, purpose limitation, and retention become central rather than peripheral.

How SISA's Solutions Help Address These Threats

Securing reconciliation calls for data-discovery capability that reaches into sprawling analytics estates, privacy engineering, and monitoring tuned to insider and misconfiguration risk. SISA brings these together into an integrated programme built for payment data once it enters the enterprise:

• SISA Radar for data discovery and classification: Radar maps where payment and personal data have spread across data lakes, warehouses, and BI environments - answering the question most organisations cannot: where has all the data actually gone?

• Data privacy services (DPIA, RoPA, and retention): SISA formally governs what data is held, on what basis, and for how long - directly addressing GDPR and DPDP Act obligations and shrinking the analytics footprint over time.

• Access governance and configuration review: SISA reviews storage ACLs and access models across the analytics estate, closing the misconfigurations that expose bulk data to the wrong audiences.

• Red teaming for exfiltration scenarios: SISA simulates insider mass-exfiltration and wrong-bucket ACL exposure to prove whether your analytics controls genuinely hold.

• Vulnerability assessment on DW and BI hosts: Continuous scanning keeps the analytics infrastructure hardened as it grows and changes.  

• SISA ProACT Agentic SOC with SOAR-driven response: Continuous monitoring across data-warehouse and BI hosts, with automated response to contain exfiltration and anomalous access in real time.

• Compliance and assessment programmes. From PCI DSS v4.0 through GDPR, the DPDP Act, and SOC 2, SISA's assessors help you meet the privacy- and confidentiality-focused obligations that govern this stage.  

In the next part of this series, we return to the movement of money itself: Settlement / Funding: how treasury nets funds, and how to secure the high-value settlement systems that are a prime target for ransomware and fund-misrouting attacks.