10 Years Later, the Bangladesh Bank Cyberheist Still Offers Cyber-Resilience Lessons

The Bangladesh Bank cyberheist was not simply a case of criminals “breaking SWIFT.” Attackers compromised the bank’s internal environment, obtained access to its SWIFT-related payment operations, and used authenticated-looking instructions to target funds held at the Federal Reserve Bank of New York. The New York Fed said its systems were not compromised and that the instructions passed SWIFT’s normal authentication protocols.

In February 2016, attackers attempted to move about $951 million through 35 fraudulent instructions. Approximately $101 million left the account, and $81 million was ultimately stolen, according to the investigative and journalistic record. Ten years later, the most important lesson is simple: authentication can establish that a message is valid without proving that the transaction is legitimate.

#	Preview	Product	Price
1		Cisco ASA 5516-X hardware firewall 1U 850 Mbit/s ASA 5516-X w/ FirePOWER services, 8GE Data, 1GE...	$642.75	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

What happened in the Bangladesh Bank heist?

The attack unfolded as a chain of failures rather than one dramatic vulnerability:

1. Initial compromise: Attackers entered Bangladesh Bank’s internal network.
2. Access to payment operations: They reached systems associated with the bank’s SWIFT environment.
3. Credential and process abuse: Fraudulent payment instructions were sent using apparently valid credentials and authenticated messages.
4. Attempted transfers: The instructions targeted Bangladesh Bank’s account at the New York Fed.
5. Delayed visibility: Interference with normal operational visibility and reconciliation slowed detection.
6. Partial interruption: Suspicious details and operational anomalies helped stop most attempted transfers.
7. Cross-border recovery: Funds that reached the Philippines moved through local banks and casinos, complicating recovery and litigation.

The distinction between attempted, transmitted, executed, stopped and recovered funds matters. The approximately $951 million figure describes the value targeted through 35 instructions; it does not mean every instruction was processed. The commonly reported confirmed loss was $81 million.

#1 Best Overall

Cisco ASA 5516-X hardware firewall 1U 850 Mbit/s ASA 5516-X w/ FirePOWER services, 8GE Data, 1GE Mgmt, 100 GB mSATA SSD, AC, DES (Renewed)

• Industry's first threat-focused NGFW; provides ASA firewall functionality, advanced threat protection, and advanced breach detection and remediation combined in a single device
• Rich routing, stateful firewall, Network Address Translation, and dynamic clustering for high-performance, highly secure, and reliable access with Cisco AnyConnect VPN
• Superior threat prevention and mitigation for both known and unknown threats
• Detection, blocking, tracking, analysis, and remediation to protect the enterprise against targeted and persistent malware attacks
• Policy enforcement based on complete visibility of users, mobile devices, client-side applications, communication between virtual machines, vulnerabilities, threats, and URLs

$642.75

Buy on Amazon

The New York Fed stated in March 2016 that there was no evidence its systems had been penetrated and that the payment instructions were authenticated according to standard SWIFT protocols. That makes the incident especially important: a secure correspondent or messaging system cannot compensate for a compromised participant environment.

Why authentication did not stop the fraud

Financial institutions often use “secure” as if it answers every security question. It does not. A payment system must answer several different questions:

The heist demonstrated that these controls are not interchangeable. A criminal operating inside a trusted environment may be able to use valid credentials and produce messages that are technically authentic. That still does not make a new beneficiary, unusual currency, exceptional amount or weekend payment legitimate.

This is also why saying “SWIFT was hacked” is misleading. The available official account distinguishes the SWIFT messaging and authentication process from the bank’s compromised customer environment. The broader weakness was at the intersection of internal IT, payment operations, credentials, monitoring, correspondent banking and fraud controls.

Lesson 1: Isolate critical payment infrastructure

A SWIFT-connected system or other high-value payment environment should not be treated like ordinary office IT. Security leaders should map whether a compromise of email, employee laptops, identity services, printers, remote-access tools or general administrative systems could reach:

• SWIFT interfaces and payment terminals;
• payment-creation or approval workstations;
• operator and administrator credentials;
• printers and reconciliation devices;
• backup and recovery systems; or
• third-party support tools.

Effective separation includes restricted internet access, dedicated administration, limited remote access, tightly controlled removable media, physical protection and tested firewall rules. Segmentation that exists only on a diagram is not protection if administrators can bypass it through a broadly permitted account.

SWIFT’s current Customer Security Programme groups relevant controls around restricting internet access, protecting critical systems from general IT, reducing the attack surface and physically securing the environment. Its Customer Security Programme guidance is designed for SWIFT users, but the underlying principle applies to any system that can initiate irreversible payments.

Lesson 2: Protect the transaction, not just the login

Multifactor authentication is valuable, but it is not a complete answer. It may not stop an attacker who compromises a trusted workstation, steals a valid session or persuades an authorized operator to approve a transaction. Payment security therefore needs controls at the transaction level.

For high-value, unusual or irreversible payments, institutions should consider:

• dual approval by separate people;
• separate roles for payment creation, approval and administration;
• risk-based transaction limits and velocity controls;
• allowlisted beneficiaries and controlled changes to beneficiary records;
• holds for new destinations, unusual currencies or exceptional amounts;
• phishing-resistant, hardware-backed authentication for privileged users;
• privileged-access management and monitored break-glass accounts; and
• independent confirmation through a clean device or pre-established callback process.

A callback is not independent if the attacker can edit the bank’s directory, contact database, email, VoIP system or staff phone records. The verification channel must be protected separately from the system that created the payment.

Lesson 3: Make transaction monitoring contextual

Cryptographic validity is not the same as commercial plausibility. Monitoring should look for behavior that is unusual for the institution, not just transactions above an arbitrary amount.

Useful signals include:

• new or recently changed beneficiaries;
• unusual payment amounts, currencies or destinations;
• bursts of payment instructions;
• activity outside normal staffing, business or holiday patterns;
• repeated failed, cancelled or modified instructions;
• unusual message formatting or operator behavior; and
• payments inconsistent with the institution’s ordinary business.

Automation can identify anomalies quickly, but payment teams need understandable reasons for a hold and a controlled process for releasing it. Excessive false positives can encourage staff to bypass controls. Monitoring also needs a named owner for after-hours escalation; an alert nobody acts on is not a control.

Lesson 4: Keep reconciliation and evidence independent

Logging is not automatically independent monitoring. If the same compromised administrator can alter the payment platform, the dashboard, the identity system and the logs, the organization may have visibility without trustworthy evidence.

Resilient payment operations should maintain:

• tamper-resistant centralized logs;
• immutable or write-once evidence where appropriate;
• separate comparison of sent instructions, internal ledger entries, correspondent confirmations and account movements;
• real-time alerts to personnel outside the payment operations team; and
• protected administrative paths for monitoring systems.

Reconciliation should happen through more than one representation of the transaction. A payment marked “successful” in an application should be compared with the institution’s accounting record and the correspondent’s independent confirmation.

Lesson 5: Rehearse the first hour

Stopping a suspicious payment is a race against settlement, fraud laundering and the availability of reliable evidence. A practical first-hour playbook should include:

1. Stop or quarantine suspicious activity. Apply pre-authorized holds or isolate affected payment endpoints without destroying evidence.
2. Activate the incident commander. Notify the executive sponsor, security team, payment operations and legal counsel.
3. Contact external institutions. Use pre-established channels to reach the correspondent bank, SWIFT, regulators and law enforcement.
4. Preserve evidence. Secure logs, forensic images, volatile data, credentials, transaction records and relevant communications.
5. Contain access. Disable or isolate affected accounts, endpoints and remote-access paths, while protecting evidence.
6. Check other payment channels. Determine whether cards, instant payments, treasury systems or correspondent relationships are also exposed.
7. Coordinate across jurisdictions. Work quickly on freezes, recalls, sanctions and suspicious-activity reporting where applicable.
8. Separate containment from restoration. Do not rebuild systems until investigators and recovery leaders agree that essential evidence has been preserved.

Emergency contact lists should be tested outside business hours. A plan containing obsolete phone numbers or relying on a compromised corporate email account is not operationally ready.

Recovery is part of cyber-resilience

The incident did not end when suspicious transfers were blocked. Bangladesh Bank, the New York Fed and SWIFT continued recovery, investigation and infrastructure-rebuilding work. A 2017 joint statement referred to rebuilding Bangladesh Bank’s SWIFT-related infrastructure so correspondent-banking operations could continue in a highly secure manner. In 2019, the New York Fed said it had entered a Resolution and Assistance Agreement with Bangladesh Bank and would provide technical assistance connected with recovery litigation.

Safe recovery requires more than restoring the latest backup. Organizations should:

• rebuild from trusted, validated configurations;
• reset and rotate potentially exposed credentials;
• test backups in an isolated environment;
• verify that restored systems cannot reintroduce malicious configurations;
• stage payment operations gradually;
• maintain alternate procedures if the primary payment channel remains unavailable; and
• retest monitoring, reconciliation and approval controls before returning to normal volumes.

Backups that have never been restored are an assumption, not a recovery capability.

What changed after 2016?

SWIFT’s Customer Security Programme now organizes controls around several areas directly relevant to the heist:

1. restricting internet access and protecting critical systems from general IT;
2. reducing attack surfaces and vulnerabilities;
3. physically securing the environment;
4. preventing credential compromise;
5. managing identities and segregating privileges;
6. detecting anomalous activity in systems and transaction records; and
7. planning for incident response and information sharing.

The 2025 Customer Security Controls Framework says organizations should maintain and annually update incident-response plans, maintain backup and recovery plans for critical business lines, and test the plan at least every two years.

For a broader enterprise view, NIST Cybersecurity Framework 2.0 uses six continuous functions: Govern, Identify, Protect, Detect, Respond and Recover. NIST’s framework is outcome-based guidance, not a certification or a guarantee of safety. NIST SP 800-61 Revision 3, finalized in April 2025, updates incident-response guidance around that model.

Common lessons that are wrong or incomplete

“A typo saved the bank.”

A suspicious beneficiary detail may have helped trigger scrutiny, but relying on a clerical mistake is luck, not resilience. Human review should be deliberately built into high-risk payment workflows.

“The answer is better monitoring.”

Monitoring matters, but it cannot replace segmentation, independent approval, credential protection, reconciliation and practiced response.

“MFA would have prevented it.”

MFA reduces account-takeover risk. It does not by itself stop an attacker operating through a trusted environment or stolen session. Transaction-level controls remain necessary.

“The incident ended when the transfers stopped.”

Recovery, litigation, infrastructure rebuilding, cross-border coordination and accountability continued for years. The official statements from 2017 and 2019 document that longer process.

A board-level cyber-resilience checklist

Executives and directors should be able to answer these questions clearly:

• Which systems can originate or approve an irreversible payment?
• Can a compromise of ordinary office IT reach those systems?
• Can one person create and approve the same payment?
• Who can independently verify a high-risk transaction?
• Can an attacker disable or alter the logs and alerts?
• Are beneficiary changes subject to separate approval?
• When was the last isolated restore test?
• Which external contacts are reachable outside business hours?
• What happens if the primary payment channel is unavailable?
• What evidence would prove that recovery is safe?
• Are correspondent banks, vendors and managed-service providers included in tabletop exercises?

Security products can help, including managed detection, SIEM, identity, privileged-access, segmentation and incident-response services. But the Bangladesh Bank case argues against buying another dashboard as a substitute for process discipline. The higher-value questions are whether alerts are acted on, whether critical systems are genuinely isolated, whether payment approval is independent and whether recovery has been tested.

Quick Recap

Bestseller No. 1

Cisco ASA 5516-X hardware firewall 1U 850 Mbit/s ASA 5516-X w/ FirePOWER services, 8GE Data, 1GE Mgmt, 100 GB mSATA SSD, AC, DES (Renewed)

Superior threat prevention and mitigation for both known and unknown threats

$642.75

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.