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

In Part 5, we saw capture turn an approval into a claimed amount and found that the risk there lived in business logic: individual transactions manipulated one at a time. Now the lifecycle changes shape entirely. Transactions stop being individual events and become records in a file.

This is Clearing, and it introduces a risk profile the previous stages simply do not have: scale. A single clearing file can carry thousands or millions of transactions. It is written to storage, transmitted between organisations, ingested by an issuer, and then archived for years to satisfy audit requirements. Where earlier stages protected data in motion or data in use, clearing is where cardholder data accumulates and persists - and where one misconfigured storage bucket can expose more card data than any point-of-sale compromise ever would.

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 a single transaction is executed, we now turn to how transactions are batched, exchanged, and stored at volume.

Stage 5: Clearing — Where Cardholder Data Accumulates at Scale

Clearing is the reconciliation of what was authorised against what is actually owed. The gateway or Order Management System (OMS) assembles transaction records into an encrypted clearing file, which travels to the acquirer and onward through the network to the issuer, who validates it and returns a response file. The batches are then archived.

Every element of that description carries risk. Files sit at rest before and after transmission. They move between organisations over Secure File Transfer Protocol (SFTP) or API. They are retained for years to satisfy audit obligations. And they contain cardholder data in bulk. The attacker's economics change completely here: rather than intercepting one transaction at a time, they can target a single file - or a single storage bucket - and obtain everything at once.

How the Clearing Flow Works

The clearing process typically unfolds in five steps:

1. The clearing file is built. The gateway or OMS assembles transaction records into an encrypted clearing file.

2. The file is transmitted. It is sent via SFTP or API to the acquirer, and onward to the network.

3. The issuer validates. The issuer's clearing host ingests the file and validates its contents.

4. A response file returns. Validation results and exceptions travel back along the chain.

5. Batches are archived. Files are retained for audit and dispute purposes.

The defining security principle here is protecting data at rest and in bulk. Encryption in transit is necessary but not sufficient - the file must be protected before it is sent, after it is received, and for the entire retention period that follows.

The Threats: Where Clearing Goes Wrong

Because clearing concentrates cardholder data into files that are stored, transferred, and retained, its threats cluster around data exposure at rest, interception in transit, and manipulation of file contents. The most significant include:

• Plain-text PAN in storage buckets: Unencrypted or improperly masked card data sitting in S3 and similar storage, often in archives no one has reviewed in years.

• Batch-file interception in transit: Capturing clearing files as they move between organisations over SFTP or API.

• Token reversal attacks: Attempting to recover original PANs from tokenised or masked values.

• Amount alteration in batch files: Modifying transaction amounts within a batch to redirect or inflate value at scale.

The common thread: at clearing, the prize is volume. A successful attack here does not compromise a transaction; it compromises a portfolio. And because archived files are often forgotten, the exposure can persist silently for years after the transactions themselves have settled.

The Security Controls: What It Takes to Secure Clearing

Mitigating these threats requires controls focused on data discovery, encryption enforcement, file integrity, and testing the infrastructure that stores and transfers batches. Effective controls at this stage include:

• Data discovery and classification across batch archives to proactively hunt for plain-text PAN in storage and archives.

• Token and mask integrity verification to confirm that tokenisation and masking are applied correctly and consistently.

• PGP / GPG* encryption enforcement for clearing files in transit, ensuring files are protected independently of the transport channel.

• SFTP penetration testing and continuous vulnerability scanning on batch servers, which are frequently long-lived and under-patched.

• Agentic SOC and SOAR-driven monitoring on batch servers for real-time detection and automated containment.

• Red teaming simulating batch interception and amount-alteration scenarios to validate file integrity controls.

• Quarterly PCI technical health-checks to keep clearing infrastructure aligned with evolving requirements.

• Exfiltration testing via batch manipulation to prove whether bulk data could actually be extracted undetected.

• BIN and Luhn mask-verification on masked PANs to confirm that masking genuinely renders data unrecoverable.

The Compliance Frameworks Governing Clearing

Clearing is governed by standards focused on protecting stored cardholder data and the cryptographic controls that render it unreadable. Teams operating at this stage typically need to satisfy:

• PCI DSS v4.0:  The foundational standard, with particular weight on the requirements governing stored cardholder data, encryption, and retention.

• PCI PIN v3.1: Requirements pertaining to secure PIN management and the keys that protect it.

• PCI S3 v1.2.1: The framework governing the software that builds, transmits, and processes clearing files.

The takeaway is that clearing compliance centres on data at rest. PCI DSS requirements around storage, encryption, masking, and retention are at their most consequential here, and retention policy becomes a security control in its own right, because every batch kept longer than necessary is additional exposure.

How SISA's Solutions Help Address These Threats

Securing clearing calls for genuine data-discovery capability, cryptographic enforcement, and adversary simulation aimed at bulk data exfiltration. SISA brings these together into an integrated programme built for payment data at rest and at scale.

• SISA Radar for data discovery and classification. SISA Radar hunts for plain-text PAN across batch archives, storage buckets, and file-transfer paths, surfacing the forgotten data that drives the largest clearing-stage exposures, and bringing hard clarity to PCI scope.

• Token and mask integrity verification. SISA validates that tokenisation and masking are correctly applied, including BIN and Luhn verification.  

• Encryption enforcement for file transfers. SISA reviews and hardens PGP/GPG enforcement for clearing files, ensuring protection travels with the file rather than depending on the channel.  

• SFTP and batch-server penetration testing. SISA tests the long-lived, often under-patched infrastructure that stores and transfers batches, backed by continuous vulnerability scanning.  

• Red teaming for batch attacks. SISA simulates batch interception, amount alteration, and bulk exfiltration to prove whether your file integrity and detection controls genuinely hold.

• Quarterly PCI technical health-checks. SISA keeps clearing infrastructure continuously aligned with PCI requirements rather than assessed once a year.  

• SISA ProACT Agentic SOC with SOAR-driven response. Continuous monitoring across batch servers, with automated response to contain exfiltration attempts and anomalous file access in real time.  

• Data privacy and retention advisory. SISA helps establish retention policies that shrink your data footprint - the single most effective long-term control at this stage.

In the next part of this series, we follow the data into the back office: Reconciliation & Reporting - how settlement confirmations are matched, posted to the general ledger, and fed into BI and data-lake environments, and how to secure the analytics estate.

*PGP (Pretty Good Privacy) - created in 1991, it is a proprietary, copyrighted encryption program owned by Broadcom; GPG (GNU Privacy Guard) - created in 1999, it is an open-source, free alternative modeled after PGP.