Permissions audited in January, $46,000 wire fraud stopped in March: a Waterloo Region accounting firm

Industry: Chartered accounting

Region: Waterloo Region, Ontario

Engagement: Baseline assessment, fraud prevention, ongoing managed partnership 

Year: 2026

Summary

A chartered accounting firm in Waterloo Region engaged OnionGrid for a readiness review ahead of tax season. The assessment found more than 40 stale cloud-sharing permissions still granting access to former contractors and a departed employee, DMARC configured but not enforced, and — most consequentially — no verification requirement for wire transfers or bank-detail changes.

Two months later, at the height of tax season, a bookkeeper received a convincing email appearing to come from a firm partner, requesting an urgent $46,000 wire to an “updated” vendor account. The email came from a lookalike domain differing by a single character, and it passed every technical check. The callback-verification policy OnionGrid had established in January is what stopped it. Nothing was transferred.

Engagement at a glance

Headline outcomes: $46,000 fraudulent wire request attempted · $0 actually transferred · 40+ stale permissions closed at onboarding · Client relationship renewed annually for 2 years

Phase one: the assessment found access nobody remembered granting

The firm was not responding to an incident. They engaged OnionGrid for a general readiness review before their seasonal peak — the sensible reason to run an assessment, and the reason this story has the ending it does.

More than 40 stale cloud-sharing permissions. Folders containing client financial data were still accessible to former contractors and to an employee who had left over a year earlier. Nobody had revoked the access because nobody had reviewed it.

No wire-transfer verification policy. Requests to change bank details or process a payment were actioned on the strength of an email. There was no required second step and no written expectation that staff should create one.

Email authentication only partially configured. SPF and DKIM records existed, but DMARC was published without enforcement — no p=quarantine or p=reject policy. The records were reporting, not protecting.

No dedicated incident-response contact. Any issue arising during tax season would have entered a general support queue, at exactly the time of year when hours matter.

Why an accounting firm is a seasonal target

Fraud against professional-services firms is timed. The attempt against this firm landed two months into tax season, and that is not coincidence — it is the operating model.

During peak season, a finance team is processing an unusual volume of payment requests, working longer hours, and under direct client deadline pressure. Verification feels like friction precisely when friction is least welcome. An attacker who understands the calendar knows that a request marked urgent in March will get less scrutiny than the same request in August.

This is why the timing of an assessment matters as much as its content. A policy written in January is a habit by March. A policy written during the busy season is a document nobody reads.

What OnionGrid built before tax season began

Five phases, closed out in January. The policy created in Phase 4 is the one that mattered two months later.

Phase 1 — Baseline assessment

A full review of cloud access, email security posture, and incident readiness, scoped specifically around the firm’s peak-season risk profile.

Phase 2 — Cloud permissions audit

More than 40 stale sharing permissions were identified and closed, covering former staff and contractors across the firm’s cloud file-sharing environment.

Phase 3 — Email authentication hardening

DMARC was deployed at p=reject alongside the firm’s existing SPF and DKIM records, closing the domain-spoofing gap and moving the configuration from reporting-only to enforcing.

Phase 4 — Wire-transfer verification policy

A mandatory callback-verification step was established for any bank-detail change or wire request, using a phone number already on file — explicitly never a number supplied in the email requesting the transfer. The policy was documented in writing and communicated to every member of finance staff.

Phase 5 — Dedicated account manager

A direct point of contact was assigned, with incident-response hours reserved through the tax-season window so nothing would be routed through a general queue during peak period.

March: the email that looked exactly right

1. Reconnaissance. The attacker had researched the firm’s partner names and at least one vendor relationship — information available through public filings and professional networking profiles.
2. Lookalike-domain request. An email arrived from a domain differing from the firm’s by a single character, written in a tone matching a partner’s usual style, requesting an urgent $46,000 wire to an “updated” vendor account.
3. Callback policy triggered. Per the January policy, the bookkeeper did not reply. She called the partner directly on the firm’s on-file number — not the one in the email signature.
4. Confirmed fraudulent and reported. The partner confirmed no such request existed. The domain was reported to the Canadian Anti-Fraud Centre and the registrar, and blocked internally.

Why DMARC did not catch this — and the policy did

The firm’s DMARC record at p=reject prevents an attacker from spoofing the firm’s own domain. This attacker never tried to. They registered a separate, similar-looking domain and sent authentic email from it, which is why nothing flagged.

The control that stopped a $46,000 loss was not technical. It was a written rule requiring a human phone call before any bank-detail change — a control that costs nothing to implement, depends on no vendor, and works regardless of how convincing the email is.

Results

Verification policy held. The callback step caught what email authentication alone could not.

DMARC enforcement live. Spoofing of the firm’s own domain is now rejected outright.

Cloud permissions locked down. No stale access remained for a former employee or contractor to exploit.

Dedicated incident response. A direct account contact meant the incident was escalated in minutes rather than routed through a queue.

Staff followed protocol. The training and the written policy did exactly what they were built to do, under time pressure, without supervision.

Fraud reported and blocked. The lookalike domain was reported and blocked before it could be reused against another target.

Key takeaways for accounting and professional-services firms

A wire-transfer verification policy is the highest-leverage control available against this fraud. It does not depend on any system detecting anything, which is exactly why it works when detection fails.

Cloud permissions rot quietly. Any firm that has changed staff or used contractors without a permissions review is carrying access debt it cannot see.

DMARC enforcement stops domain spoofing, not lookalike domains. Both controls are needed, and they cover different attacks.

Fraud attempts are timed to your busiest week on purpose. For accounting firms, that means tax season. Plan the assessment around the calendar.

The deliverable of an assessment is not the report. It is the policy and the habit the report leaves behind, still running months later without anyone thinking about it.

Controls that held during the attempt

• Callback verification for wire and bank-detail changes
• DMARC enforced at p=reject
• Cloud-sharing permissions reviewed and closed
• Dedicated account manager for direct escalation
• Documented fraud reporting process to CAFC and registrars

The ongoing relationship

Frequently asked questions

What is a wire-transfer callback verification policy? A written requirement that any request to move funds or change banking details must be confirmed by phone before it is actioned — using a phone number already held in company records, never a number provided in the request itself. It is the single most effective control against business email compromise because it does not rely on detecting fraud.

Why do fraud attempts spike during tax season for accounting firms? Because payment volume, time pressure, and the perceived cost of asking questions all peak simultaneously. An attacker marking a request urgent during peak season is exploiting a predictable drop in scrutiny, not getting lucky.

How often should a firm review cloud-sharing permissions? At minimum annually, and always after any staff or contractor departure. This firm’s audit found more than 40 stale permissions, including access held by an employee who had left over a year earlier — a typical finding where no review cycle exists.

Does DMARC protect against lookalike domain fraud? No. DMARC prevents others from sending mail that claims to be from your domain. It has no effect on a separate domain registered to resemble yours, because mail from that domain is not spoofed — it is authentic mail from a deceptively named sender.

What should a business do immediately after spotting an attempted wire fraud? Do not reply to the email. Confirm with the supposed sender using a known phone number. Preserve the email and its full headers rather than deleting it. Report the sending domain to the Canadian Anti-Fraud Centre and the registrar, block it internally, and if any funds have moved, contact the bank immediately — recall windows are measured in hours.