Module 3: Compliance and PCI Rules

Learning Objectives

PCI: The Basics

PCI is short for ‘Payments Card Industry’. The PCI is responsible for administering a strict set of rules, known as PCI DSS (Payments Card Industry Data Security Standards). It’s an industry-wide group of guidelines dedicated to preventing fraud.

PCI DSS was set up by the Data Security Council, a body made up of the big credit card brands, including Mastercard, Visa, American Express, and Discover.
PCI DSS credit card processing laws help safeguard the cardholder’s data when a transaction takes place, and all merchants, financial institutions, payment processors, and merchant services providers are responsible for upholding them. 

PCI compliance doesn’t just protect your customers, though – it’ll protect your business from data breaches, and help you swerve the crippling cost of fraudulent transactions. Plus, not complying with PCI standards comes with big fines – meaning it’s best to get wise to them sooner rather than later.

How Do You Ensure Your Business is PCI Compliant?
How you’ll remain PCI compliant depends largely on the type of company you’ve chosen to process your credit card payments. 
Dedicated (or traditional) merchant accounts set up with a bank or independent company may require you to take PCI compliance into your own hands. This involves validating your current data security standards by filling out a Self-Assessment Questionnaire (SAQ). 

The PCI has nine different forms. Which one you must fill out is based on your transaction volume, and the method you use to accept credit card payments. It’s your job to figure out (or hire someone to figure out) which form is relevant to you, and ensure it gets completed on an annual basis. 

Based on how much you’re processing, you’ll be sorted into one of four ‘levels’ of compliance. 

The Four Levels of PCI Compliance

• For businesses that process more than six million payments a year
• Most expensive
• Comes with hardware and software costs, plus the fees involved with training an internal auditor
  • Validation Requirements
    • Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or Internal Auditor
    • Quarterly network scan by an ASV
    • Attestation of Compliance Form

• For businesses that process between one million and six million payments a year
  • Validation Requirements
    • Annual Self-Assessment Questionnaire (SAQ)
    • Quarterly network scan by an ASV
    • Attestation of Compliance Form

• For businesses that take between 20,000 and one million e-commerce payments annually
  • Validation Requirements
    • Annual Self-Assessment Questionnaire (SAQ)
    • Quarterly network scan by ASV
    • Attestation of Compliance Form

• For businesses that process up to 20,000 payments a year via e-commerce 
• OR up to one million payments via other channels
  • Validation Requirements
    • Annual Self-Assessment Questionnaire (SAQ), recommended
    • Quarterly network scan by ASV, if applicable
    • Compliance validation requirements set by merchant bank

PCI: The 3-Step Process

 

PCI DSS Requirements Overview

01. Protect Your System Firewalls  Install a hardware and software firewall Tweak firewall configuration for your system Have strict firewall rules	07. Restrict Access Firewalls  Restrict access to cardholder data Document who has access to the card data environment Establish a role-based access control system
02. Use Adequate Configuration Standards  Change default passwords Harden your systems Implement system configuration management	08. Use Unique ID Credentials  Use unique ID credentials for every employee  Disable/delete inactive accounts Configure multi-factor authentication
03. Protect Stored Data  Find where card data is held Craft your card flow diagram  Encrypt stored card data	09. Ensure Physical Security  Control physical access at your workplace  Keep track of POS terminals  Train your employees often
04. Secure Data Over Open and Public Networks  Know where data is transmitted and received Encrypt all transmitted cardholder data system Stop using SSL and early TLS	10. Implement Logging and Log Monitoring   Implement logging and alerting  Establish log management  Create log management system rules
05. Protect System With Anti-Virus  Create a vulnerability management plan Regularly update anti-virus Maintain an up-to-date malware program	11.  Test Security Systems and Processes Know your environment  Run vulnerability scans quarterly Conduct a penetration test
06. Protect System With Anti-Virus  Consistently update your systems  Apply all critical/high patches to systems and software Establish secure software develpment processes	12. Start Documentation and Risk Assessments Document policies and procedures for everything Implement a risk assessment process Create an incident response plan (IRP)

PCI DSS Requirement Overview (Source SecurityMetrics®)

It's also important to note that PCI compliance is an ongoing process; complying isn’t a one-time thing, but a constant cycle of assessment and reporting. PCI’s ‘3-Step Process’ serves as a good guide to get going with: 

1. ASSESS: Identifying cardholder data, taking an inventory of IT assets and business processes for payment card processing, and analyzing them for vulnerabilities.
2. REMEDIATE: Fixing vulnerabilities and eliminating the storage of cardholder data unless absolutely necessary. 
3. REPORT: Compiling and submitting required reports to the appropriate acquiring bank and card brands.

(Source: PCI Securities Standard Council) 

IN SUMMARY
PCI RULES: Single use virtual card numbers – corporate cards single-use virtual cards do not require PCI DSS be applied because these cards are inactive/disabled after use, therefore the PANS no longer pose fraud risk to the payment system. VCNs which are Mastercard corporate cards require no obligation by the corporate card client to provide validation that corporate card data is protected in accordance with PCI DSS. The corporate card client is not obligated to secure their data as it is their cardholder data and their risk to assume and manage. As a result, Mastercard does not require corporate card entities to validate PCI DSS compliance for its commercial cards but highly recommends taking appropriate steps to secure those account numbers.

However, Virtual Card Numbers cannot be recognized as single use (i.e. via BIN) by suppliers. Therefore, hoteliers must provide and protect VCNs in the same way required by PCI DSS for standard, plastic cards.

What is Strong Customer Authentication (SCA)

Strong Customer Authentication (SCA) is an EEA & UK regulatory requirement under the revised Payment Services Directive (PSD2) designed to make payments more secure. It means on occasion that cardholders will be required to authenticate themselves via the use of EMV®3DS technology before completing checkout.

Source: High Level Authentication Flow, Visa, 2018. 

SCA must be performed on all in-scope travel related transactions at the time of booking unless the transaction qualifies for an exemption or is out of scope.

The Secure Corporate Payment (SCP) exemption will be applicable for many transactions related to business travel bookings; however, many transactions will not be eligible for the SCP exemption and will require SCA to be undertaken. Consequently TMCs, OBTs and travel suppliers taking business travel bookings should be preparing to authenticate cardholders where required at the time of booking. The use of EMV®3DS technology at the time of booking will assist with processing transactions even where the SCP exemption can be applied. 

How is Strong Customer Authentication (SCA) being managed today?

Most of the travel related merchants or intermediates like TMCs or the GDS process their transactions as MOTO which is out of scope for SCA. Based on this, there is currently no disruption in this channel as many transactions are being processed without the requirement for SCA or SCA exemptions.

There are cases like direct website bookings via a TMC, where SCA gets activated when an agent initiates the booking, and the cardholder gets a code on their phone. In this case the cardholder might be passing on the code to the travel agent which is usually done via a phone call. The same scenario could apply when an assistant books for a cardholder, here the code might be being shared at the time of booking.

Impacts to Consider

• Sharing of the SCA codes provided by your card issuer to other parties goes against your cardholder T&Cs and is not permitted. There is also a risk that issuers may consider this as negligence in the event that fraud takes place on the card and will withdraw any fraud protection they currently offer.

Best Practice

• For online transactions where SCA will be required it is recommended that the cardholder undertakes these types of transactions themselves online instead of via a 3rd party. 
• Where an assistant is required to make online bookings for their manager, they should be furnished with their own card with their own mobile number registered against the account. If supported by the issuer this could be an additional card issued on the manager’s account.

Source: SCA - Travel and Hospitality Readiness, 2020. 
 

Pain points that could occur when MOTO is removed as an option:

The MOTO category is out of scope as it’s generally regarded as paper mail/mail order or telephone orders directly from the cardholder to the merchant. Consequently, the regulator considers it not to be an electronic/digital method of payment and two factor authentication is not possible. However, the travel industry has traditionally used MOTO for many travel bookings that originate electronically through OBTs and email, for example. As these are not true MOTO transactions, it is anticipated that the industry will need to transition away from flagging them as MOTO to true e-commerce transactions that will need authenticating, or a valid exemption applied, so that they do not appear to be circumventing the requirement for SCA. It could be expected that a transition away from MOTO will come with advance notice of possibly no more than one year.

When the use of MOTO is removed for current use cases, the following situations might need a change of process, or the transaction may be declined:
 

GDS Air Booking

Where MOTO is not an option anymore, the authentication of a cardholder during a TMC booking performed by an agent or OBT would need to happen when the ticket is booked. This could be at night when a TMC automation starts but even with instant ticketing, bookings could be impacted.

Impacts to Consider

The cardholder could be unavailable at the time; they may be in a meeting, on a plane or asleep and may not be able to respond in time so the transaction would be declined. Even if the cardholder was available, they may not have anywhere to enter the required code so the transaction would be declined. The existing booking flows would need to be rearranged to allow a transaction getting SCA on time. Cardholders with many bookings going on at the same time may be unable to identify for what booking they get the SCA request.

Best Practice

All payments for TMC originated bookings via the GDS can use the SCP exemption, even for Corporate cards issued to employees. The exemption flag needs to be used and the ecosystems (TMCs, OBTs, GDS, acquirers) need to perform work to support this as it will need to be passed from the booking tool/TMC via the GDS to the relevant acquirer. Receipt of the exemption flag in the authorization request will allow the issuer to apply the exemption.

GDS Hotel Booking

In case the hotel needs to charge the card for a no-show or other transaction when the cardholder is not present.

Impacts To Consider

Without MOTO being available for use or a cryptogram allowing the hotel to perform a merchant-initiated transaction (MIT), the transaction would likely be declined.

Best Practice

All payments for pay-at-property bookings should have SCA performed at time of booking so that the authentication cryptogram is passed onto the hotel for use as a MIT (merchant-initiated transaction). The ecosystems (TMCs, OBTs, GDS, Hotel PMS, acquirers) need to perform work to support this.

TMC Fee

TMC fees are usually charged via a batch file upload at night. This process does not allow for an SCA request. If the TMC changes the charge model and debits the card at an earlier stage, it could mean that cardholders may not be able to identify a charge or approve it within the common 10-minute SCA window.

Impacts to Consider

Issuers/Acquirers may not continue to support the batch process. Or if the model is changed it could mean the cardholder is unavailable at the time, may not be able to respond in time, or have anywhere to enter the required code so the transaction would be declined.

Best Practice

All payments for TMC originated bookings can use the SCP exemption, even for Corporate cards issued to employees. The exemption flag needs to be used and the eco systems (TMCs, acquirers) need to perform work to support this.

 
Calls for Action:
TMCs should check with acquirers, GDS, PSPs, OBTs etc. how a SCA process can be established, and/or how the SCP exemption can be applied. IATA/Airlines might check how an SCA process/SCP exemption can be implemented on GDS processes considering the TMC workflow. Corporate clients should check with their card issuers on alternative payment products like virtual cards or lodge cards that can always make use of the SCP exemption and without the requirement to use the SCP exemption flag.
 

Two-Factor Authentication

Two-factor authentication (2FA), also called dual-factor authentication or two-step verification, is a process in which users provide two of three different authentication factors to verify themselves. Used to secure credit and debit card transactions against data theft and fraud, the Payment Card Industry Data Security Standard (PCI DSS) requires 2FA as a prerequisite for receiving certification.

Implementation of 2FA enhances the security of the system or website for increased protection of the consumer's credentials and the resources the consumer is accessing. The verification steps must have two different types of factors in order for the security process to be defined as 2FA. Authentication should include 2 of 3 elements:

• Something the customer knows (e.g. PIN or Password) 
• Something the customer has (e.g. phone or token) 
• Something the customer is (e.g. face or fingerprint recognition) 

Source: SwoopNow, How Does Two Step Authentication Work, 2019.