The deepfake got on the video call. It still couldn't sign the wire.

A finance employee joined a routine video call, saw and heard colleagues he recognised, and moved a very large sum out of the company. Every participant except him was synthetic. The control that survives this attack does not try to work out whether the people on the call are real, because that question no longer has a reliable answer.

What actually happens on the call

Picture a Thursday afternoon in a finance function at a large engineering firm. An analyst has an email in his inbox from a senior finance executive about a confidential transaction. He is suspicious of it, which is the detail everyone forgets when this story is retold. He suspects a phishing attempt, because he has been trained to suspect exactly this.

So he does what the training says. He does not act on the email. He joins a video conference to check.

On the call are the finance executive and several other colleagues. They look right. They sound right. They have the mannerisms of people he has worked with. They talk about the transaction, they answer in real time, and they ask him to proceed. His doubt resolves, because the evidence of his own eyes and ears is the strongest evidence a human being has ever had access to, and it has just told him the request is genuine. He proceeds. Reporting on the incident at the engineering firm Arup describes an employee releasing the equivalent of roughly 25.5 million dollars across about fifteen transfers before the fraud was identified.

Every participant on that call except the analyst was generated. He did the right thing at every step according to the guidance he had been given, and the guidance was the vulnerability.

That is the part worth sitting with. This was not a case of someone clicking a bad link or ignoring a policy. This was a control working exactly as designed, being satisfied by evidence it was never built to evaluate. Verification by video call was a good control for as long as making a convincing video of a specific person in real time was expensive. It stopped being a good control the moment that stopped being true, and nobody updated the runbook, because the runbook does not have a field for this.

How big is business email compromise, really?

The fraud family this belongs to is business email compromise, and it is large and unusually well measured for a fraud category, because victims are organisations that report.

The FBI Internet Crime Complaint Center recorded 24,768 business email compromise complaints in 2025 with reported losses of 3.046 billion dollars (FBI IC3 2025 Internet Crime Report). That is an average of roughly 123,000 dollars per reported incident, which tells you something important about the shape of the problem. This is not a high volume, low value fraud like card skimming. It is a low volume, high value fraud, and it targets a specific decision inside a specific department.

The IC3 also reports that a large majority of these losses, in the region of 86 percent, move by wire or automated clearing house transfer. That matters more than it sounds. Those rails are fast and they are hard to reverse. Where recovery happens at all, it usually happens because funds were frozen before they left the domestic banking system, which is a matter of hours rather than days.

On the deepfake dimension specifically, be careful with the numbers you will see quoted. Compilations of publicly reported deepfake fraud incidents circulate widely and are often presented as authoritative totals. They are not counts. They are aggregations of incidents that were reported publicly, in a category where most incidents are never disclosed, so they are floors of unknown tightness rather than measurements. Consultancy projections of deepfake enabled fraud reaching tens of billions of dollars annually within a few years are projections, built on assumptions that are usually not published. Treat both as directional. The IC3 complaint and loss figures are the firmest ground available, and they are firm enough to justify a control.

Why does deepfake detection keep losing?

The instinct, once you have seen this attack, is to buy a detector. Detection is not useless and this post is not going to tell you it is worthless. It is going to tell you why it cannot be the last line in front of an irreversible payment.

The generator is always newer than the detector

A detector is a classifier trained on the artefacts that current generation methods leave behind. Generation methods improve, the artefacts change, and the classifier degrades until it is retrained. This is a structural lag, not a quality problem, and it runs in the attacker's favour because they can test against public detectors before they attack and you cannot test against their next model.

Email authentication passes when the account is genuine

Sender authentication mechanisms confirm that a message came from a domain authorised to send it. When an attacker is operating a real, compromised mailbox inside the real company, every one of those checks passes correctly. They are functioning as designed. They are answering a question about the domain, and the question you needed answered was about the person.

Training collapses under authority and time pressure

The instruction to verify out of band assumes the employee has a channel that the attacker does not control and the standing to use it. In practice the employee is junior, the apparent requester is senior, the transaction is described as confidential, and the deadline is today. The Arup analyst did verify out of band. The out of band channel was the compromised one.

There is a general principle here that runs through most of this problem class. If your control depends on a human correctly judging the authenticity of a signal, and the cost of forging that signal is collapsing, your control is depreciating on a schedule set by somebody else. The way out is not a better judge. It is a control that does not require a judgement.

What exactly should be signed at the payment release endpoint?

Here is the shift. Instead of asking whether the request is genuine, require proof that only the authorising human can produce, and bind that proof to the specific payment rather than to the session or the login.

Concretely, the release step in your accounts payable or treasury workflow calls out for a signature before it will execute. What gets signed is not a login challenge and not a generic approval. It is a hash over the canonical representation of the payment itself.

payment = {
  "payment_id":    "AP-2026-118842",
  "beneficiary":   "Northwind Fabrication Ltd",
  "bank_routing":  "026009593",
  "bank_account":  "****4417",
  "amount_cents":  2550000000,
  "currency":      "USD",
  "value_date":    "2026-10-02",
  "requested_by":  "[email protected]",
  "approver_id":   "u_8842_finance_director"
}

challenge = sha256(canonical_json(payment))

The canonical serialisation matters and is the part implementations get wrong. Both the party displaying the payment and the party verifying the receipt must derive identical bytes from identical facts, or you have moved the ambiguity rather than removed it. Fixed key ordering, no insignificant whitespace, explicit integer amounts in minor units rather than floating point, and explicit currency. If two systems can disagree about the bytes, an attacker can live in the disagreement.

The approver's enrolled device signs that challenge. What comes back is a receipt: the challenge, the signature, the credential identifier, and a timestamp. The payment executes only if the receipt verifies.

Note what this does to the deepfake. It does not matter how good the synthetic executive on the call is. It does not matter that the mail came from a genuine mailbox. The attacker is not in possession of the approver's enrolled device, so no valid signature over this payload exists, and the release endpoint has nothing to accept. The question has changed from one that requires judgement to one that has a cryptographic answer.

This is the same control shape that applies to the neighbouring attacks in this family. When the fraud targets the vendor record rather than the payment, the same signature moves to the master data change, which is covered in vendor email compromise and the bank account that is not real. When it targets the beneficiary list, it moves to the account shape change, covered in the payee add is the real transaction.

How does a bank, an auditor or an insurer verify the receipt?

The verification is deliberately dull, which is the property you want in evidence. The verifier recomputes the hash from the payment facts they hold, checks the signature against the approver's registered public key, and checks that the credential and the timestamp are what they should be. There is no callback to a vendor, no availability dependency, and no requirement to trust the company that produced the receipt.

def release_is_authorised(payment, receipt, approver_public_key):
    expected = sha256(canonical_json(payment))
    if receipt["challenge"] != expected:
        return False, "receipt does not cover this payment"
    if not ed25519_verify(approver_public_key,
                          receipt["challenge"],
                          receipt["signature"]):
        return False, "signature invalid for this approver"
    if receipt["credential_id"] not in approver_enrolled_credentials:
        return False, "unknown credential"
    return True, "authorised"

The second check is the one that carries the weight. If an attacker intercepts a legitimate receipt for a 4,000 dollar invoice and replays it against a 2.5 million dollar payment, the recomputed hash does not match the challenge in the receipt, and the release fails. The receipt is not a token that grants approval generally. It approves exactly one payload and nothing else.

This offline property is what makes it useful after the fact. A year later, in a dispute with a bank, an insurance claim or an audit, the receipt still verifies against a published key. It does not depend on your log retention, and it is not your own account of your own behaviour, which is the weakness of every audit trail written by the party with an interest in it.

What does the finance team actually experience?

Very little changes for legitimate work, and this is worth being precise about, because finance teams have been promised low friction by every vendor that ever sold them a control.

The approver receives the release request as they do now. They see the amount, the beneficiary and the account on their own device, rendered from the canonical payload rather than from whatever the requesting screen chose to display. They confirm with the same gesture that unlocks their phone. The payment moves.

The separation of the display from the requesting system is not incidental. If the screen that shows the payment and the key that signs it can be compromised together, an attacker who controls the display can show one payment and have another one signed. That failure has a dedicated treatment in the post on blind signing and what you see is what you sign, and the short version is that the device rendering the payload for the human should not be the device the attacker is already inside.

The other thing that changes is what exists afterwards. Today, if someone asks who approved a payment, the answer is a row in an application database saying that a user account clicked a button. That row was written by the application, it can be edited by anyone with database access, and it means nothing to a third party. After, the answer is an artefact the approver produced with a key only they hold.

Which payments deserve this control?

Not all of them, and any vendor telling you to gate everything is not thinking about your operations team. The useful axis is not payment size alone. It is reversibility multiplied by novelty.

Recurring payments deserve a specific note because they are the most common objection. They run under a scoped authorisation the human signs once, carrying explicit constraints: a ceiling, a set of approved beneficiaries, an expiry. Anything that falls outside the scope prompts for a fresh signature. This is the same delegation shape used for agents, and the constraint fields are the same ones.

Does this work if the fraudster fools two approvers?

Partly, and the honest answer here is more interesting than a marketing answer would be.

Dual authorisation is the standard control for large payments, and it rests on an assumption that most implementations quietly violate: that the two approvals are independent events. When both approvals are clicks inside browser sessions, and a single adversary in the middle phishing kit has harvested both sessions, the two approvals share one root of trust and the control has collapsed to one. Two stolen sessions produce two clicks. That specific failure is treated at length in dual control is not dual when both approvers are behind the same phishing kit.

Device bound signatures restore the independence, because the attacker now needs two separate enrolled devices rather than two session cookies. What it does not restore is independence of judgement. If both approvers watch the same convincing synthetic executive and both choose to sign, you have two valid signatures over a fraudulent payment. The control binds intent. It does not audit judgement, and no cryptographic control ever will.

Honest limits

• It does not stop a knowingly deceived approver. If a real, authorised human is persuaded to sign a payment they understand and intend to make, the signature is valid and the money is gone. This control removes the impersonation class. It does not remove persuasion.
• Enrollment is the trust bottleneck. Somebody, once, confirms that this key belongs to this person. An attacker who controls enrollment controls everything downstream. Enrollment deserves the strongest process in the whole system.
• A compromised device is a compromised signer. Binding to hardware raises the cost substantially. It does not create an uncompromisable endpoint.
• Coverage is a policy decision. Gate too little and the fraud routes around you into the ungated path. Gate too much and staff will build a workaround, which is worse than no control because you will believe you have one.
• Collusion is out of scope. Two colluding approvers with their own devices produce two valid signatures. Separation of duties and monitoring address that, and this composes with them rather than replacing them.
• Single approver dependency. If one person holds the only enrolled device for a payment class, they become an availability risk. Enroll at least two authenticators per approver so that a broken phone never becomes a reason to bypass the control.

What to do this week

1. Pull the last twelve months of payments and mark every one that went to a beneficiary paid for the first time, or to a bank account changed within thirty days of payment. That is your exposed set, and it is usually a small fraction of volume and a large fraction of risk.
2. Find the release endpoint in your accounts payable or treasury system and write down exactly what it currently checks. In most organisations the honest answer is a session and a role.
3. Write down the canonical payload for a payment at your organisation: the fields that must not change between display and execution. Get treasury and engineering to agree on it before anyone builds anything.
4. Check whether your dual approval implementation involves two sessions or two devices. If it is two sessions, you have one control, not two.
5. Establish who is allowed to enroll a new approver device and what evidence they require. This is now your most sensitive process.
6. Ask your cyber insurer what evidence they want after a social engineering loss, and whether a per payment authorisation artefact changes your position. The answers are usually more encouraging than people expect.
7. Stop telling staff to verify by video call. Update the runbook to say plainly that video and voice are no longer evidence of identity, and give them the control that replaces the judgement. Retiring bad guidance is free and most organisations have not done it.

If you want to see the release gate end to finish before designing yours, the signing demo in Manav Labs walks through payload, signature and offline verification, and the developer documentation covers the integration at the release endpoint.

Frequently asked questions

Does this slow down legitimate payments? Barely. A legitimate approver confirms on their own device with the gesture that unlocks their phone, typically in under fifteen seconds. Almost all payment volume in a normal organisation runs under standing scoped authorisations and prompts nobody. The friction concentrates on new beneficiaries and large amounts, which is exactly where you want it.

What about recurring and automated payments? They run under a scoped authorisation the human signs once, with explicit constraints such as an amount ceiling, a list of approved beneficiaries and an expiry date. Payments inside that scope execute without prompting. Anything outside it, including a changed bank account, requires a fresh signature bound to the new facts.

Does this replace our ERP, treasury system or bank? No. It gates one action inside the workflow you already run and emits a receipt. Your ERP, treasury platform and banking rails are unchanged. The integration is at the release step, not in the money path.

Is this different from multi factor authentication on the finance system? Yes, and the difference is the whole point. Multi factor authentication proves someone opened a session. Every action taken afterwards inherits that session, including one taken by an attacker who stole it. A per payment signature binds the approval to the specific amount, beneficiary and account, so a stolen session grants nothing.

What if the approver loses their phone? They use their second enrolled authenticator, which is why you enroll two. Recovery is the genuinely hard part of any device bound scheme and it deserves a designed path rather than an exception, because attackers target recovery precisely because it is the weakest route into a strong system.

Could the attacker just deepfake the approver instead of the executive? They can appear as the approver on a call, but appearing as somebody does not produce their device signature. The relevant target then becomes enrollment and recovery rather than the payment itself, which is why both of those processes need to be stronger than the payment control they support.

Does the receipt help after a loss, or only prevent one? Both. Prevention is the primary value. The secondary value is that for every payment that did execute you hold an artefact showing which human authorised exactly what, verifiable by a third party without trusting your logs. That changes conversations with banks, auditors and insurers.

Sources

1. FBI Internet Crime Complaint Center, 2025 Internet Crime Report (business email compromise complaint counts, loss totals, and the share moving by wire or ACH): ic3.gov annual reports
2. FBI Internet Crime Complaint Center, public service announcements on business email compromise and the Recovery Asset Team: ic3.gov public service announcements
3. Contemporaneous reporting on the Arup incident, including the transfer count and approximate value: Financial Times and subsequent coverage
4. Surfshark research, compilation of publicly reported deepfake fraud incidents (used here as a floor, not a total): surfshark.com/research
5. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator binding and verifier impersonation resistance: pages.nist.gov
6. W3C Web Authentication (WebAuthn) Level 3 specification, on assertion signatures over a supplied challenge: w3.org
7. Uniform Commercial Code Article 4A, funds transfers and commercially reasonable security procedures: law.cornell.edu

Stop asking whether the executive on the call is real. Ask whether the approver's device signed this exact payment. Only one of those questions has an answer a deepfake cannot fake.

This lesson is part of Proof of human intent, the guide to the whole problem area.