The PCI Fraud Argument Conundrum

GuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.

Why do retailers, service providers and financial institutions strive to achieve and maintain PCI compliance (assuming they do)? Mostly, they do it because it's mandated by the card brands and their card acquirer. Too often lost in the coercive relationship that drives PCI, however, is the intent of the standards: fraud reduction. A few simple Google searches will confirm that the links between PCI compliance and fraud reduction are largely unexplored and unproven.

  • Connecting Breaches, PCI Compliance And Fraud
    As we've noted previously, being PCI compliant won't stop breaches. It also won't stop fraud. Standards, by their very nature, cannot be adjusted fast enough to incorporate the latest technological advances (by good people or bad people). And their implementation is always imperfect, even if a company manages to score 100 percent on the "PCI test."

    However, if the focus of compliance is shifted to "detection" of a breach or any resulting fraud, the value of PCI controls becomes clearer. Don't think of PCI as building a wall around your credit card or other confidential data. Think of PCI controls as enabling improved fraud and breach analysis.

  • Lots More Security Data For Analysis
    Very few organizations incorporate PCI controls data into their fraud analytics process. Sometimes it's because the fraud analysts have a specific set of tools they use and these tools do not incorporate any awareness of (or data from) PCI controls. Other times it's because the analysis of PCI controls data is too technically focused--whether a specific control is in place and whether it is detecting unauthorized access.

    The missing connection between the data that PCI controls generate and the fraud analytics process may be related to the usability or granularity of the PCI controls data. On the other hand, the connection may be missing because the fraud analytics process is run out of accounting and finance while PCI is being run out of IT or the compliance office. Whether the problem is technical, analytical or organizational, it would be very valuable to get people from all these divisions talking about how to use all the data that PCI controls generate to improve fraud and/or security breach detection.

  • Operationalizing PCI Compliance
    PCI compliance has not been "operationalized" by 95 percent of merchants. As such, even for those who have achieved compliance and (hopefully) are working to maintain it, the business value of PCI compliance is going unrealized. One reason is (and will continue to be) that PCI is too "technology focused" for business managers, accountants or internal auditors to want to own it or use the data its controls generate. This schism creates an opportunity for what we're calling "PCI Analytics," which is a type of tool or service that makes PCI controls data usable by business analysts for the purposes of fraud detection and risk management. Even though PCI requirement 12.1.2 requires a risk analysis, PCI controls themselves typically have little or no impact on any corporate risk analysis. This situation is true despite the fact that a lack of certain PCI controls almost unquestionably increases the material risk of potential security breaches an enterprise faces.

  • The Bottom Line
    We will increasingly focus our 2009 research on developing links between PCI compliance, fraud analytics and risk management because these links are key to demonstrating the business value of PCI compliance beyond avoiding fines and satisfying the demands of acquiring banks. Needless to say, if you have any involvement in, or even just an interest in, proving the business value of PCI compliance, please visit the PCI Knowledge Base. If you'd like to participate in our research, send an E-mail to [email protected]