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!
Glenbrookers are often asked to contribute their thoughts on payment trends. Co-founder Allen Weinberg is no exception. Here’s his take on the latest trends at the point of sale as he shared it with TSYS’ n>genuity journal.
What is happening at the point of sale, and why is it so important?
There are a number of changes going on at the point of sale (POS). The changing landscape includes the introduction of chip, NFC, Apple Pay, cloud-based/Internet-connected terminals and integrated POS systems, point-to-point encryption, in-aisle checkout, and the notion of “merchant app stores.”
Can you step back for a second and give us a sense of where we were in the past and the problems this posed for the ecosystem?
Back in 2004 or so, we operated in what I call a “brittle” POS environment. On one project, we were helping a client pilot the first open-loop contactless payment systems, which was particularly difficult and time-consuming. Contactless readers had to be added to POS terminals, and the terminal software had to be upgraded.
Back then, a huge percentage of the devices out there were proprietary hardware running proprietary software on proprietary operating systems. It was very difficult not only to make the changes, but also simply to download the updates onto the devices. The merchant had to take the terminals offline, manually initiate a download sequence, and pray that it all worked – hardly ideal. We’ve come a long way since.
Surprising disruptions and unanticipated consequences abound in payments.
Sometimes, it’s just a rule change that makes all the difference. In 2001, the NACHA rule enabling ad hoc web debits was put in place, primarily at the behest of banks who wanted to make it easier for their cardholders to pay their credit card bills. Great idea. But once in place, others saw its power, including PayPal who now uses that low cost avenue to fund a significant proportion of its customer transactions.
We’ve seen lots of technology upend entire industries. But in payments new technology usually affirms one set of incumbents while disrupting others. Take Square. At the outset, that combination of a smartphone with a simple magstripe dongle disrupted few. Indeed, Square’s innovation brought in a whole new base of merchants and a growing transaction volume that the payments industry had never seen before. It disrupted nothing except for cash and checks.
But since then—driven by the tablet and tablet-optimized software for the merchant—the incumbent terminal makers, electronic cash register manufacturers, and the sales channels who take these tools to market find themselves in competition with direct sellers like Square as well as a new crop of independent software vendors (ISVs) like Revel Systems, Shopify, Shopkeep, Vend, Breadcrumb, Toast, and dozens of others. The iPad and Android have forever changed what’s possible with an electronic cash register.
That change was in evidence at the Electronic Transaction Association’s TRANSACT conference earlier this month. You could hardly turn around without finding a booth selling EMV capable card readers or bumping into one of those ISVs looking to partner with an ISO to take its software to market.
Apple Pay is another technology that, while hugely improving the NFC experience, affirms the incumbent system’s economics and transaction flow. I doubt that, six months in, that Apple Pay has added much net new transaction volume. The still limited acceptance footprint is largely at fault. But that should change over the next couple of years thanks to Apple’s magisterial orchestration of the payments industry.
Apple Pay has excited financial institutions like no other recent event (how often do banks get to be the cool kids?) at the very same time as the US market is rushing to replace, almost wholesale, its entire point of sale infrastructure to support contact and contactless EMV.
The impact of these changes falls particularly heavily on the merchant services industry, the ISO, and the agents who, for decades, have been the feet-on-the-street for acquirers and processors. ISOs and agents find themselves selling against ISVs delivering more business value than card acceptance. The winners in the sea change are smaller merchants who find that they can get inventory, ecommerce, table management, and more for the cost of payment processing plus a small monthly fee.
Who’s doing what? How is this going to play out? What are the other moving pieces? Those are the questions we’re going to be answering in our upcoming Insight Workshop. Held May 21 in Menlo Park, the New Point of Sale is a deep dive into how payment initiation and acceptance are changing at the POS and what that means for the payments industry.
If you work in the acquiring space and need to get your arms around what’s happening or if you are a merchant trying to get a straight answer about your POS options, the New Point of Sale is for you.
Recorded about a month ago by VC firm Matrix Partners, Glenbrook’s Scott Loftesness and Dana Stalder of Matrix Partners discuss the evolution of mobile payments, the business model failure of Softcard, and other topics including:
The 8+ year journey to ApplePay
Technologies here to stay: NFC, tokenization, and biometrics
Paying invoices and moving funds aross borders for small and medium business (SMB) is expensive and full of uncertainties. How much does the recipient actually get once the transaction is finished? (Hint: it’s not always what was sent.) How long does it take a San Francisco firm to pay an invoice to a contractor in Berlin or Hyderabad? (Hint: it’s hard to know exactly when it gets there).
Since there’s no such thing as an international wire, entrepreneurs in the virtual currency space have been looking at how these new math-based “rails” can move money faster at lower cost across borders. In this Payments on Fire episode, Marwan Forzley, CEO of Align Commerce, talks with Glenbrook’s George Peabody about how his firm moves value for its SMB customers from the sender’s currency to the receiver’s over bitcoin rails.