PCI DSS, Chargebacks and Card Data Retention
In the Certified Treasury Professional (CTP) body of knowledge, Risk Monitoring and Control includes managing the operational, financial, and compliance risks associated with accepting payment cards. Three key concepts are PCI DSS, chargebacks, and card data retention. PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements established by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB) that applies to any organization that stores, processes, or transmits cardholder data. It contains 12 core requirements grouped into six goals: building and maintaining a secure network, protecting cardholder data (including encryption), maintaining a vulnerability management program, implementing strong access controls, regularly monitoring and testing networks, and maintaining an information security policy. Compliance validation depends on merchant level (based on annual transaction volume), ranging from self-assessment questionnaires to on-site audits by a Qualified Security Assessor. Non-compliance exposes treasury to fines, higher interchange, liability for breach costs, and potential loss of card acceptance privileges. Chargebacks occur when a cardholder disputes a transaction and the issuing bank reverses the charge, debiting the merchant's account through the acquirer. Common causes include fraud, non-receipt of goods, product quality disputes, and processing errors. Treasury professionals monitor chargeback ratios because excessive rates trigger penalties, reserve requirements, higher processing fees, or termination by the acquirer. Controls include address verification (AVS), card verification values (CVV), 3-D Secure authentication, clear billing descriptors, prompt refunds, and robust documentation to support representment (disputing the chargeback). Card data retention refers to policies governing how long cardholder data is kept. PCI DSS requires minimizing storage: sensitive authentication data (full magnetic stripe, CVV, PIN) must never be stored after authorization, and the primary account number (PAN) must be rendered unreadable if retained. Organizations should define retention periods tied to legal and business needs, securely purge data afterward, and use tokenization or third-party processors to reduce PCI scope. Together, these practices limit fraud losses, regulatory exposure, and reputational risk.
PCI DSS, Chargebacks and Card Data Retention: A Complete CTP Exam Guide (Financial Regulatory and Operational Risk)
Payment cards are one of the most widely used collection channels for businesses, and treasury is usually the function that owns the merchant acquiring relationship, negotiates interchange and processing fees, forecasts card receipts, and reports on the risks that card acceptance creates. The AFP CTP body of knowledge places this topic within Financial Regulatory and Operational Risk because accepting cards exposes the organization to three distinct categories of exposure:
• Compliance and legal risk – failure to protect cardholder data can trigger contractual fines from the card networks (passed through the acquiring bank), forensic investigation costs, mandatory card reissuance costs, state breach-notification obligations, lawsuits and, in extreme cases, loss of the right to accept cards.
• Operational risk – chargebacks reverse cash that treasury has already counted, create reconciliation work, attract penalty fees, and can lead the acquirer to hold reserves or terminate the merchant account.
• Reputational risk – a publicized data breach damages customer trust far beyond the direct financial cost.
On the exam, this material tends to appear as factual recall questions (who sets the standard, what data may never be stored, how a chargeback flows) and as application questions (what a treasurer should do to reduce PCI scope or chargeback rates). Because the facts are concrete, this is an area where careful preparation produces reliable points.
2. What PCI DSS Is
PCI DSS stands for the Payment Card Industry Data Security Standard. It is a set of technical and operational security requirements for every organization that stores, processes or transmits cardholder data, including merchants, processors, acquirers, issuers and service providers.
Key facts to memorize:
• It is administered by the PCI Security Standards Council (PCI SSC), founded in 2006 by the five major card brands: Visa, Mastercard, American Express, Discover and JCB.
• It is not a government law or regulation. It is an industry standard enforced through contracts: the card networks impose it on acquiring banks, and acquirers impose it on their merchants through the merchant agreement. (A few U.S. states such as Nevada, Minnesota and Washington have written elements of PCI DSS into state law, but the standard itself is a private-sector rule.)
• Compliance is validated annually and, for network scanning, quarterly.
• The current version is PCI DSS v4.0 / v4.0.1, which replaced v3.2.1 (retired March 31, 2024). Version 4 emphasizes continuous security, allows a customized approach to meeting requirements, strengthens multi-factor authentication, and adds controls over e-commerce page scripts and phishing.
The Six Goals and Twelve Requirements
The standard is organized into six control objectives containing twelve high-level requirements. Exam questions frequently test whether a given control belongs to PCI DSS, so know the structure:
Build and Maintain a Secure Network and Systems
1. Install and maintain network security controls (firewalls).
2. Apply secure configurations; do not use vendor-supplied default passwords.
Protect Account Data
3. Protect stored account data (retention, masking, rendering PAN unreadable).
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
Maintain a Vulnerability Management Program
5. Protect systems and networks from malicious software.
6. Develop and maintain secure systems and software; patch promptly.
Implement Strong Access Control Measures
7. Restrict access to system components and cardholder data by business need-to-know.
8. Identify users and authenticate access (unique IDs, multi-factor authentication).
9. Restrict physical access to cardholder data.
Regularly Monitor and Test Networks
10. Log and monitor all access to system components and cardholder data.
11. Test security of systems and networks regularly (vulnerability scans, penetration tests).
Maintain an Information Security Policy
12. Support information security with organizational policies and programs.
Merchant Levels and Validation
Each card brand assigns merchants to a level based on annual transaction volume; the level determines how compliance must be validated. Visa and Mastercard levels (the ones most often tested) are approximately:
• Level 1 – more than 6 million transactions per year (or any merchant that has suffered a breach). Must have an annual on-site assessment by a Qualified Security Assessor (QSA) (or qualified internal auditor) producing a Report on Compliance (ROC), plus quarterly network scans by an Approved Scanning Vendor (ASV).
• Level 2 – 1 million to 6 million transactions. Annual Self-Assessment Questionnaire (SAQ) and quarterly ASV scans.
• Level 3 – 20,000 to 1 million e-commerce transactions. Annual SAQ and quarterly ASV scans.
• Level 4 – fewer than 20,000 e-commerce transactions, or up to 1 million transactions through other channels. Annual SAQ; scans as required by the acquirer.
All levels submit an Attestation of Compliance (AOC) to the acquirer. Remember: the larger the merchant, the more rigorous (and independent) the validation.
Consequences of Non-Compliance
• Monthly non-compliance fines assessed by the networks and passed through by the acquirer (commonly cited ranges of USD 5,000 to 100,000 per month).
• If a breach occurs: forensic investigation costs, reimbursement of issuers for card reissuance and fraud losses, higher processing fees, mandatory upgrade to Level 1 validation, and possible termination of card acceptance.
• Note that being PCI compliant does not eliminate liability for a breach, but it substantially reduces fines and is often a condition of safe-harbor treatment from the networks.
3. Card Data Retention: What May and May Not Be Stored
This is the most heavily tested detail in the topic. Cardholder data is divided into two groups.
Cardholder Data (may be stored if protected):
• Primary Account Number (PAN) – the 15- or 16-digit card number. Storage permitted only if rendered unreadable (strong encryption, truncation, one-way hashing or tokenization). When displayed it must be masked, showing at most the first six (BIN, up to eight under v4.0) and last four digits.
• Cardholder name
• Expiration date
• Service code
Sensitive Authentication Data (SAD) – may NEVER be stored after authorization, even if encrypted:
• Full track data from the magnetic stripe or chip equivalent.
• Card verification code – the three- or four-digit code printed on the card (CVV2, CVC2, CID, CAV2).
• PIN or PIN block.
Requirement 3 also imposes a data retention and disposal policy: keep cardholder data storage to the minimum required for legal, regulatory or business purposes; define specific retention periods; identify all locations where data is stored; and purge data that exceeds the retention period at least quarterly. The guiding principle is: if you do not need it, do not store it.
Reducing PCI Scope
Treasury professionals are expected to know the techniques that shrink the cardholder data environment (CDE) and therefore reduce compliance cost:
• Tokenization – the processor replaces the PAN with a surrogate value (token) that has no value outside the merchant system. The merchant retains the token for recurring billing and refunds while the real PAN sits in the processor vault. This is the single most frequently tested scope-reduction tool.
• Point-to-point encryption (P2PE) – card data is encrypted at the terminal and decrypted only at the processor.
• Hosted payment pages / redirects – the customer enters card data on the processor page, so the merchant never touches it.
• Network segmentation – isolating systems that handle card data from the rest of the corporate network.
• Outsourcing to PCI-validated service providers (while retaining responsibility for oversight; compliance can be outsourced in part, but accountability cannot).
4. Chargebacks: What They Are and How They Work
A chargeback is the reversal of a card transaction, initiated by the card-issuing bank on behalf of the cardholder (or by the issuer itself), that removes funds from the merchant and returns them to the cardholder. It is a consumer-protection mechanism required under Regulation Z (Truth in Lending) for credit cards and Regulation E for debit cards in the U.S., and is operationalized through card network rules.
The Chargeback Life Cycle
1. Dispute – the cardholder contacts the issuer (or the issuer detects a problem such as a stolen card). Cardholders generally have up to 120 days from the transaction or expected delivery date to dispute, though time limits vary by reason code and network.
2. Chargeback – the issuer assigns a reason code, provisionally credits the cardholder, and sends the chargeback through the network to the acquirer.
3. Acquirer debits the merchant – the transaction amount plus a chargeback fee (commonly USD 15 to 100) is deducted from the merchant settlement account. The merchant is notified and given a short window (often 7 to 30 days) to respond.
4. Representment (second presentment) – the merchant may accept the chargeback or fight it by submitting compelling evidence: signed receipts, proof of delivery, authorization records, IP address and device data, customer communications, or proof that a refund was already issued.
5. Pre-arbitration / arbitration – if the issuer rejects the representment, the case can escalate to network arbitration, where the network makes a binding decision and charges arbitration fees to the losing party.
(Visa Claims Resolution and Mastercom have automated much of this flow and largely replaced the older stand-alone retrieval request, but the exam may still describe a retrieval request as an issuer asking for a copy of the sales draft before filing a chargeback.)
Common Chargeback Reason Categories
• Fraud – card-not-present fraud, counterfeit card, stolen card, transaction not recognized.
• Authorization – no authorization obtained, declined authorization, expired card.
• Processing errors – duplicate processing, incorrect amount, late presentment, currency error.
• Consumer disputes – goods not received, not as described, defective, cancelled recurring billing, credit not processed.
Friendly fraud (also called first-party misuse) occurs when a legitimate cardholder disputes a valid charge, either by mistake or deliberately. It is now the largest single source of chargebacks for many e-commerce merchants.
Liability Shifts
• EMV liability shift (U.S., October 2015) – for card-present transactions, counterfeit fraud liability falls on whichever party (merchant or issuer) has not adopted EMV chip technology. A merchant with chip-enabled terminals is protected; a merchant still swiping magnetic stripes bears the loss.
• 3-D Secure (Verified by Visa, Mastercard Identity Check, etc.) – for e-commerce, when the cardholder is authenticated through 3-D Secure, fraud chargeback liability shifts from the merchant to the issuer.
• Without these protections, card-not-present merchants bear most fraud losses themselves, which is why mail-order, telephone and internet merchants pay higher interchange and experience higher chargeback rates.
Excessive Chargeback Programs
The networks monitor the ratio of chargebacks to sales. Merchants that exceed thresholds (roughly 0.9 percent to 1 percent of transactions combined with a minimum count, such as 100 chargebacks per month under the Visa Dispute Monitoring Program and the Mastercard Excessive Chargeback Program) face escalating monthly fines, mandatory remediation plans, and ultimately account termination. A terminated merchant is listed in the industry MATCH (Member Alert to Control High-Risk Merchants) database, making it very difficult to obtain a new merchant account.
Treasury Implications of Chargebacks
• Chargebacks reduce net card receipts and complicate cash forecasting and reconciliation; treasury must track them as a distinct line item.
• Acquirers protect themselves by holding reserves (fixed, rolling or up-front) against merchants with high chargeback risk, tying up working capital.
• Chargeback fees, arbitration fees and network penalties add to the total cost of acceptance alongside interchange and processor markups.
• Chargeback trends are a leading indicator of fraud exposure, product quality problems and customer-service failures, and should be reported to the risk committee.
Chargeback Prevention Best Practices
• Use Address Verification Service (AVS) and card verification code (CVV2) checks for card-not-present sales.
• Deploy EMV terminals and 3-D Secure to secure the liability shifts.
• Use a clear billing descriptor so customers recognize the charge on their statements.
• Obtain proof of delivery and keep records for the full dispute window.
• Process refunds promptly and respond to retrieval requests and disputes within deadlines.
• Use fraud-screening tools (velocity checks, device fingerprinting, geolocation) and chargeback alert services that let the merchant refund before a dispute becomes a formal chargeback.
5. How PCI DSS, Chargebacks and Data Retention Fit Together
These three subjects are linked by a single idea: every piece of card data a company keeps is both an asset and a liability. Merchants are tempted to retain full card numbers to simplify refunds, recurring billing and chargeback representment. PCI DSS says this is acceptable only for permitted data elements, only when encrypted or tokenized, and only for as long as a documented business need exists. Tokenization resolves the tension: the merchant keeps a token that supports refunds and dispute responses while the sensitive PAN resides with the processor. A strong chargeback program also depends on good record retention, but of transaction evidence (receipts, delivery proof, authorization codes), not of sensitive authentication data.
6. Exam Tips: Answering Questions on PCI DSS, Chargebacks and Card Data Retention
Tip 1 – Know who owns the standard. If an answer choice says PCI DSS is a federal regulation, enforced by the Federal Reserve, the FTC or the OCC, it is wrong. PCI DSS is a private industry standard created by the card brands and administered by the PCI Security Standards Council, enforced through the merchant agreement with the acquirer.
Tip 2 – Memorize the never-store list. Any question about what may not be retained after authorization points to full track (magnetic stripe) data, the card verification code (CVV2/CVC2/CID) and the PIN or PIN block. The word even if encrypted is the clue that the question is about sensitive authentication data. By contrast, PAN, name, expiration date and service code may be stored if protected.
Tip 3 – Masking versus encryption. Masking applies to display (first six or eight and last four digits visible); rendering unreadable applies to storage (encryption, truncation, hashing, tokenization). Do not confuse them.
Tip 4 – Tokenization is the go-to scope reducer. When a question asks how a merchant can continue to support recurring billing or refunds while minimizing PCI compliance burden, the answer is almost always tokenization (or outsourcing to a hosted payment page). Remember that outsourcing reduces scope but does not transfer ultimate accountability.
Tip 5 – Levels follow volume; validation follows levels. Level 1 (more than 6 million transactions, or any breached merchant) requires a QSA on-site assessment and ROC; lower levels use the SAQ. All levels except small Level 4 merchants need quarterly ASV network scans. If the question mentions a breach, remember the merchant is automatically treated as Level 1.
Tip 6 – Follow the money in a chargeback question. The flow is cardholder → issuer → network → acquirer → merchant. The issuer initiates the chargeback; the acquirer debits the merchant; the merchant may represent; the network arbitrates. Questions that reverse these roles are testing whether you know the sequence.
Tip 7 – Liability shift logic. For card-present counterfeit fraud, liability rests with the party that has not adopted EMV. For e-commerce, 3-D Secure shifts fraud liability to the issuer. Without either protection, the card-not-present merchant eats the loss. Expect a scenario question built on this.
Tip 8 – Reason codes drive the response. If a chargeback reason is fraud or no authorization, the best defense is evidence of authorization and authentication (AVS, CVV match, 3-D Secure, chip read). If the reason is goods not received or not as described, the defense is proof of delivery and customer communication. Match the evidence to the reason.
Tip 9 – Think like a treasurer, not an IT auditor. CTP questions frame these issues in terms of cost of acceptance, cash flow impact, reserve requirements, operational risk reporting and relationship management with the acquirer. When two answers both seem technically correct, prefer the one that addresses the treasury or risk-management consequence.
Tip 10 – Watch absolute words. Answers claiming compliance eliminates breach liability, that chargebacks cannot be contested, or that data can be stored indefinitely if encrypted are typically wrong. Compliance reduces exposure, chargebacks can be represented, and retention must be limited by a documented policy with regular purging.
Tip 11 – Know the thresholds roughly, not precisely. The exam is unlikely to test exact fine amounts, but it may test the concept that a chargeback ratio around 1 percent triggers network monitoring programs, that the dispute window is roughly 120 days, and that excessive chargebacks can lead to reserves, termination and MATCH listing.
Tip 12 – Use elimination on list questions. When asked which item is not one of the 12 PCI DSS requirements, look for controls that are purely financial (such as segregation of duties over wire transfers) or that belong to another framework (such as SOX internal control over financial reporting). PCI requirements are all about protecting cardholder data and the systems that touch it.
7. Quick Review Summary
• PCI DSS = industry standard from the PCI Security Standards Council (Visa, Mastercard, Amex, Discover, JCB); contractual, not statutory.
• 6 goals, 12 requirements; validated annually (ROC by QSA for Level 1, SAQ for others) plus quarterly ASV scans.
• Storable if protected: PAN, name, expiration, service code. Never storable after authorization: full track data, card verification code, PIN.
• Retention policy: minimum necessary, defined periods, quarterly purge; tokenization, P2PE, hosted pages and segmentation reduce scope.
• Chargeback: issuer reverses a transaction; acquirer debits merchant plus fee; merchant may represent with evidence; network arbitrates.
• Liability shifts: EMV (card-present) and 3-D Secure (e-commerce) move fraud losses away from compliant merchants.
• Excessive chargebacks lead to fines, reserves, termination and MATCH listing; treasury must forecast, reconcile and report them as operational risk.
Master these points and you will be well equipped for any CTP question on PCI DSS, chargebacks and card data retention.
CTP - PCI DSS, Chargebacks and Card Data Retention Example Questions
Test your knowledge of PCI DSS, Chargebacks and Card Data Retention
Question 1
Under PCI DSS, which card data element may a merchant keep after authorization, provided it is rendered unreadable wherever it is stored?
Question 2
A merchant processed 25,000 card transactions in a month and received 125 chargebacks. Chargeback ratio = chargebacks ÷ transactions. What is the merchant's chargeback ratio for the month, expressed as a percentage?
Question 3
A company's call center agents key card numbers into the order system, which keeps the full card number in an encrypted database. The company uses the stored data to bill repeat orders and to match sales records when a chargeback arrives. The treasurer wants to shrink the company's PCI DSS compliance scope and keep both capabilities. Which change BEST meets this goal?