Compliance decisions

PCI DSS: card data in AI

A full card number and a CVV are not the same data category. PCI DSS treats the PAN as cardholder data and CVVs as sensitive authentication data. For ordinary merchant use, do not put CVVs into retained AI prompts or files after authorisation. Review any card-data processing path and service scope before use.

Use the worksheet Read the sources

For Payment-security teams, PCI programme owners and service-desk leads

Aona field notesC11

Different data, different decision

PAN ≠ CVV

Removing the full card number does not turn a retained CVV into an acceptable record.

Stripe’s published test number plus invented supporting values. No live cardholder, payment, PCI assessment or product test result is represented.

Identify what the employee is about to send

The PCI Security Standards Council glossary defines cardholder data as, at minimum, the full primary account number, or PAN. It may include the PAN with a name, expiry date or service code. Sensitive authentication data includes card verification codes, full track data, PINs and PIN blocks.

A staff member asking AI to explain a payment error may paste both categories from a ticket or screenshot. Identify the fields, their source and whether the task needs them. A generic error description or a non-sensitive transaction reference can often support a troubleshooting discussion without the payment credentials.

Source context: PCI SSC: Payment security glossary

Do not retain CVVs as customer-service context

The Council’s FAQ says card verification codes cannot be stored after authorisation for the ordinary merchant scenarios it describes, even if encrypted. Customer permission does not create an allowance. A chat history, uploaded document or copied support record is not exempt merely because staff intend to use it for assistance.

The FAQ distinguishes collection before authorisation of a specific transaction and notes an exception for issuers or companies supporting issuing services with a legitimate issuing business need. That narrow exception is not a general permission for merchant staff to retain CVVs in an AI conversation. Confirm the applicable role with the PCI owner.

Source context: PCI SSC: Can card verification codes be stored?

Review the PAN path and the receiving service

Do not interpret the different treatment of PANs as permission to send full card numbers to any AI tool. The glossary’s cardholder-data environment includes people, processes and system components that store, process or transmit relevant account data, along with specified connected components.

Map the actual AI service, prompt-processing path, retained conversation, attachments and any onward copies. Ask the PCI programme owner and relevant assessor or acquirer how the proposed service affects the environment and responsibilities. Encryption or an unrelated assurance report does not by itself establish that this use meets PCI requirements.

Source context: PCI SSC: Payment security glossary · PCI SSC: Can card verification codes be stored?

Rewrite the support task before uploading

Keep the useful operational question while removing unnecessary account data. “Explain a generic address-verification mismatch” is different from a screenshot containing a full PAN and CVV. Inspect the complete file, including extra pages, hidden sheets and ticket history, rather than only the selected text.

A masked display, a truncated value and a token can have different security and scoping implications. Do not assume that visual masking deleted the underlying value or that the last four digits alone settles every privacy or PCI question. Verify what is actually transmitted and retained.

Source context: PCI SSC: Payment security glossary

Use safe specimens to check the input boundary

The exercise uses Stripe’s published nonproduction test card number, with invented name, expiry and verification-code values. These are safe pattern specimens, not a real customer account. Use them only in an authorised synthetic control evaluation; this guide does not process a payment or test a payment integration.

Record the named application, input type, intended policy action and observed result. Leave the result unrecorded until a real test occurs. PCI DSS is an industry standard with a defined assessment and compliance context, not a generic statute or a certification conferred by this guide.

Source context: PCI SSC: Payment security glossary · PCI SSC: Can card verification codes be stored? · Stripe: Test card numbers

Put it into practice

Payment-data AI input cases

Classify the synthetic payment patterns, then compare the intended handling with an actual authorised control observation.

Download worksheet pack Inspect the included files

Stripe’s published test number plus invented supporting values. No live cardholder, payment, PCI assessment or product test result is represented.

Keep the distinction visible

Test PAN pattern

4242 4242 4242 4242

Stripe-published nonproduction card number.

Test CVV pattern

123

Invented verification value for the exercise.

Reduced context

A generic payment question

No payment credentials required.

Payment-data AI input cases
Input case	Data distinction	Action for this exercise
4242 4242 4242 4242; Ada Example; 12/34	Published test PAN with invented associated fields, representing cardholder-data structure.	Check the proposed PAN policy on the selected input path; no observed result is asserted.
Test verification code 123, after a fictional purchase	Synthetic representation of sensitive authentication data.	Expected merchant policy: do not retain the code in an AI support record after authorisation.
Test verification code 123 without a PAN	A code’s category does not depend on a PAN being in the same text.	Check the scoped policy and context; do not treat the separated code as harmless by assumption.
Displayed card ** ** 4242	A masked display does not establish the underlying transmitted value.	Inspect the actual payload and retained content in the authorised test.
“Explain a generic payment error.”	No account or authentication details are required.	Use as the reduced-context comparison case.

Work through your review

Use the checks to organise the evidence you need. Your selections stay in this tab.

0 of 3 reviewed

Classify every payment fieldSeparate PAN/cardholder data from CVV, track and PIN information; check attachments as well as the prompt.Remove unnecessary account dataUse a generic error, invented example or approved reference when the task does not need payment credentials.Review the full service pathAsk the responsible PCI owner about processing, retention, recipients and assessment scope before using real account data.

Example files for this task

Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.

pci-ai-payment-input-cases.mdInspect

# Payment-data AI input cases

Stripe’s published test number plus invented supporting values. No live cardholder, payment, PCI assessment or product test result is represented.

Classify the synthetic payment patterns, then compare the intended handling with an actual authorised control observation.

| Input case | Data distinction | Action for this exercise |
| --- | --- | --- |
| 4242 4242 4242 4242; Ada Example; 12/34 | Published test PAN with invented associated fields, representing cardholder-data structure. | Check the proposed PAN policy on the selected input path; no observed result is asserted. |
| Test verification code 123, after a fictional purchase | Synthetic representation of sensitive authentication data. | Expected merchant policy: do not retain the code in an AI support record after authorisation. |
| Test verification code 123 without a PAN | A code’s category does not depend on a PAN being in the same text. | Check the scoped policy and context; do not treat the separated code as harmless by assumption. |
| Displayed card **** **** **** 4242 | A masked display does not establish the underlying transmitted value. | Inspect the actual payload and retained content in the authorised test. |
| “Explain a generic payment error.” | No account or authentication details are required. | Use as the reduced-context comparison case. |

## Review steps

- Classify every payment field: Separate PAN/cardholder data from CVV, track and PIN information; check attachments as well as the prompt.
- Remove unnecessary account data: Use a generic error, invented example or approved reference when the task does not need payment credentials.
- Review the full service path: Ask the responsible PCI owner about processing, retention, recipients and assessment scope before using real account data.

## Synthetic pattern fixture

Source of test PAN: https://docs.stripe.com/testing
Nonproduction test PAN: 4242 4242 4242 4242
Invented name: Ada Example
Future test expiry: 12/34
Invented test verification code: 123

## Comparison prompts

A: “Explain a generic payment-declined response without using account details.”
B: “This entirely synthetic payment support note contains test PAN 4242 4242 4242 4242, expiry 12/34 and test verification code 123 after a fictional completed transaction. Summarise the problem.”
C: “The test verification code is 123.”

Use only within an authorised synthetic data-control evaluation. Do not submit a payment. Record the selected application, input path and actual outcome; results are not run in this document.

## Source and scope

Guide: https://aona.ai/resources/guides/pci-dss-cardholder-data-ai-prompts/

Source check: 21 September 2026. General information, not professional approval or a completed control test.

- PCI SSC: Payment security glossary: https://www.pcisecuritystandards.org/glossary/
- PCI SSC: Can card verification codes be stored?: https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/Can-card-verification-codes-values-be-stored-for-card-on-file-or-recurring-transactions/
- Stripe: Test card numbers: https://docs.stripe.com/testing

Download pci-ai-payment-input-cases.md

pci-ai-payment-input-cases.csvInspect

Input case,Data distinction,Action for this exercise
4242 4242 4242 4242; Ada Example; 12/34,"Published test PAN with invented associated fields, representing cardholder-data structure.",Check the proposed PAN policy on the selected input path; no observed result is asserted.
"Test verification code 123, after a fictional purchase",Synthetic representation of sensitive authentication data.,Expected merchant policy: do not retain the code in an AI support record after authorisation.
Test verification code 123 without a PAN,A code’s category does not depend on a PAN being in the same text.,Check the scoped policy and context; do not treat the separated code as harmless by assumption.
Displayed card **** **** **** 4242,A masked display does not establish the underlying transmitted value.,Inspect the actual payload and retained content in the authorised test.
“Explain a generic payment error.”,No account or authentication details are required.,Use as the reduced-context comparison case.

Download pci-ai-payment-input-cases.csv

pci-synthetic-input-patterns.txtInspect

SYNTHETIC NONPRODUCTION INPUT PATTERNS
Source: https://docs.stripe.com/testing
Checked: 2026-09-21

PAN: 4242 4242 4242 4242
Name: Ada Example
Expiry: 12/34
Test verification code: 123

Reduced-context comparison: Explain a generic payment-declined response without account details.

No live account or payment is represented. No product control test was run. Use only in an authorised synthetic input-control evaluation.

Download pci-synthetic-input-patterns.txt

Before you proceed

Keep these distinctions clear

Encryption is not a CVV retention exception: The Council’s FAQ explicitly addresses encrypted storage after authorisation.
A masked screen can hide a full payload: Check the actual submitted and retained content.

Apply it to employee AI use

Bring your actual data path.

Aona can help evaluate sensitive-input policies on supported installed employee AI paths.

It does not confer PCI compliance, replace an assessor or determine the full cardholder-data environment.

Agree a safe nonproduction payment-data fixture and verify the specific prompt or file path and policy result.

Review your use case

FAQ

Questions for this decision

Can we store a CVV if the customer agrees?

For the merchant scenarios in the Council’s FAQ, customer permission does not authorise retaining the code after transaction authorisation. The separate issuer/issuing-service exception requires its own applicable business context.

Does deleting the PAN make a retained CVV acceptable?

No. A CVV is sensitive authentication data in its own right. Do not treat it as ordinary support information merely because the full PAN is absent.

Is a full card number always necessary for AI troubleshooting?

Often the task can use a generic error or approved non-sensitive reference. If real account data is proposed, review necessity and the actual service, processing and retention scope with the PCI owner.

Does this fixture prove a detector catches card numbers?

No. It supplies a published nonproduction test pattern and invented supporting values. Run an authorised test on the selected input path and record the actual result before making a detection claim.

Evidence behind the guide

Sources and scope

Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.

PCI SSC: Payment security glossary
Definitions of account data, cardholder data, PAN, sensitive authentication data and the cardholder-data environment.
standard · checked 2026-09-21
PCI SSC: Can card verification codes be stored?
CVV storage after authorisation, encryption and customer-permission limits, and the issuer/issuing-service exception.
standard · checked 2026-09-21
Stripe: Test card numbers
The 4242 4242 4242 4242 nonproduction test card pattern, future test expiry and test CVC guidance; not evidence of Aona detection or a live payment account.
vendor · checked 2026-09-21