Quick answer: Classify each caller request by what it discloses or changes, then gate it at the lowest rung of a five-rung ladder that covers it. Caller ID proves the call came from a number, not that your customer placed it. NIST SP 800-63A revision 4 bans knowledge-based verification outright. Australia’s telco rules want two authenticators when the caller rings you and one when you ring them back.
The question people actually type is “how do I verify a caller’s identity before my AI agent gives out account details?”, and it is a design problem, not a policy problem. An AI voice agent that answers your main line will be asked for a balance, an address change, a booking someone else made and a copy of last month’s invoice, often inside the first ninety seconds. Every one of those requests has a different blast radius, and the mistake almost everyone makes is to build a single verification step and apply it to all of them — usually name, date of birth and address, read aloud, on an inbound call from a number nobody checked.
The caller verification ladder: five rungs and what each one actually proves
Name the rungs and the argument becomes tractable. The point of the table is the third column: each check proves something narrow, and almost none of them prove the thing people assume.
| Rung | The check | What it actually proves | Sufficient for | Not sufficient for |
|---|---|---|---|---|
| 0 | CLI/ANI matches the number on the record | That this call arrived carrying a number that matches. Calling line identification is asserted by the originating network and can be spoofed. | Routing, personalising the greeting, picking which account to load in the background | Anything at all. Rung 0 is a hint, not a factor. |
| 1 | Name, date of birth and address (knowledge-based verification) | That the caller has data about your customer. It does not prove they are your customer. | Resolving which record the caller means, before any gate is applied | Disclosing anything, changing anything, or moving money. Banned outright for identity verification in NIST SP 800-63A rev 4. |
| 2 | One-time code sent by SMS to the mobile number already on file | Possession of the enrolled factor, at this moment. | Disclosure of account detail; low-value changes; most of what a receptionist agent is asked for | Anything that survives a SIM swap or a hijacked mailbox. The code rides the PSTN, and NIST SP 800-63B rev 4 says that at the time of publication its one restricted authenticator is the use of the PSTN for out-of-band authentication. |
| 3 | You hang up and ring the number on the account | Possession, plus immunity to inbound caller ID spoofing, because you chose the destination. | High-value changes; any request where the inbound number is the thing you doubt | A caller whose number has already been ported or swapped away. Still the PSTN. |
| 4 | In-app or signed-in approval, confirmed back on the call | Possession of the device plus control of the account itself, off the phone network entirely. | Irreversible changes, payout details, adding an authorised representative | Callers who do not have the app, are not enrolled, or cannot use it. You always need a fallback, and the fallback is the real gate. |
Two things fall out of that table immediately. Rung 1 is not a weak version of verification; under the current NIST guidance it is not verification. And rungs 2 and 3, the two rungs a phone agent can actually reach, both ride the public telephone network, which is exactly the network the standards bodies are most nervous about. Rung 4 is the only rung that leaves it.
Is date of birth enough to verify a caller? No, and the standard hardened between revisions
This is the most interesting citation on the page, because you can watch the position change.
NIST SP 800-63A revision 3, section 5.3.2 permitted knowledge-based verification with conditions. Its first requirement reads: “The CSP SHALL NOT use KBV to verify an applicant’s identity against more than one piece of validated identity evidence.” The same section required a minimum of four KBV questions, each needing a correct answer; no more than three attempts; a two-minute timeout per question on inactivity; and it ruled out source data that is “accessible freely, for a fee in the public domain, or via the black market”.
NIST SP 800-63A revision 4, in its list of identity verification methods, replaces all of that with one sentence: “Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification.”
Read the two revisions in order and the trajectory is unmistakable, and it is the reason a 2018-era verification script is not a defensible one in 2026. Do not, however, mix the revisions in one sentence: revision 3 constrained KBV, revision 4 prohibits it, and they are different documents.
What that prohibition actually binds, and what it does not
SP 800-63A is about identity proofing — establishing who a new applicant is at enrolment. Revision 4 states its audience plainly: it “provides guidance for federal agencies, third-party Credential Service Providers (CSPs), and other organizations that provide or use identity proofing services.” Revision 3 is blunter still, saying the publication “may be used by nongovernmental organizations on a voluntary basis”. It is US federal guidance. It is not law in Australia and it is not a duty on a dental clinic, a strata manager or a law firm.
Authenticating a returning caller is the neighbouring document, SP 800-63B, and it is worth noticing what that document contains: its permitted authenticator types are passwords, look-up secrets, out-of-band devices, single-factor and multi-factor one-time-password devices, and cryptographic authenticators. Facts about a person are not on the list at any assurance level. The closest 800-63B rev 4 comes to knowledge questions is a prohibition in its password section — “Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., ‘What was the name of your first pet?’) or security questions when choosing passwords.” Narrow in scope, unambiguous in direction.
What Australia’s telco rules require — and who they actually bind
Australia has a published benchmark for authenticating someone on the phone, and it is worth copying. It is also, for most readers of this page, not a duty.
The boundary, stated plainly: the Telecommunications Service Provider (Customer Identity Authentication) Determination 2022 binds carriage service providers. Section 4 says it “applies to carriage service providers: (a) involved in the supply of a telecommunications service; and (b) when conducting a high-risk customer interaction relating to a customer of a carriage service provider”, and excludes account managed and integrated customers. If you run a dental clinic, a conveyancer, a gym or a law firm, this instrument does not apply to you. It is the best-documented Australian model for phone authentication and a defensible thing to imitate. It is not your obligation.
What makes it worth imitating is the shape of the requirement. The ACMA’s summary page states the headline rule — “Multi-factor identity authentication (MFA) processes must be used for all high-risk transactions” — and lists seven worked examples of high-risk transactions, including SIM swaps, transfers of title, activating a service for an overseas customer and blocking an IMEI. But the instrument itself defines a high-risk customer transaction by consequence, not by a list, and limb (d) is the one that matters here: a transaction that may result in “disclosure to the requesting person of a customer’s personal information, business information or account security information held by the carriage service provider relating to the customer’s account”.
That is the whole of this page’s subject, written into an Australian legislative instrument. Disclosure is the risky act. Now look at the price the instrument puts on it:
| Who initiated the call | What section 9 requires | The design lesson |
|---|---|---|
| The caller rang you (s 9(1)) | Two authenticators — two account information authenticators, two personal information authenticators, or one of each — and at least one process from the closed list in s 9(3) | Knowledge alone is never the whole gate. The s 9(3) list is where the strength is. |
| You rang the number listed on the account (s 9(2)) | At least one personal information authenticator. The callback itself is taken to satisfy s 9(3)(b). | Placing the call yourself is worth a whole factor. When in doubt, hang up and ring back. |
| The s 9(3) list, in full | Direct and immediate access to the service; direct and immediate access to the public number on the account; a unique verification code or secure hyperlink; biometric data; a category A document via Schedule 1; or a cryptographic key. | Six options, not one. Your fallback for callers who cannot receive a code is a design requirement, not an edge case. |
| The s 9(3) check failed (s 10) | An employee or agent who has completed fraud mitigation training must use one of three things: category A and/or category B documents via Schedule 1, a government online document verification service, or a government-accredited digital identity service. For the latter two only, the requesting person must supply the identifying numbers of at least two unique government documents, each verified. | The failure path is a trained human with stronger evidence. It is not a softer version of the same questions. |
| A person in vulnerable circumstances (s 11) | Two authenticators, assessed by an employee or agent who has completed fraud mitigation training, and the s 9(3) requirement is not imposed. | The strongest ladder in the world needs a humane exception, and the instrument writes one. |
Records of compliance must be retained for a minimum of one year under section 16. That is a cheap thing to copy and it is the first thing anyone will ask you for after an incident.
The Disclosure Line: the rule for what an AI agent may read back
The Disclosure Line — an AI agent may read back nothing the caller has not already proven it may hear. Everything that discloses account state or changes it sits above the line and needs rung 2 or higher. Everything below the line is limited to what the customer already holds in their own bill or correspondence, or a masked form of no more than the last three digits. A rung-1-only gate is a rung-1-only disclosure.
The “already in their own bill” half of that rule is borrowed openly from the Determination, which carves out of its high-risk definition a disclosure where the information falls into any of three limbs: it “is included in a bill or in other correspondence with the customer”; it “is mostly hashed or obscured for the purpose of reminding a customer of the customer’s information”; or it “is included in notifications relating to a customer’s telecommunications service usage”. That is a regulator drawing exactly the line a voice agent needs: reminding is not disclosing.
The operational consequence is that your agent has two verbs, not one. It can confirm — the caller supplies a value and the agent answers yes or no — or it can disclose, and only disclosure needs a rung. “Is the address on file 14 Boundary Street?” is a confirmation and can sit below the line. “What address do you have for me?” is a disclosure and cannot.
| What the caller wants | What it discloses or changes | Minimum rung | Notes |
|---|---|---|---|
| Opening hours, service list, “do you take my insurer” | Nothing account-specific | None | Do not verify. Gating public information trains callers to hand data to anyone who asks. |
| “Do I have a booking this week?” | Existence of a booking, and by implication the account | 1 to resolve, 2 to answer | Or answer as a confirmation: caller states the date, agent says yes or no. |
| Read back an address, email or last invoice amount | Personal information | 2 | Mask by default. Last three digits, month and year only. |
| Change the mobile number, email or address on file | Account security information — this is the SIM-swap shape | 3 | Notify the old contact point as well as the new one. |
| Move a payment, change bank details, issue a refund | Money | 4, or a human | Card data has its own scope problem before identity is even reached. |
| Add an authorised representative or a third party | Everything, permanently | 4, or a human | The Determination sends unlisted representatives to a trained human with documentary evidence (s 12). Copy that. |
How to wire the out-of-band step into an AI voice agent
The mechanics are the easy part, and they are the same whether you build on a framework or run a managed platform such as our AI customer support agents for tier-1 resolution.
- Resolve before you gate. Use rung 0 and rung 1 to work out which record the caller means. Revision 4’s glossary is explicit that KBV “does not include collecting personal attributes for the purposes of identity resolution” — resolution is a legitimate use of the very data that is illegitimate as proof.
- Classify the intent before you answer it. The agent’s first tool call on any account-shaped request is a classifier that returns an intent and a required rung. If the classifier is unsure, it returns the higher rung.
- Hold state server-side, never in the prompt. The verified rung is a field on the session, set by your backend after the code matches. A model that can be told “I already verified earlier” is not a gate. Keep the correct code out of the transcript and out of the context window entirely, so no prompt can extract it.
- Send the code from your system, not from the model. One tool, one destination: the contact point already on file. The agent never accepts a number from the caller to send the code to, because that turns the check into an ornament.
- Compare server-side and expire fast. The agent passes the digits the caller read out to a verify tool that returns a boolean. Nothing else. A five-minute expiry and a three-attempt limit per call are our defaults, and the three-attempt figure is deliberately borrowed from revision 3’s KBV cap rather than invented.
- Log the rung reached against every disclosure. Section 16 of the Determination requires a year of records for telcos. For everyone else it is simply the only way to answer “what did the agent tell them?” later.
Day one action: do not build this everywhere. List the three highest-risk intents your line actually receives — for most operators they are a contact-detail change, a payment question and a records request — and gate only those. Everything else keeps working while you do it, and you will learn more from three gated intents in a fortnight than from a six-week project to gate forty.
The finish state you are aiming for is narrow and testable: for each of those three intents, a caller who cannot reach the enrolled factor is routed to a human within ninety seconds, and no disclosure above the line has ever occurred at rung 1.
What the agent says while the code is in flight
Nobody writes this down, and it is where most implementations fall over. A human agent fills the silence by typing audibly. An AI agent produces perfect silence, on a phone line, for as long as it takes a text message to arrive — and a caller in silence either hangs up or starts volunteering information you did not ask for and must not accept.
These are our defaults, not a published standard. Tune them; do not skip them.
| Elapsed | What the agent says | What it must not do |
|---|---|---|
| On send | “I’ve sent a six-digit code to the mobile number on your account. Read it back to me when it arrives — I’ll wait.” | Name the number in full. A masked form of no more than the last three digits is the ceiling the Disclosure Line sets, and saying nothing at all is the safer default here, because naming any part confirms the account exists. |
| 0–20 seconds | Nothing. Hold the line open with the ambience already on the call. | Fill the gap with chat. Every filler question invites the caller to offer more personal data. |
| 20–40 seconds | “Still here. Let me know the moment it lands.” | Resend. A second code arriving mid-read is the most common cause of a false failure. |
| 40–75 seconds | “If it hasn’t come through, I can hang up and call you back on the number we have on file instead.” | Offer to continue without it, or offer to send it somewhere else. |
| Past 90 seconds | Offer a human, or book a callback, and say which. | Loop. Three attempts, then escalate. |
Two script rules worth more than the timings. The agent announces the wait before it starts, because unexplained silence on a phone call reads as a dropped connection. And it offers the callback route as a normal option rather than a punishment, because under the Determination’s own logic the callback is the stronger path, not the consolation prize.
What happens when verification fails
The failure path is where a well-built gate leaks, and the leak is almost always the same one: the agent explains too much.
A failed verification must not reveal whether the account exists. “That’s not the date of birth we have on file” tells an attacker that the account exists and that date of birth is a gate. “I can’t confirm those details” tells them nothing. The agent must say the same sentence whether the record is missing, the caller is wrong, or the caller is right but unreachable — and that sentence must not vary in length, tone or route. This is the single easiest thing to get wrong, because the helpful phrasing is the unsafe one.
The rest of the path:
- Cap attempts, then stop. NIST SP 800-63B rev 4 tells verifiers to limit consecutive failed attempts on a single subscriber account to no more than 100 by disabling that authenticator, unless a given authenticator type’s own description says otherwise, and adds that “The limit of 100 attempts is an upper bound, and agencies MAY impose lower limits.” On a live phone call, 100 is absurd. Three is right.
- Escalate to a person, with the rung reached and nothing else. The human needs to know the caller reached rung 1 and failed rung 2. They do not need the transcript of the attempts. Our note on AI-to-human handoff and context transfer covers the packet; the addition here is that a failed-verification handoff carries less context, not more.
- Notify the account holder out of band. The Determination requires that when a code recipient says they did not initiate the interaction, the provider must not undertake the transaction, must tell them so, and must tell them what they can do to protect the account (s 9(5)(b)). That is a good pattern regardless of whether you are a telco.
- Make the fallback a trained human, not an easier question. Section 10 sends failed authentications to an employee who has completed fraud mitigation training, armed with government document checks. The principle transfers: when the machine gate fails, the next step should be harder evidence assessed by a person, never softer evidence accepted by the agent.
Where voice itself sits, and why it is not your factor
One honest sentence: your AI agent is not doing voice biometrics. It receives an audio stream and transcribes it, and unless you have separately deployed a speaker-verification system with presentation attack detection and an enrolled voiceprint per customer, nothing anywhere in that pipeline compares the caller’s voice to a stored sample.
Voice biometrics is a real technology and the Determination expressly permits “use of one or more forms of biometric data” as an s 9(3) process. But NIST SP 800-63B rev 4 does not merely condition it — in the same section, under presentation attack detection, revision 4 states flatly that “Biometric comparison based on voice SHALL NOT be used.” The rest of its biometric regime explains why that line was drawn: “Biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator (i.e., ‘something you have’)”, the characteristic must be presented and compared at every authentication, a non-biometric alternative must always be offered, and the system must hit a false match rate of one in 10,000 or better for all demographic groups. The same document notes that biometric characteristics “do not constitute secrets” and can often be obtained without consent, and states at both AAL2 and AAL3 that “A biometric characteristic is not recognized as an authenticator by itself.”
And we should be straight about our own position rather than gesture at it. Zian’s published capability list includes voice cloning, alongside 30+ languages and private model deployment. A platform that can synthesise a voice is not in a good position to tell you that hearing a familiar voice is evidence of who is speaking. If you are weighing what that means for disclosure and consent on your own outbound calls, we cover it separately in our note on voice cloning on business calls and the consent rules. For inbound verification the conclusion is short: treat a matching voice the way you treat a matching caller ID. It is a hint. It is not a rung.
Where this page is not the answer
Everything above is authentication: a returning caller, an existing record, a decision about disclosure. Identity proofing of a brand new customer under Australia’s AML/CTF regime is a different regime with different deadlines, different evidence and a statutory obligation that does not move onto your agent. If that is your question, do not read this page — read our note on delayed verification and what an AI KYC onboarding agent may do under the AUSTRAC rules instead.
Similarly, if the caller’s real request is to make a card payment, the binding constraint arrives before identity does, in the form of PCI DSS scope over every component that hears the digits.
And if you are in a sector with its own authentication rule — a licensed credit provider, a health service, a government agency operating under an agency-specific framework — that rule outranks everything on this page. This is general information about designing a verification step, not legal or security advice, current as at 22 September 2026. Check your own obligations with someone qualified to advise on them.
Frequently asked questions
Is date of birth enough to verify a caller?
No. Date of birth is knowledge-based verification, and NIST SP 800-63A revision 4 states in its list of identity verification methods that “Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification.” That guidance binds US federal agencies and the credential service providers working for them, not an Australian clinic, but the reasoning travels: a date of birth proves the caller has data about your customer, and data about your customer leaks constantly. Use it to work out which record is meant, then gate the disclosure on something the caller must possess.
Can an AI agent verify a customer before giving out account details?
Yes, for rungs 2 and above, provided the check runs in your systems rather than in the model. The agent asks for the code, the caller reads it out, and a backend tool compares it and returns true or false. What an AI agent cannot safely do is hold the correct answer in its context and decide for itself whether the caller got close enough. Keep the secret out of the prompt and the decision out of the model.
What does ACMA require telcos to do when someone rings up?
The ACMA states that “Multi-factor identity authentication (MFA) processes must be used for all high-risk transactions”, and the underlying Telecommunications Service Provider (Customer Identity Authentication) Determination 2022 sets the detail: for a caller-initiated interaction, section 9(1) requires two authenticators plus at least one process from the six listed in section 9(3). Where the provider places the call to the number on the account, section 9(2) requires only one personal information authenticator, because the callback itself is taken to meet the section 9(3) limb. The instrument applies to carriage service providers, so it is a benchmark for other industries rather than a duty on them.
Is a one-time code by SMS good enough?
For most disclosure decisions, yes, and it is far better than questions. Be clear-eyed about the limit, though: NIST SP 800-63B revision 4 records that at the time of publication “there is one restricted authenticator: the use of the PSTN for out-of-band authentication”, and advises verifiers to consider risk indicators such as a device swap, SIM change or number porting before sending a secret that way. For anything irreversible, prefer an in-app approval or a callback you place yourself.
Can my AI agent use the caller’s voice as a factor?
Not as it stands. A conversational agent transcribes audio; it does not compare a voiceprint unless you have deployed a speaker-verification system separately. Even if you did, NIST SP 800-63B revision 4 states that “Biometric comparison based on voice SHALL NOT be used.” Treat a familiar voice as a routing hint, never as a rung.
What should the agent say when verification fails?
One sentence that does not vary: something along the lines of “I am not able to confirm those details, so I cannot go further on this call.” The wording must be identical whether the account exists, the caller is mistaken, or the record is simply unreachable, because a helpful explanation is what tells an attacker the account is real. Then offer a human or a callback, cap the call at three attempts, and notify the account holder through the contact point already on file.
How many intents should I gate to start with?
Three. Pick the three highest-risk intents your line actually receives, gate those at rung 2 or above, and leave everything else alone while you measure. Gating everything on day one produces a verification step in front of “what time do you close”, which teaches callers that being asked to prove themselves is routine and unimportant — the opposite of what the control is for.
Where every figure on this page comes from
| Figure | Who published it | Link | Date read |
|---|---|---|---|
| “Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification.” | NIST, SP 800-63A rev 4, Identity Verification Methods | pages.nist.gov/800-63-4/sp800-63a.html | 22 September 2026 |
| Scope: guidance “for federal agencies, third-party Credential Service Providers (CSPs), and other organizations that provide or use identity proofing services”; KBV excludes collection for identity resolution | NIST, SP 800-63A rev 4, Introduction and Glossary | pages.nist.gov/800-63-4/sp800-63a.html | 22 September 2026 |
| “The CSP SHALL NOT use KBV to verify an applicant’s identity against more than one piece of validated identity evidence”; minimum four questions; no more than three attempts; two-minute inactivity timeout; public-domain or black-market data excluded; voluntary use by nongovernmental organisations | NIST, SP 800-63A rev 3, §5.3.2 | pages.nist.gov/800-63-3/sp800-63a.html | 22 September 2026 |
| Permitted authenticator types at AAL1, AAL2 and AAL3 (passwords, look-up secrets, out-of-band devices, single- and multi-factor OTPs, cryptographic authenticators); “A biometric characteristic is not recognized as an authenticator by itself”; “one restricted authenticator: the use of the PSTN for out-of-band authentication”; risk indicators including SIM change and number porting; “The limit of 100 attempts is an upper bound”; KBA prohibition when choosing passwords | NIST, SP 800-63B rev 4, §§ Authentication Assurance Levels 1 to 3, Restricted Authenticators, Rate Limiting, Passwords | pages.nist.gov/800-63-4/sp800-63b.html | 22 September 2026 |
| “Biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator”; false match rate of one in 10,000 or better for all demographic groups; biometric characteristics “do not constitute secrets”; “Biometric comparison based on voice SHALL NOT be used.” | NIST, SP 800-63B rev 4, Use of Biometrics | pages.nist.gov/800-63-4/sp800-63b.html | 22 September 2026 |
| “Multi-factor identity authentication (MFA) processes must be used for all high-risk transactions”; seven listed high-risk transactions; two worked MFA examples; records kept for at least 1 year | ACMA (page last updated 10 September 2025) | acma.gov.au/customer-identity-authentication-rules | 22 September 2026 |
| Application to carriage service providers (s 4); definition of high-risk customer transaction including limb (d) disclosure and the bill/obscured carve-outs (s 6); two authenticators plus s 9(3) for caller-initiated (s 9(1)); one authenticator for provider-initiated callback (s 9(2)); the six s 9(3) processes; the duty not to proceed and to tell the relevant person what they can do, where the code recipient did not initiate the interaction (s 9(5)(b)); failure path via trained employee and two government documents (s 10); vulnerable circumstances (s 11); unlisted authorised representatives (s 12); records for a minimum of one year (s 16) | Australian Communications and Media Authority, Telecommunications Service Provider (Customer Identity Authentication) Determination 2022 (F2022L00548), made under s 99(1) of the Telecommunications Act 1997, commenced 30 June 2022. Text read from the as-made download. | legislation.gov.au/F2022L00548/asmade | 22 September 2026 |
| Zian capability references: voice cloning, 30+ languages, private model deployment on customer infrastructure | Zian AI (first-party) | zian.ai | 22 September 2026 |
Timings in the “what the agent says” table are our own working defaults for a voice agent holding an open line. They are design parameters, not measurements, and no published standard sets them.
Building the gate into a live phone line? Zian AI is in partnership-application beta. Apply For Partnership.