An employee of a Hong Kong engineering firm received a message that appeared to come from the company’s chief financial officer requesting several financial transfers. The employee was suspicious but was reassured in a video conference with the CFO and colleagues.
Every participant, except the employee, was an AI-generated deepfake, and the company lost $25 million.
Deepfakes are AI-generated or manipulated audio, images, or video that falsely depict a real person. The fraudsters targeting the Hong Kong company didn’t need to penetrate the network. They just persuaded an honest employee to act on instructions from fabricated versions of trusted colleagues.
Payment law often asks who initiated the transfer, not what induced it. As artificial intelligence tools improve and spread, deepfake fraud becomes more foreseeable, potentially affecting what verification procedures are reasonable.
Fraudulently Induced
If a fraudster steals credentials and transfers money, the transaction generally is considered unauthorized. The Electronic Fund Transfer Act and its implementing regulation, Regulation E, protect qualifying unauthorized consumer transfers. The Consumer Financial Protection Bureau explains that a transfer may remain unauthorized when a fraudster obtains account information through deception and initiates the transfer.
The analysis becomes harder when a consumer or authorized employee is the one who actually initiates the transaction. In false pretenses or social engineering fraud, a fraudster uses a fabricated identity or story to manipulate the victim into sending money. Although the fraud was what induced the transaction, the bank may argue that it was authorized because the customer directed that the money be sent.
Deepfakes sharpen the distinction because authentication may confirm who operated the account, but not the executive, vendor, or relative who appeared on a call and prompted the payment. A transfer therefore can satisfy every account-level security measure even though the decision to send it was induced by a fabricated identity.
Bank Liability
For commercial transfers, the analysis often begins with Article 4A of the Uniform Commercial Code. It distinguishes between an order the customer authorized and one initiated without authorization. An unauthorized order may still be effective against the customer if the bank followed an agreed, commercially reasonable security procedure and acted in good faith.
In Patco Construction Co. v. People’s United Bank, unusual transfers generated high-risk scores without an adequate response, and the court found the bank’s procedures to be commercially unreasonable. By contrast, the court in Choice Escrow & Land Title, LLC v. BancorpSouth Bank held for a bank that followed its agreed procedure after the customer declined stronger dual control, which would have required two users to approve payments.
Those decisions involved orders disputed as unauthorized. If an employee submits a payment order after being deceived by a deepfake, the order may still be authorized. The dispute may instead concern the employee’s authority, internal limits, or restrictions communicated to the bank.
Deepfakes also expose a limit in Article 4A’s framework. A security procedure verifies that an order came from the customer or detects errors in its transmission or content. But it doesn’t necessarily verify the person who instructed the customer’s employee.
A plaintiff seeking to hold the bank liable must identify a duty that applies to an authenticated order. It might arise from the account agreement, written restrictions, representations about fraud monitoring, or other laws. The bank can see unusual amounts, new recipients, quick transfers, and departures from an account’s usual history. It may argue that it saw the transaction but not the deepfake, and the business may respond that the transaction itself required review.
The receiving institution presents a related issue. The US Court of Appeals for the Fourth Circuit held that the institution couldn’t be liable under Article 4A without actual knowledge that the beneficiary’s name and account number identified different people.
The fact that better procedures might have revealed the mismatch didn’t establish actual knowledge. A deepfake doesn’t change that statutory requirement, and liability still depends on what the receiving institution actually knew when it processed the payment.
Another federal court applied the same actual-knowledge requirement to a CFO-impersonation scheme earlier this year in Marks v. Citibank N.A., in which the plaintiff sent $1 million using instructions from a spoofed CFO email.
The court held that fraud alerts and allegedly deficient account-opening procedures showed only that the receiving bank should have known of the mismatch, not that it actually knew. The court also dismissed the negligence claim because the receiving bank owed no duty to the plaintiff, who wasn’t its customer.
Preventing the Loss
Deepfakes may change what reasonable verification requires, but their use doesn’t establish liability on its own. Payment systems generally verify the person initiating a transaction.
In a deepfake scheme, however, the fraud occurs one step earlier when someone is deceived into initiating it. The payment may be real, the credentials valid, and every technical control satisfied, even though the request rests on a fabricated identity.
Liability will depend on whether any party had both a duty and a practical opportunity to detect the deception, and whether doing so would have prevented the loss.
This article does not necessarily reflect the opinion of Bloomberg Industry Group Inc., the publisher of Bloomberg Law, Bloomberg Tax, and Bloomberg Government, or its owners.
Author Information
Joseph L. Kish is a shareholder at Segal McCambridge and chairs its complex commercial litigation and Technology and cyber risk practice groups.
Kathryn Lapin is an associate at Segal McCambridge focusing on complex commercial litigation and product liability defense.
Interested in writing? Review our author guidelines and submit pitches to Insights@bloombergindustry.com.
