Vendor Payment Fraud and Why Verification Keeps Failing
AI voice cloning and callback manipulation are breaking traditional vendor payment verification. Learn why AP teams must verify identity, not channels.
The phone call is no longer the safe channel
In January 2026, Swiss public broadcaster SRF reported that an entrepreneur in the canton of Schwyz had lost several million Swiss francs to fraudsters who used AI-generated voice audio to impersonate a trusted business partner across a series of phone calls conducted over roughly two weeks. The deception was discovered only after multiple transfers had moved to a bank account in Asia.
The Swiss case is geographically distant from most US-reported vendor fraud, but the mechanism is global, and the underlying control failure is one every accounts payable team in the world has been told to depend on. For more than a decade, when a vendor requests a payment-detail change, Accounts Payable (AP) is supposed to verify by phone, using a number already on file. That step was meant to catch a forged email. It no longer does, because the phone has become a place where the attacker is waiting too.
Two engines that broke the callback model
The first is rarely named in fraud advisories. Anti-impersonation firm Doppel notes that the more common attacker win in vendor payment scams is not voice cloning but controlling the callback path AP will use. The attacker plants the number. The call still happens. The verification still feels complete. The person who answers is the attacker.
Alternatively, the second engine is AI voice cloning itself. Consumer Reports’ 2025 report, AI Voice Cloning: Do These 6 Companies Do Enough to Prevent Misuse?, found that four of six tested products had no meaningful barriers to cloning someone’s voice without consent. That matters because once safeguards are thin, the practical barrier becomes the amount of source audio an attacker needs. Three seconds of publicly available audio is now enough to produce a usable clone. Even when AP reaches the right number, the voice on the line is no longer a credential.
Together, the two engines strip the callback model of both assumptions it was built on: that the number AP dials is reachable only by the vendor, and that the voice that answers belongs to the vendor.
Where the old controls stop working
Industry guidance to verify wire details before release names the right instinct, but the rest of the picture is harder to admit. Callback verification fails when the attacker chooses the number. Voice recognition fails when voice can be reproduced from three seconds of audio. Awareness training does not close the gap either, because even when employees are warned and detection alerts fire, roughly one in four users still acts on the fraudulent request.
Each failure rests on the same flaw. AP is trying to confirm a person through a channel the attacker can shape, impersonate, or both. Adding more channels to that model does not solve it. It gives the attacker more channels to occupy.
Verifying the person, not the channel
The question stops being whether the channel seems trustworthy and becomes whether the human on the other end of the conversation has authenticated through a credential the attacker cannot reproduce.
That question survives voice cloning, because no clone can satisfy a passkey or a push to the real vendor's authenticator. It survives a planted callback number, because verification is no longer riding on whichever line AP dialed. It survives the long patient campaign that broke the Schwyz case, because no number of friendly calls over two weeks builds a credential the attacker can present.
Where Traceless Verify fits
Traceless Verify is built around exactly that question. When a vendor contacts AP about a payment-detail change, by phone or by chat, an AP team member triggers a verification request from inside the platform they already use.
The person on the other end has to authenticate through a credential they hold. That could be a biometric passkey, Verified ID, Okta, Duo, Entra, or another mechanism the vendor's organization supports. That verification can work both ways, which means the vendor can confirm they are talking to the real AP team, closing the loop in the other direction.
Identity & Authentication Integrations
The verification does not depend on AP holding the right number, recognizing the voice, or trusting the channel. It binds the human to an authenticated identity at the moment the request is made, which is the moment the older controls were always trying, and increasingly failing, to secure. The audit record of who confirmed what falls out of the same step, rather than being reconstructed afterward from email chains and call logs.
A payment-detail change is not vendor maintenance. It is the moment someone can redirect a real payment by impersonating a person AP has every reason to trust. The verification problem has not changed. The channels through which AP can answer it have. The reliable answer now is to verify the person, not the inbox, not the invoice, not the number on the contact card.
Prevent impersonation attacks
Start with one integration, validate quickly, and expand across your environment.