Advanced: cyber attacks on payment infrastructure.

A central bank heist, step by step

In February 2016, attackers stole about US$81 million from Bangladesh Bank's account at the Federal Reserve Bank of New York. The account of how it happened comes from a US criminal complaint unsealed in 2018 and an indictment unsealed in 2021, which charge North Korean military intelligence hackers. These are allegations: nobody has been convicted, and the defendants are presumed innocent.

How the attackers got in, as alleged:

1. Phishing. In early 2015, bank employees received emails posing as job applications, with a link to a "resume" file. At least three bank computers tried to download it.
2. A foothold. Malware gave the attackers a backdoor, using traffic designed to look like normal encrypted traffic and slip past intrusion detection.
3. Patience. For about a year they moved through the network. In January 2016 they installed further malware disguised with the name of a legitimate system file, changed the firewall to allow access, and reached the computers at the heart of the bank's SWIFT messaging environment.
4. Authentic but fraudulent messages. On 4 February 2016 they used the bank's own systems to send genuine, authenticated SWIFT payment messages the bank had never authorised, instructing the New York Fed to pay out from the bank's account. The indictment says they attempted transfers totalling about US$951 million.
5. Hiding the evidence. Malware interfered with the printed confirmations and with the database that recorded the bank's SWIFT messages, so staff could not see what had gone out, and other malware deleted traces.

What happened to the money. About US$81 million went to accounts in the Philippines opened in fictitious names, and was laundered through bank accounts, a money remitter and casinos; most was not recovered. The receiving bank in Sri Lanka halted a further US$20 million.

The lessons:

• The messaging system worked exactly as designed. The weakness was the endpoint: the bank's own computers connected to it.
• Attackers can be inside for months before acting.
• Reconciliation and confirmation are controls in their own right; disabling them was part of the attack.
• The receiving side matters: one transfer was stopped because the receiving bank questioned it.

What standard setters expect of payment systems

Endpoint security for wholesale payments. In 2018 the BIS Committee on Payments and Market Infrastructures (CPMI) set out a seven-part strategy to reduce wholesale payments fraud related to endpoint security, prompted by incidents like the one above. Its elements, in the CPMI's own titles:

1. identify and understand the range of risks;
2. establish endpoint security requirements for participants;
3. promote adherence to them;
4. provide and use information and tools to improve prevention and detection, such as payment limits set by participants, screening payments against their own parameters, detecting unusual timing, values or destinations, and frequent reconciliation during the day;
5. respond in a timely way to potential fraud;
6. support ongoing education, awareness and information sharing;
7. learn, evolve and coordinate.

The CPMI adds that the response to fraud should not undermine the finality of payments that have already settled.

Cyber resilience for financial market infrastructures. The CPMI and IOSCO's 2016 guidance, which supplements the international Principles for Financial Market Infrastructures, organises cyber resilience into five risk management categories: governance, identification, protection, detection, and response and recovery, plus three overarching components: testing, situational awareness, and learning and evolving. It sets a demanding objective: payment and settlement systems should be designed and tested so that critical operations can restart safely within two hours after an outage, with settlement finished the same day, even in extreme but plausible scenarios. It also tells them to use judgement so that a hasty restart does not make things worse, and to plan for cases where the objective cannot be met.

The G7's eight elements. In October 2016 the G7 published non-binding Fundamental Elements of Cybersecurity for the Financial Sector: cybersecurity strategy and framework; governance; risk and control assessment; monitoring; response; recovery; information sharing; and continuous learning.

The common thread: treat cyber risk as a business and governance issue, assume attackers will get in, and be able to detect, respond and recover fast.

The EU Digital Operational Resilience Act

The EU's Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025 to most financial entities in the EU. Its chapters cover five areas, often called its pillars:

• ICT risk management: a governed framework for identifying, protecting against, detecting, responding to and recovering from ICT risks.
• ICT incident management and reporting: classifying incidents and reporting major ones to supervisors.
• Digital operational resilience testing, including advanced threat-led penetration testing for some entities.
• ICT third-party risk, including EU oversight of critical technology providers.
• Information sharing: financial entities may share cyber threat information with each other.

Reporting a major incident. Under the EU's technical standards, a financial entity must send:

• an initial notification within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it;
• an intermediate report within 72 hours of the initial notification;
• a final report within one month of the latest intermediate report, once the root cause is known.

Threat-led penetration testing. Entities identified by their supervisors must carry out advanced testing on live production systems covering critical functions at least every three years, though supervisors can change the frequency.

Critical technology providers. In November 2025 the EU supervisory authorities published their first list of critical ICT third-party providers subject to direct EU oversight. It named 19 providers.

Why it matters beyond Europe. DORA reflects where supervisors everywhere are heading: incident reporting within hours, regular realistic testing, and accountability for technology suppliers.

Testing like an attacker

TIBER-EU. The European Central Bank's framework for Threat Intelligence-Based Ethical Red teaming was updated in January 2025 to align with DORA's threat-led penetration testing. It has three mandatory phases:

• Preparation: scoping the test on critical functions and setting up a small control team inside the entity that knows about the test, previously called the white team.
• Testing: a threat intelligence provider builds realistic attack scenarios based on the actual threats to that entity, then a red team executes them for at least 12 weeks, while the entity's defenders, the blue team, do not know a test is under way.
• Closure: the red and blue teams replay the attack and, since 2025 mandatorily, run a purple teaming exercise together within ten weeks of the end of active testing, covering what was missed, alternative scenarios and remediation.

Why threat-led? Ordinary penetration tests find technical weaknesses. A threat-led test asks whether a realistic attacker, using the methods seen in real attacks on the sector, could reach the systems that move money, and whether the defenders would notice.

Ransomware: also a sanctions problem. In September 2021 the US Treasury's Office of Foreign Assets Control (OFAC) updated its advisory on ransomware payments. It says the US government strongly discourages paying ransoms, that paying a sanctioned person can breach sanctions law, and that civil liability is strict liability, meaning a firm can be liable even if it did not know the attackers were sanctioned. Applications for a licence to pay are reviewed case by case with a presumption of denial. Taking meaningful cyber hygiene steps, reporting promptly to law enforcement and cooperating fully count as significant mitigating factors.

The scale. The US Financial Crimes Enforcement Network's December 2025 analysis of bank reports found over US$2.1 billion in ransomware payments across 4,194 incidents from 2022 to 2024, with financial services among the most affected industries. These figures cover only incidents reported in those filings.

Building resilience in practice

Bringing the lessons together for a bank, payment service provider or payment system:

• Protect the endpoints that connect to payment systems: separate them from the general network, restrict and monitor administrator access, and apply the provider's security requirements.
• Control payments independently of the systems that send them: limits, screening against expected patterns, and reconciliation during the day, so that fraudulent messages are caught even if the sending system is compromised.
• Detect early: attackers may be inside for months; monitor for unusual logins, new software and changes to firewalls.
• Plan to recover fast, with tested procedures aiming to restore critical operations within hours, and manual fallbacks.
• Report quickly to supervisors and law enforcement, within the deadlines that apply.
• Test realistically, with threat-led red teaming where your size and role justify it, and fix what it finds.
• Manage suppliers, since a technology provider's weakness can become yours.

In Kenya: the Central Bank of Kenya's 2017 cybersecurity guidance for banks requires them to notify the Central Bank within 24 hours of a cybersecurity incident that could significantly affect their services, reputation or financial condition, and to submit quarterly incident reports. Its 2019 guideline for payment service providers requires notice within 24 hours, and within 2 hours for systemically important payment systems. The Computer Misuse and Cybercrimes Act, 2018 established the National Computer and Cybercrimes Co-ordination Committee, provides for designating critical information infrastructure, including systems whose failure would disrupt the money market, and requires attacks on it to be reported within 24 hours. The Central Bank published a revised draft cybersecurity guidance note for comment in 2026 that adds red-teaming and penetration testing. Check the current versions.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.