As merchants work to reduce the scope of PCI compliance and the risk due to having credit card data in their environment, some companies are actually taking access to this data away from people who need it to do their job, including the managers who are charged with investigating fraudulent credit card transactions. Instead of PCI controls helping reduce fraud, for some companies, they are making fraud detection more difficult.
We all know that PCI compliance creates dividing lines. Flat networks must be segmented. The number of databases that store—and applications that use—cardholder data needs to be reduced and the number of persons with full card number access needs to be reduced as well. The whole process of separating the “haves” from the “have nots” often leads to arguments and requires extensive justification on the part of those who maintain they must have the ability to see unencrypted card data in order to do their job.
This seems obvious: Why should marketing have access to full, unencrypted credit card data? Yet it still provokes arguments. Not because of the people or policies, but simply because of the applications and the costs of changing them. Two years ago, we talked to merchants who were able to get away with this, using compensating controls that reduced data volumes, logged each access, and restricted access to batches of transactions, etc.
Today, however, that sort of explanation will not fly with an assessor or processor who reviews an assessment. Although card data is still described by merchants we speak with as being “all over the place,” this is one department that is definitely a “have not.”
Loss Prevention is a more tricky call. Some LP departments are also responsible for E-Commerce LP (i.e., fraud analysis) as well as physical security, so they do have “caseloads” that include verifying specific transactions with banks. This may be a manual process that is the “back end” to the fraud analytics group, which are the folks who use the automated tools.
In other cases, the fraud management organization is completely separate from LP. In such cases, LP can probably get away with having “only” the cardholder name, plus the first 6 and last 4 digits of the card number. This will be sufficient for most purposes, especially when the investigation is manual and they’re talking about a specific case with a bank.The only issue we’ve seen is that some of the banks are, themselves, insisting that they be provided with the full 16 digit number. And that’s the problem: why should banks demand that merchants provide them with a 16 digit number to validate a transaction when they are telling merchants to reduce or eliminate this as part of PCI compliance? For some of the LP managers we’ve spoken with, this is more than a little annoying.
Some solved the problem by successfully arguing that they needed access to full card data. Others, because they wanted to keep LP out of PCI scope, have preferred to work with partially masked data. Both approaches work, but the tradeoff of reduced scope vs. increased case resolution time is a decision for the LP manager, rather than a decision to be made by the PCI project manager, IMHO.
Pretty much every fraud manager or sales audit manager has said they need to have full, unencrypted access to 16 digit card numbers, mainly because the analytical and reconciliation tools they use include credit card white lists and black lists as part of their fraud rules and/or analytical process. Because the tools they use are automated, for the most part, they cannot handle tokens or even encrypted data that results in another 16 digit number.
At least they can't do so without making some changes to their applications and processes. Although it’s clear that this will change over time, for now, both the fraud management and sales audit groups should be included in the “have” group simply because their jobs either become much harder or nearly impossible without it.
Granted, some companies have outsourced card processing yet still accomplish these functions through thin client access that does not allow for downloading data into the corporate environment, but that is still rare. The re-architecting of merchant payment systems continues, and the “in-source / outsource” decision comes up almost daily. This is particularly true for those merchants who are looking at “peer-based” fraud analysis services, since these merchants are already shipping transaction data to third parties for analysis. As processors increasingly embrace fraud analytics as an add-on service, I would expect to see more merchants outsource fraud analysis at the same time (and to the same processor) to which they’re outsourcing their card processing.
The research project from which I’ve draw this analysis is actually just in its beginning stages. We are working with the Merchant Risk Council on this, and we strongly encourage any merchant involved in E-Commerce to contact us and/or the MRC regarding it. We’d really like to talk with you – 100 percent anonymously, of course – and have you visit (and log into) the PCI Knowledge Base so you can search our research database on this topic. If you want to discuss this topic, send an E-mail to [email protected].