This is page 2 of:
PCI and Fraud Analysis: To Have and Have Not
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 David.Taylor@KnowPCI.com.
Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code.
-Marc
