Deepfake RWA Fraud: Stopping Fake Issuer Wire Calls

What is deepfake RWA fraud?

Deepfake RWA fraud is payment fraud aimed at transactions involving real-world assets, commonly shortened to RWA. These assets may include tokenized money market funds, government securities, private credit, commodities, or other claims represented through blockchain-based systems. The fraudster does not necessarily hack the token or its smart contract. Instead, the attacker impersonates a trusted person and redirects the conventional payment used to buy or settle the asset.

A typical target is a treasury employee, fund administrator, family office, broker, or institutional investor preparing a large subscription. The victim believes that an issuer representative, placement agent, lawyer, transfer agent, or escrow officer has supplied valid instructions. The payment instead reaches an account controlled by criminals, a recruited money mule, or a shell company with a name resembling the legitimate beneficiary.

This distinction matters when discussing products associated with BUIDL, ONDO, PAXG, or XAUT. Those tickers refer to different structures and do not share one subscription process. ONDO is also used as a token ticker within the Ondo ecosystem, while PAXG and XAUT represent tokenized gold products. A fraudulent wire instruction mentioning any of them does not prove that the underlying protocol or issuer was breached. Attackers often exploit the recognizable name around an otherwise traditional bank payment.

Why the financial risk is unusually severe

The obvious risk is losing the full principal of a subscription. Large wires may pass through several mule accounts within hours, be converted into crypto, or leave the receiving jurisdiction before the victim notices. A bank can attempt a recall, but a recall is a request rather than a guaranteed reversal. Recovery becomes less likely as money is split, withdrawn, or transferred onward.

The February 2024 Hong Kong case shows the potential scale. Police said an employee at a multinational company joined a video conference that appeared to include the company chief financial officer and other colleagues. After the call, the employee reportedly authorized 15 transfers totaling about HK$200 million, then worth roughly $25 million, to five bank accounts. Engineering firm Arup later confirmed that it was the victim, while stating that its internal systems had not been compromised.

Deepfakes sit inside the broader problem of business email compromise, impersonation, and authorized payment fraud. Public loss reports often combine several methods, so no reliable public figure isolates the annual amount attributable only to AI-generated voices and faces. What is known is that business email compromise has produced multibillion-dollar reported losses over time. For an individual enterprise, one successful instruction can create an immediate eight-figure or nine-figure exposure.

• Principal loss: the subscription money may never reach the issuer, so the victim receives no token or legal interest.
• Operational loss: trading, treasury, legal, and incident-response teams may spend weeks tracing the payment and preserving evidence.
• Legal uncertainty: contracts, bank terms, insurance exclusions, and employee authority determine who ultimately bears the loss.
• Secondary compromise: documents sent during the fake onboarding process can expose passports, signatures, beneficial-owner records, and wallet addresses.
• Reputational damage: delayed disclosure can weaken relationships with investors, banks, auditors, and regulators.

Historical losses also show why a deepfake should not be treated as a novelty that only fools careless users. The decisive failure is usually procedural. One employee can receive an urgent request, see apparently familiar executives, and follow a payment workflow that lacks independent verification. AI makes the story more convincing, but weak approval controls make the loss possible.

How a fake issuer call becomes a fraudulent wire

The attacker begins with reconnaissance. Public conference videos, earnings calls, podcasts, webinars, social posts, regulatory filings, and employee profiles reveal voices, faces, job titles, business relationships, and upcoming transactions. A few minutes of clean audio may be enough for some cloning tools to imitate vocal characteristics. More material can help reproduce speech patterns, vocabulary, and visual mannerisms, although quality varies and artifacts may still appear.

Next comes access or positioning. The criminal may compromise an email account, register a lookalike domain, buy a sponsored search result, create a fake onboarding portal, or impersonate an intermediary on a messaging service. The victim may believe that they called the issuer because they dialed a number shown in a fraudulent email or on a cloned website. In reality, the attacker controlled the starting point and every later confirmation.

During the call, AI-generated audio can be routed through voice over internet protocol software, a virtual audio device, or real-time voice conversion. The operator speaks normally, software alters the voice, and the modified output enters a telephone or conference application. Video may use face replacement, lip synchronization, prerecorded footage, or a mixture of synthetic and genuine material. Other supposed participants can be silent recordings, bots, or accomplices who reinforce the same request.

The payment story is designed to sound operationally plausible. The fake issuer representative might say that the usual account is under review, that a new escrow provider is handling the closing, or that settlement must occur before a cutoff. A second cloned voice may appear to represent the lawyer or escrow officer. The attacker then sends matching invoices, subscription documents, bank letters, or email approvals, making several compromised signals look like independent evidence.

A believable attack chain

• An investor searches for an issuer contact or replies to a compromised email thread about an RWA subscription.
• A familiar-sounding representative answers and confirms the transaction amount, legal entity, and expected closing date.
• A video meeting displays a recognizable executive or colleague, sometimes alongside several supporting participants.
• The caller introduces changed escrow details and explains the change with urgency, confidentiality, or regulatory language.
• The victim checks the instructions by replying to the same email thread or calling a number included in the new documents.
• Approvers release a multimillion-dollar wire, believing that multiple confirmations have occurred.
• The real issuer later reports that no payment arrived, by which point the receiving account may be empty.

Attackers may also substitute a crypto wallet address rather than a bank account. That variant overlaps with wallet address poisoning and clipboard manipulation. Blockchain transfers generally lack a bank recall process, which can make recovery even harder. Whether settlement uses a wire or an onchain transfer, changed destination details should be treated as a new high-risk instruction rather than a routine amendment.

Why a video call is no longer proof of identity

Video used to provide strong psychological reassurance because reproducing a known person in real time was expensive and difficult. That assumption is no longer safe. Consumer hardware and widely available software can generate a face, alter a voice, blur artifacts, and route the result into common meeting platforms. A poor connection can even help the attacker because compression, low resolution, muted participants, and audio delays make anomalies seem normal.

The Hong Kong case demonstrated that several apparently familiar people in one meeting can all be fabricated. Group consensus is not useful if every participant and invitation came through the same compromised path. An employee who recognizes the CFO's face is observing a likeness, not verifying control of the CFO's identity, device, corporate account, or legal authority.

WPP disclosed a separate attempted fraud in 2024 involving impersonation of chief executive Mark Read. According to the company's warning, attackers created a fake WhatsApp account, used a voice clone, and used public footage in a Microsoft Teams meeting. They tried to solicit money and personal details while proposing a new business setup. The attempt failed, but it showed how public media and ordinary collaboration tools can be assembled into an executive impersonation.

Visual clues can still contribute to an investigation, but they should not authorize a payment. Unnatural blinking, mismatched lighting, lip-sync errors, unusual phrasing, or refusal to move the camera may raise suspicion. Their absence proves little because generation tools improve, conference compression conceals defects, and a skilled attacker can mix authentic footage with synthetic segments. Detection software also produces false positives and false negatives, so it should be one layer rather than the final control.

Signals that deserve a payment hold

• The beneficiary account, bank, country, escrow agent, or wallet address changed after onboarding.
• The caller introduces urgency tied to a closing window, market event, audit, or compliance deadline.
• The supposed executive discourages contact with legal, compliance, the bank, or another known employee.
• The meeting invitation, telephone number, or document portal was supplied in the same message as the payment change.
• Participants avoid transaction-specific questions or explain inconsistencies as confidential internal matters.
• The beneficiary name does not exactly match the legal entity named in executed subscription documents.

Out-of-band verification versus in-band confirmation

In-band verification means checking a request through the same channel or trust path that delivered it. Replying to the email that supplied new bank details is in-band. Calling the telephone number printed on the attached instruction is also in-band because the attacker may control both. Moving from email to video is not truly independent when the email invitation leads to an attacker-run meeting.

Out-of-band verification starts from contact information established separately before the disputed request. Examples include calling an issuer's known main switchboard from an approved vendor record, contacting a relationship manager already stored in the treasury system, or opening the issuer portal from a saved bookmark rather than a message link. The goal is not merely to use another app. It is to leave the potentially compromised chain and rebuild contact from a trusted source.

Independence also applies to people and data. If one employee receives instructions and asks a colleague to approve the same PDF, two people have reviewed one attacker-controlled artifact. Stronger verification assigns a second employee to retrieve the standing settlement instructions from a protected system, contact the issuer independently, and compare each material field. Neither approver should rely on caller ID, since displayed numbers can be spoofed.

• Weak check: reply to the sender asking whether the new account is correct.
• Weak check: call the number in the changed wire instruction.
• Weak check: ask the same video participant to show identification on camera.
• Stronger check: call a previously recorded issuer number and request transfer through the main switchboard.
• Stronger check: confirm the change separately with the escrow bank, counsel, or administrator using independently sourced details.
• Stronger check: compare the instruction with signed documents and require a controlled amendment when any field differs.

No channel is perfect. A stored contact may be outdated, an employee account may be compromised, and a switchboard could make an error. Out-of-band verification reduces correlated failure by forcing an attacker to compromise more than one independent system or relationship. High-value transactions should combine it with dual approval, least-privilege access, payment limits, and documented change controls.

A callback-to-issuer procedure that closes the loop

For treasury teams, the practical objective is to prove that the genuine issuer or authorized administrator expects the exact transaction being released. A callback is effective only when the team chooses the contact path independently. Calling a number supplied by the requester, trusting an incoming call, or relying on displayed caller ID leaves the loop open.

Before any subscription request

• Record the issuer's legal name, authorized contacts, main switchboard, administrator, transfer agent, escrow provider, and approved bank details in a restricted system.
• Source those details from executed agreements, regulatory records, an authenticated issuer portal, or an existing verified relationship, not from a new payment email.
• Define which roles may request a payment change and require two employees to approve any change involving a beneficiary, bank, account number, SWIFT code, routing number, or wallet.
• Agree that the issuer will not demand secrecy or bypass the callback process, even near a closing deadline.

When instructions arrive

• Pause the payment if any destination field differs from the standing record. Do not edit the master record from the incoming document.
• Have a second employee retrieve the established issuer number without using links, signatures, attachments, chat messages, or search results supplied during the transaction.
• Place an outgoing call to the issuer's known main switchboard. Ask the operator to connect the team to the previously authorized representative rather than requesting a direct number from the original caller.
• State the internal transaction reference and ask the representative to identify the investor entity, asset, amount, currency, expected date, beneficiary legal name, bank, account ending, and reason for any change.
• Read back every material settlement field. Do not accept a general response such as the details are correct.
• End the first call and independently contact the escrow provider, administrator, or counsel using its previously verified details. Confirm that it recognizes the same transaction and beneficiary.
• Require a formally executed amendment for changed instructions, then validate the signatures or digital approval through the established document process.
• Apply a cooling-off period for newly changed accounts where operations permit, and have both approvers document the sources, time, contacts, and fields checked.

This closes the loop because the transaction begins with the investor's trusted directory, reaches the genuine issuer through its established switchboard, and returns with transaction-specific information that can be matched to controlled records. A voice match or recognizable face is unnecessary. The procedure verifies authority, destination, and transaction details rather than appearance.

If a suspicious payment has already been sent, contact the sending bank's fraud desk immediately and request a wire recall or freeze. Notify the receiving institution when permitted, preserve emails, call logs, headers, documents, account details, and meeting records, and involve legal counsel, insurers, and law enforcement. Do not continue engaging the suspected attacker from ordinary corporate accounts, since doing so can reveal the response plan or destroy evidence.

Track RWA security signals with context

RWA markets and the fraud techniques surrounding them change quickly, while incident reports often mix genuine protocol failures with offchain impersonation. Zippfeed organizes relevant headlines with bullish, neutral, or bearish sentiment scoring and an importance rating, helping security and treasury teams separate market noise from developments that may justify a control review. Sentiment is context, not proof, so payment verification must still rely on independently established procedures.