Richard McCammon, founder, and Craig Lehtovaara, VP of Product Innovation, sat down with Corevist to help educate B2B decision-makers on PCI compliance and what it means for them, particularly as it relates to B2B payments. The expert panel was asked the following questions:
- What trends do you see in PCI compliance for B2B? Read part 1 of this blog series
- What’s one thing that you wish SAP manufacturers knew about PCI compliance? Read part 2 of this blog series
- Are there any PCI compliance issues which you feel are “hot” in the B2B market that you want to address?
Here’s our insight to question 3.
Are there any PCI compliance issues which you feel are “hot” in the B2B market that you want to address?
The hottest PCI compliance issue in the B2B market may be PCI avoidance! In the B2C world, the idea of simply ceasing to accept credit cards as a form of payment to save on the fees and PCI compliance costs associated with them is generally met with scorn, backlash and much gnashing of teeth amongst consumers. So too does the age-old idea of simply passing along those fees to the consumer as a surcharge, something Visa and Mastercard have been fighting for years. The B2B market, however, can be slightly more receptive to narrowing the tender type field, in that the potential for payment type collusion exists more organically. In a more competitive space for the card brands, with massive revenue streams up for grabs, we see a much greater headwind for credit cards in general, and PCI compliance is a contributing factor. If credit cards are to become a viable component of B2B merchant’s e-commerce strategy, then PCI compliance costs must not preclude credit cards from being competitive with other payment methods. Do Visa and Mastercard worry about Bitcoin? Probably not. Do they want to take market share from ACH, check, and cash? You bet they do. The merchants’ drive to reduce compliance cost has already led to trends like tokenization and P2PE, and we see the hot issues of the coming years all pointing towards:
- Continued adoption of, and legacy process migration to, Payments-as-a-Service through PCI DSS compliant Payment Service Providers (PSP). By leverage Payments-as-a-Service via PCI compliant PSPs, merchants can keep their compliance costs reasonable, enjoy the convenience of credit cards in their B2B eCommerce strategy, and protect their data with world-class security services.
- PCI DSS streamlining for the PSPs to reduce the burden on merchants and place it on firms specializing in information security. We’ve already seen the PCI SSC respond with a variety of different, and streamlined, Self-Assessment Questionnaires (SAQ) that help clarify the responsibilities of controls when merchants leverage a PSP in their e-commerce stores.
- Visa and Mastercard (and the PCI SSC by extension) continuing to evolve the PCI DSS towards providing B2B merchants with a Data Security Standard that provides an appropriate level of data security without pricing credit cards out of the equation.
The PCI Council has built multi-factor authentication into successive versions of the standard. The use of multi-factor authentication will continue to be expanded across more and more of the network as well as the applications that handle cardholder data. Too many breaches of late occurred because a single password was hacked or worse, the default password was not changed. Fundamentally, multi-factor authentication means that a user must present at least two and at most three different types of credentials before access is granted. The three factors can be generalized as “Something I know”, “Something I have” and “Something I am”. User IDs and passwords are examples of “Something I know”. Biometrics such as fingerprints, iris scans, facial recognition, and heartbeats provide unique signatures of the person or “Something I am”. Currently, there are many examples of the “Something I have”. These include a cell phone with an app that generates a unique passcode or receives a passcode by text message or email. Many companies issue fobs that generate passcodes. In all cases, the user must have the equipment to generate a unique identifier which is used in the authentication process. To be true multi-factor authenticated, the process must involve two different types of factors. Using the same factor twice such as a password and a security question does not count as multi-factor. It is really two “Something I know” factors. Although using two of the same factor is more secure than just one, it does not meet the standards of multi-factor. Security is what the PCI standards is all about. Hackers and fraudsters are getting smarter and so, the standards will continue to evolve to make it more difficult to break into the vault. Multi-factor authentication is and will continue to be used to help prevent breaches.
