Blog · November 7, 2026

Detecting Synthetic Voices on Calls

Cloned and converted voices now reach call centers and finance teams. A score that says a voice may be synthetic is useful when it triggers one more verification step, and harmful when it is treated as a verdict. This guide covers how to use it as the first, and what not to do.

Saina · November 7, 2026 · 6 min read

A caller sounds like the finance director and asks for an urgent transfer. A customer calls the bank to raise a daily limit. Both used to be checked by recognising the voice, or by asking a few security questions the caller could answer from memory. Voice cloning and voice conversion tools have made the first check weak, and social media has made many of the second kind guessable.

A synthetic-voice score, a probability that the speech was generated or converted by a computer, can help. It helps only if it is wired in the right place: as a reason to ask for more proof of identity, never as proof of fraud on its own. This post covers what such a score can and cannot tell you, how to connect it to step-up verification, and the mistakes to avoid. It uses Saina Helm 2 Omni for the examples; the design applies to any spoof detector.

What a spoof score measures

A spoof detector listens to a short stretch of speech and estimates whether it came from a human voice or from a text-to-speech or voice conversion system. It says nothing about who is speaking. A real human can still be a fraudster, and a synthetic voice can be legitimate (an accessibility tool, a company's own voice bot calling back).

Omni's model card is explicit on this: identifying people, faces or the voices of specific individuals is out of scope, and a synthetic-voice score is a signal for extra verification, not proof of fraud. Speaker verification ("is this the account holder's voice?") is a different problem with different tools, and Omni does not do it.

What the published number means

The Omni card reports a held-out audio evaluation across 21 public sources. On ASVspoof 2019 LA, synthetic or converted voice against real speech, it answers 93% of 392 questions correctly.

Read that number with its context:

The card also lists non-English speech as largely untested. If your callers speak other languages, measure on those calls separately.

Use the score to step up verification

The safe pattern is a gate that can only add friction, never remove it:

  1. Score a short clip from the start of the call. Omni accepts clips of up to 10 seconds; a longer clip is refused, never cut. A few seconds of the caller speaking fits well inside that limit; see the windowing notes in sound event detection if you score more than one window.
  2. Run in decision mode. With a threshold, a yes_no answer comes back as yes, no, or no selection with a reason (below_threshold, below_margin, tie).
  3. Route on three outcomes. If the spoof answer is yes, or the model is unsure, ask for a stronger check before the risky action: a callback to the number on file, a one-time code to the registered device, a question from the account history, or a second person approving a payment. If the answer is no, run your normal checks. Never skip them because the score was low.
  4. Tie it to the action, not the call. A balance enquiry and a request to change the payout account do not deserve the same response. Put the requested action in the state, and only gate the actions that move money or change credentials.
  5. Log the score with the outcome. Over time that gives you your own labelled set from your own channel, which is worth more than any public benchmark.

Treating an unsure answer like a yes is what makes this safe: a strict threshold sends more calls to extra verification, never fewer.

A request

Illustrative; the request shape follows the API docs, and the base64 string is cut short.

curl https://api.saina.run/v1/ask \
  -H "Authorization: Bearer $SAINA_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "saina-helm-2-omni-0.8b",
    "mode": "decision",
    "threshold": 0.8,
    "state": "Inbound call to the bank: a short recording of English speech. The caller asks to raise their daily transfer limit.",
    "audios": ["data:audio/wav;base64,UklGRi..."],
    "questions": {
      "spoof": {"type": "yes_no",
                "question": "Is this speech synthesized or voice-converted by a computer (a spoof)?"}
    }
  }'

In your code, the rule is a single line: if answers.spoof.selected is anything other than false, require the stronger check. That covers both a yes and a rejected answer.

The state follows the card's advice for audio: say what the clip is ("a short recording of English speech") and keep the question short and literal about what is audible.

What not to do

When a dedicated vendor is the better choice

Voice-security companies such as Pindrop and Reality Defender work on this problem full time. If phone fraud is a large part of your losses, if you need someone else to own detection quality as attack tools change, or if you need it integrated with your telephony platform and fraud case management, a dedicated vendor is likely the better choice. Ask them for results on audio like yours, from your channel, rather than for a single benchmark figure.

A general audio decision model fits when you want a self-hostable signal you can run on your own servers (the weights are open under Apache 2.0, so call audio need not leave your infrastructure), when the spoof check is one question among several in the same request, or when you are prototyping the verification flow before choosing a vendor. Either way, the step-up design above stays the same.

Try it

With a free account, the Voice fraud check preset in the Studio playground lets you try your own recordings and change the question. Runs are charged in credits, and the cost is shown first. The card, with its full out-of-scope list, is at run-saina/saina-helm-2-omni-0.8b.