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

In Part 7, we followed payment data as it spread into the back office - the reporting and analytics estate where governance, not perimeter defence, was the challenge. Now the lifecycle returns to its most consequential act: actually moving the money.

This is Settlement / Funding, and it carries the highest stakes of any stage in the entire flow. Everything before this has been about data: capturing it, routing it, deciding on it, storing it. Settlement is about funds. Treasury nets what is owed, generates the files that instruct banks to move money, and the network debits issuers and credits acquirers until the merchant is finally paid. A compromise here does not expose a card number. It moves real money to the wrong place, or stops it moving at all.

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 reconciled and reported, we now turn to how funds are actually settled, and to the treasury and messaging systems that are among the highest-value targets in all of finance.

Stage 7: Settlement / Funding - Where the Money Actually Moves

Settlement is the stage where treasury systems, SWIFT and ACH gateways, and settlement servers instruct the movement of funds between institutions, often in high volumes and high values, on predictable schedules. Where earlier stages guarded cardholder data, this stage guards the instruction to pay. And an instruction to pay, if forged, altered, or replayed, is indistinguishable from a legitimate one until the money is gone.

That raises the two defining risks of this stage. The first is integrity: an attacker who can tamper with a settlement file or a treasury configuration can silently redirect funds. The second is availability: an attacker who can encrypt or disable settlement systems - via ransomware, can halt the movement of money entirely, holding an institution's core function hostage. Few stages combine such high value with such operational fragility.

How the Settlement Flow Works

The settlement process typically unfolds in five steps:

1. Treasury nets funds and fees: The amounts owed between parties are calculated and netted.

2. A settlement file is created: A camt.054 or ACH file is generated and sent to the network.

3. The network moves funds: Issuers are debited and the acquirer is credited.

4. The merchant is funded: Credit reaches the merchant, typically within T+1 to T+3 days, or instantly on faster rails.

5. Confirmations are logged: Settlement confirmations are recorded and archived.

The defining security principle here is protecting the integrity and availability of payment instructions. The files must be authentic and unaltered, the systems that produce them must be resilient against disruption, and every instruction must be traceable and recoverable.

The Threats: Where Settlement Goes Wrong

Because settlement concentrates high-value fund movement in treasury and messaging systems on predictable schedules, its threats cluster around fund redirection, message manipulation, credential theft, and operational disruption. The most significant include:

• Ransomware on treasury and settlement servers: Encrypting or disabling the systems that move money, halting settlement and holding a core banking function hostage.

• Configuration tampering to mis-route funds: Altering settlement configuration so that money is credited to attacker-controlled accounts.

• Stolen or compromised SWIFT operator credentials: Using legitimate operator access to issue or approve fraudulent payment instructions.

• camt.054 / ACH file injection or replay: Inserting fraudulent settlement files or replaying legitimate ones to move funds more than once.

• Timing attacks on settlement windows: Exploiting the predictable ACH settlement schedule to slip fraudulent activity through the moment it is least likely to be caught.

The common thread: at settlement, the attacker is after the money itself, and they have two paths to it: corrupt the instruction so funds go to the wrong place, or corrupt the system so funds cannot move at all. Both are catastrophic, and both target the systems an institution can least afford to lose.

The Security Controls: What It Takes to Secure Settlement

Mitigating these threats requires controls focused on resilience, file integrity, adversary simulation, and rehearsed recovery for the highest-value systems in the environment. Effective controls at this stage include:

• Agentic SOC and SOAR-driven monitoring on treasury and SWIFT/ACH gateways for real-time detection and automated containment of threats to fund movement.

• Ransomware simulation and tabletop exercises, including camt.054 replay scenarios, to test both technical defences and the human decision-making a real incident would demand.

• Incident-response plan and readiness audits to confirm the organisation can actually respond when its most critical systems are hit.

• Continuous vulnerability assessment scanning on treasury and settlement infrastructure.

• Red teaming simulating fund-misroute configuration tampering, to validate whether an attacker could actually redirect settlement.

• camt.054 integrity testing after restore, ensuring that recovery from backup does not itself reintroduce tampered or replayed files.

• Security awareness training for treasury and operations staff, whose credentials and actions are a primary target at this stage.

• Data classification services to keep sensitive settlement data identified and protected.

Together, these controls address settlement risk where it lives - in the integrity of payment files, the resilience of treasury systems, the trustworthiness of operator credentials, and the organisation's ability to recover cleanly when the worst happens.

The Compliance Frameworks Governing Settlement

Settlement is governed by standards focused on financial messaging security, the integrity of payment instructions, and the regulation of payment systems themselves. Teams operating at this stage typically need to satisfy:

• PCI DSS v4.0: The foundational standard for protecting cardholder data.

• SWIFT CSCF 2024: The Customer Security Controls Framework governing the security of SWIFT-connected financial messaging infrastructure.

• ISO 20022 (camt.054): The messaging standard underpinning modern settlement files and their structure.

• RBI PSS Act 2007: The Payment and Settlement Systems Act, the regulatory foundation governing payment systems in India.

• PCI S3 v1.2.1: The Software Security Framework governing the software that generates and processes settlement files.

The takeaway is that settlement compliance is financial-infrastructure-centric. The prominence of SWIFT CSCF, ISO 20022, and the RBI PSS Act reflects a stage where the obligations are about the security and integrity of the payment system itself, not merely the data it carries. Compliance here is inseparable from operational resilience: regulators and frameworks alike expect not just that instructions are protected, but that the systems producing them can withstand and recover from attack.

How SISA's Solutions Help Address These Threats

Securing settlement calls for resilience engineering, file-integrity assurance, and rehearsed incident response for the highest-value systems an institution operates. SISA brings these together into an integrated programme built for the secure movement of money:

• Ransomware simulation and tabletop exercises. SISA runs realistic ransomware and camt.054 replay scenarios against treasury and settlement environments, testing both technical defences and the human response a real incident demands.  

• Incident-response readiness and retainer. SISA Sappers – an alite team of DFIR responders help you prepare for, and, if needed, respond to an attack on the systems you can least afford to lose, where recovery speed is everything.  

• Red teaming for fund-misroute scenarios. SISA simulates configuration tampering and settlement redirection to validate whether an attacker could actually move funds to the wrong place.

• camt.054 and settlement-file integrity testing. SISA validates file integrity controls, including integrity checks after restore, so recovery does not reintroduce tampered or replayed instructions. (Interlink: SISA Payment Security services.)

• SWIFT CSCF assessment. SISA helps you meet the Customer Security Controls Framework governing your financial messaging infrastructure.  

• Vulnerability assessment on treasury and gateway infrastructure. Continuous scanning keeps the highest-value systems hardened against emerging weaknesses.

• Security awareness training. SISA’s CPISI certification equips treasury and operations staff to recognise and resist the credential-theft and social-engineering attacks that target them directly.

• SISA ProACT Agentic SOC with SOAR-driven response. Continuous monitoring across treasury and SWIFT/ACH gateways, with automated response to contain fund-misroute and disruption attempts in real time.  

• Compliance and assessment programmes. From PCI DSS v4.0 and SWIFT CSCF through ISO 20022 and the RBI PSS Act, SISA's assessors help you meet the infrastructure- and resilience-focused obligations that govern settlement.  

In the final part of this series, we close the loop: Disputes & Chargebacks - how cardholders contest transactions, how merchants defend them with evidence, and how to secure the dispute portals and forensic processes where the payment lifecycle finally resolves.