Lesson 1.1: Phony Bank Account Change Requests: Incident Deep Dive

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Phony Bank Account Change Requests: Incident Deep Dive! Over the next 45 minutes, we will explore how a simple, low-tech request can bypass sophisticated defences and lead to a major data breach.

But first, let me tell you about Marcus Webb.

It's 2:15 PM on a Tuesday in October. Marcus Webb, a senior finance manager at a mid-sized manufacturing firm in Birmingham, is reviewing the weekly payment run. The office is quiet, the hum of the air conditioning the only sound. He sips lukewarm coffee from a chipped mug.

An email notification pops up. It's from '[email protected]'. The subject is 'URGENT: Action Required - Supplier Payment Details Update'. The email is polite, professional, and references a real supplier, 'Precision Components Ltd'. It states their bank has undergone a merger and all payments must be sent to a new account, effective immediately. A PDF attachment contains a letter with what looks like the bank's official letterhead.

Marcus knows the procedure. He logs into the company's finance portal to update the supplier's bank details. He enters the new account number and sort code from the PDF. The system asks for a second approver. He forwards the email to his colleague, Laura, who approves it without question. A payment for £187,500 is scheduled. The money leaves the company account the next morning.

This is the story of a Data Breach. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: What is a Phony Bank Account Change Request?

Think of it as identity theft for a company's money flow. Instead of stealing a person's credit card, attackers impersonate a trusted partner to redirect entire payment streams.

Key Characteristics

This attack targets the business process, not the technology. It uses social engineering, relying on human trust and established procedures.

The communication is often highly targeted. Attackers research real suppliers, use convincing language, and mimic official correspondence.

The goal is direct financial theft. Once the bank details are changed, legitimate payments are sent to accounts controlled by the attackers.

The Attacker's Advantage

Attackers exploit a gap between departments. The finance team trusts procurement, and procurement trusts supplier communications. The verification chain breaks down.

The attack has a low technical barrier. It doesn't need malware or zero-day exploits. A spoofed email address and a forged document are often enough.

DORA Article 5-17 DORA's ICT risk management framework requires financial entities to identify and manage risks from all sources, including non-technical threats like business process compromise.

ISO A.8.1.3 ISO 27001 A.8.1.3 mandates policies for the acceptable use of information assets, which must extend to governing how critical business information, like supplier bank details, is verified and changed.

Content Section 2: The Anatomy of the Attack

Understanding the attack flow reveals why it's so effective. Let me show you exactly how Marcus was compromised.

Attack Flow

Step 1: Reconnaissance. Attackers identify a target company and research its key suppliers through public websites, LinkedIn, or even phishing a junior employee.

Step 2: Impersonation. They register a domain similar to the supplier's bank (e.g., 'theirbank-co-uk.com' vs. 'theirbank.co.uk') and craft a convincing email.

Step 3: Execution. The email, often with a forged PDF on fake letterhead, is sent to a finance or accounts payable contact. It creates urgency to bypass scrutiny.

Step 4: Monetisation. Once the details are updated in the victim's system, the next legitimate payment is routed to the attacker-controlled account. The funds are quickly moved through multiple accounts.

The Human Element

The attacker's script relies on established trust. The request appears to come from a known partner. The employee is trying to be helpful and efficient.

Pressure is a key tool. Words like 'URGENT' or threats of 'service disruption' push the victim to act quickly, short-circuiting normal verification.

Why Traditional Defences Fail

Notice what all of these methods have in common. They are designed to stop technical intrusions, not the misuse of authorised access by a deceived employee.

Standard security controls are often looking the wrong way.

NIST PR.AC-1 NIST CSF PR.AC-1 requires managing identities and credentials for authorised access. This attack shows that managing the *use* of that authorisation—ensuring it's applied correctly—is just as important.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures. A complete risk assessment must include business process risks, like the verification procedures for changing financial data.

Content Section 3: Detection and Signals

Marcus's finance system couldn't tell him the new account belonged to a criminal. But there were signals. We just need to know where to look.

Process-Level Indicators

Monitor for unusual patterns in vendor master data changes. A surge in bank detail updates, especially for critical suppliers, is a red flag.

Look for changes made outside of normal business hours or by users who don't normally perform this function.

Correlate a bank detail change with the immediate scheduling of a large payment to that vendor. This sequence is the heart of the attack.

Communication-Level Indicators

Deploy email security tools that flag lookalike domains. 'theirbank-co-uk.com' should be scored as highly suspicious compared to the legitimate 'theirbank.co.uk'.

Train staff to spot subtle cues: generic greetings ('Dear Sir/Madam'), poor formatting on 'official' letters, and pressure tactics.

Financial Control Signals

Implement a 'positive pay' service with your bank, where you send a list of approved payments, and the bank flags any discrepancies.

Require dual approval for payments over a certain threshold, with the second approver independently verifying the payment details.

SOC2 CC6.1 SOC 2 CC6.1 requires logical access controls to protect assets. Detecting anomalous use of authorised access—like unusual vendor data changes—is part of demonstrating effective control operation.

GDPR Article 32 GDPR Article 32 requires appropriate security of personal data. A breach caused by this fraud could expose employee and supplier personal data, making detection and prevention a data protection requirement.

Content Section 4: Building Your Compliance Evidence

Compliance documentation isn't just paperwork. It's the blueprint for your defence. For Marcus's company, a solid control framework would have been the guardrail that stopped the error.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that you have identified 'Business Email Compromise leading to payment fraud' as a specific ICT risk and are training staff on its detection.

For ISO A.8.1.3 auditors... For ISO 27001 assessors, you can evidence that your 'Acceptable Use Policy' for the finance system includes mandatory verification procedures for changing supplier financial data.

For NIST PR.AC-1 auditors... For NIST CSF reviewers, you can show you are implementing controls (PR.AC-1) not just for login, but for supervising high-risk transactions like bank detail changes.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified (e.g., 'Schedule a meeting with the Head of Finance to discuss process review')

Conclusion

Let me tell you how Marcus's story ended.

The £187,500 was gone. The bank traced it to an account that was emptied within hours. The company's insurance covered part of the loss, but the excess was significant. Marcus was not fired, but his reputation was damaged. The stress took a personal toll.

The organisation eventually implemented a new rule: any change to a supplier's bank details required a verification call to a contact number held on file from the original supplier contract. They also started using a positive pay service. The changes worked, but they were expensive lessons.

But it doesn't have to be your story. That's why we're here.

You should now understand that a data breach can start with a simple email, not a complex hack. You understand why this attack bypasses standard technical defences. You know the key detection signals in your processes and systems. And you understand the specific compliance controls that map directly to stopping this threat.

Next, we'll explore Next, we'll explore Lesson 1.2: The Infrastructure of Fraud. We'll look at how attackers set up the bank accounts, domains, and money mules to make their thefts stick, and how you can disrupt their operations.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators (process anomalies, lookalike domains) and immediate response steps (contact bank, freeze payments) for a suspected Phony Bank Account Change Request on a single page.
• Compliance Mapping Worksheet - Map your organisation's controls for supplier data verification and payment authorisation to the specific DORA, ISO 27001, and NIST CSF requirements covered in this lesson.
• Risk Assessment Template - Assess your organisation's exposure to Business Email Compromise and payment fraud based on the supplier interaction and finance process attack vectors covered in this lesson.
• Further reading - Links to official framework documentation (e.g., ISO 27001:2022 A.8.1.3) and threat intelligence reports on Business Email Compromise (BEC) tactics.

Phony Bank Account Change Requests: How to Detect and Stop AP's Silent Killer Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026