We are just a month away from the October EMV liability shift and the transition is, to no one’s surprise, mostly incomplete. EMV credit card issuance is expected to be at just 50% by the end of this year. Point of sale hardware upgrades at major retailers may be in place but the long tail of SMB merchants will lag for years.
We expect many of the largest retailers to turn on their EMV hardware by October. But likely not all. EMV is not trivial. And retailer wisdom, gained through long experience, advises against making POS changes when November nears. You don’t want to break your ability to get paid during the year’s busiest shopping season. (I’m going to be doing a lot of test shopping come October.)
The near-perfect EMV perimeter is six years (wild-eyed optimist) to a decade away (grumpy pessimist), leaving us with exposure at non-EMV terminals and, of course, at e-commerce and mobile channels.
The 3D Secure protocols, one for each network, that connect ecommerce merchants to the cardholder’s issuer, has had a rough go. But after ten years, smarter application of the tool and, in particular, risk-based usage makes it more attractive to both issuers and merchants.
In this conversation with Mike Roche, VP of Consumer Authentication at Cardinal Commerce, we take a deep dive into these protocols, their implementation and continuing evolution, expectations of increased card not present fraud due to EMV’s US arrival, and the positive effect on merchant sales and issuer spend of using this approach.
The Internet’s designers quickly realized that no one’s very good at remembering IP address numbers. Unless you type the same number over and over again (and I did when I ran an ISP) a human readable version is a lot easier. That’s what the domain name system or DNS is all about, connecting human readable names to specific IP addresses.
You can imagine then that Bitcoin, with its long alphanumeric addresses, suffers from similar challenges. That insight is what this podcast is about and the reason Justin Newton and Dawn Newton formed Netki. Try it out by sending bitcoin to me at wallet.geopeabody.bit (kidding) or, better, take a listen as the Netki leaders discuss their directory service for virtual currency wallet addresses.
Every payment pro in the US is also a shopper and we all know that the largest retailers are poised to support EMV. Nearly all have EMV capable hardware. A few have turned it on. Most are waiting for the October liability shift so the temporary pain and awkwardness of clerk and consumer confusion is spread across everyone.
But what about the small and medium business (SMB) market? Mike English, VP of Product Development, at Heartland Payment Systems has a front line view on the EMV transition of its SMB customers. Take a listen as Mike discusses EMV, the future of contactless and the NFC evolution. Mike also discusses how Heartland is thinking about omnichannel payments and commerce, proving that the definition of “payment processor” is morphing far beyond its traditional remit.
Host card emulation (HCE) was invented back in 2012. It was supposed to do for NFC on Android what Apple Pay has done for NFC in the iOS ecosystem. But it’s taken longer, a lot longer, for a robust Android-based NFC capability to get deployed. In this conversation with HCE inventor Doug Yeager, CEO of SimplyTapp, we review how HCE works, what it requires, and take a look at why it’s taken so long to gain momentum. The good news is that momentum is increasing with a growing set of HCE technology providers pushing it forward and, it appears, a pipeline of HCE-based apps on the way.
The domain of point of sale (POS) has three legs to its security stool: EMV, point to point encryption, and card number tokenization. Card not present (CNP) merchants and issuers have the more challenging task of assembling fraud mitigation tools on their own. The networks have had, until EMVCo’s move into payment card tokenization, not much more than 3D Secure to offer. Merchants and card issuers have a lot of transaction and fraud data and when that data gets shared, improvements are possible. That’s what Ethoca is about. Its growing network of merchants and issuers share their fraud data to improve fraud detection and lower chargeback rates. Take a listen to this discussion with Keith Briscoe, Ethoca’s CMO, on what’s possible through collaboration.
Tokenization is, and will continue to be, a hot topic in payments. After all, it’s what powers Apple Pay. Last week I chaired the Mobile Payment Innovation Summit where tokenization was a recurring theme. I asked Glenbrook partner Russ Jones to return for an update, to help us dig deeper into what’s happened over the six months and to consider where tokenization is going. He’s bullish on the capabilities of this technology and likes what he’s seen so far. Take a listen to what Russ has to say.
We all know EMV is coming to the U.S and that it will take years to build a complete EMV security perimeter. But the work starts with issuers sending out chip cards to their customers. Take a listen to this conversation with Chase’s Dina DeMerell, Director, Card Services Chip Security, to hear how Chase is deploying EMV credit, debit, prepaid and co-branded card products. She wasn’t kidding about their accelerated push of credit cards to frequent transactors. I received my new EMV United co-branded card the day after we spoke – and it wasn’t special treatment.
Decisions about point of sale transactions are largely made using card data alone but in e-commerce the merchant has to use a rich mix of data sources to manage fraud. The merchant is, after all, liable for both the transaction as well as the goods or services lost due to fraud. E-commerce merchants use publicly sourced data from firms like Whitepages to perform both automated and manual reviews. This discussion with Tom Donlea, Director, e-Comm/Retail Practice at Whitepages, looks at how the data is provided to the merchant, the challenge of data sourcing in international markets, the care and control of PII, and what the US EMV roll-out could mean for CNP fraud.
This week, I began an important new assignment. I am now the CEO of the International Payments Framework Association (IPFA). If you haven’t yet heard of it, the IPFA provides rules, standards, operating procedures, and guidelines to improve cross-border payments. It’s now five years old and moving into the next, exciting, and supercharged phase of payments along with the rest of the industry.
Composed of banks, clearing and settlement mechanisms, payments service providers and some observer members, the IPFA created a formula for removing some of the friction from cross-border payments. There are two key ingredients to the IPFA formula. The first is an ISO 20022 format that serves as a sort of middleware translation layer to convert into and out of domestic formats. The second ingredient is the set of rules and procedures that guide payment processing.
At Glenbrook we take pride in, and place great importance on, our historical focus on end users: consumers, enterprises and small businesses that make and receive payments.
Recently, we’ve been working with and thinking about billers – the unsung masters of payments complexity. Consider the table below. What other players in the industry accept as many different forms of payment, across so many channels as billers?
We recently performed a Glenbrook biller benchmarking study that confirmed the acute challenges facing billers, ranging from persuading customers to pay electronically, the cost of payment acceptance, to timeliness of processing incoming payments (see chart below).
This week’s CNP Expo in Orlando brought together some 1,000 fraud technology vendors, processors, merchants, commerce-focused entrepreneurs and others to discuss the arrival of EMV in the US, global payments, and more. We took the opportunity to speak with two enterprise focused firms, Nu Data Security and CardConnect. We also spoke with the founder of mobile shopping service SelfPay. Nothing like good conversations!
One of the fun things we do at Glenbrook is help clients think through product concepts in financial services, commerce, and payments. An intriguing area that I’ve been thinking about and watching closely over the years is voice-activated purchasing.
My interest in “voice” stems from my belief that as microprocessors get smaller and faster, the user interface as we know it will fade into the background. The visual display will go away, the tap and swipe interface will go away, and you will simply talk with devices in a conversational way.
I termed this “conversational commerce” several years ago when I was describing how voice-based personal assistants might someday help us make on-the-fly purchases. While there has been steady progress, things are starting to heat up and I’m getting excited about the concept again.
First, all the major technologies providers are now out on the playing field. What was only Apple Siri four years ago, has expanded to a broader lineup of services that include Google Now, Microsoft Cortana, and Amazon Echo. They all have their strengths and weaknesses. No arguing that. Some do a better job than others answering trivia questions. But that’s not the point. I’m interested in which ones are going to help consumers buy things.
Siri has made some progress on the commerce front. Through private integrations with Shazam and Fandango, there is now a clear “buy” vocabulary. Siri can use Shazam to recognize a song, and the “buy” command will take you to that song in the iTunes Store. But you still have to tap to buy, so we’re not quite there yet. Likewise, Siri can help find local movie venues and times, but you still have to tap the “buy” button in Fandango to finalize the ticket purchase. I’m looking forward to the day when “buy” means buy and not help-me-tap-to-purchase.
The flaw in this example is not really specific to Fandango. It’s that after four years, Siri is still a closed service that doesn’t permit third party apps to integrate to a voice command API. And with all due respect to Apple, it’s going to be third parties that are really going to drive conversational commerce.
In this regard, Amazon has made the greatest strides with the release of Amazon Echo into beta and the launch of a third-party SDK for developers. If you are not familiar with Amazon Echo, take a quick look at this video. You’ll get the idea.
Cuteness aside, it’s easy to see why Amazon wants to extends its own voice command assistant into your home. It’s already making headway with Amazon Dash, and now the new Amazon Dash Button, as a way to help customers instantly order common household consummables.
Echo does provide built-in support for card-on-file purchases and setting controls for “1-click” purchasing — effectively what we know as Amazon Payments. It’s somewhat ironic that the one thing missing in 1-click purchasing is the “click’. It’s really 1-command purchasing. So far, this commerce capability is only used to sell music from the Amazon’s digital music store. But I have to believe that Amazon is going to marry Echo and Dash to support voice-activated ordering of products from Amazon.
While that might be interesting for Amazon buyers, what I find more encouraging is the announcement of a beta SDK program for third-party developers. While the SDK is not yet public, the intention to make is public is clear. Just last week there was an IFTTT integration done to support linking Echo with Twitter, Gmail, Evernote, Todoist and Nest. Earlier, there were some private integrations done for several of smart-device manufacturers.
So there is progress. While we’re not quite there yet on conversational commerce, the building blocks are falling into place. I’m very encouraged.
Over the past few weeks I’ve had a chance to talk about the prospects for faster payments in the U.S. with representatives from both The Clearing House and the Fed. Both groups, as I’m sure you know, are actively working the space: the Fed with its ongoing Payments Systems Improvement initiative, now with a number of task forces in formation, and The Clearing House with its intention, announced last October, to “build the rails”.
Frankly, I was pretty skeptical last fall. I was worried that The Clearing House banks would be too concerned about cannibalization of wire transfer revenue to move quickly on the build, and I was disappointed that the Fed had backed away from being the direct provider: the “son of Fedwire” option.
But I’ve changed my mind. It sounds like the board of The Clearing House (the CEO’s of some of the biggest banks in the country) is solidly behind the initiative to build, and eager groups are at work on the design process. The Fed’s task forces are a major, well organized initiative, which may end up with the Fed playing a role in some aspect of faster payments operations, or rules – or may just create some pressure to keep The Clearing House (as well as all of the myriad other players – Fiserv, FIS, PayPal, Dwolla, Square et. al) focused on the goals: what I think of as “faster, better, cheaper” payments. (Btw, “better” includes “more secure.”)
Today I want to express my enthusiasm about these developments, beam encouragement at the industry, and advocate for a few additional points that I think are important in the design phase.
Common Brand– with some 240 million adults and 14,000 or so financial institutions, we need some common terminology so that the phrase “I’ll send you the money by ….” makes sense. This will require individual solution providers to add a common term to their own proprietary brand: “Send money with fastpay (common brand) using your superwallet (proprietary brand)”. Everybody needs to be grown-up about this, and realize that a common term will help the end-users (who, without exception, they claim to care about) more than will insisting on the use of their brand only.
Flexible Directories– these are going to be “push” payments, so the sender of money needs to know the address of the receiving party. No one wants to remember (or even know) their counterparty’s bank account or credit card information, so some form of directory is going to be needed. My point here is that we should bring some sophistication to the design of this component. This is 2015, not 1995, so we aren’t limited to a flat, “dumb” directory mapping account numbers to telephone numbers, for example. We could instead design a distributed directory that encompasses many different potential “alias” form factors – some controlled by a consumer (such as a phone number), others controlled by a biller, etc. The design could be structured to deliberately encompass existing directories at closed-loop solution providers, for example.
Significantly, this should not be a point of commercial control – it should be within the “zone of collaboration” for all solution providers.
And no, this isn’t the same thing as tokenization – although it is frequently confused with it. Issuer tokenization is primarily for “pull” payments, where you want to hide your “real” account number from the pulling party or wallet, so it isn’t compromised or stolen. A directory is for “push” payments, where you want to design an alias that is both easy to remember and safe to use. So similar – and some of the same concepts may be used – but also many differences.
One idea related to directories that I think is very good is the concept of a “pay code” of some sort – an alias that you give people who you want to receive payment from. Not your phone number – after all, you do change that from time to time, and you probably only have one phone number. You could have multiple “pay codes”, for different reasons – all mapping to various accounts. Banks have tried this in the past with the unsuccessful “UPIC” project. Recently, Square introduced something like this with their $CashTag – a good idea, but limited to users of Square Cash. Let’s refresh the thinking on this, and do it right – for all parties using the new system.
My bottom line here? Let’s not do a simple, “dumb” directory. Let’s take advantage of current technologies and build something sleek and simple – and capable of many things.
Bi-Directional (and Optional) Interchange – a similar sophistication is going to be needed around interchange in the new system. After all, like all “payments rails”, this system is going to be used for multiple different applications (P2P, B2B, bill payment, purchases, etc. etc.). Some applications are going to need interchange going from sending bank to receiving bank. Other applications are going to need interchange going from receiving bank to sending bank. Yet others will need no interchange at all. Let’s make sure the design of the system anticipates these complexities.
Ubiquity – finally, as the “user requirements” teams form and debate, let’s keep in mind one simple requirement – ubiquity. Let’s have a system that allows anyone with a bank account to pay anyone else with a bank account – on the same terms, and at the same time. After all checks do it, ACH does it, debit cards do it – surely we want the new thing to be at least as good as the old things? And then, maybe we could think about it allowing payment from anyone with a payment account (not just in a bank!) to transfer money to anyone else with a payment account?
That’s all – just a few things for the teams to think about!