.png?width=365&height=122&name=BTLogo%20(1).png)
Does Your Chatbot Put You in PCI Scope? Here's How to Fix It
AI is making customer support conversational, and it’s becoming a PCI compliance problem nobody is talking about.
The classic point-and-click user experience is giving way to natural language interactions, and customer support is increasingly being supplied through online chat and voice agents versus telephone calls.
But when credit card data is exposed during an online conversation, the company running that interface risks expanding PCI-DSS scope.
Any person, process, or system that has access to customer cardholder data is in PCI Scope. While this makes intuitive sense, it can also create unexpectedly tricky challenges. For instance, if a printer is networked such that customer data could be sent to print, then it comes in scope; if a room is occupied by workers who can access the data, then that room comes in scope; and, of course, any computer system that holds the data in plain text is also in scope.
The cardholder data environment (CDE) represents every system, person, and process that ever handles consumer credit card data. Whether collecting that data, storing it, processing it, or simply looking it up to answer a customer question, any interaction puts a process into PCI-DSS scope. This is why, for instance, telephone operators tend only to ask for the last four digits of a credit card number: so long as they never see the full number, their systems often stay outside of the CDE.
As merchants grow and move from the lowest level of PCI-DSS (Level 4, which requires only a self-report and periodic penetration tests from a qualified vendor) up the highest level (Level 1, which requires the merchant to hire an independent approved auditor to confirm their controls are acceptable), the investment required grows. And because the cost grows, so does the incentive to exclude as much of the operation as possible from scope.
How can my chatbot become part of the CDE?
Chat interfaces have transformed the way in which consumers interact with companies. From live chat with humans, to simple chatbots that summarize and spit back basic information, to AI-driven solutions that converse at a near-human level, the option to interact by typing has become a significant element in the vendor-customer relationship. Few, if any, businesses now fail to have some kind of chat interface on their website - and customers increasingly expect it.
But when the chat has access to personally identifiable information (PII), it suddenly becomes part of the PCI-DSS scope. For companies intending to replace a substantial amount of their human interaction with computer-driven interactions, this can be challenging.
How to reduce PCI scope for a chatbot?
The first step is to ensure that the chat application itself has no actual access to Primary Account Numbers (PAN). That’s not to say that customers must be prevented from understanding their accounts or prior history: the chat can be designed to use iFrames, or move information directly to the front end without passing through its underlying system.
For instance, if a consumer wants to purchase something through the chat and is ready to transmit their credit card details, the chat can be designed to pull an iFrame in from another locale; it can then confirm success (or failure) based on the messages returned from the other system.
Similarly, a customer who wants to update their address can do so through a pass-through interface that simply provides the chat with status updates.
How does a token vault help manage the chatbot CDE scope?
An approach that is gaining popularity in the merchant world is using a third party token vault, or programmable payments vault. This service provides APIs and SDKs to help build elements that ensure all PII is passed directly to the vault, without traversing the merchant’s payment systems.
The data collected, stored, and subsequently submitted to downstream payment processors by the merchant programmatically is protected in a PCI Level One environment, while the merchant payment system holds only a non-sensitive token that can’t be reversed into the original PAN.
By using a token vault, merchants can keep their chat interfaces outside of the CDE, and thus out of PCI scope by:
- Embedding data collection forms that speak directly to the vault into the experience, so that the information typed in by the customer bypasses the chat entirely.
- Embedding data access forms that also speak directly to the vault, so that customers can check or update their information, without the merchant payment system ever receiving it.
- Having the chat object ‘speak’ directly to the vault, so it can relay information, then receive confirmation codes so it can know that the activity has been successfully completed, without needing access to the data itself.
The Benefits of Limiting Chat CDE Scope
The benefit to the merchant is relatively clear: by avoiding having protected data flow through the chat CDE in plain text, they reduce the scope of their PCI-DSS compliance requirements, reducing resource needs and cost. There is also a strong benefit for the customer: programmable payment vaults are custom-built to protect sensitive data, reducing the risk of data leaks or hacks, and keeping the customer’s digital identity secure.
This is a rare win-win opportunity for organization and customer alike: reduce the cost of providing a secure payment system, while delivering ironclad security for customer data.
Your chatbot shouldn’t need a PCI audit just to say, “Your order shipped.” Let Basis Theory take the PAN out of the equation. Find out how much of your chat stack is actually in PCI scope.
