Dennis Moser is Glenbrook’s payments systems expert. He’s worked on building the engines that make payment networks run, especially the critical component of the POS and payment acceptance infrastructure. He’s also been neck deep in payment data management systems, both as a designer and as a data mining practitioner.
Dennis and I have worked together on a few projects for merchants looking to strengthen their security posture and to get ready for EMV while expanding their payments acceptance flexibility. After all, we’re in a new world of payment initiation methods. Given those requirements, we’ve found in our work that the complexity of the payments acceptance and routing challenges for merchants is going up. Increases in complexity often increase costs, too.
Wrapping up a recent project, we landed on the topic of how merchants should be thinking about their payments infrastructure and how, often, its very complexity causes trouble for the merchant. Here’s the gist of our conversation.
George Peabody: Dennis, do you think national and global merchants adequately understand their payment systems? What are they missing most often?
Dennis Moser: Of the many payments issues facing merchants, I would mention two:
First and foremost, security of payments data. There is nothing payments-related that is more damaging to a merchant than a severe security breach. We should talk a bit more about that.
Second, I think that more merchants should work on reporting systems that show the trends of payment cost and operational status over time. Payments should be viewed holistically – all channels and payment types. Cost of payments should include external costs and internal cost. Operational status reporting should provide longer term insight than day-to-day reconciliation activities. When payments are understood in this broader context, merchants are often able to take actions to reduce costs or improve efficiencies that otherwise would go unnoticed. We think that about 40% of US merchants have this type of reporting. I’ve been working on projects in this area and have found that a phased approach can be used to develop meaningful perspective reporting and initial costs for initial implementation can be low.
George: Given PCI, security, EMV, routing issues, payment switching, we’re seeing merchants look at outsourcing more often, in a “make the payment pain go away” move. What’s your view?
Dennis: If we focus on PCI and security,I beleive that many merchants are rethinking – or should be rethinking – how they manage this. There is an emerging capability for vendors to provide end-to-end solutions that relieve merchants of much of the PCI/security hassle. I think these capabilities deserve a close look by many merchants, particularly those that do not have a highly skilled security team. As you know, the project we recently worked on recommended an outsource approach!
George: EMV, and security awareness in general, have both been pushed forward because of the Target breach. Any thoughts on the recent compromises?
Dennis: The Target breach is, I think, a significant milestone. It may be the impetus to give EMV critical momentum. It may cause merchants to rethink their security along the lines we just spoke about – vendor end-to-end solutions that relieve PCI requirements. I wouldn’t go so far as to say that it suggests that merchants, given the business they are in, are simply not suited to deal with the security challenges. But Target is large and sophisticated and it happened to them.
George: We’re hearing a lot about data analytics, Big Data, these days. Payments data is a huge component of that. But it has its limitations. It often comes too late, after the sale, to be helpful to a merchant trying to sell more or better to an individual customer. There are privacy concerns, too. How do you approach the mining of payments data? Where’s it most useful and to who?
Dennis: We should both go to our “Data in Payments” workshop! I say this because, although I have done a ton of work with payments data, it has been pretty narrowly focused: the mining of “minimal” payment data to get value. By minimal, I mean data elements like transaction amount, date of purchase, merchant name, etc. Russ is teaching the workshop and has done a lot of thinking about broader implications and uses of payment data.
There are probably a number of definitions of Big Data. If you were only to look at the quantity of data, examples would be Google clicks, space telescope data downloads, etc.
The transactions flowing through a Visa or MasterCard would have been considered big data years ago, but not any more. But when transaction data is combined with other information such as item detail, or location of customer in store, then we are talking Big Data in the quantity dimension.
There is another dimension to consider: response time. If you are, for example, attempting to do real-time scoring with payments data, the speed of response needed could drive a normally medium data problem into Big Data territory.
One other way to look at data is to ask what kind of technology do you need. If the answer is 1,000 processors and Hadoop, you have a Big Data problem. If the answer is a large relational database system, it’s probably not Big Data.
When you mine payments data, big or otherwise, customer privacy is a key concern. In my own work on payments data mining, great care was taken to remove sensitive information from the analysis. As an example, in loyalty work, customer categories are determined from the detailed data, and customers get assigned to their category. But the individual customer’s data is not in play when the category is used.
This post profiles Glenbrook’s Dennis Moser.
