SWIFT CSP Compliance in India: Attestation Guide for Banks

Most banks in India treat the SWIFT Customer Security Programme attestation like a tax return. Someone in the treasury back office logs into the KYC-SA portal in November, ticks the boxes green, uploads a two-year-old assessment report, and moves on. Nobody in the room has actually walked the payment operator's terminal or checked whether the jump server they swear exists is still switched on.

Then the 2016 Bangladesh Bank heist gets mentioned in an RBI inspection, and suddenly everyone remembers that SWIFT sits closer to real money than almost any other system in the bank. USD 81 million left Dhaka through fraudulent SWIFT messages. The attackers did not break SWIFT's network. They broke the local operating environment around it — the exact thing the CSP was built to force you to secure. If your attestation is a box-ticking exercise, you are attesting to a control set you have never verified. That is the gap this guide is about.

The Customer Security Programme, or CSP, is SWIFT's mandatory security framework for every institution connected to its network. The heart of it is the Customer Security Controls Framework, the CSCF, which is published fresh every year (the CSCF v2024 and v2025 versions are what most Indian banks are assessing against right now). Each year you must submit an attestation against the current version through the KYC-Security Attestation portal, known as KYC-SA.

The framework groups controls under three objectives and seven principles: secure your environment, know and limit access, and detect and respond. Controls are split into mandatory and advisory. You must attest compliance against all mandatory controls that apply to your SWIFT architecture type. Advisory controls are strongly encouraged and, in practice, examiners increasingly expect them too.

Two things trip Indian banks up immediately. First, the attestation must be supported by an independent assessment — you cannot just self-declare any more. Second, your obligations depend entirely on your architecture type, and most banks mis-classify their own architecture.

Before you look at a single control, you have to know which architecture type you are. This determines how many controls apply and where your CSP scope starts and stops. Get this wrong and every downstream decision is wrong.

The number of applicable mandatory controls climbs as you move from B towards A1. An A1 bank running its own Alliance Access and Alliance Gateway on-premises carries the fullest control burden — hardening, network segmentation, the general operator PC, back-office data flow security, the lot. A type B institution can offload most technical controls to its provider but still owns operator-side controls and must obtain the provider's own attestation.

The single most common error we see in the audit room: a bank declares itself A4 or B to shrink its scope, while a live Alliance Access instance is sitting in its own data centre. The moment an assessor sees that server, the architecture is A1 and half the attestation is now unsupported. Classify honestly, or the assessment collapses.

Since the 2021 attestation cycle, SWIFT has required that your attestation be backed by an independent assessment. You get two routes. An internal independent assessment, performed by a function within your bank that is organisationally independent of the team that runs SWIFT (typically internal audit or a second-line risk function). Or an external independent assessment, performed by a qualified third-party cyber security firm.

For Indian banks the practical answer is usually external, for three reasons. RBI inspection teams give more weight to a named external assessor. Your internal audit function rarely has hands-on SWIFT hardening expertise. And a CERT-In empanelled auditor's report doubles up neatly with your other regulatory obligations. The assessor must be competent in the CSCF and independent of the assessed controls — a firm that also implemented your SWIFT hardening cannot then assess it.

On paper there are 30-odd controls. In the room, the same handful sink attestation after attestation. Here is where the evidence is thinnest for Indian banks specifically.

The mandate is a segregated SWIFT zone, separated from the general enterprise network. What we find instead is a flat network where the Alliance Access server can reach, and be reached from, the general LAN. There is a firewall, but its rule set has an any-any rule from three years ago that nobody dares touch. The control fails not because segmentation is absent but because the rule base was never reviewed against the actual data flows.

Least privilege on the SWIFT servers. In reality, the same domain admin account that patches the print server also administers the Alliance Gateway. Shared local accounts, no individual accountability, service accounts with interactive login rights. When we ask who logged into the messaging interface at 02:00 on a given night, the answer is a shared account name. That is an audit failure and, more importantly, a heist waiting to happen.

The link between your back-office application and the SWIFT interface must be confidential and integrity-protected. Banks routinely run this over an internal network in clear text because it is inside the perimeter. The CSCF does not care that it is internal. Encrypt it or compensate and document the compensating control.

Anti-malware, software integrity, database integrity, and centralised logging on the SWIFT-related components. The gap here is almost always logging. Logs exist on the server but never leave it, so an attacker who owns the box owns the evidence too. The control requires logs captured to a system the SWIFT operator cannot tamper with — usually your SIEM. If your SIEM is not ingesting Alliance Access and Gateway logs, 6.4 is not met.

The advisory-turned-expected controls. Restricting outbound internet from the general operator PC is where a lot of banks quietly fail. The operator's PC that accesses SWIFT also browses the web and reads email. That machine is your single richest attack surface, and the CSCF explicitly wants it isolated.

Let me walk you through a real shape of engagement, anonymised. A mid-size private sector bank in Mumbai, architecture A1, calls us six weeks before its attestation deadline because internal audit flagged that last year's self-attestation had no supporting evidence.

Day one, we ask for the network diagram showing the SWIFT zone. The diagram they hand over is the target state from a 2022 project. The live environment is different: a second Alliance Access instance was spun up for a DR test and never decommissioned. It is on the general LAN, patched to nobody's schedule, and it can send live messages. That single finding reclassifies their risk overnight and becomes the top remediation item.

Day three, we sit with the payment operator and ask her to log in. She uses a shared operator ID. There is no MFA. Control 4.1 fails on the spot. We pull the Gateway logs; they exist locally but the SIEM has no feed. Control 6.4 fails. By the end of week one we have a findings register with eleven items, four of them mandatory-control failures that block a clean attestation.

The bank cannot honestly attest full compliance yet, so it attests with the failures declared and a documented remediation plan with dates — which is permitted and far safer than a green tick that an RBI inspection later punctures. Over the next four weeks they decommission the rogue server, enforce individual operator accounts with MFA, and pipe SWIFT logs into the SIEM. The re-test closes the mandatory gaps. The attestation goes in supported and defensible.

CSP is a SWIFT requirement, not an RBI one — but in India the two are inseparable in practice. The RBI's cyber security framework for banks (the June 2016 circular and the graded SOC/security operations expectations that followed) covers the same ground: network segmentation, privileged access, logging, incident response. A well-run CSP assessment feeds directly into your RBI compliance evidence and your CERT-In obligations.

One consequence worth stating plainly: under the CERT-In directions of 2022, a SWIFT-related security incident is a reportable cyber incident and must be reported within six hours of detection. If your CSP incident-response control (7.1) has no SWIFT-specific playbook that names the six-hour CERT-In clock, you have a control that looks compliant on paper and fails the moment it is needed.

Banks ask us for a number before they ask for anything else, so here it is, with the caveat that architecture type and estate size swing it heavily.

On timeline, plan a first full assessment across six to ten weeks: scoping and architecture validation, evidence collection, control testing, findings and re-test, then completion letter. Do not start six weeks before the KYC-SA deadline — that is the mistake almost every bank makes, and it forces you either to attest with open gaps or to rush the evidence.

The CSP was written in the shadow of a real heist where the attackers never touched SWIFT's own network — they walked in through a poorly secured local environment and a payment operator's trust. Your attestation is only worth the evidence underneath it. A green tick with nothing behind it is not compliance; it is a liability you have signed your name to, and an RBI inspection or a genuine incident will find the hollow space fast.

Treat the attestation as the by-product of a control set you have actually verified, not the goal. Walk the terminal. Pull the logs. Find the rogue server. If you would value a second set of hands from people who have sat on the wrong side of these findings, CyberSigma's CERT-In empanelled auditors and PCI QSAs do SWIFT CSP assessments hands-on, and we would rather find your rogue server than let an examiner find it for you.