Email Security in Hong Kong: A Wholesaler's Near-Miss Supplier Fraud

The short answer: Business email compromise in Hong Kong rarely looks like phishing. The request to change a supplier's bank details often arrives from that supplier's genuine mailbox, inside a real thread, at a moment when a payment is genuinely due. Stopping it takes two halves that only work together — enforced email security controls, and a written rule that no bank-detail change is ever actioned without an out-of-band callback.

A finance director at a Hong Kong wholesaler comes close to paying a fake invoice, and the thing that saves the company is not a security product. It is a habit: the accounts clerk always rings the supplier on the number in the signed contract before releasing a payment on changed bank details. She rings. The supplier says they never sent that email. The payment does not go out.

That is the version of this story that ends well, and it is worth being honest about why it ended well. Nothing in the company's IT setup caught it. The email arrived from the supplier's real domain, in a thread the two companies had been running for weeks, with the right purchase order number and the right amount. Every technical control the company had was working exactly as designed, and every one of them let the message through — because from the mail system's point of view, there was nothing wrong with it.

This guide is written for the finance director or operations lead at a Hong Kong retail and wholesale business of roughly 60 to 100 people that pays overseas suppliers regularly. It is an illustrative composite rather than a named client, but the pattern is one Brocent sees repeatedly at Hong Kong trading and retail operations. Brocent has been running IT and security for businesses of this shape since it was founded in Beijing in 2007, has had a Hong Kong office since 2016, and has been headquartered in Singapore since 2021.

Hong Kong Retail and Wholesale: Where One Misdirected Payment Is Material

Hong Kong's retail and wholesale sector is built on paying people in other countries. A brand distributor pays manufacturers on the mainland and in Southeast Asia. A specialty importer pays European and Japanese principals. A trading company sits between an overseas buyer and a factory and pays both sides on different terms. In all of these, telegraphic transfers to overseas beneficiaries are not an occasional treasury exercise — they are the normal weekly rhythm of the business, and the people executing them are a small finance team measured on getting payments out on time.

Two features of this sector make it an unusually good target. The first is that supplier bank details genuinely do change. A factory restructures, switches banks, opens an offshore account, or asks to be paid through a different group entity. Finance teams here are not suspicious of a bank-detail change the way a company paying three domestic vendors would be, because for them it is a routine event that happens several times a year. The second is that the amounts are material relative to the company's margin. A single misdirected payment on a container of goods can wipe out the profit on that shipment and more, and unlike a domestic error, recovering funds that have moved through an overseas beneficiary account is slow, uncertain, and frequently unsuccessful.

That combination — routine changes, large amounts, tight deadlines, small team — is exactly the environment business email compromise is built for. It is not a coincidence that Hong Kong wholesalers and trading firms feature so heavily in this attack class. Attackers go where large payments are normal.

The Scenario: 80 Staff, a Three-Person Finance Team, and a Shared Accounts Mailbox

The composite company: about 80 people. A showroom and sales team, a merchandising and buying function, warehouse and logistics staff, and a back office. Finance is three people — a finance director, an accounts payable clerk, and a part-time bookkeeper who comes in twice a week. Everyone runs Microsoft 365, because that is what a company this size runs.

Mail is organised the way it usually is at this size. There is a shared orders mailbox that the buying team all work out of, and a shared accounts mailbox where supplier invoices arrive. Both are shared for a good operational reason: when the accounts clerk is on leave, someone else has to be able to see the invoices. Staff have mail on personal phones, because the merchandising team travels to factories and the sales team is on the showroom floor. Multi-factor authentication is switched on for some accounts and not others, usually because someone had trouble enrolling and it was quietly left off to unblock them.

There is no written rule about bank-detail changes. There is a practice — the accounts clerk usually calls — but it lives in her head, it is not in any document, and nobody has ever tested what happens when she is away and someone else releases the payment. IT is a single generalist or an external provider on a break-fix arrangement, and neither has ever been asked a question about email authentication, because nobody in the business knew it was a question.

None of this is negligent. It is what a company looks like when it has grown steadily, kept its overheads sensible, and never had an incident that forced a policy. It is also, almost exactly, the environment in which the near-miss above happens.

Real Problem One: The Email Is Genuine, Which Is Exactly Why It Works

The mental model most businesses have of email fraud is a badly written message from a lookalike domain with a suspicious attachment. That model is a decade out of date, and it is the single biggest reason otherwise careful finance teams get caught.

In the pattern that actually costs Hong Kong companies money, the attacker has already compromised a mailbox at the supplier — often a small factory or trading office with weaker controls than yours. Then they read. They sit in that mailbox for days or weeks, learning who talks to whom, what the payment terms are, what the invoice format looks like, and crucially when a large payment is due. Then they reply in the existing thread, from the real account, at the right moment, with a plausible reason for a new account: the usual bank is under audit, the company has opened an account in another jurisdiction, this quarter's payment must go to a related entity.

There is nothing for a spam filter to find. The sending domain is legitimate and passes every authentication check, because the mail genuinely originates from that domain. The thread history is real. The invoice is a real invoice with the numbers changed. Attachment scanning finds nothing, because there is often no attachment worth scanning. Reputation-based filtering sees a domain the company has exchanged hundreds of clean messages with.

This is the point most product-led security conversations miss. You can buy the best filtering in the market and it will not reliably stop this, because the message is not malicious in any way a filter can measure. What it is, is a request to move money to a new account — and that is a business-process question, not a mail-flow question.

Real Problem Two: Shared Mailboxes Make It Impossible to Say Who Saw What

Shared mailboxes are operationally sensible and forensically terrible. When something goes wrong in a shared accounts mailbox, the questions that matter immediately are: who read this message, who replied, was a forwarding rule created, and what else has been touched. In a small company with a shared mailbox and inconsistent MFA, those questions are often unanswerable with any confidence.

There are two specific failure modes. The first is attribution: several people have access, individual sign-in is not always enforced, and the audit trail — if auditing is even turned on at the right level — shows access without cleanly showing who did what. The second, and more damaging, is the mailbox rule. A common attacker step after gaining access is to create an inbox rule that quietly moves messages from a particular sender, or containing a particular word, into a folder nobody looks at. In a shared mailbox where three people each have their own idea of how the folders work, such a rule can sit undetected for a long time — and its effect is that the supplier's genuine follow-up asking why they have not been paid never reaches the person who could have caught it.

The practical consequence at this size is that the incident is usually discovered by the supplier rather than by the company. That is weeks later, and by then the money has moved.

Real Problem Three: Domain Authentication Is Sitting in a State Nobody Ever Tightened

SPF, DKIM and DMARC are the three records that let the rest of the world verify that mail claiming to be from your domain actually came from you. Nearly every Hong Kong SME has some version of them, because the initial Microsoft 365 setup produces them. Very few have them in an enforcing state, and the gap between "present" and "enforcing" is where the damage lives.

The typical picture on taking over a tenant at this size: an SPF record that has accumulated entries over the years as a marketing tool, an e-commerce platform, a courier notification service and an accounting package were each added, now sitting close to or past its lookup limit and ending in a soft-fail that tells receiving servers to accept the mail anyway. DKIM signing that was never enabled on the custom domain, only on the default one. And DMARC either absent entirely or published at a monitoring-only policy with no reporting address configured — which means nobody has ever read a single report, and the policy does precisely nothing except create a favourable impression on a security questionnaire.

What that state actually costs is the ability to stop someone impersonating your domain outward, to your own customers or your own staff. It does not, and cannot, stop the compromised-supplier case above. This distinction is worth being blunt about: fixing your authentication records protects your name; it does not protect your outbound payments. Both jobs are necessary, and confusing them is one of the most common ways a company ends up feeling protected while remaining exposed.

Real Problem Four: The Payment Process Has No Out-of-Band Step

Strip away the technology and the fraud is simple: an instruction to pay a different account arrives through a channel, and the company acts on it through that same channel. Every version of this attack depends on that single-channel loop, and every reliable defence breaks it.

At the composite company, the loop is unbroken by construction rather than by accident. The invoice arrives by email. The bank-detail change is communicated by email. The finance director approves by email. Confirmation goes back by email. If the email channel is compromised at any point in that chain, nothing else in the process is capable of noticing, because there is no second, independent source of truth about where the supplier's money should go.

The dangerous detail is that this loop tightens under time pressure exactly when it should loosen. A container is at the port. The supplier says goods will not release until payment clears. The accounts clerk is on leave, so the bookkeeper who is in twice a week is asked to release it. The person with the calling habit is not the person at the keyboard, and the habit is not written down anywhere. That is the day it goes wrong — not the day someone is careless, but the day the informal control was not in the room.

What Usually Forces the Issue

Companies of this size rarely commission an email security review because it seemed prudent. Something specific pushes it onto the agenda, and it is usually one of four things. Most often it is a near-miss like the one above, where the gap between "we caught it" and "we didn't" turns out to have been one person's personal habit. Sometimes it is a peer: another company in the same trade loses a payment, the story travels, and the finance director asks whether the same thing could happen here — and does not like the answer.

The third trigger is a customer or an insurer. An overseas buyer's vendor questionnaire, or a crime-insurance renewal, asks whether the company enforces DMARC, requires MFA, and has a documented payment-verification procedure. Answering honestly is uncomfortable, and answering carelessly on an insurance form has consequences of its own. The fourth is an audit or a banking relationship review that touches payment controls directly.

It is worth saying plainly that the review is far cheaper than the incident, and that the single most effective control involved — a written verification rule — costs nothing but the decision to write it down.

Brocent's Perspective: A Payment-Process Problem With an Email Attack Surface

Brocent's position on this class of incident, formed over years of taking over tenants at exactly this size, is that it is misfiled from the start. It gets treated as an email problem with a payment consequence. It is the reverse: a payment-process problem with an email attack surface.

That reframing has a practical edge, because it explains why the two most common responses both underperform. A company that buys a filtering product and changes nothing about how payments are authorised has bought protection against the attacks that were never going to reach its bank account anyway, and no protection against the one that will. A company that writes a strict callback policy but leaves its tenant unhardened — no enforced MFA, no conditional access, permissive authentication records, no impersonation detection — has a control that depends entirely on one busy person doing one manual thing correctly every single time, with no technical safety net underneath and no way to detect that a mailbox has been taken over.

Both halves or neither. That is the honest version, and it is not the version that sells a single product line. The technical controls reduce how often a fraudulent instruction ever reaches a human at all, and give you the visibility to know when something is wrong. The process control catches the residue no technical control can catch — the genuine email from the genuine supplier. Neither half is sufficient. Together they are, in practice, very effective, because the attack depends on a chain and the two halves break different links in it.

The corollary matters too: this is achievable at 80 people without an enterprise budget. Almost everything below is either included in licensing the company already owns, or is a policy decision. What is usually missing is not money. It is that nobody owns the problem.

What Real Coverage Looks Like at a Company This Size

Six things, in rough order of how much risk they remove per unit of effort.

A written out-of-band verification rule, with no exceptions for urgency. Any change to a supplier's bank details — and any first payment to a new beneficiary — is verified by voice call to a number held in your own supplier master file, never a number taken from the email requesting the change. The rule names who may perform the verification, requires it to be recorded against the payment, and states explicitly that time pressure is not grounds for skipping it. This is the single highest-value control here and it is free. The reason it must be written down is precisely the scenario above: informal habits do not survive annual leave, staff turnover, or a container sitting at the port.

Domain authentication actually enforced rather than merely present. SPF cleaned up and within its lookup limit, ending in a hard fail. DKIM signing enabled on the real sending domain. DMARC moved deliberately from monitoring through quarantine to reject, with reports going somewhere a human reads them. This is a staged piece of work rather than a switch — jumping straight to reject without reading reports first is how a company breaks its own invoicing email — and several weeks of monitoring is normal at a business with as many third-party senders as a wholesaler typically has.

Impersonation and lookalike-domain protection, plus external-sender marking. These catch the other half of the attack family: a display name matching one of your directors sent from an outside address, a domain one character different from a real supplier's, a first-contact sender pretending to be an established one. Paired with a clear visual marker on every externally originated message, this removes a large share of the cases where a busy person reads a name rather than an address. The capability exists in the Microsoft 365 licensing many companies at this size already hold, and is frequently switched off or left at default.

MFA everywhere and conditional access, so a stolen password is not a stolen mailbox. Not MFA on most accounts — on all of them, including shared-mailbox delegates, the finance team, and every account with a licence attached. Conditional access adds the layer that matters for a Hong Kong company whose buyers travel: sign-in policy based on device compliance and location, blocking legacy authentication protocols that bypass MFA entirely, and alerting on impossible-travel and unusual-forwarding-rule events. This is the control that stops your side of the conversation from becoming the compromised side that defrauds someone else. It sits naturally alongside the rest of a managed cloud and Microsoft 365 service.

Monitoring, alerting and an actual response path. Mailbox auditing on, alerts configured for new forwarding or redirect rules, and someone whose job it is to receive that alert and act on it out of hours — because these events do not respect Hong Kong office hours, and the window between a mailbox being taken over and money moving is often measured in hours. A 24/7 help desk is the difference between an alert acted on at 2am and one read on Monday morning.

Periodic simulated phishing and short, specific training, so the rule survives turnover. Not an annual slide deck. Short, regular exercises aimed at the people who actually authorise payments, plus a five-minute induction for every new finance or buying hire covering the one rule that matters. The purpose is not to catch people out; it is to keep the verification habit alive as the team changes. Brocent runs this inside managed IT security services rather than as a standalone product, because a simulation programme disconnected from the controls and the policy is theatre.

Default Mailbox Settings Only vs a Bolt-On Product Nobody Tunes vs Managed Email Security With a Written Payment Rule

• Default Microsoft 365 settings only — Genuinely stops commodity spam and known malware, and costs nothing extra. The weaknesses are exactly the ones that matter here: authentication records left permissive, impersonation protection off or at default, MFA inconsistent, no mailbox-rule alerting, and no payment-process control at all. This is the configuration in which the near-miss above depends entirely on one clerk's personal habit — which is to say, on luck wearing the costume of a control.
• A bolt-on email security product nobody tunes — Buys real capability, and a line on the insurance form. The failure is operational rather than technical: it is installed at default settings, its policies are never tuned to the company's actual sender pattern, its quarantine is never reviewed, its reports go to an unread mailbox, and nothing about how payments are authorised has changed. It stops more spam, and roughly the same amount of supplier fraud as before, while creating a firm belief that the problem is handled.
• Managed email security plus a written payment-verification rule and regular drills (Brocent's model) — Authentication staged through to enforcement with reports genuinely reviewed, impersonation and lookalike protection tuned to your real supplier list, MFA and conditional access with no exceptions, mailbox-rule and impossible-travel alerting routed to a monitored helpdesk, and a written out-of-band verification rule kept alive with periodic drills. The honest tradeoff is that this needs business-process change and the finance team's agreement, not just a purchase order — which is exactly why it works, and exactly why it is the harder sell.

If You Think It Has Already Happened: The First Hour

Speed matters more than certainty here, and the two workstreams run in parallel — do not wait for the IT investigation before contacting the bank.

On the money side: call your bank's fraud line immediately and request a recall of the transfer, then report it to the Hong Kong Police Force. Recovery chances fall sharply with time, and the realistic window is short — hours, not days. Notify the supplier on a phone number you already hold, not by replying to the thread, because the thread may be the attacker's.

On the IT side: reset credentials and revoke active sessions on the affected accounts, force MFA re-registration, and check for and remove inbox rules, forwarding addresses and mail-flow rules created recently anywhere in the tenant. Preserve the audit logs before anything is cleaned up. Then establish whether the compromise was on your side or the supplier's — that answer determines both your notification obligations and what has to change. If your side was compromised and personal data sat in the affected mailbox, the Personal Data (Privacy) Ordinance becomes relevant, and the practical steps in our PDPO checklist for IT outsourcing apply.

Frequently Asked Questions

What is business email compromise, and how is it different from ordinary phishing?

Ordinary phishing is a volume attack: a generic message sent to thousands of people to harvest credentials or deliver malware, usually detectable by a filter. Business email compromise is targeted and patient. The attacker gains access to a real mailbox — often at a supplier rather than at you — reads the correspondence to learn the relationship and the payment cycle, then sends a single, well-timed, entirely plausible message asking for money to go to a different account. There is frequently no malicious link, no attachment and no forged sender, which is why filters do not catch it and why the defence has to include a step that happens outside email.

Our email is on Microsoft 365 — isn't that already secure?

Microsoft 365 provides genuinely strong building blocks and does a good job on spam and malware out of the box. But most of the controls that matter for supplier fraud are either off by default or configured once at setup and never revisited: impersonation protection, external-sender marking, mailbox auditing and rule alerting, conditional access, and consistently enforced MFA. Beyond that, no email platform can stop a legitimate message from a legitimate supplier that happens to contain fraudulent bank details. The platform is a good foundation; the configuration and the payment process are what turn it into protection.

What are SPF, DKIM and DMARC, and does a company this size need them?

They are three DNS records that together let receiving mail servers verify that a message claiming to be from your domain really is from you. SPF lists which servers may send as you. DKIM cryptographically signs your outgoing mail. DMARC tells the world what to do when the first two fail, and sends you reports. Yes, a company this size needs them — not because they stop the compromised-supplier attack, but because without them anyone can send mail that appears to come from your domain, including to your own staff and your own customers. Publishing them in a monitoring-only state, which is very common, gets you the reports without the protection; enforcement is the point.

If a supplier's mailbox is the one that got compromised, what can we actually do?

You cannot fix their security, but their compromise only costs you money if it reaches your payment process unchallenged — so that is where you intervene. The out-of-band verification rule works regardless of whose mailbox was breached. Beyond that: keep supplier bank details in your accounting or ERP system as the single source of truth rather than in email threads, make any change to that record a two-person process, and treat a first payment to a new beneficiary with the same verification as a change. It is also entirely reasonable to ask significant suppliers what their own email controls look like — for large ongoing relationships, that question increasingly appears in supplier onboarding.

Does PDPO come into this if customer or staff data was in the mailbox?

If a mailbox in your tenant was compromised and it held personal data — customer contact records, staff details, identity documents sent as attachments — then yes, this is a personal data security matter under the Personal Data (Privacy) Ordinance, not only a financial loss. Hong Kong does not impose a general statutory breach-notification duty in the way some jurisdictions do, but the Privacy Commissioner's guidance recommends notification, and the data user's obligation to take all practicable steps to protect personal data is not optional. Practically: preserve the evidence, scope what was actually in the mailbox rather than guessing, take advice on notification, and document the remediation.

Is security-awareness training worth it for an 80-person company?

Yes, but only in a specific form. An annual compliance module everyone clicks through changes nothing measurable. What works at this size is short, frequent and targeted: simulated phishing aimed particularly at finance and buying, five minutes of concrete induction for every new hire in those functions, and a periodic live drill of the payment-verification rule itself, where someone deliberately tests whether a bank-detail change gets challenged. The goal is not a training completion rate. It is that the rule keeps being followed after the person who invented it has left.

Getting Both Halves in Place

If you take one thing from this: the technical controls and the payment rule are not alternatives, and a company that has one of them is not most of the way there. A sensible starting point is a short assessment of the current state — what your authentication records actually say, where MFA is genuinely enforced, what alerting exists, and what your payment process does today when bank details change — followed by a staged plan that fixes the free things first.

Brocent runs email security as part of a managed service rather than as a product sale, for Hong Kong companies and for their mainland China and Singapore offices under one contract and one security baseline. If you want to understand the service model and what it costs before having a conversation, the pricing page sets it out. If you would rather start with the assessment, get in touch and we will look at your actual tenant configuration and payment process rather than a generic checklist.