Breaches, brand erosion, fines, legal challenges, limited resources, and an avalanche of conflicting advice – is any of that keeping you awake at night? Then there’s a good chance you have the job of ensuring your company is compliant with the Payment Card Industry Data Security Standard (PCI DSS). You can take some solace in this – you’re not alone.
The PCI Security Standards Council’s guidelines do not attempt to list all possible system configurations, relevant technologies, or processes that can help you to comply. There are so many configurations and technologies on the market that it would be an impossible task to list them all. The interpretation of the guidelines, consequently, is left up to you, your qualified security assessor and your acquirer who decides whether to accept the certification or not – hence the sleepless nights.
One thing is clear – if your organisation stores, transmits or processes any payment account information, you are responsible for maintaining PCI DSS compliance. You will have to interpret the guidelines as best as you can. Or, are there simpler answers out there?
The 12 PCI DSS requirements provide guidance on how to protect payment data for systems, processes and people that are in scope for compliance. In a nutshell, if payment data touches your systems, processes and people, they are all considered ‘in scope’ and should follow the requirements provided by PCI Security Standards Council. But what if your systems, processes and people were out of scope for compliance? What if payment data didn’t touch your systems, processes or people?
There are some newer technologies in the market that can help you reduce your PCI DSS scope so you have fewer compliance challenges. Let’s talk about two of those technologies here: payment tokenisation, together with remote secure storage of payment data, and hosted payment acceptance.
Payment Tokenisation with On-demand Secure Data Storage
Payment tokenisation with on-demand secure data storage at a remote location lets you operate your business with payment tokens instead of raw payment data. After initial payment information capture, the payment data is transmitted to a third-party vendor where the account information must be processed and stored by a Level 1 PCI DSS compliant services provider. A payment token is returned to the merchant, together with a masked account number. This token is used to initiate subsequent payment actions on that account. The masked account number, generally the first six digits and/or last four digits of the account, allows your staff to handle customer inquiries without visibility to full payment information. You can use the token anywhere in your system as you would use the credit card information. The token can be created with the same algorithm as a credit card number, so it passes the mod-10 check and your systems will accept it as a valid credit card number.
Hosted Payment Acceptance
Hosted payment acceptance allows you to transact payments with literally zero handling of sensitive payment data. The payment fields within your sales/order entry systems (online, call centre, kiosk, IP-based point-of-sale (POS), interactive voice responses system, mobile) are hosted directly by a PCI DSS compliant service provider. All payment data is captured, processed and stored within a third-party secure network. There is no impact to your brand or user experience – only the payment fields are hosted, which also allows for rapid localisation of payment channels to address new markets.
Or, if you have a call centre, an emerging approach called the hosted IVR system can handle payment information on your behalf. With this technology, your staff continues to assist customers as they gather information. At the time of payment capture, the call is diverted to an interactive voice response (IVR) system hosted directly on the payment network. Data is then collected without being seen by the call centre staff. When used together with payment tokenisation service, a payment token is generated and returned to your systems once the payment data is captured.
Tokenisation Equals Reduction in Scope
If you use payment tokenisation with remote secure storage in conjunction with any hosted payment acceptance formats for all of your payment data, you are not capturing, transmitting, storing, or processing payment data with your own systems. Instead of your customers’ payment data, you are using either a masked account number or a returned token for follow up transaction activities and to run your business operations. This changes your systems’ PCI scope, potentially reducing the PCI compliance challenges.
Specifically, the following four PCI DSS requirements may not apply to you:
- 3. Protect stored cardholder data.
- 4. Encrypt transmission of cardholder data across open, public networks.
- 7. Restrict access to cardholder data by business need to know.
- 9. Restrict physical access to cardholder data.
In addition, the following PCI DSS requirements may be reduced in scope:
- 1. Install and maintain a firewall configuration to protect cardholder data.
- 10. Track and monitor all access to network resources and cardholder data.
Level 2, 3, and 4 merchants who do not store, transmit or process cardholder data are eligible to complete the PCI Self Assessment Questionnaire A, which is the shortest of all four questionnaires. It consists of 11 questions easily understood by the general public (compared to Questionnaire D, which consists of 226 questions). Many compliance managers have to enlist the help of a qualified security assessor (QSA) to assist in completing Questionnaire D as the questions are written by and for IT experts. To complete the compliance process, Level 2 and 3 merchants are also required to use an approved scanning vendor for a quarterly network scan.
As for Level 1 merchants, they still have to bring in a QSA or put an internal audit team in place that will attest to compliance, but the scope of the assessment and quarterly scanning/penetration testing would be reduced.
Selecting a Service Provider
Here are a few tips to consider when looking at service providers:
- Assess processor and bank independence. Make sure the remote storage, tokenisation and payment acceptance solutions are compatible with multiple banks and processors for the highest degree of flexibility.
- Verify token format. Ensure the format is compatible with legacy systems, such as a 16-character length token to match former credit card fields.
- Verify hosted payment acceptance technology flexibility. Does the vendor host the payment fields that support multiple sales channels and multiple payment types?
- Confirm the vendor’s experience and financial viability. Get details on the vendor’s experience and financial viability: have they implemented solutions similar to what you require? Is there longevity in the vendor’s contracts with current customers?
By considering theres options, organisations should be able to identify a service provider that suits them, and be a step closer to PCI compliance.
Regulation technology is fast gaining currency by transforming how financial institutions can tackle compliance in a swift, comprehensive and less expensive manner.
The implementation date of Europe's revised Markets in Financial Instruments Directive, aka MiFID II, is fast approaching. Yet evidence suggests that awareness about the impact of Brexit on MiFID II is, at best, only patchy and there are some alarming misconceptions.
Despite all the automation and improvements that digital banking has the potential to achieve, customers and their needs still form the very core of the banking sector.
Politicians have united in urging the Reserve Bank of Australia to lend its backing to the digital currency by officially recognising it.