The global financial system moves over $5 trillion in payments every single business day across the SWIFT network. Securing that infrastructure is not a single institution’s problem — it is a collective one, shared across more than 11,000 financial institutions in over 200 countries, each representing a potential point of failure. A decade ago, the SWIFT Customer Security Programme set out to address that reality with a unified, mandatory framework for endpoint security across the entire network. What followed was one of the most significant coordinated cybersecurity initiatives in financial history — reshaping compliance obligations, regulatory expectations, and security investment priorities for institutions from the world’s largest central banks to the smallest regional lenders. Ten years on, the programme has measurably raised the global baseline. It has also revealed just how much further the industry still has to go.
In February 2016, a highly organised threat actor — later attributed by the FBI and international investigators to the Lazarus Group, a North Korean state-affiliated hacking collective — had spent months inside the network of Bangladesh Bank. They had entered through a spear-phishing email sent to a bank employee: a fake job application, complete with a resume and cover letter hosted on an attacker-controlled website.
When the employee downloaded the documents, they installed malware that gave the attackers an initial foothold. Over the months that followed, the attackers moved laterally through the network, learned the bank’s internal systems and operational rhythms, and positioned themselves to submit fraudulent payment orders through SWIFT that would read as entirely legitimate.
Bangladesh Bank Heist: The Decade That Changed Financial Security
World Informatix Cyber Security led the incident response and forensic investigation at the Bangladesh Bank following the 2016 attack. Our 2026 Whitepaper provides a retrospective look of the landmark incident, and discusses industry and threat landscape trends.
You can download the Full Whitepaper Here.
The attack was not a breach of SWIFT’s own infrastructure. SWIFT’s messaging network performed exactly as designed. The fraud succeeded because the attackers had compromised the bank’s local SWIFT terminal environment — the hardware, software, and credentials that sat at the bank’s end of the connection — and used that access to submit messages that the network had no basis to reject. They also modified the bank’s local SWIFT software to suppress incoming confirmation messages, delaying detection.
Bangladesh Bank was not alone. In late 2015, TPBank in Vietnam had survived a similar attempt. Banco del Austro in Ecuador had lost funds through a related scheme. By mid-2016, Akbank in Turkey had been hit. A pattern was clear: the endpoints of the SWIFT network were systematically vulnerable, and attackers had identified them as the most efficient path to the global financial system.
SWIFT’s response was rapid. In May 2016, three months after the Bangladesh attack became public, SWIFT launched the Customer Security Programme. In April 2017, it published the Customer Security Controls Framework — the technical and procedural backbone of the programme based on learnings from actual attacks on the SWIFT system worldwide. The era of voluntary, informal endpoint security among SWIFT users was over.
It was clear that a global standard of cybersecurity hygiene was required to protect the SWIFT ecosystem. The original CSCF contained 27 controls organised under three overarching objectives. Of the 27, 16 were mandatory — meaning all SWIFT users were required to implement them, regardless of size, geography, or architecture type. The remaining 11 were advisory: recommended best practices that SWIFT expected institutions to assess and implement where appropriate.
The mandatory controls addressed what the Bangladesh attack had revealed as the most critical failure points. Institutions were required to isolate their SWIFT environment from the general internet, implement multi-factor authentication for all SWIFT user accounts, enforce privileged access management, ensure systems were kept patched and updated, deploy integrity monitoring on SWIFT-related systems, and establish formal incident response plans.
These were not radical security requirements. Most of them were well-established practices that any mature security programme should have had in place. The sobering reality that the CSP’s early assessments revealed was that many financial institutions — including large and well-resourced ones — had not applied these basics consistently to their SWIFT environments.
The CSCF has been revised every single year since its introduction. Each version reflects active monitoring of the threat landscape, evolving attack patterns, changes in financial technology infrastructure, and the accumulated experience of assessors and institutions working with the controls in practice. Incremental changes were introduced in each new framework, allowing users of SWIFT to adapt to new requirements and scope elements with ease.
A summary of Customer Security Programme (CSP) key changes is provided in the table below. Major changes to the program include mandatory independent assessment and the introduction of the Independent Assessment Framework (IAF),
The raw control count understates the change, because the scope of what each control covers has also expanded significantly. Cloud hosting, API-based connectivity, containerised applications, and software-defined networking have all been brought within the framework’s perimeter as they became standard components of financial institution infrastructure.
The governance model of the CSP has tightened progressively, moving from a largely self-policed programme to one with real regulatory teeth. This progression is as important as the control count changes, and it represents the most fundamental structural evolution of the programme across its first decade.
The current version of the CSCF is one of the more consequential in recent years. Unlike v2025, which was explicitly positioned as a stabilisation year, v2026 makes several previously advisory requirements mandatory — most significantly Control 2.4M (Back Office Data Flow Security), which extends the compliance perimeter beyond the SWIFT Secure Zone into the data pathways connecting it to payment engines, ERP platforms, reconciliation tools, and middleware. All customer connectors — including client-side API consumers and middleware clients — are now mandatory in scope, meaning some institutions that previously attested as Architecture type B will need to reclassify as A4. Security awareness training must now include deepfake awareness, MFA has been extended to LSO and RSO accounts, and AI risk has been formally acknowledged in the framework for the first time.
The significance of Control 2.4M is rooted directly in the attack history that motivated it. The Bangladesh Bank attackers did not limit their activities to the SWIFT terminal — they exploited the surrounding back-office environment to move funds and suppress detection. Hardening the messaging layer while leaving adjacent data pathways unprotected was a known gap. v2026 closes it.
SWIFT CSP 2026: Changes You Need to Know
Our dedicated analysis of the v2026 framework covers the primary changes to this year’s program, including an important architecture reclassification, phased compliance roadmap for Control 2.4M, and practical guidance for institutions preparing their attestation.
Ten years of mandatory security controls, independent verification, and regulatory integration have produced measurable results. They have also produced a more honest picture of how far the industry still has to go — and the two findings are not in contradiction.
The programme has had a disproportionate positive effect on smaller and less sophisticated SWIFT users — institutions that, before the CSP, had no standardised cybersecurity framework specific to their SWIFT environments. In our observations, many clients lacked even basic cybersecurity protections and practices when the CSP was introduced. The mandatory compliance and assessment framework was an important wake-up call to banks, signaling the need for enhanced fraud protection. For a regional bank in a developing market with limited internal security capability, the CSCF provided something genuinely valuable: a clear, prioritised list of what needed to be done, mapped to international standards, with a specific deadline and a formal accountability mechanism.
Data from independent assessments bears this out. Institutions implementing all advisory controls alongside the mandatory ones see measurable reductions in fraud events, reductions in manual transaction investigation workloads, and in some cases reductions in cyber insurance premiums. The return on going beyond minimum compliance is real and quantifiable.
Our analysis of SWIFT CSP assessments conducted across central banks, commercial banks, international financial institutions, and payment processors in 2025 tells a consistent story. Grouped by SWIFT’s seven security principles, Principle 2 (Protect the Environment) and Principle 5 (Detect and Respond) account for more than two-thirds of total non-compliance findings — indicating that the hardest controls to sustain are not the ones institutions implement once, but the ones that require continuous operational discipline. Across our client base, 92% were affected by the top finding categories. The pattern holds regardless of institution size or geography: the gap between attested compliance and verified compliance remains significant, and it is widest in areas that depend on people and processes rather than technology alone.
The compliance perimeter will continue to expand. The v2026 extension into back-office data flows is a waypoint, not an endpoint. SWIFT has already confirmed that the remaining legacy back-office flows will come into full mandatory compliance requirements by 2028. As financial infrastructure continues to evolve toward API-native architectures, cloud-hosted components, and software-defined connectivity, the CSCF will follow.
Regulatory integration will deepen. National supervisors across every major financial jurisdiction are already treating CSP attestation as a proxy for SWIFT-related cyber hygiene. The direction is toward closer formal integration between CSP compliance and national regulatory examination frameworks.
AI is reshaping the threat landscape facing SWIFT users in ways the CSCF’s existing controls were not designed to address. Large language models have eliminated the manual bottleneck that previously limited spear phishing — the attack vector that compromised Bangladesh Bank — allowing adversaries to generate highly personalised, contextually accurate lures at scale. Deepfake voice synthesis can now replicate known executives to defeat verbal payment authorisation, a direct threat to the human controls that sit alongside technical ones. And AI-assisted reconnaissance dramatically compresses the dwell time attackers need to map a network and identify SWIFT-connected systems, reducing the detection window that has historically been the last line of defence. The CSCF’s v2026 acknowledgement of AI risk is a starting position; the more consequential question is whether transaction monitoring thresholds, access controls, and integrity checks calibrated against pre-AI threat actors remain adequate when adversaries can probe and game them algorithmically.
The social engineering threat will remain central. The Bangladesh attack that started all of this began with a phishing email. A decade later, spear-phishing, business email compromise, and AI-generated deepfake fraud are still the primary vectors through which financial institutions are compromised. The human factors that determine whether attackers gain initial access remain a critical and underinvested area for many institutions.
World Informatix Cyber Security has had an unusual vantage point on the SWIFT CSP’s first decade. We were at Bangladesh Bank in 2016, conducting the forensic investigation that documented what the attackers had done and how. We saw firsthand the endpoint vulnerabilities that the CSP was designed to address — not as abstract risks described in a framework document, but as live attack artefacts in a compromised financial institution.
We have spent the decade since conducting assessments across financial institutions on every continent, watching the framework evolve and watching institutions respond to it. The progress is real and significant. The institutions we assess today are meaningfully more secure in their SWIFT environments than those we assessed in 2017 and 2018. Controls that were widely absent in the early years of the programme — multi-factor authentication on SWIFT accounts, transaction monitoring, formal privileged access management — are now broadly implemented. The baseline has risen.
What has not changed is the sophistication of the threat. The adversaries who targeted Bangladesh Bank and dozens of institutions since then continue to develop their techniques, their tooling, and their understanding of financial institution architecture. The CSP raises the cost and difficulty of SWIFT-based fraud. It does not eliminate the threat. Sustained, rigorous compliance — not minimum checkbox compliance, but genuine implementation and continuous verification — remains the only effective response.
The tenth anniversary of the SWIFT CSP is a moment worth marking. What SWIFT built in the aftermath of a crisis has proven to be durable, consequential, and genuinely effective at improving the security posture of the global financial system. The compliance perimeter is wider than it was. The enforcement is stricter. The regulatory stakes are higher. And the threats are more sophisticated.
The work is not finished. But a decade in, the foundation is solid.
