A payment may travel through the expected technical interface without representing the bank's legitimate intention. Control analysis should therefore distinguish the identity of the signed-in user, that user's permissions and the legitimacy of a particular instruction. These questions are related but not interchangeable. Access validation does not by itself establish that an amount, beneficiary, purpose and circumstances match a genuinely approved action.
The documented February 2016 case
Bangladesh Bank in Dhaka suffered a cyber theft on 4 February 2016. The BFIU Annual Report 2015–2016 describes unauthorised instructions and approximately $81 million directed to the Philippines. A US Department of Justice criminal-charge announcement on 6 September 2018 described compromised bank systems and fraudulently authenticated SWIFT messages. I present attribution to particular defendants as an allegation by prosecutors, not as a final judicial finding.
I do not use these accounts to claim that SWIFT itself was breached or to invent the bank's non-public configuration. The incident is real; the control questions and hypothetical example below are my own analytical proposals. Their purpose is to examine the relationships between technical protection, business meaning and organisational response.
How I would map the payment process
I would follow a request from its origin to settlement. Who can create a beneficiary, enter an instruction, validate supporting information, authorise the transaction and reconcile the subsequent movement? Each step needs a system, event identifier and evidence. This allows examination of whether checks are genuinely independent or merely repeat information from the same vulnerable point.
I would not automatically treat two approvals as two effective barriers. Two people viewing the same incomplete information can confirm the same error. I would ask exactly which facts each person must verify and from which source. Approval should answer a defined question rather than simply move a request to its next status.
A hypothetical example: valid access, unusual request
Imagine a fictional bank in which ordinary payments of a selected type stay below CZK 2 million. A new instruction is for CZK 18 million, goes to a newly created beneficiary and arrives outside the usual operating period. The user has signed in correctly and has permission to create the instruction. This demonstrates the technical ability to enter it, not the reason it should be approved.
An unusual pattern does not establish fraud. It may be a legitimate larger transaction with valid documentation. I would propose checking the combination of circumstances through an agreed confirmation route. Independence matters: a reply from the same account may not resolve uncertainty if compromise of that account is part of the scenario. The responsible process and security owners would define the actual rules and limits.
If investigation supports approval, its basis, time and accountable person should be recorded. If the payment is held, the bank needs a prompt clarification route and communication to relevant staff. Indefinitely blocking every exception can harm customers and operations. The aim is proportionate risk-based control, not automatic suspicion of everything unusual. These figures and procedures do not describe Bangladesh Bank.
Check the information that does not arrive
I would examine the completeness of confirmations and reconciliations as well as unusual payments. If an expected control output fails to arrive, the process should not silently continue because no error message exists. Missing information can indicate quiet activity, a broken interface or a compromised control. Expected timing and population are needed to distinguish them.
For a hypothetical control I would define which events should generate a confirmation and within what window. Tests would cover a missing message, delayed delivery and a duplicate. Comparison should use a shared payment identifier and processing status. Counting messages alone may fail: a duplicate can conceal a missing item while the total still looks correct.
How I would test incident response
I would propose a safe exercise in an agreed environment without sending genuine unauthorised payments. A model alert would test who can restrict a process, contact other institutions and preserve evidence. I would also ask whether the response works outside normal office hours. A written contact list does not establish that the relevant person can actually be reached.
The timeline should start with the first available signal, not merely when an incident ticket is created. This separates detection, assessment and response delays. For each stage I would record what information was available at the time. Hindsight should not imply that staff knew the findings of a later investigation when making their initial decisions.
Connect technical evidence with banking meaning
Security specialists may analyse access and permission changes, payment staff examine amounts and counterparties, and operations staff monitor interfaces. Each view covers a different part of the event. My proposed analytical role would be to connect their timelines and identifiers, preserve the origin of evidence and separate demonstrated relationships from coincidence. Matching timestamps alone do not establish causation.
I would also examine whether fixing one weakness creates another operational problem. A new rule may generate more alerts than staff can assess. Evaluation should therefore include model detection rates, legitimate exceptions and resolution times. Controls need user confidence: repetitive unexplained alerts can encourage mechanical approval and reduce the value of an otherwise well-intended check.
Keep access control and transaction control distinct
A periodic review of permissions is useful, but it answers a different question from checking an individual payment. I would keep separate evidence for who may perform an action and why a particular action was appropriate. Linking them through an audit trail makes investigation possible without pretending that one control can replace the other.
In the fictional example, a reviewer might confirm that the staff member should retain the payment role while still questioning the supporting basis for the CZK 18 million request. Conversely, an apparently legitimate invoice would not justify using an account without the required permissions. The analytical task is to show both dimensions clearly so that the relevant specialists can reach the right conclusion.
Summary and recommendations
Authentication, permission and instruction legitimacy are three different layers. I would recommend following the whole payment chain, testing genuine approval independence and detecting missing control outputs. Significant exceptions need an evidenced basis and an executable decision route. Each measure should be tested for its ordinary path and its intended response to deviation.
For my professional development, this case reinforces the connection between data, process and accountability. I would avoid turning a public incident into an unsupported story about one person's mistake. A more useful approach is to formulate testable questions, trace evidence and work with specialists on a control whose effectiveness can subsequently be demonstrated.