Aventura, Florida · serving clients across the United States (305) 404-9404Toll-free (800) 767-8566Emergency? Get a call within 1 hour
Investment management Illustrative engagement

Trained finance staff stop a deepfake-backed wire request at a Connecticut investment firm

An investment firm in Connecticut with about 80 staff, a leader in its segment.

Scale
About 80 staff, 6 finance and operations staff, 3 approvers, 1 Microsoft 365 tenant
Engagement
Training program over 4 months, then quarterly drills

The challenge

The firm moves large sums for clients and funds by wire. Its operations staff received instructions by email and, increasingly, by phone and video, and the written procedure relied on each person's judgment. A convincing request that appeared to come from a senior partner or a known administrator would have met a busy team with no rehearsed response.

An investment firm in Connecticut, a leader in its segment, moves client and fund money by wire every day. Its operations team of six handles instructions that arrive by email and, more and more, by phone and video. The client is not named on this page. This is an illustrative case, built from patterns we see in this kind of firm.

The firm's procedure depended on judgment. An associate who received a request that looked and sounded right would approve it, and a cloned voice of a senior partner is precisely the thing that makes a request look and sound right. The partners wanted a team that would stop a convincing fake and a procedure that did not rely on anyone spotting one.

We trained by role. Operations and finance learned payment-change fraud and the callback rule. Executives and assistants learned how attackers gather public detail about them. The help desk learned to resist urgent reset requests, and new hires received a first-week module. Monthly phishing simulations and a one-click report button turned reporting into a habit, with a same-day reply to every report.

We also rehearsed the moment that matters. Every quarter we staged an email and a voice call asking for a changed instruction, timed the response and wrote up what happened. The written rule never changed: every new or changed instruction is verified by a callback to a number already on file, and any wire above a set limit needs a second approver who is not the person who entered it. Mail authentication at enforcement and phishing-resistant sign-in for approvers backed this up.

In the modeled outcome, a request supported by a cloned partner voice and a lookalike domain reached an associate, who followed the callback rule, reported it within minutes and held a wire of about $2.4 million. We present it as an example, not a promise: training and controls make a faked instruction insufficient to move money, but they do not detect every fake. Related reading: our Security Awareness Training service and the article on deepfake-proof payments.

What our team delivered

  • Role-based training for operations and finance, executives and assistants, the help desk and new hires, in short sessions
  • A written payment-change rule: every new or changed instruction is verified by a callback to a number on file, never one taken from the request, and logged
  • A second approver for every wire above a set limit, in a payment tool where the person who enters a wire cannot release it
  • Monthly phishing simulation with immediate coaching, and a one-click report button in Microsoft 365
  • A quarterly wire-fraud drill with a staged email and a staged voice call, timed and written up
  • Mail authentication at enforcement on the firm's domains, lookalike-domain monitoring and phishing-resistant sign-in for approvers

Result

In this illustrative case, a request supported by a cloned partner voice and a lookalike sender domain reached an operations associate, who followed the callback rule, reported it within minutes, and held a wire of about $2.4 million. That is a modeled outcome, not a promise: training and controls reduce the chance that a faked instruction moves money, they do not detect every fake.

Get this for your company

Related services with fixed prices and a written scope.

Insurance-ready bundle

The three things cyber insurers and clients ask for most: an external assessment, a phishing simulation for 25 users and a disaster recovery plan.

$5,400 per bundle, phishing simulation for 25 users

Show 3 more

Managed IT and security (MSP)

One monthly price per team member: help desk, device management, patching, backup monitoring and security basics.

$100 per team member, per month

Phishing simulation

A realistic, authorized phishing campaign with short training for anyone who clicks. Priced per person.

$12 per user, per campaign

Managed security monitoring

Endpoint detection and response watched by our analysts, priced per device.

$18 per endpoint, per month

After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.

No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).

Payment-change callback flow

A request to change bank details is never acted on from the request itself. Someone rings the number already on file, a second person approves, the outcome is written down, and only then is the payment released or held. If any step fails, the old details stay in use.

Payment-change callback flowFlow chart in five steps: a payment-change request arrives; someone calls back on the number already on file; a second approver confirms; the change is recorded with who, when and which number; the payment is paid or held. A failure at any step leads to holding the payment, keeping the old details and escalating to the named owner.From request to payment1Change requestArrives by email,call or portal.2CallbackRing the numberalready on file,never the one inthe request.32nd approverA different personconfirms thechange.4RecordedWho, when andwhich numberwas called.5Pay or holdPay on new detailsonly if everystep has passed.Any step fails, or nobody can be reached: hold the paymentKeep the old details in use and escalate to the named owner.Illustrative control. The callback number comes from existing records, never from the request.

A wire change is never approved on the request alone

An email or a phone call can be forged, and a cloned voice or face can pass for a colleague. The request is held, the requester is called back on the number already on file, and a second approver signs off before the payment is released or rejected. Every step is logged.

A wire change is never approved on the request aloneA wire-change request arrives by email or voice call and may be a deepfake. The payment is placed on hold. A person calls back the requester on the number on file, not the one in the message. A second approver reviews the request. The payment is then released or rejected, and both outcomes are written to an audit log. Wire requestemail or voiceHoldno release yetCall backnumber on file2nd approverseparate personReleasepayment sentRejectescalate to securityAudit logwho, when, outcomeUrgent · new account detailsVoice can be cloned1 · request arrives; the sender is not trusted2 · hold: no payment on a message alone3 · call back the number on file, not the one in the message4 · second approver, then release or rejectOut-of-band verificationDual approvalEverything logged

Mail that keeps flowing

Incoming mail is authenticated and scanned before it reaches anyone, mailboxes are copied across three regions so a server failure goes unnoticed, and outgoing mail leaves signed and encrypted.

Mail that keeps flowingDiagram of enterprise email flow. Inbound mail from an internet sender reaches the MX edge server running Postfix, where SPF, DKIM and DMARC checks light up in sequence, then passes a spam and malware filter; a spam message is diverted to quarantine. Clean mail is delivered to a mailbox cluster, a database availability group with copies in three regions. On a loop the active server in region A fails and the copy in region B activates automatically, so the next message is still delivered. Outbound mail from the user's mailbox is DKIM-signed and sent over an encrypted TLS connection to the recipient. INBOUNDOUTBOUNDSenderInternetMX edgePostfixSPFDKIMDMARCThreat filterSpam · malwareQuarantineMAILBOX CLUSTER · DAGRegion ARegion BRegion CActiveCopyActiveCopyMailboxUser inboxDKIM signingTLS encryptedRecipientSPFDKIMDMARCSPFDKIMDMARCOffline

DMARC: from watching to rejecting

Share of mail claiming the domain that passes DMARC (SPF or DKIM aligned), week by week. In the monitoring phase (p=none) reports reveal forgotten senders; each one gets SPF and DKIM fixed. Quarantine sends failures to spam, reject refuses them at the receiving server. Illustrative figures.

DMARC: from watching to rejectingLine chart over 12 weeks. DMARC pass rate climbs from 61 percent in week 1 to 78 percent at the end of the p=none phase, 94 percent at the end of p=quarantine, and 99.1 percent in week 12 under p=reject.DMARC pass rate, 12 weeksp=nonemonitor onlyp=quarantinefailures to spamp=rejectfailures refused50%60%70%80%90%100%W1W2W3W4W5W6W7W8W9W10W11W1261%78%94%99.1%Week number on the x axis. Pass rate is measured on aggregate (rua) reports.

Do you know if your company is safe?

Speak with a security engineer today. The first assessment call is free and confidential.

CallFree assessment