PCI is often mentioned in the triage PII, PHI and PCI in the context of data protection. PCI stands for “Payment Card Industry” data, which includes information such as bank account numbers, credit card numbers, card expiration dates, CVV numbers, etc. This article zeroes in on PCI and explains what data is captured under this acronym. We first look at what’s behind the acronym in a bit more detail, lay out the parties involved in the digital payment process to show the complexity and vulnerability of the data, and provide a list of the kind of information PCI encompasses, drawing from the PCI Data Security Standard’s (PCI DSS) definitions.
The PCI DSS is a global standard established by the Payment Card Industry Security Standards Council (PCI SSC), an independent body created by major credit card companies (Visa, MasterCard, American Express, Discover, and JCB). Its goal is to ensure the protection of cardholder and sensitive authentication data at every stage during the payment process.
PCI Information Flow
It is easier to understand what information is protected under the PCI DSS when we know the parties that are involved in the digital payment process. The graphic below shows the key players involved and the flow of information. POS stands for Point-of-Sale, and vPOS for virtual Point-of-Sale.
When consumers wish to pay with a credit or debit card, or a virtual wallet, they present their card or device to the POS of the merchant. In the e-commerce environment, the customer would simply provide the card information online at a virtual POS (vPOS). The POS then authenticates the customer to initiate the payment process. The authentication occurs via the information stored on the card. The card information and the POS together generate a unique encrypted code, called cryptogram or token. At times, the customer’s PIN, signature, or biometric data may also be involved for added security.
Next, the bank of the merchant, called the acquirer, which is also the entity that provides the merchant with the POS, transfers the payment information to the issuer. The issuer is the bank of the customer that issued the payment card through a card schema. A card schema allows communications between the issuer and the acquirer, but it also determines the terms that apply to the payment information exchange. Once the payment is authorized, the issuer withdraws money from the consumer’s bank account and the acquirer transfers money to the merchant’s account.
The described process is a simplified version of the payment transaction. Usually, more parties are involved, such as service providers that serve as payment gateways, and payment processors. Given the sensitivity of the data as well as the number of times the data has to be transmitted between a diversity of actors, data protection is of utmost importance. The PCI DSS takes up the challenge of addressing this issue.
The PCI DSS is not a law. It is a set of technical and operational requirements that are contractually imposed on entities that store, process, or transmit account data, or that could impact the cardholder data environment. Examples of entities that may be required to be PCI DSS compliant are the entities shown in the graphic above, but also service providers who handle account information in the course of providing services to merchants, or whose services impact the security of the merchant, e.g., cloud services, or point-of-sale system operators.
Examples of PCI
Now that we know what happens during the digital payment process, let’s look at the information that is being transferred and protected under the PCI DSS.
The PCI DSS refers to the protected data as ‘account data.’ Account data has two subcategories: ‘cardholder data’ and ‘sensitive authentication data’ (SAD).
Cardholder data encompasses the Primary Account Number (PAN) that identifies the issuer and the cardholder account, the cardholder name, the expiration date, and the service code.
Sensitive Authentication Data (SAD) is information used to authenticate cardholders and/or authorize payment card transactions, including card validation verification codes/values (CVV), full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.
Enforcement
The enforcement of the PCI DSS is not the responsibility of the PCI SSC. Rather, the issuers and acquirers manage their own compliance programs. In light of the fact that the same entity that contractually imposes the PCI DSS compliance onto a merchant also enforces the compliance, and that the same entity has significant skin in the game as they profit from the merchant’s business, enforcement can seem to be undertaken in the own interest of the credit card company, making the need for diligent compliance that much more important. Merchants do not only have to fear class actions as a result of data breaches, but also fines and compensation claims from their contractual partners.
Protection of PCI in Europe
The PCI DSS is a global standard. Hence, all point-of-sale terminals in Europe that accept international credit or debit cards need to comply with the standard. While European stakeholders were not among the founders of the PCI SSC, its board of advisors now includes eight representatives from Europe (Accor, Barclays, European Association of Payment Service Providers for Merchants or EPSM, European Card Payment Association or ECPA, Ingenico, Worldpay, Schwarz Group) and a Regional Head for Europe. The involvement of European stakeholders fosters mutual understanding and the relevance and adequacy of the PCI DSS in the European landscape.
The PCI DSS does not apply to payments with European credit and debit cards, again, because it is a standard that is imposed contractually on the merchants. Hence, if the merchant does not contract with Visa, MasterCard, etc. but only European issuers, the PCI DSS plays no role in that relationship.
Instead, a patchwork of requirements composed of whatever European card schemas deem suitable govern the transactions in those instances, as well as standards enacted by the individual states and the EU, e.g., the revised Payment Services Directive (PSD2).
A report by the Eurosystem (composed of the European Central Bank and the national central banks of the member states) from late 2017 indicates that there is currently no harmonized, competitive, and innovative European card payment area. Business practices, rules, and technical standards differ widely, and card market players in the EU actively promote their own services with proprietary standards, stifling card standardization. While it is generally possible for cardholders to pay with one card across all EU countries, this is not reliably so outside of the EU. Payment in other countries is reliant on co-badging with international card schemas. As a result, there is a trend among payment service providers to issue only cards from international card schemas, which is a questionable approach from a cost, competition, and governance standpoint, as much as there is now European involvement with the PCI SSC.
The PSD2 is aiming to support a harmonized, competitive, and innovative cards market in the EU, while enhancing payment transaction security and consumer data protection. Regulatory technical standards supplement the PSD2 by requiring strong customer authentication, common and secure open standards of communication, as well as guidelines on incident reporting and security measures for operational and security risks.
In terms of data protection, PSD2 does not comprehensively define the information to which it applies. It does, however, define ‘personalized security credentials’ and ‘sensitive payment data.’
(31) ‘personalised security credentials’ means personalised features provided by the payment service provider to a payment service user for the purposes of authentication;
(32) ‘sensitive payment data’ means data, including personalised security credentials which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;
These definitions are similar to SAD and cardholder data, respectively, as referred to in the PCI DSS, albeit account owner name and number are carved out from the definition under PSD2 in some circumstances.
As a last remark, note that PSD2 applies to international card schemas alongside PCI DSS in instances where companies headquartered outside of the EU have customers or users within EU jurisdictions. Furthermore, PSD2 also applies alongside the GDPR. Guidelines have been issued by the European Data Protection Board regarding the interplay between the two regulations.
Take-Away
We explained what PCI means in terms of the sensitive information that is commonly referred to by the acronym as well as the governing standard, the involved parties, and the flow of the information. A comparison with the European regime has surfaced considerable overlap in terms of the geographic scope of the governing standards prevalent in North America and Europe, respectively, as well as, unsurprisingly, with regard to the information that is protected.
The complexity of the payment card processes, the numerous parties involved by necessity, and the sensitivity of the information require enhanced security safeguards and processes to ensure adequate data protection. The first step is always knowing what PCI an organization holds, and where. Particularly, if PCI is collected in an unstructured format, e.g., in phone transcripts originating in a call centre, this alone is a difficult task.
Private AI can help you make that determination, even in unstructured data and across 47 languages. Using the latest advancements in Machine Learning, the time to identify and categorize your data can be minimized and compliance facilitated. To see the tech in action, try our web demo, or request an API key to try it yourself on your own data.
