What counts as payment data
Payment data is any information generated by or attached to a payment transaction, whether it concerns the instrument, the payer, or the transaction itself. The term covers five families of data governed by different rules, and that patchwork of regimes lies behind nearly every compliance failure. The card number falls under a private standard written by the card networks. The security code falls under the same standard, which flatly prohibits storing it after authorization. The transaction details concern the anti-money laundering supervisor, whose rules require five years of retention. The payer's identity falls under data protection law, which requires the opposite: erasure as soon as the data is no longer needed. These two obligations apply to the same record and call for opposite handling.
| Card type | Examples | Governed by | What breaks in practice |
|---|---|---|---|
| Card account data | PAN, expiration date, cardholder name, service code | PCI DSS, through the acquiring contract | The PAN leaks outside the declared scope: application logs, CSV exports, support tickets |
| Sensitive authentication data | Full track or chip data, CVV2/CVC2, PIN block | PCI DSS, requirement 3.3.1 | CVV stored “for the subscription”: a classic mistake the networks penalize |
| Transaction data | Amount, currency, timestamp, MCC, MID/TID, ARN, authorization code | Anti-money laundering rules, network dispute rules | Purged too early: no evidence for chargebacks, no audit trail for the regulator |
| Customer identification data | Name, address, ID document, date of birth, beneficial owner | Data protection law and due diligence (KYC) obligations | Two conflicting obligations on the same file: retain and minimize |
| Technical metadata | IP address, device fingerprint, session ID, fraud score | Data protection law, often overlooked | Nobody asks for them and nobody purges them: they outlive everything else |
A compliance program separates these five families from the inventory stage on. The question then becomes which family each record belongs to and which rule governs it, not just where payment data is located. A due diligence file and an authorization log sit in the same IT system, follow opposite rules, and must be handled separately.
PCI DSS 4.0: what it covers and what it ignores
PCI DSS is a security standard for payment card data, and it has no force of law. It is published by the PCI Security Standards Council, a body founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB. Its binding force comes from the chain of contracts. The network imposes it on the acquirer, the acquirer on the merchant, and the merchant on its service providers, each passing the obligation down through its own contracts. That is how the standard reaches every company that handles card data, in any country, without any legislature ever voting on it.
The current version is v4.0.1, published in June 2024 as an editorial revision of v4.0 (March 2022). The substantive change comes less from that revision than from the effective dates of the requirements it carries over. The “future-dated” requirements had been treated as best practice until then. They became mandatory on March 31, 2025. Two of them target data theft in the shopper's browser: managing payment page scripts (6.4.3) and detecting tampering with them (11.6.1). Earlier versions focused on the server and did not cover the shopper's browser, which stayed outside the audited scope.
- The scope is the CDE: the people, processes, and systems that store, process, or transmit account data, plus any connected system that could compromise them.
- Cardholder data may be stored, provided the PAN is rendered unreadable: truncation, salted hashing, strong cryptography, or tokenization.
- Sensitive authentication data may never be stored after authorization, even if encrypted. The rule allows no business exception.
- Network segmentation is the economic lever: whatever leaves the scope leaves the audit, and assessment costs fall accordingly.
- Compliance is an annual snapshot; security is an ongoing state. Several high-profile breaches hit companies that had been validated as compliant at the time.
India: exclusive in-country storage
Payment data localization in India rests on a Reserve Bank of India circular, the shortest and most restrictive text in the payments world. Circular RBI/2017-18/153, reference DPSS.CO.OD No.2785/06.08.005/2017-2018, is dated April 6, 2018. It requires that all data relating to the payment systems an operator runs be stored in a system located only in India. The stated reason is supervision. The RBI wants unfettered access to the logs that document how the national rails operate, and storage abroad would put those logs beyond its direct reach. Operators had to report compliance by October 15, 2018, and submit a system audit report by December 31, 2018.
The text allows only one exception. For the foreign leg of a cross-border transaction, the data may also be stored abroad if needed. The word “also” narrows that exception, since the Indian copy remains mandatory in every case. The legal basis is Section 10(2) read with Section 18 of the Payment and Settlement Systems Act, 2007. The scope is broad, covering authorized payment system operators as well as commercial banks, cooperative banks, payments banks, and small finance banks.
The scale of domestic flows explains the Indian regulator's firm stance. Unified Payments Interface has been run since 2016 by the National Payments Corporation of India under an RBI mandate. The rail processed 241.62 billion transactions in fiscal 2025–26, with volume up 30.0% (NPCI). RuPay, the national card scheme NPCI launched in 2012, accounts for more than half of all cards issued in the country. The logs from these two rails document systems the RBI supervises directly. Storing them outside the country would deny the regulator the unfettered access it insists on.
China: the data follows the architecture
Payment data localization in China results from two parallel mechanisms, one legal and one architectural. The legal mechanism rests on the Personal Information Protection Law (PIPL), adopted on August 20, 2021, and in force since November 1, 2021. Its Article 40 requires critical information infrastructure operators, and data handlers above a threshold set by the Cyberspace Administration of China, to store in China the personal information they collect there. The same law classifies financial accounts as sensitive personal information, a category with export thresholds 10 to 100 times lower.
The second mechanism is architectural, and it is more effective than the first. It governs the route payments take. Since June 2018, online payments by nonbank institutions (Alipay from Ant Group, WeChat Pay run by Tenpay) can no longer use direct bilateral connections to banks. They must go through NetsUnion Clearing Corporation, licensed in 2017, whose shareholders include the central bank and the payment institutions. Super-app flows became visible and controllable from a single point, without the central bank having to query each payment institution. Oversight is exercised through the infrastructure itself, not through reports filed by each operator. Alipay and WeChat Pay hold about 54% and 42% of China's mobile payments market (OECD, June 2025).
Exporting personal data out of China is governed by a regime separate from storage. It was overhauled by the Provisions on Promoting and Regulating Cross-Border Data Flows, Cyberspace Administration of China Order No. 16, in force since March 22, 2024. The rules relaxed thresholds that had become unworkable and created an exemption that directly affects payment acceptance. A transfer needed to conclude or perform a contract to which the individual is a party is exempt from all three export mechanisms. This covers cross-border shopping, remittances, payments, travel bookings, and visa applications.
| Case | Required mechanism | Basis |
|---|---|---|
| Critical information infrastructure operator, at any volume | Security assessment by the Cyberspace Administration | Order No. 16, Art. 7 |
| More than 1 million people (non-sensitive data) or more than 10,000 people (sensitive data) | Security assessment | Order No. 16, Art. 7 |
| 100,000 to under 1 million people (non-sensitive), or under 10,000 people (sensitive) | Standard contract or personal information protection certification | Order No. 16, Art. 8 |
| Fewer than 100,000 people, non-sensitive data | None of the three mechanisms | Order No. 16, Art. 5 |
| Transfer needed to perform a contract with the individual (payment, remittance, booking) | Exempt | Order No. 16, Art. 5 |
Indonesia: localizing processing rather than storage
Indonesia regulates payment data through a domestic routing requirement rather than a storage requirement. Bank Indonesia requires payments to run through licensed national infrastructure. Data generated by a licensed switch located in the country is there from the start. The effect is the same as a storage rule, and harder to get around, since no migration ever has to be ordered.
The framework is called GPN, for Gerbang Pembayaran Nasional (National Payment Gateway). In place since 2017, it requires domestic card transactions to be routed through one of four licensed switches (Artajasa, Rintis, Alto, Jalin), and it gave rise to a GPN debit card with lower interchange. Domestic routing is a condition for acquirers to operate, not a pricing option left to their discretion. The US challenged the requirement in its 2025 report on foreign trade barriers.
- QRIS, the single QR standard run by Bank Indonesia with the Asosiasi Sistem Pembayaran Indonesia (Indonesian Payment System Association) since 2019, ended wallet fragmentation: one code accepts every brand.
- BI-FAST, the 24/7 instant payment rail Bank Indonesia launched in 2021, with a price capped by the regulator at IDR 2,500 per transaction.
- PBI No. 22/23/PBI/2020, in force since July 1, 2021, ties licensing to ownership: Indonesian parties must hold 51% of voting rights in a payment service provider and 80% in an infrastructure provider.
- The electronic system operator regime, set by Government Regulation No. 71 of 2019, distinguishes public-scope from private-scope operators and governs where data centers may be located.
Russia: sealing off the infrastructure before the break
Russia's localization regime rests on Federal Law No. 161-FZ on the national payment system, amended in 2014 to require domestic processing of card transactions. Russia is the only case where such a requirement was followed by the international networks' withdrawal. Visa and Mastercard handed domestic switching over to NSPK (Natsionalnaya Sistema Platezhnykh Kart), a Bank of Russia subsidiary, eight years before they pulled out in 2022. The switch stayed in place. Domestic acceptance continued uninterrupted, while Russian cards stopped working abroad. That decoupling of domestic and international service is the lesson other regulators drew.
The same NSPK runs Mir, a card scheme launched in 2015 in response to the 2014 sanctions. It also serves as the operations and clearing center for the SBP (Faster Payments System), a phone-number-based instant payment rail launched in 2019. The central bank made SBP participation mandatory for large banks. That regulatory requirement ended Sberbank's dominance in person-to-person transfers, which competition alone had failed to dent.
A general personal data protection regime completes the picture. Federal Law No. 152-FZ requires Russian citizens' personal data to be recorded, systematized, accumulated, stored, and updated using databases located in Russia. Payments fall within its scope. A foreign operator serving this market would therefore need a full technical and legal presence there, regardless of sanctions.
GDPR: a cross-border payment is a data transfer
Chapter V of Regulation (EU) 2016/679 (the GDPR) sets a condition on data leaving the EU. It applies to any transfer of personal data to a third country. The regulation does not, however, require data to be hosted within the European Union. Article 44 states the principle: the level of protection the regulation guarantees must not be undermined by the transfer. The text sets a condition, not a ban, a distinction technical teams often get backwards. Hosting outside the EU remains lawful as long as it relies on one of the instruments set out in Chapter V.
The concept of a transfer covers routine operations in the acceptance chain that are often seen as purely technical. A card authorization sent to an issuer outside the EU is a transfer. Sending billing data to a US marketplace is another. Opening a dispute file from a support center in Manila falls into the same category. These operations run into the millions every day and almost never appear in the transfer maps the industry produces.
| Instrument | Article | What it requires | Its limits |
|---|---|---|---|
| Adequacy decision | Art. 45 | Confirm that the recipient is actually covered by the decision | Adequacy can be struck down: Decision 2016/1250 was, on July 16, 2020 |
| Standard contractual clauses | Art. 46 | Sign the right module of Decision 2021/914 and document a transfer impact assessment | A contract clause does not bind a foreign intelligence agency |
| Binding corporate rules | Art. 47 | Approval by the competent supervisory authority | Lengthy approval process, limited to intragroup transfers |
| Derogations for specific situations | Art. 49 | Occasional, non-repetitive transfer necessary to perform a contract | By design, does not cover an ongoing payment flow |
| Order from a foreign authority | Art. 48 | An international agreement, such as a mutual legal assistance treaty | A foreign subpoena alone is not a legal basis for disclosure |
How long to keep a transaction
The retention period is how long a payment record may or must be kept before it is deleted. It results from several obligations that apply to the same record, and they conflict. The data minimization principle requires deletion once the purpose has been served. AML traceability, network dispute windows, and accounting rules require retention. A single period for all data leads either to keeping everything out of caution or to purging too early on principle.
| Driver | Term | Starting point | Source |
|---|---|---|---|
| EU anti-money laundering due diligence | 5 years, extendable by up to 5 more | End of the business relationship, or date of the occasional transaction | Directive (EU) 2015/849, Art. 40 |
| Card dispute (chargeback) | 120 days, up to 540 days for services delivered later | Transaction processing date, or expected delivery date | Visa Core Rules, Mastercard Chargeback Guide |
| Card account data | Only as long as strictly necessary, with documented review and purging | Last justified business use | PCI DSS v4.0.1, requirement 3.2.1 |
| Sensitive authentication data | No retention allowed | Authorization | PCI DSS v4.0.1, requirement 3.3.1 |
| Personal data minimization | The shortest period consistent with the purpose | Collection | Regulation (EU) 2016/679, Art. 5(1)(e) |
| Indian supervision | No set period: the data stays in India for as long as it exists | – | RBI/2017-18/153, April 6, 2018 |
The unit of work is the data family, not the database table. A single payment record holds an amount to be kept for five years, a token to be kept for the life of the subscription, and an IP address that nobody can justify keeping after six months. Splitting the record and applying a period to each piece takes extra design work and a data model that separates the families from the start. A period applied to the whole table cannot show an inspector that each item was kept only as long as necessary.
- Inventory by data flow, not by database: follow the data from the point of acceptance to the last recipient, service providers included.
- Separate archives from live databases: the AML obligation can be met with an isolated, encrypted archive with restricted, logged access.
- Write the retention period into service provider contracts, with an obligation to return the data and then certify its deletion at exit.
- Check application logs: they escape business retention policies and routinely contain account data in cleartext.
- Test the purge on a real sample every quarter instead of trusting the job scheduler.
Tokenization: what it takes out of scope, and what it leaves alone
Tokenization replaces the card number with a substitute identifier called a token. The token travels through the acceptance chain while the PAN stays in the vault. The specification is published by EMVCo as the EMV Payment Tokenisation Specification – Technical Framework. It defines three roles: the Token Service Provider issues the token, the token requestor requests it and is identified in it, and the token vault alone holds the mapping to the PAN. Security then rests on domain restrictions: a token locked to one merchant, device, or channel is useless elsewhere if stolen.
Tokenization's effect on PCI DSS scope is direct and measurable. A merchant that no longer stores PANs removes entire systems from its CDE and cuts the related audit cost accordingly. The networks have run their own vaults since 2014. Visa Token Service and Mastercard Digital Enablement Service were built to provision cards into phones, then expanded to subscriptions, one-click checkout, and virtual cards. Visa reported more than 10 billion tokens issued since 2014, with 29% of its transactions processed using a token (Visa, June 4, 2024).
| Item | After tokenization | Rules that still apply |
|---|---|---|
| PAN held by the merchant | Removed, replaced by a token locked to that merchant | Leaves the CDE as PCI DSS defines it; this is the real gain |
| CVV2 security code | Never stored, before or after | Prohibition unchanged (requirement 3.3.1) |
| The token itself | Stored by the merchant, reused for each payment | Pseudonymized personal data: the GDPR and the PIPL apply in full |
| Amount, timestamp, merchant ID | Retained, unchanged | AML retention, Indian localization, Chinese export thresholds |
| Customer identity and contact details | Retained, unchanged | GDPR Chapter V for any transfer out of the EU; tokenization changes nothing |
A tokenized card generates several tokens, one per wallet and one per merchant. The merchant can no longer link those tokens to the same cardholder, since they share no common element. That is why EMVCo defined the Payment Account Reference (PAR), a stable identifier tied to the underlying account and shared by all its tokens. The PAR does not reveal the PAN. It is used to deduplicate customers, reconcile transactions, and run loyalty programs. A merchant that does not get the PAR from its provider ends up with tokens that no key links together.
- Map flows before systems: what needs documenting is the path the data takes, country by country and provider by provider.
- Separate security scope from territorial scope in your records of processing: two columns, two owners, two action plans.
- Require the physical location of the servers used for processing, storage, and backup in every market with a localization rule; the answer is never the provider's headquarters.
- Ask your PSP for the PAR as soon as tokenization goes live, and make sure it appears in the reconciliation files.
- Redo the exercise for every new market: a regional stack covering Southeast Asia from Singapore does not cover India, China, or Indonesia the same way.