PCI DSS Call Recording Requirements for AI Voice Agents

On this page

Does PCI DSS apply to AI voice agents?
What PCI DSS says about call recordings
Where card data leaks in an AI voice stack
Pause and resume versus DTMF masking
Taking the AI voice agent out of PCI scope
RBI's card storage rules for phone payments in India
Key dates
Sources

Does PCI DSS apply to AI voice agents?

Yes. The Payment Card Industry Data Security Standard (PCI DSS) is set by the PCI Security Standards Council (PCI SSC). It protects card data wherever it is stored, processed or sent. The phone channel is no exception. The council's telephone payments guidance says call recordings that capture spoken card details, or unaltered keypad tones, must be stored and secured under PCI DSS.

PCI DSS is an industry standard, not a law. The council writes it but does not enforce it. Compliance programmes are run by the payment brands, and merchants are told to check with their acquiring bank, the bank that processes their card payments, or the brands for what they must report (PCI SSC FAQ). A system is 'in scope' when PCI DSS requirements apply to it, which covers anything that stores, processes or transmits card data, plus systems connected to those.

An AI voice agent gives card data more places to land than a human agent does. Speech-to-text, the language model, tool calls, text-to-speech and the logs around them all handle what the caller says. If the caller speaks a card number, each of those systems is handling card data and comes into scope.

As of 24 October 2026, the version that applies is PCI DSS v4.0.1. The council published it on 11 June 2024 as a limited revision with no new or deleted requirements, and retired v4.0 on 31 December 2024 (PCI SSC). The requirements that v4 marked as 'future-dated' became mandatory on 31 March 2025, so an assessment today covers all of them.

What PCI DSS says about call recordings

The recording is the first place most businesses look, and it carries the standard's firmest rule. PCI DSS treats two kinds of card data very differently, and the difference decides what a recording may hold.

The card security code: never after authorisation

The card security code is the three- or four-digit code known as CVV2, CVC2, CID and similar names. PCI DSS calls it sensitive authentication data, and recordings must never keep it after the payment is authorised. Storing it in an audio file after authorisation breaks requirement 3.3.1, even if the file is encrypted (PCI SSC FAQ 1210). The council's guidance on card codes points to the narrower sub-requirement for these codes, 3.3.1.2, which "strictly prohibits storing them after authorization" (PCI SSC).

The council's first answer is prevention: stop the code being recorded at all, for example by suppressing audio while the caller enters card details. If that fails, delete it securely as soon as the payment is authorised. Sometimes secure deletion is not possible for legitimate technical or business reasons, and for that case the FAQ calls for compensating controls.

At a minimum those controls include comprehensive risk assessments, annually and after significant changes to the environment. They also include controls that block access to the code and to searches of the recordings, and written documentation of the controls and their justification. Compensating controls are a fallback that an assessor must accept, not an alternative to prevention.

The card number: only with a business need, and unreadable

The card number itself, called the PAN (primary account number), may be kept, but only if there is a business need, and it must be unreadable wherever it is stored (requirement 3.5.1). The telephone guidance lists voice and screen recordings, databases, log files and backups as places this applies. In practice that means limiting access to recordings by role and logging every access.

When local law requires full recording

Some laws require full call recording for years, and PCI DSS does not override them. Even then, the guidance says to make every possible effort to keep the security code out of recordings. How long recordings must be kept varies by sector and country; for India, see how long to keep call recordings.

If keeping the code out is truly impossible, the guidance says to discuss it with the acquiring bank or the card brand. The business should keep a detailed written justification and make sure the code cannot be queried. The acquirer or brand can accept or reject the approach, and encryption alone does not make the code non-queryable.

Where card data leaks in an AI voice stack

On an AI call the recording is only one of many copies, because card data goes everywhere the caller's words go. The table follows a spoken card number through a typical AI voice pipeline and shows the control that stops it at each step.

Read down the last column and one pattern stands out: the surest control at every row is to never let the digits reach the AI in the first place. Speech-to-text makes the problem worse than on a human call, because spoken digits become text, which is far easier to search and copy than audio.

Where card data can end up on an AI voice call, and how to stop it
Where	How card data gets there	Control
Phone line and audio stream	The caller speaks the digits, or presses keys whose tones can be decoded into digits	Mask or suppress keypad tones before audio reaches your platform. Treat any system carrying unmasked audio as in scope
Speech-to-text	Spoken digits become text, which is far easier to search than audio	Do not take card numbers by voice. If you must, redact the digits before the transcript is stored
Language model context and logs	The transcript is fed to the model; prompts, responses and traces are often logged	Never prompt the agent to ask for a card number. Keep card data out of prompts, traces and provider logs
Tool calls	The agent passes the card number to a payment function as an argument	Let a payment provider collect the card directly. The agent gets only "paid" or "failed" and, at most, the last four digits
Text-to-speech	The agent reads the card number back to confirm it	Confirm with the last four digits only
Call recordings	The whole call, including spoken digits, is recorded	Keep the security code out (requirement 3.3.1). Make stored card numbers unreadable. If keypad entry is masked, store only flat tones
Analytics and quality review	Transcript mining and voice analytics search for patterns, including card numbers	Keep card data out of analytics stores. PCI SSC says these tools need careful control where card data is present
Backups, exports and vendor systems	Copies of recordings and transcripts live on in backups, debug exports and third-party tools	Apply the same retention and deletion to backups. Map which vendor is responsible for which copy

Pause and resume versus DTMF masking

Two techniques dominate telephone payments, and they protect very different parts of that pipeline. Many vendor pages present them as alternatives, but they work at different points, and for an AI agent the difference is decisive.

Pause and resume protects only the recording

Pause-and-resume stops the call recording while the caller gives card details. Done properly, the council's guidance says it could take the call-recording and storage systems out of scope. It does not take the agent, the agent's desktop or the rest of the phone system out of scope, so it helps with compliance but is weak on its own.

The council also lists what goes wrong. Staff forget to pause, so card data gets recorded, or forget to resume, so the business loses recordings it may be legally required to keep. Automated versions are better, but can still be bypassed if the agent can skip the step that triggers them. Where pause-and-resume is used, especially when the agent starts it, the guidance recommends checking recordings for card data regularly, preferably weekly.

For an AI agent, pausing the recording fixes only one row of the table above. The audio still flows through speech-to-text and the model, so digits spoken during the pause can still reach transcripts, context and logs.

DTMF masking works before anything hears the digits

DTMF masking works earlier in the chain. It hides the dual-tone multi-frequency (DTMF) tones a phone keypad makes, so no one can decode the card digits from the audio. Masking swaps each tone for a flat or random tone, or suppresses it, and the real digits go straight to the payment provider. It is one of the approaches the council describes for reducing scope, as long as it happens before the audio reaches anything else.

Recordings that contain only flat tones, which cannot be turned back into digits, do not need the protections that apply to stored card numbers (telephone guidance, section 6.4.1). It still has to be checked that recordings really do contain only flat tones, because if the tones pass through unchanged, the card number and security code can be recovered from the audio.

For an AI agent, the masking or payment service must capture the keypad digits and never forward them to speech-to-text or the model. The agent can stay on the call and guide the caller without ever seeing the numbers, which keeps the conversation natural while the payment happens elsewhere.

Flowchart of a PCI DSS compliant AI voice payment with DTMF masking, keeping card digits away from the AI. — A card payment on an AI voice call with DTMF masking: the digits bypass speech-to-text, the model and the recording.

Taking the AI voice agent out of PCI scope

Masking is one route to the real goal, which is to make sure card data never passes through the agent at all. Four approaches move card entry away from the agent. The first three come from the council's guidance. A payment link is not named there, but the guidance does suggest moving payments to a secure alternative channel, such as a PCI DSS compliant e-commerce channel, which is the same idea.

Whichever route is chosen, the agent itself should never ask for card digits by voice. Its prompt should also say what to do if a caller starts reading them out anyway: "Please don't read your card number aloud. I'll take you to our secure keypad payment." The agent then hands over through a tool call or a transfer and receives back only "paid" or "failed". On Sonex, for example, agents support tool calling during a call and live transfer to a human, the two mechanisms such a hand-off needs; see AI voice agents. Collections and EMI calls are where this comes up most, as in the collections call script.

The work does not end at go-live. Transcripts, logs and recordings should be searched for card numbers on a schedule, and any security code found deleted at once. Each vendor in the chain should supply its PCI DSS attestation of compliance, the signed record of its assessment. The contract should say who is responsible for each copy of the data, including backups and debug exports.

A vendor due-diligence questionnaire can collect those answers, and lenders in India have extra vendor duties under RBI's outsourcing rules for AI voice vendors. The four approaches are:

Masked keypad entry, run by a specialist provider.
A hand-off to a payment provider's automated phone system (IVR, interactive voice response).
Outsourcing card handling to a PCI DSS validated service provider.
A payment link, so the caller pays on the payment provider's own page.

Decision chart for PCI DSS scope on AI voice agents: spoken card digits, payment links and payment IVR. — A quick scope check: the aim is that card digits never reach speech-to-text, the model or the logs.

RBI's card storage rules for phone payments in India

India adds a stricter layer on top of PCI DSS: merchants may not store actual card data at all. Only card issuers and card networks may store it, and data stored earlier had to be purged (RBI circular RBI/2021-22/96, 7 September 2021, para 4(a)). Merchants may keep only the last four digits of the card number and the issuer's name, for tracking and reconciliation (para 4(b)).

The start date was pushed back twice, from 1 January 2022 to a final deadline of 30 September 2022 (RBI/2022-23/77, 24 June 2022). Saved cards now work through tokenisation: a token replaces the card number, created only with the cardholder's explicit consent and an extra authentication step (RBI/2021-22/96, para 3).

RBI's Payment Aggregator Directions of 15 September 2025 add a similar line for merchants that use a payment aggregator. Card credentials must not be stored in any database or server the merchant accesses (Annexure 1, para 2.1). The aggregator must also make sure the merchant's systems meet standards such as PCI DSS (para 9(a)). Both are duties on the aggregator, which passes them on to the merchants it onboards.

None of these texts mentions call recordings or AI transcripts. Still, a merchant that keeps full card numbers in recordings or transcripts would struggle to square that with the rules, so the safe approach is the same as for PCI DSS. India's data protection law adds its own limits on recordings, covered in the DPDP Act for voice AI.

Key dates

Sources

Change log: 24 Oct 2026, Rewritten as one continuous guide: added how PCI DSS is enforced and what 'in scope' means, the sub-requirement 3.3.1.2 for card codes, and H3s separating the security code, the card number and local recording laws; the takeaways, steps, checklist and FAQs (taking payments, PAN versus CVV, vendor questions) folded into the body. Earlier the same day: stated FAQ 1210's minimum compensating controls exactly; dated the current-version statements; clarified who the RBI aggregator rule binds · 23 Oct 2026, First published

PCI DSS call recording requirements: taking card payments on AI voice calls