Consumers and organizations have a variety of options for making and receiving payments. While these payment types share the ultimate goal of transferring funds from payer to payee, the path those funds travel and the approaches employed for safely and securely completing transactions vary. The Secure Payments Task Force developed the Payment Lifecycles and Security Profiles as an educational resource and to provide perspectives related to:
- The lifecycles of the most common payment types, covering enrollment, transaction flow and reconciliation
- Security methods, identity management controls and sensitive data occurring at each step in the payment lifecycles
- Relevant laws and regulations, and other references, as well as challenges and improvement opportunities related to each payment type
The profiles employ a consistent format for describing the lifecycle of each payment type. The lifecycle template is not designed to represent the nuances of specific payment transaction flows, but as a broad taxonomy that can be applied across different payment types for understanding and comparing controls and risks. The profiles are not all-encompassing in describing the layered security strategies that may be employed by specific networks, providers or businesses and shouldn’t be considered an assessment of overall security of different payment types. The improvement opportunities noted in the profiles highlight areas for further industry exploration and are not intended as guidance or specific solutions to be implemented.
These valuable resources were developed through the collaborative efforts of more than 200 task force participants with diverse payments and security expertise and perspectives. It is the hope of the task force that by helping industry stakeholders better understand these payments processes, the security and risks associated with these processes, and potential improvement opportunities, they will be well positioned to take action to strengthen their payment security practices.
Note: These materials were created by the Secure Payments Task Force and are intended to be used as educational resources. The information provided in the Payment Lifecycles and Security Profiles does not necessarily reflect the views of any particular individual or organization participating in the Secure Payments Task Force. The document is not intended to provide business or legal advice and is not regulatory guidance. Readers should consult with their own business and legal advisors.
Feedback and/or questions related to the Payment Lifecycles and Security Profiles can be submitted by using the “provide feedback” form.
This overview supports the Payment Lifecycle and Security Profile for the Card Present Payment Type.Card Present Definition: A payment card (e.g. credit or debit) funded transaction whereby the cardholder either physically swipes the magnetic stripe of their card or inserts their EMV chip card at the point of sale terminal.
Overview of Laws, Regulations and References on Payment Security (Including Challenges and Improvement Opportunities)
Debit cards (consumer) – Electronic Fund Transfer Act (EFTA), 15 U.S. Code (U.S.C.) § 1693 et seq.; Regulation E. 12 Code of Federal Regulations (CFR) § 1005.2 et seq. (EFTA applies only to accounts “established primarily for personal, family, or household purposes” 15 U.S.C. § 1693a(2))
Credit cards (consumer) – Truth in Lending Act (TILA), 15 U.S.C. § 1601 et seq.; Regulation Z. 12 CFR § 1026.1 et seq. (TILA exempts “extensions of credit primarily for business, commercial, or agricultural purposes, or to governmental agencies or instrumentalities, or to organizations”)
Prepaid cards (consumer) – Under the Consumer Financial Protection Bureau (CFPB) Prepaid Accounts Rule (81 Fed. Reg. 83934 (November 22, 2016)) (to be codified at 12 CFR pts. 1005 and 1026), as amended on January 25, 2018, and effective April 1, 2019, Regulation E would apply to prepaid cards, with Regulation Z expanded to apply to prepaid cards with certain credit features.
Financial Crimes Enforcement Network (FinCEN) Bank Secrecy Act, 31 U.S.C. § 5311, et seq.; 31 CFR § 1010.100, et seq. (implementing regulations); Federal Financial Institutions Examination Council (FFIEC), Bank Secrecy Act/Anti-Money Laundering Examination Manual (2014)
Customer Identification Program (CIP), 31 CFR 1020.220, et seq.
Identity Theft Red Flags Rules, 12 CFR § 41.90 (OCC); 12 CFR § 222.90 (FRB); 12 CFR § 334.90 (FDIC); 12 CFR § 717.90 (NUCA); 16 CFR § 681.1 (FTC); 17 CFR § 162.30 (CFTC); 17 CFR § 248.201 (SEC)
Board of Governors of the Federal Reserve System, Guidance on Managing Outsourcing Risk (Dec. 5, 2013) – FRB SR 13-19: Third party oversight guidance, set of cyber-risk oversight activities which includes reporting and expectations for Boards of Directors and Senior Management.
FFIEC IT Exam Handbooks: Some of the handbooks are more frequently a factor in exams, but they all contain provisions that impact payments compliance in the areas of confidentiality, availability, data integrity, privacy and third party oversight.
- FFIEC, IT Examination Handbook, Information Security (Sept. 2016)
- FFIEC, IT Examination Handbook, Retail Payment Systems (Apr. 2016)
- FFIEC, IT Examination Handbook, Supervision of Technology Service Providers (Oct. 2012)
FFIEC, Authentication in an Internet Banking Environment (Oct. 12, 2005); FFIEC, Supplemental to Authentication in an Internet Banking Environment (June 28, 2011)
FFIEC, Cybersecurity Assessment Tool (CAT) (June 2015): The CAT is a support tool issued by the FFIEC to assist financial organizations with managing cyber-risk. CAT is strongly encouraged by some US states, but in general it is based on existing guidance and thus does not constitute new regulation.
Gramm-Leach-Bliley Act (1999), 15 U.S.C. § 6801 et seq.
Regulation P, Privacy of Consumer Financial Information, 12 CFR 1016.1 et seq. – enacted to control how financial institutions manage the private information of individuals. In addition, the Interagency Guidelines Establishing Standards for Safeguarding Customer Information include provisions associated with the role of risk management, boards and third party oversight.
Federal Trade Commission Act (1914), 15 U.S.C. § 45(a) (prohibiting “unfair or deceptive acts or practices in or affecting commerce”); 16 CFR § 314.3 (requiring companies to develop written information security programs to protect customer information)
Consumer Financial Protection Act of 2010, 15 U.S.C. § 5531 et seq. (prohibiting “unfair, deceptive, or abusive act[s] or practice[s]. . .” in consumer finance)
State-based cybersecurity and breach laws: A challenge due to the variation among those sets of regulation which include:
- All 50 States address unauthorized access, malware and viruses
- 20 States address spyware
- 23 States address phishing
International cybersecurity regulations and related data-protection laws: Vary widely and continue to evolve, e.g. European Union General Data Protection Regulations (May 2018); Japan: The Act on the Protection of Information (May 2017)
Office of Foreign Assets Control (OFAC)/Sanction Screening
American National Standards Institute (ANSI) X9.122 Secure Customer Authentication for Internet Payments – draft in approval stage
- Requirements for secure customer authentication for electronic payment transactions over multiple channels initiated through the interchange system (debit/credit network) via internet, mobile or voice channels
- Covers passcodes, passwords, biometrics, magnetic stripe authentication values, cryptography, small device authentication, and vendor considerations
International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 7816-4 Identification cards – Integrated circuit cards Part 4: Organization, security and commands for interchange
ISO Information Technology – Encryption Algorithms
- ISO/IEC 10116 – Security techniques – Modes of operation for an n-bit block cipher – These modes provide methods for encrypting and decrypting data where the bit length of the data may exceed the size of the block cipher and provide protection of data confidentiality.
- ISO/IEC 18033-2 – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers – Encryption (or encipherment) techniques protect the confidentiality of stored or transmitted data. An encryption algorithm is applied to plaintext or cleartext data to yield encrypted data (or ciphertext). The encryption algorithm should be designed so that the ciphertext yields no information about the plaintext except, perhaps, its length. Every encryption algorithm has a corresponding decryption algorithm, which transforms ciphertext back into its original plaintext. An asymmetric, i.e. public-key, encryption scheme allows a sender to use a recipient’s public key to transmit an encryption of a message to the receiver, who uses a secret key to decrypt the given ciphertext to obtain the original message.
- ISO/IEC 18033-3 – Security techniques – Encryption algorithms – Part 3: Block ciphers: A block cipher is a symmetric encipherment system with the property that the encryption algorithm operates on a block of plaintext, i.e. a string of bits of a defined length, to yield a block of ciphertext. The following algorithms are specified in this standard:
- 64-bit block ciphers: TDEA, MISTY1, CAST-128, HIGHT
- 128-bit block ciphers: AES, Camellia, SEED
ANSI Accredited Standards Committee (ASC) X9.97 Secure Cryptographic Devices (Retail)
- Part 1: Concepts, Requirements and Evaluation Methods – incorporates the cryptographic processes defined in ISO 9564, ISO 16609 and ISO 11568. Part 1 has two primary purposes:
- State the requirements concerning both the operational characteristics of secure cryptographic devices (SCDs) and the management of such devices throughout all stages of their life cycle.
- Standardize the methodology for verifying compliance with those requirements.
- Part 2: Security Compliance Checklists for Devices Used in Financial Transactions – Identical to ISO 13491, which specifies use of checklists to evaluate SCDs incorporating cryptographic processes, as specified in parts 1 and 2 of ISO 9564, ISO 16609 and parts 1 to 6 of ISO 11568, in the financial services environment. IC payment cards are subject to the requirements identified in this part of ISO 13491 up until the time of issue, after which they are regarded as a “personal” device and outside of the scope of this document.
Protection of Sensitive Payment Card Data through Encryption
ANSI ASC X9.119 Retail Financial Services – Requirements for Protection of Sensitive Payment Card Data
- Part 1: Using Encryption Methods – defines minimum security requirements when employing encryption methods to protect sensitive payment card data. “Protection” refers to maintaining the secrecy of the data from unauthorized disclosure. It applies to protection of the data from the point of encryption to the point of decryption, wherever those points may be in a given system. Addresses the protection of sensitive payment card data from the Requesting Entity to the Token Request Interface.
- Part 2: Implementing Post-Authorization Tokenization Systems standard focuses on the Tokenization Service and the Token Request Interface. It defines the minimum security requirements when employing a post-authorization tokenization system to protect sensitive payment card data. “Protection” refers to maintaining the secrecy and integrity of the data protected by tokenization from unauthorized disclosure and modification. Data encryption, integrity protection, and the support for key management services are required to protect sensitive payment card data during the tokenization and de-tokenization process.
ISO 13491 Banking – Secure cryptographic devices, all parts
Format Preserving Encryption
- ANSI ASC X9.124 Format Preserving Encryption of Financial Information – Format Preserving Encryption is useful in situations where fixed-format data, such as Primary Account Numbers or Social Security Numbers, must be encrypted, but there is a requirement to limit changes to existing communication protocols, database schemata or application code. Format Preserving Encryption Counter Mode is a particularly simple and efficient mechanism to achieve format preserving encryption, which shares many of the strengths and challenges of Counter Mode (CTR) as defined in NIST SP 38B.
- Part 1 Cryptographic algorithms – Block Ciphers – covers format preserving block ciphers
- Part 2 Cryptographic algorithms – Stream Ciphers – covers format preserving stream ciphers
- NIST SP 38B – Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication – this recommendation specifies a message authentication code (MAC) algorithm based on a symmetric key block cipher. This block cipher-based MAC algorithm, called CMAC, may be used to provide assurance of the authenticity and, hence, the integrity of binary data.
EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3
EMV Payment Tokenization Specification – Technical Framework
- Payment tokens are surrogate values that replace the Primary Account Number (PAN) in the payments ecosystem. They may be used to originate payment transactions, while non-payment tokens may be used for ancillary processes, such as loyalty tracking. This specification does not address non-payment tokens, but does not does preclude their use.
Payment Card Industry (PCI) Data Security Standard (DSS) – Requirements and Security Assessment Procedures
- Developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. It provides a baseline of technical and operational requirements designed to protect account data and applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
PCI Payment Application Data Security Standard (PA-DSS) – Requirements and Security Assessment Procedures
- Define security requirements and assessment procedures for software vendors of payment applications. This document is to be used by Payment Application Qualified Security Assessors (PA-QSAs) conducting payment application assessments to validate that a payment application complies with the PA-DSS.
- Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of Primary Account Numbers (PAN), full track data, Card Verification Values1, PINs and PIN blocks, and the damaging fraud resulting from these breaches.
PCI Point-to-Point-Encryption (P2PE) – Solution Requirements and Testing Procedures
- Defines both requirements and testing procedures for P2PE solutions. The objective of this standard is to facilitate the development, approval, and deployment of PCI approved P2PE solutions that will increase the protection of account data by encrypting that data from the point of interaction within the encryption environment where account data is captured through to the point of decrypting that data inside the decryption environment, effectively removing clear-text account data between these two points.
- The requirements contained within this standard are intended for P2PE solution providers and other entities that provide P2PE components or P2PE applications for use in P2PE solutions, as well as P2PE assessors evaluating these entities. Additionally, merchants benefit from using P2PE solutions due to increased protection of account data and subsequent reduction in the presence of clear-text account data within their environments.
PCI P2PE – Encryption, Decryption, and Key Management within Secure Cryptographic Devices (Hardware/Hardware)
- Provides a method for providers of P2PE solutions to validate their solutions, and for merchants to reduce the scope of their PCI DSS assessments when using a validated P2PE solution for account data acceptance and processing. Specifically, this version contains validation requirements and testing procedures for hardware-based encryption and decryption solutions, also called “hardware/hardware.” Hardware/hardware solutions utilize secure cryptographic devices for both encryption and decryption including at the point of merchant acceptance for encryption, and within hardware security modules (HSMs) for decryption.
PCI P2PE – Encryption and Key Management within Secure Cryptographic Devices, and Decryption of Account Data in Software (Hardware/Hybrid)
- Assignment of token usage parameters
- Token lifecycle management
- Processes to map or re-map tokens, or perform de-tokenization
- Cryptographic processes to support tokenization functions
- Maintenance of underlying token security and related processing controls, such as domain restrictions during transaction processing.
- This document for hardware/hybrid Point-to-Point Encryption (P2PE) solutions provides a method for providers of P2PE solutions to validate their solutions, and for merchants to reduce the scope of their PCI DSS assessments when using a validated P2PE solution for account data acceptance and processing. Specifically, this version contains validation requirements and testing procedures for hardware/hybrid solutions which utilize secure cryptographic devices at the point of merchant acceptance for encryption and for managing cryptographic keys in the decryption environment while utilizing non-SCDs for the decryption of account data.
PCI Token Service Providers (TSP) – Additional Security Requirements and Assessment Procedures for Token Service Providers (EMV Payment Tokens)
- The requirements in this document are intended to apply in addition to applicable PCI DSS requirements to the token data environment (TDE). The TDE is a dedicated, secure area within the TSP, where one or more of the following services are performed:
- Token generation, issuing, and mapping processes
- Manage over-the-air (OTA) personalization, lifecycle management, and preparation of personalization data; or
- Manage associated cryptographic keys.
PCI Card Production and Provisioning – Physical Security Requirements
- Manual is a comprehensive source of information for entities involved in card production and provisioning, which may include manufacturers, personalizers, pre-personalizers, chip embedders, data-preparation, and fulfillment.
- The contents of this manual specify the physical security requirements and procedures that entities must follow before, during, and after the following processes:
- Perform cloud-based or secure element (SE) provisioning services; Card manufacturing, chip embedding , personalization , storage, packaging, mailing, shipping or delivery, fulfillment
PCI Card Production and Provisioning – Logical Security Requirements
All systems and business processes associated with the logical security activities associated with card production and provisioning such as data preparation, pre-personalization, card personalization, PIN generation, PIN mailers, and card carriers and distribution must comply with the requirements in this document.
This document describes the logical security requirements required of entities that:
- Perform cloud-based or secure element (SE) provisioning services;
- Manage over-the-air (OTA) personalization, lifecycle management, and preparation of personalization data; or
- Manage associated cryptographic keys.
Wherever the requirements specify personalization, the requirements also apply to cloud-based provisioning networks (e.g., those for host card emulation). Cloud-based systems differ from those based on requiring the use of a secure element on a mobile device.
PCI PIN Transaction Security (PTS) Point of Interaction (POI) – Modular Security Requirements
- Provides vendors with a list of all the security requirements against which their product will be evaluated in order to obtain Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) device approval
National Institute of Standards and Technology (NIST) Cybersecurity Framework
Payment network rules (e.g. Visa, MasterCard, American Express, Discover Network, JCB and debit card networks)
Payments stakeholders employ various methods and processes to comply with relevant state and federal regulations regarding customer onboarding as well as relevant private sector protocols. Greater focus on the development and adoption of standards related to online registration or mobile enrollment could enhance security.
Payment stakeholders are deploying authentication and multiple layers of risk mitigation. Some of these tools include dynamic data, tokens, multi-factor authentication, geolocation, and analytic engines. Greater deployment of such tools may help reduce risk.
Greater deployment of tokenization, user authentication and encryption based on open standards could enhance payment security.
Improvements to the quality and accuracy of data collected and used to facilitate mail order, telephone order, recurring payments, one-time card on file and card present key entry payments may help further mitigate payments risk. Participants who collect, process, or authorize transactional data play an important role in ensuring the accuracy of data submitted. This includes ensuring that hardware and software are properly configured. Participants may use this information as part of their authentication decision process, making accuracy an important priority.
Greater focus on development and adoption of risk-based cybersecurity rules, frameworks and open standards could enhance security.
Last Updated: 02/21/2018
1Card Verification Values: Card Verification Values represent data elements that are (1) encoded on the magnetic stripe or the chip of a payment card; or (2) printed on the physical payment card and are used to validate the card information during the transaction authorization process. Card Verification Values encoded on the magnetic stripe (e.g. CAV, CVV, CVC, CSC) or on the chip (e.g. dCVV, iCVV) are generated via a secure cryptographic process and may be static or dynamic data used to validate the card during the authorization process. Card Verification Values printed on the physical card (e.g. CID, CAV2, CVC2, CVV2) may be three-digit or four-digit codes printed on the front or back of the physical card that are uniquely associated with the physical card and ties the primary account number to the physical card. Note: Payment network rules and the Payment Card Industry (PCI) Security Standards Council provide additional definitions of Card Verification Values.