All posts by Cherian Abraham

Experian conducted a joint-survey that uncovered insights into the topic of conversational commerce and voice assistants. The survey audience constituted nearly 1300 smartphone users of smart voice assistant tools. The survey asked about most requested tasks and general consumer satisfaction with the voice-recognition capabilities of Amazon's Alexa relative to other smart voice assistants such as Siri and Google.

Published: September 14, 2016 by Cherian Abraham

Experian consultant offers his recap from attending a half-day event hosted at The White House called the “FinTech Summit” largely focused on how government agencies can tap into the innovation, in which new firms are offering small-business owners and consumers faster forms of loans and digital payments. Federal regulators have been studying the industry to determine how it can be regulated while still encouraging innovation.

Published: June 15, 2016 by Cherian Abraham

Payments and the Internet of things has been colliding for a while now – and it surfaced again recently with Mastercard announcing that it is working with an array of partners including Capital One to launch payments in connected devices. The thinking here seems to be that payments is a function in the Marlow’s pyramid of needs for any new consumer device. I am conflicted on this point – not that I don’t believe the Internet of Things isn’t important, but that we may be overthinking in how payments is important to be shoved inside everything that has a radio baked in. And not everything will have a radio in the future, and the role of a smartphone as the center of the connected device commerce universe isn’t going away. It is important to keep perspective here – as this announcement is less about coat sleeves hiding NFC chips with tokenized credit cards – rather it’s the commerce enablement of devices that we may carry on our person so that they can be armed for payment. Though I may disagree on whether a coat sleeve or jewelry are essential end-points in commerce, a platform of capabilities to challenge, authenticate and verify, and ultimately trust and provision a tokenized representation of something, whether its a card or a fragment of a consumer\'s identity, to a device that itself represents a collection of radios and sensors is very exciting. It is exciting because as device counts and assortments grow, they each have their own residual identity as a combination of things and behaviors that are either deterministic or probabilistic. The biggest shift we will see is that the collective device identities can be a far better and complete representation of customer identity that the latter will be replaced by the former. Name-centric identities will give away to algorithmically arrived ones. As Dan Geer puts it, no longer will I need to announce that I am Cherian, but my collection of devices will indeed do so on my behalf, perhaps in consultation with each other. More over, none of these devices need to replicate my identity in order to be trusted and tethered, either. Coming back to Payments, today my Fitbit’s claim to make a successful payment is validated way before the transaction, when I authorized provisioning by authenticating through a bank app or wallet. What would be interesting is when the reverse becomes true – when these class of devices that I own can together or separately vouch for my identity. We may forget usernames and passwords, fingerprints may prove to be irrevocable and rigid, but we will always be surrounded by a fog of devices that each carry a cryptographically unique and verifiable signature. And it will be up to the smartphone, its ecosystem and the devices that operate in its periphery to individually negotiate and establish trust among each of them. So this is why I believe the MasterCard effort in tokenizing devices is important when you view it in conjunction with the recent launch of SwiftID from CapitalOne. Payments getting shoved in to everyday things like wearables, disguises the more important effort of becoming a beachhead in establishing trust between devices, by using tokenization as the method of delivery. As you may have gathered by now, I am less excited of pushing cards in to devices (least of all – cars!) and more about how a trusted framework to carve out a tamper proof and secure cache within an untrusted device, along with the process to securely provision a token or a signed hash representing something of value, can serve as the foundation for future device – and by extension – user identity. On a side note, here’s a bit about pushing cards in to cars, and mistaking them for connected cars. To me there are only two connected car classes today. One is Tesla where each car on the road is part of the whole, each learning separately and together as they examine, encounter and learn the world around them to maneuver safely. The other is a button in an app that I hit to have a car magically appear in front of me. Other than Tesla and Uber, there are no other commercial instances of a connected car that appeals (Google has no cars you can buy, yet).

Published: December 21, 2015 by Cherian Abraham

Commerce: A conversation between merchants and consumers Last week I joined Sherri Haymond of MasterCard and Bharathi Ramavarjula of Facebook on a panel moderated by Paul Moreton, for a CapitalOne summit on Payments. When asked what was more important for the future of commerce – Sherri spoke of how security and trust is key, and I talked about how messaging has intersected with payments, (and in Wechat’s case) now intersecting with lending – with Bharathi eloquently summing it up as – “Facebook sees Commerce as a conversation”. If Commerce is a conversation between a merchant and a consumer (however loosely defined those terms have now come to be), then it has become contorted and clustered around payments and point of sale. Till not too long ago, there also existed a high barrier for entry to become a merchant, to accept payments, to promote and sell online, and to find cheap capital for growth. All these things are different now – and unsurprisingly, little of this progress can be attributed to banks or other current payment stakeholders. For example: I didn’t know I could be a merchant till Square showed me how easy it is to accept credit cards, and setup a small business. I didn’t know that I could become a driver in my spare time – till Uber showed me how easy it is to become one. I didn’t know that I could become a landlord till AirBnB showed me how easy it is to find people to rent it to. I know I am oversimplifying. These three and others like them chose to use technology and smartphones to exponentially scale the size of existing two-sided markets as well as create new ones. When another billion people on the planet stand to be connected over the next five years – entirely via cheap smartphones – it is hard to view commerce as a zero sum opportunity. Being wired for commerce may come to mean something entirely different for those billion, and messaging apps and social networks will replace point of sale for discovery, acquisition and engagement. This is why I believe changes in payments today are largely incremental and localized to the developed world. The platform driven efforts – such as tokenization – do go beyond any specific modality (card, mobile, connected things) to further the notion and benefit of trust entirely within the network. But that is as far as it goes. Issuers and networks may have little role to play in discovery, consumer loyalty and now more so than ever – identity. Case in point: Through Relay, Stripe enables a retailer to push a button and start selling through new channels while taking comfort in that his pricing and inventory will remain real-time. Through Messenger and Shopping – Facebook will encapsulate product discovery, guide the intent to purchase, host the informed pre-purchase debate and even payment – flattening it and never letting it out of sight. It is no accident that each of the four horsemen of the Internet has heavily invested in voice assistants – (Apple/Siri, Google/Now, Facebook/M, Amazon/Echo, Microsoft/Cortana) – especially as we confront old habits in interaction design that are failing on mobile, to continue to shorten the distance between intent and action through things like 3D Touch, the Amazon Dash button, and intelligent agents. Everything that is interesting in commerce: product discovery, search, interface and interaction design are all being done – with the sole exception of Amazon – by an entity that is neither a retailer nor a bank. Conversational commerce does not end with payments being swallowed up by messaging apps. It is a pre-requisite, but hardly not even a way point in that journey. Originally posted on: Droplabs.co

Published: October 14, 2015 by Cherian Abraham

Apple eschewed banks for a retailer focus onstage at their Worldwide Developers Conference (WWDC) when it spoke to payments. I sense this is an intentional shift – now that stateside, you have support from all four networks and all the major issuers – Apple understands that it needs to shift the focus on signing up more merchants, and everything we heard drove home that note. That includes Square’s support for NFC, as well as the announcements around Kohls, JCPenney and BJ’s. MasterCard\'s Digital Enablement Service (MDES) - opposite Visa’s Token Service - is the tokenization service that has enabled these partnerships specifically through MasterCard’s partners such as Synchrony – (former GE Capital) which brought on JCPenney, Alliance Data which brought on BJ’s, and CapitalOne which enabled Kohls. Within payments common sense questions such as: “Why isn’t NFC just another radio that transmits payment info?” or “Why aren’t retailer friendly payment choices using NFC?” have been met with contemptuous stares. As I have written umpteen times (here), payments has been a source of misalignment between merchants and banks. Thus – conversations that hinged on NFC have been a non-starter, for a merchant that views it as more than a radio – and instead, as a trojan horse for Visa/MA bearing higher costs. When Android opened up access to NFC through Host Card Emulation (HCE) and networks supported it through tokenization, merchants had a legitimate pathway to getting Private label cards on NFC. So far, very few indeed have done that (Tim Hortons is the best example). But between the top two department store chains (Macy’s and Kohls) – we have a thawing of said position, to begin to view technologies pragmatically and without morbid fear. It must be said that Google is clearly chasing Apple on the retailer front, and Apple is doing all that it can, to dig a wider moat by emphasizing privacy and transparency in its cause. It is proving to be quite effective, and Google will have to “apologize beforehand” prior to any merchant agreement – especially now that retailers have control over which wallets they want to work with – and how. This control inherits from the structures set alongside the Visa and MasterCard tokenization agreements – and retailers with co-brand/private label cards can lean on them through their bank partners. Thus, Google has to focus on two fronts – first to incentivize merchants to partner so that they bring their cards to Android Pay, while trying to navigate through the turbulence Apple has left in its wake, untangling the “customer privacy” knot. For merchants, at the end of the day, the questions that remain are about operating costs, and control. Does participation in MDES and VEDP tokenization services through bank partners, infer a higher cost for play – for private label cards? I doubt if Apple’s 15bps “skim off the top” revenue play translates to Private Label, especially when Apple’s fee is tied to “Fraud Protection” and Fraud in Private Label is non-existent due to its closed loop nature. Still – there could be an acquisitions cost, or Apple may plan a long game. Further, when you look at token issuance and lifecycle management costs, they aren’t trivial when you take in to context the size of portfolio for some of these merchants. That said, Kohls participation affords some clarity to all. Second, Merchants want to bring payments inside apps – just like they are able to do so through in-app payments in mobile, or on online. Forcing consumers through a Wallet app – is counter to that intent, and undesirable in the long scheme. Loyalty as a construct is tangled up in payments today – and merchants who have achieved a clean separation (very few) or can afford to avoid it (those with large Private label portfolios that are really ‘loyalty programs w/ payments tacked on’) – benefit for now. But soon, they will need to fold in the payment interaction in to their app, or Apple must streamline the clunky swap. The auto-prompt of rewards cards in Wallet is a good step, but that feels more like jerry rigging vs the correct approach. Wallet still feels very v1.5 from a merchant integration point of view. Wallet not Passbook. Finally, Apple branding Passbook to Wallet is a subtle and yet important step. A “bank wallet” or a “Credit Union wallet” is a misnomer. No one bank can hope to build a wallet – because my payment choices aren’t confined to a single bank. And even where banks have promoted “open wallets” and incentivized peers to participate – response has been crickets at best. On the flip side, an ecosystem player that touches more than a device, a handful of experiential services in entertainment and commerce, a million and a half apps – all with an underpinning of identity, can call itself a true wallet – because they are solving for the complete definition of that term vs pieces of what constitutes it. Thus – Google & Apple. So the re-branding while being inevitable, finds a firm footing in payments, looks toward loyalty and what lies beyond. Solving for those challenges has less to do with getting there first, but putting the right pieces in play. And Apple’s emphasis (or posturing – depending on who you listen to) on privacy has its roots in what Apple wants to become, and access, and store on our behalf. Being the custodian of a bank issued identity is one thing. Being a responsible custodian for consumer’s digital health, behavior and identity trifecta has never been entirely attempted. It requires pushing on all fronts, and a careful articulation of Apple’s purpose to the public must be preceded by the conviction found in such emphasis/posturing. Make sure to read our perspective paper to see why emerging channels call for advanced fraud identification techniques

Published: June 9, 2015 by Cherian Abraham

“Building a better mousetrap merely results in smarter mice” – Charles Darwin Credit card issuers in general have a good handle on fraud. They manage it under 10bps (i.e. losses of $0.10 or less per $100 of transactions) on transactions made with a \"dumb\" plastic card lacking any additional context. So Issuers wishing for Apple Pay fraud to fall between 2-3bps was not totally out of character, considering the protections in place by Apple and Networks to keep fraud away – including issuer support during provisioning, NFC, Tokenization, a tamper proof Secure Element and TouchID. But fraud seems to have followed a different trajectory here. About a month post-launch, it seems like fraud has come to Apple Pay. (in one case – as high as 600bps for an issuer that I cannot name). Though what follows was written in the context of Apple Pay, much of it translates to any other competitor – irrespective of origin, scale, intent, or patron saint. Apple Pay and the Yellow Path: All Apple Pay participating card issuers are required to build a “Yellow Path” for when card provisioning in to Apple Pay requires additional bank verification. Implementation of the “Yellow Path” and corresponding customer experience has varied per Card Issuer. Today, depending on your card issuer – you could expect much variance – such as being directed to their call center, being asked to authenticate via the bank’s mobile app, or an entirely other 2FA verification. As one can expect – each has varying levels of success and friction – with just a couple of banks opting to authenticate via their mobile apps, that would have provided a far easier and customer friendly provisioning experience. Where as, those that opted for call center verification traded efficiency for friction and by most reports – the corresponding experience has been subpar. In fact initially “Yellow Path” was marked optional for card issuers by Apple – which meant that only a couple of Issuers directed much focus at it. Apple reversed its decision and made it mandatory less than a month before launch – which led to issuers scrambling to build and provide this support. Why any bank would consider this optional is beyond me. Either way, Card issuer implementations of the Apple Pay Yellow Path have proved to be inadequate – as I am willing to bet that most of the fraud in Apple Pay came by stolen identities. For all the paranoia around elevating your phone to be the container for all your credit cards – fraud in Apple Pay has assumed more traditional and unsophisticated ways. No, iPhones weren’t stolen and then used for unauthorized purchases, TouchID was not compromised, Credentials weren’t ripped out of Apple’s tamper proof secure element – nor the much feared but rarely attempted MITM attacks(capture and relay an NFC transmission at a different terminal). Instead fraudsters bought stolen consumer identities complete with credit card information, and convinced both software and manual checks that they were indeed a legitimate customer. Fraud on Apple Pay is somewhat unique – as the Pay setup is one of the first things one would do upon getting their iPhone 6. At which point – the device will have little to no background or context with the bank. Further, the customer most likely haven’t had the time to install the bank app or login. It is no wonder then that a number of banks defaulted to “Call our call center” as the default Yellow path. In an earlier post on ISIS (Softcard) I did write how the vast retail network coupled with visibility in to customer identity positioned Carriers as a trusted partner for banks to do secure provisioning. But ISIS had other (yet unrealized) aspirations. For all the focus in protecting transactions and plastic – for e.g. via EMV and Tokenization – issuance and provisioning remains the soft underbelly – under protected and easily compromised. And this should concern all – because the strongest chain is only as good as its weakest link – and those with malice are almost always the first to find it. Fraud in Apple Pay will in time, come to be managed – but the fact that easily available PII can waylay best in class protection should give us all pause. Make sure to download our fraud prevention whitepaper to gain more insight on how you can prepare your business. This post originally appeared here. 

Published: January 9, 2015 by Cherian Abraham

Through all the rather “invented conflict” of MCX vs Apple Pay by the tech media these last few weeks – very little diligence was done on why merchants have come to reject NFC (near field communication) as the standard of choice. Maybe I can provide some color here – both as to why traditionally merchants have viewed this channel with suspicion leading up to CurrenC choosing QR, and why I believe its time for merchants to give up hating on a radio. Why do merchants hate NFC? Traditionally, any contactless usage in stores stems from international travelers, fragmented mobile NFC rollouts and a cornucopia of failed products using a variety of form factors – all of which effectively was a contactless chip card with some plastic around it. Any merchant supported tended to be in the QSR space – biggest of which was McDonalds - and they saw little to no volume to justify the upgrade costs. Magstripe, on the other hand, was a form factor that was more accessible. It was cheap to manufacture, provisioning was a snap, distribution depended primarily on USPS. Retailers used the form factor themselves for Gift cards, Pre-paid and Private Label. In contrast – complexity varies in contactless for all three – production, provisioning and distribution. If it’s a contactless card – all three can still follow pretty much the norm – as they require no customization or changes post-production. Mobile NFC was an entirely different beast. Depending on the litany of stakeholders in the value chain – from Hardware – OEM and Chipset support – NFC Controller to the Secure Element, the OS Support for the NFC stack, the Services – Trusted Service Managers of each flavor (SE vs SP), the Carriers (in case of OTA provisioning) and the list goes on. The NFC Ecosystem truly deters new entrants by its complexity and costs. Next – there was much ambiguity to what NFC/contactless could come to represent at the point of sale. Merchants delineated an open standard that could ferry over any type of credential – both credit and debit. Even though merchants prefer debit, the true price of a debit transaction varies depending on which set of rails carry the transaction – PIN Debit vs Signature Debit. And the lack of any PIN Debit networks around the contactless paradigm made the merchants fears real – that all debit transactions through NFC will be carried over the more costly signature debit route (favoring V/MA) and that a shift from magstripe to contactless would mean the end to another cost advantage the merchants had to steer transactions towards cheaper rails. The 13 or so PIN debit networks are missing from Apple Pay – and it’s an absence that weighed heavily in the merchants decision to be suspicious of it. Maybe even more important for the merchant – since it has little to do with payment – loyalty was a component that was inadequately addressed via NFC. NFC was effective as a secure communications channel – but was wholly inadequate when it came to transferring loyalty credentials, coupons and other things that justify why merchants would invest in a new technology in the first place. The contactless standards to move non-payment information, centered around ISO 18092 – and had fragmented acceptance in the retail space, and still struggled from a rather constricted pipe. NFC was simply useful as a payments standard and when it came to loyalty – the “invented a decade ago” standard is wholly inadequate to do anything meaningful at the point of sale. If the merchant must wrestle with new ways to do loyalty – then should they go back in time to enable payments, or should they jerry rig payments to be wrapped in to loyalty? What looks better to a merchant? Sending a loyalty token along with the payment credential (via ISO 18092) OR Encapsulating a payment token (as a QR Code) inside the Starbucks Loyalty App? I would guess – the latter. Even more so because in the scenario of accepting a loyalty token alongside an NFC payment – you are trusting the payment enabler (Apple, Google, Networks, Banks) with your loyalty token. Why would you? The reverse makes sense for a merchant. Finally – traditional NFC payments – (before Host Card Emulation in Android) – apart from being needlessly complex – mandated that all communication between the NFC capable device and the point-of-sale terminal be limited to the Secure Element that hosts the credential and the payment applets. Which means if you did not pay your way in to the Secure Element (mostly only due to if you are an issuer) then you have no play. What’s a merchant to do? So if you are a merchant – you are starting off with a disadvantage – as those terminologies and relationships are alien to you. Merchants did not own the credential – unless it was prepaid or private label – and even then, the economics wouldn’t make sense to put those in a Secure Element. Further, Merchants had no control in the issuer’s choice of credential in the Secure Element – which tended to be mostly credit. It was then no surprise that merchants largely avoided this channel – and then gradually started to look at it with suspicion around the same time banks and networks began to pre-ordain NFC as the next stage in payment acceptance evolution. Retailers who by then had been legally embroiled in a number of skirmishes on the interchange front – saw this move as the next land grab. If merchants could not cost effectively compete in this new channel – then credit was most likely to become the most prevalent payment option within. This suspicion was further reinforced with the launch of GoogleWallet, ISIS and now Apple Pay. Each of these wrapped existing rails, maintained status quo and allowed issuers and networks to bridge the gap from plastic to a new modality (smartphones) while changing little else. This is no mere paranoia. The merchants fear that issuers and networks will ultimately use the security and convenience proffered through this channel as an excuse to raise rates again. Or squeeze out the cheaper alternatives – as they did with defaulting to Signature Debit over PIN debit for contactless. As consumers learn a new behavior (tap and pay) they fear that magstripe will eclipse and a high cost alternative will then take root. How is it fair that to access their customer’s funds – our money – one has to go through toll gates that are incentivized to charge higher prices? The fact that there are little to no alternatives between using Cash or using a bank issued instrument to pay for things – should worry us as consumers. As long as merchants are complacent about the costs in place for them to access our money – there won’t be much of an incentive for banks to find quicker and cheaper ways to move money – in and out of the system as a whole. I digress. So the costs and complexities that I pointed to before, that existed in the NFC payments ecosystem – served to not only keep retailers out, but also impacted issuers ability to scale NFC payments. These costs materialized in to higher interchange cards for the issuer when these initiatives took flight – partly because the issuer was losing money already, and had then little interest to enable debit as a payments choice. GoogleWallet itself had to resort to a bit of “negative margin strategy” to allow debit cards to be used within. ISIS had little to no clout, nor any interest to push issuers to pick debit. All of which must have been quite vexing for an observant merchant. Furthermore, just as digital and mobile offers newer ways to interact with consumers – they also portend a new reality – that new ecosystems are taking shape across that landscape. And these ecosystems are hardly open – Facebook, Twitter, Google, Apple – and they have their own toll gates as well. Finally – A retail payment friend told me recently that merchants view the plethora of software, systems and services that encapsulate cross-channel commerce as a form of “Retailer OS”. And if Payment acceptance devices are end-points in to that closed ecosystem of systems and software – they are rightfully hesitant in handing over those keys to the networks and banks. The last thing they want to do is let someone else control those toll-gates. And it makes sense and ironically – it has parallel in the iOS ecosystem. Apple’s MFi program is an example of an ecosystem owner choosing to secure those end-points – especially when those are manufactured by a third party. This is why Apple exacts a toll and mandates that third party iOS accessory manufacturers must include an Apple IC to securely connect and communicate with an iOS device. If Apple can mandate that, then why is it that a retailer should have no say over the end-points through which payments occur in it’s own retail ecosystem? Too late to write about how the retailer view of NFC must evolve – in the face of an open standard, aided by Host Card Emulation – but that’s gotta be another post. Another time. See you all in Vegas. Make sure to join the Experian #MobilePayChat on Twitter this Tuesday at 12:15 p.m. PT during Money2020 conference: http://ex.pn/Money2020. If you are attending the event please stop by our booth #218. This post originally appeared here. 

Published: November 3, 2014 by Cherian Abraham

If rumors hold true, Apple Pay will launch in a week. Five of my last six posts had covered Apple’s likely and actual strategy in payments & commerce, and the rich tapestry of control, convenience, user experience, security and applied cryptography that constitutes as the backdrop. What follows is a summation of my views – with a couple of observations from having seen the Apple Pay payment experience up close. About three years ago – I published a similar commentary on Google Wallet that for kicks, you can find here. I hope what follows is a balanced perspective, as I try to cut through some FUD, provide some commentary on the payment experience, and offer up some predictions that are worth the price you pay to read my blog. Source: Bloomua / Shutterstock.com First the criticism. Apple Pay doesn’t go far enough: Fair. But you seem to misunderstand Apple’s intentions here. Apple did not set out to make a mobile wallet. Apple Pay sits within Passbook – which in itself is a wrapper of rewards and loyalty cards issued by third parties. Similarly – Apple Pay is a wrapper of payments cards issued by third parties. Even the branding disappears once you provision your cards – when you are at the point-of-sale and your iPhone6 is in proximity to the reader (or enters the magnetic field created by the reader) – the screen turns on and your default payment card is displayed. One does not need to launch an app or fiddle around with Apple Pay. And for that matter, it’s even more limited than you think. Apple’s choice to leave the Passbook driven Apple Pay experience as threadbare as possible seems an intentional choice to force consumers to interact more with their bank apps vs Passbook for all and any rich interaction. Infact the transaction detail displayed on the back of the payment card you use is limited – but you can launch the bank app to view and do a lot more. Similarly – the bank app can prompt a transaction alert that the consumer can select to view more detail as well. Counter to what has been publicized – Apple can – if they choose to – view transaction detail including consumer info, but only retains anonymized info on their servers. The contrast is apparent with Google – where (during early Google Wallet days) issuers dangled the same anonymized transaction info to appease Google – in return for participation in the wallet. If your tap don’t work – will you blame Apple? Some claim that any transaction failures – such as a non-working reader – will cause consumers to blame Apple. This does not hold water simply because – Apple does not get in between the consumer, his chosen card and the merchant during payment. It provides the framework to trigger and communicate a payment credential – and then quietly gets out of the way. This is where Google stumbled – by wanting to become the perennial fly on the wall. And so if for whatever reason the transaction fails, the consumer sees no Apple branding for them to direct their blame. (I draw a contrast later on below with Samsung and LoopPay) Apple Pay is not secure: Laughable and pure FUD. This article references an UBS note talking how Apple Pay is insecure compared to – a pure cloud based solution such as the yet-to-be-launched MCX. This is due to a total misunderstanding of not just Apple Pay – but the hardware/software platform it sits within (and I am not just talking about the benefits of a TouchID, Network Tokenization, Issuer Cryptogram, Secure Element based approach) including, the full weight of security measures that has been baked in to iOS and the underlying hardware that comes together to offer the best container for payments. And against all that backdrop of applied cryptography, Apple still sought to overlay its payments approach over an existing framework. So that, when it comes to risk – it leans away from the consumer and towards a bank that understands how to manage risk. That’s the biggest disparity between these two approaches – Apple Pay and MCX – that, Apple built a secure wrapper around an existing payments hierarchy and the latter seeks to disrupt that status quo. Let the games begin: Consumers should get ready for an ad blitz from each of the launch partners of Apple Pay over the next few weeks. I expect we will also see these efforts concentrated around pockets of activation – because setting up Apple Pay is the next step to entering your Apple ID during activation. And for that reason – each of those launch partners understand the importance of reminding consumers why their card should be top of mind. There is also a subtle but important difference between top of wallet card (or default card) for payment in Apple Pay and it’s predecessors (Google Wallet for example). Changing your default card was an easy task – and wholly encapsulated – within the Google Wallet app. Where as in Apple Pay – changing your default card – is buried under Settings, and I doubt once you choose your default card – you are more likely to not bother with it. And here’s how quick the payment interaction is within Apple Pay (takes under 3 seconds) :- Bring your phone in to proximity of the reader. Screen turns on. Passbook is triggered and your default card is displayed. You place your finger and authenticate using TouchID. A beep notes the transaction is completed. You can flip the card to view a limited transaction detail. Yes – you could swipe down and choose another card to pay. But unlikely. I remember how LevelUp used very much the same strategy to signup banks – stating that over 90% of it’s customers never change their default card inside LevelUp. This will be a blatant land grab over the next few months – as tens of millions of new iPhones are activated. According to what Apple has told it’s launch partners – they do expect over 95% of activations to add at least one card. What does this mean to banks who won’t be ready in 2014 or haven’t yet signed up? As I said before – there will be a long tail of reduced utility – as we get in to community banks and credit unions. The risk is amplified because Apple Pay is the only way to enable payments in iOS that uses Apple’s secure infrastructure – and using NFC. For those still debating whether it was a shotgun wedding, Apple’s approach had five main highlights that appealed to a Bank – Utilizing an approach that was bank friendly (and to status quo) : NFC Securing the transaction beyond the prerequisites of EMV contactless – via network tokenization & TouchID Apple’s preference to stay entirely as an enabler – facilitating a secure container infrastructure to host bank issued credentials. Compressing the stack: further shortening the payment authorization required of the consumer by removing the need for PIN entry, and not introducing any new parties in to the transaction flow that could have introduced delays, costs or complexity in the roundtrip. Clear description of costs to participate – Free is ambiguous. Free leads to much angst as to what the true cost of participation really is(Remember Google Wallet?). Banks prefer clarity here – even if it means 15bps in credit. As I wrote above, Apple opting to strictly coloring inside the lines – forces the banks to shoulder much of the responsibility in dealing with the ‘before’ and ‘after’ of payment. Most of the bank partners will be updating or activating parts of their mobile app to start interacting with Passbook/Apple Pay. Much of that interaction will use existing hooks in to Passbook – and provide richer transaction detail and context within the app. This is an area of differentiation for the future – because those banks who lack the investment, talent and commitment to build a redeeming mobile services approach will struggle to differentiate on retail footprint alone. And as smarter banks build entirely digital products for an entirely digital audience – the generic approaches will struggle and I expect at some point – that this will drive bank consolidation at the low end. On the other hand – if you are an issuer, the ‘before’ and ‘after’ of payments that you are able to control and the richer story you are able to weave, along with offline incentives – can aid in recapture. The conspicuous and continued absence of Google: So whither Android? Uniformity in payments for Android is as fragmented as the ecosystem itself. Android must now look at Apple for lessons in consistency. For example, how Apple uses the same payment credential that is stored in the Secure Element for both in-person retail transactions as well as in-app payments. It may look trivial – but when you consider that Apple came dangerously close (and justified as well) in its attempt to obtain parity between those two payment scenarios from a rate economics point of view from issuers – Android flailing around without a coherent strategy is inexcusable. I will say this again: Google Wallet requires a reboot. And word from within Google is that a reboot may not imply a singular or even a cohesive approach. Google needs to swallow its pride and look to converge the Android payments and commerce experience across channels similar to iOS. Any delay or inaction risks a growing apathy from merchants who must decide what platform is worth building or focusing for. Risk vs Reward is already skewed in favor of iOS: Even if Apple was not convincing enough in its attempt to ask for Card Present rates for its in-app transactions – it may have managed to shift liability to the issuer similar to 3DS and VBV – that in itself poses an imbalance in favor of iOS. For a retail app in iOS – there is now an incentive to utilize Apple Pay and iOS instead of all the other competing payment providers (Paypal for example, or Google Wallet) because transactional risk shifts to the issuer if my consumer authenticates via TouchID and uses a card stored in Apple Pay. I have now both an incentive to prefer iOS over Android as well as an opportunity to compress my funnel – much of my imperative to collect data during the purchase was an attempt to quantify for fraud risk – and the need for that goes out of the window if the customer chooses Apple Pay. This is huge and the repercussions go beyond Android – in to CNP fraud, CRM and loyalty. Networks, Tokens and new end-points (e.g. LoopPay): The absence of uniformity in Android has provided a window of opportunity for others – regardless of how fragmented these approaches be. Networks shall parlay the success with tokenization in Apple Pay in to Android as well, soon. Prime example being: Loop Pay. If as rumors go – Samsung goes through with baking in Loop Pay in to its flagship S6, and Visa’s investment translates in to Loop using Visa tokenization – Loop may find the ubiquity it is looking for – on both ends. I don’t necessarily see the value accrued to Samsung for launching a risky play here: specifically because of the impact of putting Loop’s circuitry within S6. Any transaction failure in this case – will be attributed to Samsung, not to Loop, or the merchant, or the bank. That’s a risky move – and I hope – a well thought out one. I have some thoughts on how the Visa tokenization approach may solve for some of the challenges that Loop Pay face on merchant EMV terminals – and I will share those later. The return of the comeback: Reliance on networks for tokenization does allay some of the challenges faced by payment wrappers like Loop, Coin etc – but they all focus on the last mile and tokenization does little more for them than kicking the can down the road and delaying the inevitable a little while more. The ones that benefit most are the networks themselves – who now has wide acceptance of their tokenization service – with themselves firmly entrenched in the middle. Even though the EMVCo tokenization standard made no assumptions regarding the role of a Token Service Provider – and in fact Issuers or 3rd parties could each pay the role sufficiently well – networks have left no room for ambiguity here. With their role as a TSP – networks have more to gain from legitimizing more end points than ever before – because these translate to more token traffic and subsequently incremental revenue – transactional and additional managed services costs (OBO – On behalf of service costs incurred by a card issuer or wallet provider). It has never been a better time to be a network. I must say – a whiplash effect for all of us – who called for their demise with the Chase-VisaNet deal. So my predictions for Apple Pay a week before its launch: We will see a substantial take-up and provisioning of cards in to Passbook over the next year. Easy in-app purchases will act as the carrot for consumers. Apple Pay will be a quick affair at the point-of-sale: When I tried it few weeks ago – it took all of 3 seconds. A comparable swipe with a PIN (which is what Apple Pay equates to) took up to 10. A dip with an EMV card took 23 seconds on a good day. I am sure this is not the last time we will be measuring things. The substantial take-up on in-app transactions will drive signups: Consumers will signup because Apple’s array of in-app partners will include the likes of Delta – and any airline that shortens the whole ticket buying experience to a simple TouchID authentication has my money. Apple Pay will cause MCX to fragment: Even though I expect the initial take up to be driven more on the in-app side vs in-store, as more merchants switch to Apple Pay for in-app, consumers will expect a consistency in that approach across those merchants. We will see some high profile desertions – driven partly due to the fact that MCX asks for absolute fealty from its constituents, and in a rapidly changing and converging commerce landscape – that’s just a tall ask. In the near-term, Android will stumble: Question is if Google can reclaim and steady its own strategy. Or will it spin off another costly experiment in chasing commerce and payments. The former will require it to be pragmatic and bring ecosystem capabilities up to par – and that’s a tall ask when you lack the capacity for vertical integration that Apple has. And from the looks of it – Samsung is all over the place at the moment. Again – not confidence inducing. ISIS/SoftCard will get squeezed out of breath: SoftCard and GSMA can’t help but insert themselves in to the Apple Pay narrative by hoping that the existence of a second NFC controller on the iPhone6 validates/favors their SIM based Secure Element approach and indirectly offers Softcard/GSMA constituents a pathway to Apple Pay. If that didn’t make a lick of sense – It’s like saying ‘I’m happy about my neighbor’s Tesla because he plugs it in to my electric socket’. Discover how an Experian business consultant can help you strengthen your credit and risk management strategies and processes: http://ex.pn/DA_GCP This post originally appeared here.

Published: October 21, 2014 by Cherian Abraham

Apple held its annual developers conference last week to showcase its new features within iOS8. One area that still needs clarification is Apple’s intent for mobile payments. Cherian Abraham, Experian Decision Analytics mobile payments analyst, shares what he thinks Apple might look to do in the mobile payment space going forward. In my first post, I touched upon Apple’s program for third party hardware attachment market as being significant and likely to be a key aspect of its payments approach. In this post I discuss these three things: 1. How Apple’s new security paves the way for mobile payments 2. Bluetooth being secured enough where Payments is a use-case 3. Why the iPhone 6 will not have NFC Last week, 9to5mac reported that Apple has introduced a new specification for manufacturers in its MFi program (Made for iPad, iPhone and iPod) that allows them to create headphones that connect to iOS devices using a lightning connector instead of relying on the 3.5mm audio jack. Why is it important? Because as Apple looks to rid itself of any such remaining legacy vestiges, it’s also shedding any ambiguity around who is in control of the iOS hardware ecosystem and what it means to be a third party accessory maker – once reliant on open standards supported by all devices and now serving at Apple’s pleasure. It is a strategy that fits against the backdrop of an iOS ecosystem that is made up of software that is increasingly becoming more open, and hardware that is slowly being walled off – primarily in the name of security. The former is evident in how Apple has opened up third-party access to core authentication services like TouchID. What about the latter? Apple’s new security blanket Well, first let’s look at what Apple has publicly acknowledged about the MFi program. Every iOS device will initiate communication with a third-party accessory by asking it to prove sufficient authorization by Apple — to respond with an Apple-provided certificate, which iOS subsequently verifies. Further, the iOS device then issues a challenge, which is then answered by the third-party accessory by a signed response. These two steps require that a third-party accessory must have: • An Apple certificate • Requisite cryptographic capabilities — preferably in hardware to comply. That is precisely what Apple does by encapsulating all this in an Integrated Circuit that it controls – where the entire handshake is transparent to the accessory. With this – Apple’s role in the third-party accessory market becomes non-negotiable. You think you have a cool accessory that requires a trusted connection and intends to share data with an iOS device? Unless you inherit Apple’s controls you are relegated to speaking analog and conducting a limited set of user-driven operations — Start, Pause, Rewind (standard Serial UART audio playback controls) — usable only to headphones using the audio jack. Now, how about them apples? It’s important to note that these steps to validate whether an accessory is authorized to communicate with an iOS device can happen over the lightning connector, Bluetooth or WiFi. The advantage here is that this repels man-in-the-middle attacks because a malicious interceptor will not have the Apple IC to pass authorization, and subsequently will not have the negotiated key that encrypts all subsequent communication. The whole key negotiation occurs over Bluetooth. It is important because this approach can solve man-in-the-middle attacks for Bluetooth in scenarios including payments. A cynical view of the MFi program would be to consider it a toll that Apple is eager to extract from the third-party accessory makers building accessories authorized to communicate with an iOS device. A more pragmatic view would be to recognize Apple’s efforts as an ecosystem owner, whose primary intent is authenticating any and all devices within and in the periphery of the iOS ecosystem and secure all inbound and outbound data transfers. With more iOS device types, and a heterogeneous accessory market Apple is entirely justified in its role as the ecosystem owner to be at the front of the curve, to ensure security is not an afterthought - and instead to – mandate that data in transit or at rest is fully secured at all end-points. In fact, interest in Wearables, Home automation, Healthcare and Telematics are completely rewiring the rules of what it means to be an accessory anymore I believe this approach to security will be the mainstay of how Apple visualizes its role in enabling payments — regardless of channel. Anything it does to reduce payments friction will be counterbalanced by serious cryptographic measures that secure devices that have a need to communicate in payments — to authenticate, to encrypt and to subsequently transfer a payment token. With TouchID today it does so by verifying the fingerprint before authorizing the transmission of an authentication token from the Secure Enclave to an Apple server in the cloud. I don’t doubt that the authentication token being sent to the Apple server in the cloud is itself signed by the device’s unique ID – which is verified, before the server completes the purchase with a card on file. Thus, crypto pervades everything the iPhone does, touches or trusts. So how do the MFi program, Bluetooth, iOS Security fit in within Apple’s plan to tackle retail payments? For that, let’s start with NFC. With NFC anointed as the only way forward by networks and other stakeholders — every other approach was regarded as being less secure without much thought given to that classification by way of actual risk of fraud. You could build the best payments “whatchamacallit” and throw everything and the kitchen sink at it — and be still branded as ‘Card Not Present’ and inherit a higher cost. Understandably — merchants passed on it as they couldn’t scale with the costs that it confronted. No self-respecting merchant could afford to scale — unless they owned all of the risk (via decoupled debit, ACH or private label). All they could do was reject contactless and prevent themselves from being burdened by the network’s definition of a payments future. Thus the current NFC impasse was born. Now with merchants rolling out EMV-compliant terminals, many of which have contactless built in, they are desperately looking to Apple for clarity. If Apple does NFC then they have the entirety of a terminal refresh cycle (approximately 10 years) within which they hope that common sense may prevail (for example, debit as an acceptable payments choice via contactless) and correspondingly toggle the switch to begin accepting contactless payments. If Apple goes in a different direction, a merchant who has chosen an EMV-compliant terminal with or without contactless is locked out until the end of the current refresh cycle. But what if Apple went with Bluetooth? Two factors stand in the way: Bluetooth is not secure enough for payments today and terminal makers need to comply. Yet, with EMVCo publishing draft standards around tokenization one can argue that non-NFC modalities now are being given fair share, where proximity is not the only guarantee for security and other options such as Bluetooth can begin to address the challenge creatively. Where is the opportunity among all this for Bluetooth? Let’s tackle Bluetooth Range and Device Pairing that limit its utility in payments today. Range is as much a curse as it is a blessing for Bluetooth. If security via proximity was NFC’s raison d’être, then in contrast Bluetooth had to worry about man-in-the-middle attacks due to its range. Though Bluetooth communication is invariably always encrypted, the method in which two devices arrive at the encryption key is suboptimal. Since much of the early key negotiation between devices happens in the clear, brute forcing the shared secret that is key to encryption is a fairly easy and quick attack — and the range makes man-in-the-middle attacks easy to implement and harder to detect. The approach to device pairing also differs from Bluetooth to BLE. Needless to say, it is even less secure for BLE. Pairing in a payments context brings up further challenges, as it has to be silent, customer initiated and simple to execute. I am not going to pair my iPhone with a point-of-sale by punching in “000000” or another unique code each time I must pay Can NFC be of use here? It can. In fact, Bluetooth pairing is the only use case where I believe that Apple may feel there is utility for NFC so that an out-of-band key exchange can be possible (versus an in-band key exchange wholly over Bluetooth). This is far more secure than using Bluetooth alone and derives a much stronger encryption key. An out-of-band key exchange thus enables both devices to agree on a strong encryption key that can prevent malicious third parties from splicing themselves in the middle. BLE however does not allow for out-of-band key exchange and therefore is limited in its utility. This is another reason why if you are a BLE accessory maker Apple excludes you from having to participate in the MFi program. How can Apple secure Bluetooth and make it the standard of choice for a retail payment use case? The answer to that lies inside Apple’s specification for MFi participants — manifested in the form of the Integrated Circuit Apple provides to them so that these iOS accessories may authorize themselves to an iOS device and secure the communication that follows. This IC which encapsulates the initial setup including the certificate, mutual key negotiation and deriving the encryption key — can support Bluetooth. So if all that ails Bluetooth can be cured by including an IC – will point-of-sale manufacturers like Verifone and Ingenico line up to join Apple’s MFi program? The message is clear. You must curry favor with Apple if you want to be able to securely communicate with the iOS ecosystem. That is no tall barrier for terminal makers who would willingly sacrifice far more to be able to speak to 800M iOS devices and prevent being made irrelevant in an ever-changing retail environment. So why not include a single IC and instantaneously be able to authorize to that broad ecosystem of devices, and be capable of trusted communication? And if they do — or when they do — how will merchants, networks and issuers react? Today a point of sale is where everything comes together — payments, loyalty, couponing — and it’s also where everything falls apart. Will this be considered Card Present? Even with all the serious crypto that would become the underpinnings of such a system, unfairly or not the decision is entirely that of a few. Networks and issuers To answer how they may respond, we must ask how they may be impacted by what Apple builds. Is Apple really upending their role in the value chain? I believe Apple cares little about the funding source. Apple would instead defer to – the merchants who believe it should be debit, and the issuers who believe the customer should choose – and secretly hope that it is credit. I don’t think that Apple would want to get between those two factions. It wants to build simply the most secure, easy way to bring retail payments to iOS devices —  and allow all within the transaction flow to benefit. The rails do not change, but the end-points are now much more secured than they ever were, and they form a trusted bond and a far bigger pipe. A customer who authenticates via TouchID, a phone that announces to the point of sale that it’s ready to talk, a smart circuit that negotiates the strongest encryption possible while being invisible to all and a token that stands in for your payment credential that is understood by the point of sale. It is business as usual, and yet not. Will the iPhone6 have NFC? The presence of NFC in iPhone6 — if it’s announced — will not mean that NFC will be utilized in the same manner as it is today (for example, Isis). The radio will exist, but there will be no global platform secure element. Today the role of the radio is instrumental (in both secure element or HCE cases) in transmitting the PAN to the point of sale. When there are coupons that need to be presented and reconciled at the point of sale — things begin to get complex. Since the radio becomes the bottleneck, it requires longer than a quick tap for more data to be transmitted. Proximity is a good guarantee for device presence as well as the customer, but it’s a poor vehicle for information. So why wouldn’t one try to relegate it to the initial handshake to enable authentification of the device and therefore the customer with the point of sale? As I mentioned above, if Apple uses NFC, its role will be to facilitate an out-of-band key exchange to secure the subsequent Bluetooth communication so that an iOS device can trust the point of sale and securely transmit payment data. This data may include any and all tokenized payment credential along with loyalty, couponing and everything else. By using NFC for out-of-band authentication in conjunction with the authentication IC (provided by Apple) in the point of sale, Apple can run circles around the limitations imposed by a pure NFC approach — exceeding it on usability, security, adaptability and merchant utility. Yet, if NFC’s role is limited to the initial key negotiation, then the case can be made that NFC has very limited utility, it exists only to serve Apple’s security narrative, and utilizing NFC for the initial pairing strengthens the encryption and makes it harder to snoop. If it has only derived incremental value, would Apple care to put it on iPhone6 — and split its utility among customers using iPhone6 versus all others? With more than 400M iPhones out there that can support Bluetooth LE and iOS8, why ignore that advantage and create a self-induced dependency on a radio that has no subscribers today?  So where do I fall within this debate? I believe iPhone6 will not have NFC. Learn more about our Global Consulting Practice.  

Published: June 10, 2014 by Cherian Abraham

Both Visa and MasterCard announced their support for Host Card Emulation (HCE) and their intent to release HCE specifications soon. I have been talking about HCE from late 2012 (partly due to my involvement with SimplyTapp) and you could read as to why HCE matter and what Android KitKat-HCE announcement meant for payments. But in light of the network certification announcements yesterday, this post is an attempt to provide some perspective on what the Visa/MasterCard moves mean, how do their approaches differ in certifying payments using cloud hosted credentials, what should issuers expect from a device and terminal support perspective, why retailers should take note of the debate around HCE and ultimately – the role I expect Google to continue to play around HCE. All good stuff. First, what do the Visa/MasterCard announcements mean? It means that it’s time for banks and other issuers to stop looking for directions. The network announcements around HCE specifications provide the clarity required by issuers to meaningfully invest in mobile contactless provisioning and payment. Further, it removes some of the unfavorable economics inherited from a secure element-centric model, who were forced to default to credit cards with higher interchange in the wallet. Renting space on the secure element cost a pretty penny and that is without taking operational costs in to consideration, and as an issuer if you are starting in the red out of the gate, you were not about to put a Durbin controlled debit card in the wallet. But those compulsions go with the wind now, as you are no longer weighed down by these costs and complexities on day one. And further, the door is open for retailers with private label programs or gift cards to also look at this route with a lot more interest. And they are. MasterCard mentioned bank pilots around HCE in its press release, but MCX is hardly the only retailer payment initiative in town. Let me leave it at that. How do the Visa/MasterCard specs differ? From the press releases, some of those differences are evident – but I believe they will coalesce at some point in the future. MasterCard’s approach speaks to mobile contact-less as the only payment modality, whereas Visa refers to augmenting the PayWave standard with QR and in-app payments in the future. Both approaches refer to payment tokens (single or multi-use) and one can expect them to work together with cloud provisioned card profiles, to secure the payment transaction and verify transactional integrity. To MasterCard’s benefit – it has given much thought to ensuring that these steps – provisioning the card profile, issuing payment tokens et al – are invisible to the consumer and therefore refrains from adding undue friction. I am a purist at heart – and I go back to the first iteration of Google Wallet – where all I had to do to pay was turn on the screen and place the device on the till. That is the simplicity to beat for any issuer or retailer payment experiences when using contactless. Otherwise, they are better off ripping out the point-of-sale altogether. MasterCard’s details also makes a reference to a PIN. The PIN will not be verified offline as it would have been if a Secure Element would have been present in the device, rather – it would be verified online which tells me that an incorrect PIN if input would be used to create an “incorrect cryptogram” which would be rejected upstream. Now I am conflicted using a PIN at the point of sale for anything – to me it is but a Band-Aid, it reflects the inability to reduce fraud without introducing friction. Visa so far seems to be intentionally light on details around mandating a PIN, and I believe not forcing one would be the correct approach – as you wouldn’t want to constrain issuers to entering a PIN as means to do authentication, and instead should have laid down the requirements but left it to the market to decide what would suffice – PIN, biometrics et al. Again – I hope these specs will continue to evolve and move towards a more amenable view towards customer authentication. Where do we stand with device and terminal support? All of this is mute if there are not enough devices that support NFC and specifically – Android KitKat. But if you consider Samsung devices by themselves (which is all one should consider for Android) they control over 30% of the NA market – 44.1 million devices sold in 2013 alone. Lion share of those devices support NFC out of the box – including Galaxy Note II and 3, Galaxy S3 and S4 – and their variants mini, Active, Xoom et al. And still, the disparity in their approach to secure elements, continuing lack of availability in standards and Android support – Tap and Pay was largely a dream. What was also worrisome is that 3 months after the launch of Android KitKat – it still struggles under 2% in device distribution. That being said, things are expected to get markedly better for Samsung devices at least. Samsung has noted that 14 of its newer devices will receive KitKat. These devices include all the NFC phones I have listed above. Carriers must follow through quickly (tongue firmly in cheek) to deliver on this promise before customers with old S3 devices see their contracts expire and move to a competitor (iPhone 6?). Though there was always speculation as to whether an MNO will reject HCE as part of the Android distribution, I see that as highly unlikely. Even carriers know a dead horse when they see one, and Isis’s current model is anything but one. Maybe Isis will move to embrace HCE. And then there is the issue of merchant terminals. When a large block of merchants are invested in upending the role of networks in the payment value chain – that intent ripples far and wide in the payments ecosystem. Though it’s a given that merchants of all sizes can expect to re-terminalize in the next couple of years to chip & pin (with contactless under the hood) – it is still the prerogative of the merchant as to whether the contactless capability is left turned on or off. And if merchants toe Best Buy’s strategy in how it opted to turn it off store-wide, then that limits the utility of an NFC wallet. And why wouldn’t they? Merchants have always viewed “Accept all cards” to also mean “Accept all cards despite the form factor” and believes that contactless could come to occupy a higher interchange tier in the future – as questions around fraud risk are sufficiently answered by the device in real-time. This fear is though largely unsubstantiated, as networks have not indicated that they could come to view mobile contact-less as being a “Card Present Plus” category that charges more. But in the absence of any real assurances, fear, uncertainty and doubt runs rampant. But what could a retailer do with HCE? If re-terminalization is certain, then retailers could do much to explore how to leverage it to close the gap with their customer. Private label credit, closed loop are viable alternatives that can be now carried over contactless – and if previously retailers were cut out of the equation due to heavy costs and complexity for provisioning cards to phones, they have none of those limitations now. A merchant could now fold in a closed loop product (like a gift card) in to their mobile app – and accept those payments over contact-less without resorting to clunky QR or barcode schemes. There is a lot of potential in the closed loop space with HCE, that Retailers are ignoring due to a “scorched earth” approach towards contactless. But smarter merchants are asking ‘how’. Finally, what about Google? Google deserves much praise for finally including HCE in Android and paving the way for brands to recognize the opportunity and certify the approach. That being said, Google has no unequal advantage with HCE. In fact, Google has little to do with HCE going forward, despite GoogleWallet utilization of HCE in the future. I would say – HCE has as much to do with Google going forward, as Amazon’s Kindle Fire has to do with Android. Banks and Retailers have to now decide what this means for them – and view HCE as separate to Google – and embrace it if they believe it has potential to incent their brands to remain top of wallet, and top of mind for the consumer. It is a level playing field, finally. Where do you go next? Indeed – there is a lot to take in – starting with HCE’s role, where it fit in to your payment strategy, impact and differences in Visa/MasterCard approaches, weaving all of these in to your mobile assets while not compromising on customer experience. Clarity and context is key and we can help with both. Reach out to us for a conversation. HCE is a means to an end – freeing you from the costs and complexities of leveraging contactless infrastructure to deliver an end-to-end mobile experience, but there is still the question of how your business should evolve to cater to the needs of your customers in the mobile channel. Payment is after all, just one piece of the puzzle.

Published: February 20, 2014 by Cherian Abraham

In the days following the Target breach, both clarity and objectivity are in short supply. Everything that didn’t already exist became suddenly the cure-all – EMV being one. Retailers bristle, albeit in private – due to the asymmetry in blame they have come to share compared to banks – despite having equal ownership of the mess they have come to call payments. Issuers and Schemes scramble to find an empty deck chair on the Titanic, just to get a better view of the first of the lifeboats capsizing. Analogies aside, we may never fully eliminate breaches. Given an infinite amount of computing power and equal parts human gullibility – whether its via brute forcing encryption systems or through social engineering – a breach is only a matter of time. But we can shorten the half-life of what is stolen. And ensure that we are alerted when breaches occur – as fraudsters take care to leave little trace behind. Yet today our antiquated payments system offer up far too many attack vectors to a fraudster, that the sophistication in attempts of the likes of what we saw at Target, is the exception and not the norm. But are the retailers absolved of any responsibility? Hardly. Questions from a breach: According to Target, malware was found on Target’s PoS – presumably pushed by unauthorized outsiders or via compromised insiders. If so, how is it that unauthorized code managed to find its way to all or most of its PoS terminals? Could this have been uncovered by performing a binary or checksum comparison first, to ensure that files or packages are not tampered with, before they are deployed to the Point-of-Sale? Such a step could have certainly limited the attack vectors to a small group of people with administrative access – who would have the need to handle keys and checksums. Further, depending on the level of privilege accorded to every binary that gets deployed to the point of sale – Target could have prevented an unauthorized or remotely installed program from performing sensitive functions such as reading consumer data – either in transit or in RAM. That said – I am not sure if PoS manufacturers provide for such layered approach towards granting access and execution privileges to code that is deployed to their systems. If not, it should. Where DOES EMV come in? EMV helps to verify the card – indisputably. Beyond that, it offers no protection to either the consumer or the merchant. The risk of EMV, and it’s infallibility in the eyes of its true believers, is that it can lull the general public in to a sense of false security – much like what we have now under Reg E and Reg Z. With EMV, PAN and PIN continues to be passed in the clear, unencrypted. Retailers could deploy EMV terminals and still be riddled like cheese by fraudsters who can siphon off PANs in transit. Fraudsters who may find it nearly impossible to create counterfeit cards, instead will migrate online where inadequate fraud mitigation tools prevail – and those inadequacies will force both banks and retailers to be heavy handed when it comes to determining online fraud. Friction or Fraud should not be the only two choices. Solving Card Not Present Fraud: There are no silver bullets to solve Card Not Present fraud. Even with EMV Chip/Pin, there is an opportunity to put a different 16 digit PAN on the front of the card versus the one that is on the magstripe/chip. (I am told that Amex does this for its Chip/pin cards.) The advantage is that a fraudster using a fraudulently obtained PAN from the chip for an e-commerce purchase will standout to an card issuer compared to the legit customer using a different PAN on the front of the card for all her e-commerce purchases. This maybe one low tech way to address CNP fraud alongside of an EMV rollout. But if asking a consumer to enter his Zipcode or show his ID was enough for retail purchases, there exists equivalent friction-bound processes online. Authentication services like 3-D Secure are fraught with friction, and unfairly penalize the customer and indirectly – the retailer and issuer, for its blind attribution of trust in a user provided password or a token or a smart card reader. Where it may (in some cases) undeniably verifies consumer presence, it also overwhelms – and a customer who is frustrated with a multi-step verification will simply shop somewhere else or use Paypal instead. Ever had to input your Credit Card Verification code (CVV2 or CVC2) on an Amazon purchase? Me neither. Fraud in connected commerce: As connected devices outnumber us, there needs to be an approach that expands the notion of identity to look beyond the consumer and start including the device. At the core, that is what solutions like 41st Parameter – an Experian company, focuses on – which enables device attributes to collectively construct a more sophisticated indicator of fraud in an e-commerce transaction – using 100 or so anonymous device attributes. Further it allows for more nuanced policies for retailers and issuers, to mitigate fraud by not only looking at the consumer or device information in isolation – but in combination with transactional attributes. As a result, retailers and issuers can employ a frictionless, smarter, and more adaptive fraud mitigation strategy that relies less on what could be easily spoofed by a fraudster and more on what can be derived or implied. If you want to know more why this is a more sensible approach to fighting fraud, you should go here to read more about 41st Parameter. Remnants from a breach: Even though the material impact to Target is still being quantified, little doubt remains as to the harm done to its reputation. Target RED card remains largely unaffected, yet it is but a fleeting comfort. Though some, thus had been quick to call decoupled debit a more secure product, those claims choose to ignore the lack of any real consumer protection that is offered alongside of these products. Though Reg E and Reg Z have been largely instrumental in building consumer trust in credit and debit cards, they have also encouraged general public to care less about fraud and credit card security. And this affects more than any other – MCX, whose charter calls for reduction of payment acceptance costs first, and to whom – decoupled debit offered a tantalizing low cost alternative to credit. But when it launches this year, and plans to ask each customer to waive protections offered by Reg E and Reg Z and opt for ACH instead – those consumers will find that choice harder to stomach. Without offering consumers something equivalent, MCX Retailers will find it exceedingly difficult to convince customers to switch. Consumer loyalty to retailer brands was once given as the reason for creating a retailer friendly payment backbone, but with Target’s reputation in tatters – that is hardly something one can bank on these days – pun intended. Where does this leave us? To be completed…   This blog post was originally featured at: http://www.droplabs.co/?p=964

Published: January 14, 2014 by Cherian Abraham

When I wrote about Host Card Emulation back in March, it provoked much debate around whether this capability will die on the cutting floor or be meaningfully integrated in to a future Android iteration. And now that it has, this post is an attempt to look forward, even though much of it is speculative. But I will provide some perspective from a number of conversations I had in the last week with Networks, Issuers, TSMs, Merchants, Platform Owners and EMV practitioners and provide some insight in to perceptions, impacts and the road ahead for NFC. And I will provide some context to why HCE matters to each of these players. First – if you haven’t read my previous post on HCE – this would be a good time to do so. Media has unfortunately focused yet again on the controversy in light of the KitKat HCE announcement – focusing on the end-run around Carriers rather than the upside this brings to those who have been disincentivized previously to consider NFC. What they all seem to have missed is that HCE allows for the following: it reduces the gap between merchants and card issuance, brings the topic of closed-loop and contactless in focus, and more tactically – allows for an easy deployment scenario that does not require them to change the software inside the terminal. I hope those three things do not get lost in translation. Google: Being a Platform Owner for once The Android team deserves much credit for enabling support for Host Card Emulation in KitKat. Beyond the case for platform support – something Blackberry already had – there were both altruistic and selfish reasons for going this route. The former – altruistic – had to do with throwing open another door that would invite third party developers to build on an open NFC stack – while firmly shutting other ones (read criticism from Ars that Android is quickly becoming a closed source – partly through its Play services approach). It was time it acted like a platform owner. And being one entailed democratizing access to tap-and-pay. Selfish – because for the more than 200M Android devices that shipped with NFC support – a fraction of these are tap-and-pay worthy. It had become absurd that one must enquire upon Carrier, Platform, Issuer and Device support before installing an NFC payment app, much less use it. Talk about fragmentation. This was a problem only Google could begin to fix – by removing the absurd limitations put in place in the name of security – but in truth existed because of profit, control and convenience. Google’s role hardly ends here. Today – Host Card Emulation – by definition alone, is reserved as a technical topic. Out of the gate, much needs to be done to educate Issuers and Merchants as to why this matters. For retailers – used to much cynicism in matters relating to NFC – Host Card Emulation offers an opportunity to develop and deploy a closed-loop contactless scheme using retailer’s preferred payment sources – private label, debit, credit and in that order. HCE to Merchants: Friend or Foe? In my opinion – merchants stand to benefit most from HCE. Which is another reason why Google really embraced this concept. Despite having certain benefits for Issuers to provision cards without having to pay the piper, Google had its eyes set on expanding the offline footprint for GoogleWallet and to successfully do so – needed to focus on the merchant value prop while dialing back on what retailers once called the “data donation agreement”. Where merchants primarily struggle today in mobile – is not in replicating the plastic model – it is to create a brand new loyalty platform where the customer sets a payment source and forgets it – preferably one that’s preferred by the merchant – for example a private label card or debit. Except, no open loop wallets had actually centered itself around this premise so far. Google Wallet launched with Citi, then reverted to a negative margin strategy – by charging the merchant CP rates while paying the Issuers CNP rates. It wasn’t ideal – as merchants did not want Google anywhere near the transaction value chain. Meanwhile – it gave Google quite the heartburn to see Apple being successful with Passbook – requiring merchants give nothing back in return for leveraging it to deliver geo-targeted offers and loyalty. This silent takedown must have forced Google’s hands in getting serious about building a complete offer, loyalty, payment scheme that is collaborative (HCE support was a collaborative effort introduced by SimplyTapp) and merchant friendly. I believe HCE support now represents a serious effort to help merchants commercialize a closed-loop advantage in contactless without requiring software changes inside the terminal. Contactless was out of bounds for merchants till now. Not anymore. Having fielded a number of calls from retailers as to what this means, I will distill retailer reactions down to this: measured optimism, casual pessimism and “network” cynicism. Retailers have always looked at EMV and terminalization as a head-fake for NFC – to further lay down the tracks for another three decades of control around pricing and what they see as anti-competitive behavior. Though HCE is in no way tethered to NFC (it’s agnostic of a communication method) – due to its current close association with NFC, merchants see the conversation as a non-starter – until there is a constructive dialogue with networks. At the same time, merchants are cautiously optimistic about the future of HCE – provided that there is a standards body that provides them equal footing with Platform owners, Issuers and networks – to dictate its scope and future. As the platform owner – Google should work with the merchant body, networks, issuers and other stakeholders to see this through. It was not a surprise that those who I talked to all agreed about one thing: that Carriers really should have no role to play in this framework. TSM’s/SE Providers: Where to from here? The nine party model is dead, or will be very soon – as the SE rental model has been shown as previously not being sustainable – and now with HCE – simply wasteful. TSM’s had been focused outside of US for the last several years – as the lack of meaningful commercial launches meant that the US market will simply not bring scale for many years. And with Google shifting away from using a Secure Element in its flagship Nexus models – the writing was already on the wall. TSM’s will look to extend their capabilities in to non-traditional partnerships (Gemalto/MCX) and in to non-hardware scenarios (competing with Cloud SE providers like SimplyTapp in the HCE model). Bell-ID is such an example – and quite likely the only example right now. Networks: Certify or Not? What does Host Card Emulation mean to V/MA? It is no secret that the networks had more than toyed with the idea of software card emulation these last couple of years – realizing the rapidly shrinking runway for NFC. Focus for networks should be now to certify the new approach, as a legitimate way to store and transfer credentials. It’s interesting to hear how our neighbors in the north have reacted to this news. There is still ambiguity among Canadian issuers and networks as to what this means – including debates as to whether an onboard SE is still required for secure storage. That ambiguity will not dissipate till V/MA step in and do their part. I must quote an EMV payments consultant from the north who wrote to me this week: “My boss calls the TSM model “traditional” and I remind him in NFC payments there is no tradition… I think for some people the Global Platform standards with the TSM smack in the middle are like a comfort food – you know what you are getting and it feels secure (with 1000′s of pages of documentation how could they not be!)” That should give GP and TSMs some comfort. Device Support for HCE: What does that look like? Google does not report sales figures on Nexus 4, Nexus 5, Google Play editions of Samsung Galaxy S4 and HTC One – the four devices that are slated to receive KitKat over the next few weeks (apart from the Nexus tablets). So if I would venture a guess – I would say approx 20M devices in total that has NFC capability that will support Host Card Emulation soon. That may not seem much – but it’s a strong base . There is also a possibility that post-Galaxy Nexus devices from Samsung may leapfrog 4.3 to go directly to KitKat. If that happens – just based on reported sales volumes for Galaxy S3 and S4 – that would be a total of 100M devices with NFC support. What does that mean for Samsung’s revenue model around SE – who has an embedded SE from Oberthur in the S3 & S4 devices, which it hopes to charge rent to Visa and others – that’s unclear at this point. Issuers: ISIS alternative or more? For those issuers who passed on Isis, or those who were scorned by Isis – this enables them to outfit their current mobile assets with a payment feature. I wrote about the absurdity in a contactless transaction where the consumer has to close his merchant or banking app and switch to Isis to tap-and-pay – instead of equipping merchant/bank apps with a tap-and-pay feature. HCE means a lot more for Private label Issuers – who have a very inspired base of merchants looking to bridge the gap between private label cards and mobile – and now have an alternative to clumsy, costly and complex orchestrations for provisioning cards – replaced with an easy integration and cheaper deployment. More about that later. Finally, Carriers & Isis: Fight or Flight? God Speed.

Published: November 7, 2013 by Cherian Abraham

In the 1970s, it took an average of 18 days before a decision could be made on a credit card application. Credit decisioning has come a long way since then, and today, we have the ability to make decisions faster than it takes to ring up a customer in person at the point of sale. Enabling real-time credit decisions helps retail and online merchants lay a platform for customer loyalty while incentivizing an increased customer basket size.   While the benefits are clear, customers still are required to be at predetermined endpoints, such as: At the receiving end of a prescreened credit offer in the mail At a merchant point of sale applying for retail credit In front of a personal computer The trends clearly show that customers are moving away from these predetermined touch-points where they are finding mailed credit offers antiquated, spending even less time at a retail point of sale versus preferring to shop online and exchanging personal computers for tablets and smartphones. Despite remaining under 6 percent of retail spending, e-commerce sales for Q2 2013 have reportedly been up 18.5 percent from Q2 2012, representing the largest year-over-year increase since Q4 2007, before the 2008 financial crisis. Fueled by a shift from personal computers to connected devices and a continuing growth in maturity of e-commerce and m-commerce platforms, this trend is only expected to grow stronger in the future. To reflect this shift, marketers need to be asking themselves how they should apportion their budgets and energies to digital while executing broader marketing strategies that also may include traditional channels. Generally, traditional card acquisitions methods have failed to respond to these behavioral shifts, and, as a whole, retail banking was unprepared to handle the disintermediation of traditional products in favor of the convenience mobile offers. Now that the world of banking is finding its feet in the mobile space, accessibility to credit must also adapt to be on the customer’s terms, unencumbered by historical notions around customer and credit risk. Download this white paper to learn how credit and retail private-label issuers can provide an optimal customer experience in emerging channels such as mobile without sacrificing risk mitigation strategies — leading to increased conversions and satisfied customers.  It will demonstrate strategies employed by credit and retail private-label issuers who already have made the shift from paper and point of sale to digital, and it provides recommendations that can be used as a business case and/or a road map.  

Published: November 4, 2013 by Cherian Abraham

TL;DR Read within as to how Touch ID is made possible via ARM’s TrustZone/TEE, and why this matters in the context of the coming Apple’s identity framework. Also I explain why primary/co-processor combos are here to stay. I believe that eventually, Touch ID has a payments angle – but focusing on e-commerce before retail. Carriers will weep over a lost opportunity while through Touch ID, we have front row seats to Apple’s enterprise strategy, its payment strategy and beyond all – the future direction of its computing platform. I had shared my take on a possible Apple Biometric solution during the Jan of this year based on its Authentec acquisition. I came pretty close, except for the suggestion that NFC is likely to be included. (Sigh.) Its a bit early to play fast and loose with Apple predictions, but its Authentec acquisition should rear its head sometime in the near future (2013 – considering Apple’s manufacturing lead times), that a biometric solution packaged neatly with an NFC chip and secure element could address three factors that has held back customer adoption of biometrics: Ubiquity of readers, Issues around secure local storage and retrieval of biometric data, Standardization in accessing and communicating said data. An on-chip secure solution to store biometric data – in the phone’s secure element can address qualms around a central database of biometric data open to all sorts of malicious attacks. Standard methods to store and retrieve credentials stored in the SE will apply here as well. Why didn’t Apple open up Touch ID to third party dev? Apple expects a short bumpy climb ahead for Touch ID before it stabilizes, as early users begin to use it. By keeping its use limited to authenticating to the device, and to iTunes – it can tightly control the potential issues as they arise. If Touch ID launched with third party apps and were buggy, it’s likely that customers will be confused where to report issues and who to blame. That’s not to say that it won’t open up Touch ID outside of Apple. I believe it will provide fettered access based on the type of app and the type of action that follows user authentication. Banking, Payment, Productivity, Social sharing and Shopping apps should come first. Your fart apps? Probably never. Apple could also allow users to set their preferences (for app categories, based on user’s current location etc.) such that biometrics is how one authenticates for transactions with risk vs not requiring it. If you are at home and buying an app for a buck – don’t ask to authenticate. But if you were initiating a money transfer – then you would. Even better – pair biometrics with your pin for better security. Chip and Pin? So passé. Digital Signatures, iPads and the DRM 2.0: It won’t be long before an iPad shows up in the wild sporting Touch ID. And with Blackberry’s much awaited and celebrated demise in the enterprise, Apple will be waiting on the sidelines – now with capabilities that allow digital signatures to become ubiquitous and simple – on email, contracts or anything worth putting a signature on. Apple has already made its iWork productivity apps(Pages, Numbers, Keynote), iMovie and iPhoto free for new iOS devices activated w/ iOS7. Apple, with a core fan base that includes photographers, designers and other creative types, can now further enable iPads and iPhones to become content creation devices, with the ability to attribute any digital content back to its creator by a set of biometric keys. Imagine a new way to digitally create and sign content, to freely share, without worrying about attribution. Further Apple’s existing DRM frameworks are strengthened with the ability to tag digital content that you download with your own set of biometric keys. Forget disallowing sharing content – Apple now has a way to create a secondary marketplace for its customers to resell or loan digital content, and drive incremental revenue for itself and content owners. Conclaves blowing smoke: In a day and age where we forego the device for storing credentials – whether it be due to convenience or ease of implementation – Apple opted for an on-device answer for where to store user’s biometric keys. There is a reason why it opted to do so – other than the obvious brouhaha that would have resulted if it chose to store these keys on the cloud. Keys inside the device. Signed content on the cloud. Best of both worlds. Biometric keys need to be held locally, so that authentication requires no roundtrip and therefore imposes no latency. Apple would have chosen local storage (ARM’s SecurCore) as a matter of customer experience, and what would happen if the customer was out-of-pocket with no internet access. There is also the obvious question that a centralized biometric keystore will be on the crosshairs of every malicious entity. By decentralizing it, Apple made it infinitely more difficult to scale an attack or potential vulnerability. More than the A7, the trojan in Apple’s announcement was the M7 chip – referred to as the motion co-processor. I believe the M7 chip does more than just measuring motion data. M7 – A security co-processor? I am positing that Apple is using ARM’s TrustZone foundation and it may be using the A7 or the new M7 co-processor for storing these keys and handling the secure backend processing required. Horace Dediu of Asymco had called to question why Apple had opted for M7 and suggested that it may have a yet un-stated use. I believe M7 is not just a motion co-processor, it is also a security co-processor. I am guessing M7 is based on the Cortex-M series processors and offloads much of this secure backend logic from the primary A7 processor and it may be that the keys themselves are likely to be stored here on M7. The Cortex-M4 chip has capabilities that sound very similar to what Apple announced around M7 – such as very low power chip, that is built to integrate sensor output and wake up only when something interesting happens. We should know soon. This type of combo – splitting functions to be offloaded to different cores, allows each cores to focus on the function that it’s supposed to performed. I suspect Android will not be far behind in its adoption, where each core focuses on one or more specific layers of the Android software stack. Back at Google I/O 2013, it had announced 3 new APIs (the Fused location provider) that enables location tracking without the traditional heavy battery consumption. Looks to me that Android decoupled it so that we will see processor cores that focus on these functions specifically – soon.                   I am fairly confident that Apple has opted for ARM’s Trustzone/TEE. Implementation details of the Trustzone are proprietary and therefore not public. Apple could have made revisions to the A7 chip spec and could have co-opted its own. But using the Trustzone/TEE and SecurCore allows Apple to adopt existing standards around accessing and communicating biometric data. Apple is fully aware of the need to mature iOS as a trusted enterprise computing platform – to address the lack of low-end x86 devices that has a hardware security platform tech. And this is a significant step towards that future. What does Touch ID mean to Payments? Apple plans for Touch ID kicks off with iTunes purchase authorizations. Beyond that, as iTunes continue to grow in to a media store behemoth – Touch ID has the potential to drive fraud risk down for Apple – and to further allow it to drive down risk as it batches up payment transactions to reduce interchange exposure. It’s quite likely that à la Walmart, Apple has negotiated rate reductions – but now they can assume more risk on the front-end because they are able to vouch for the authenticity of these transactions. As they say – customer can longer claim the fifth on those late-night weekend drunken purchase binges. Along with payment aggregation, or via iTunes gift cards – Apple has now another mechanism to reduce its interchange and risk exposure. Now – imagine if Apple were to extend this capability beyond iTunes purchases – and allow app developers to process in-app purchases of physical goods or real-world experiences through iTunes in return for better blended rates? (instead of Paypal’s 4% + $0.30). Heck, Apple can opt for short-term lending if they are able to effectively answer the question of identity – as they can with Touch ID. It’s Paypal’s ‘Bill Me Later’ on steroids. Effectively, a company like Apple who has seriously toyed with the idea of a Software-SIM and a “real-time wireless provider marketplace” where carriers bid against each other to provide you voice, messaging and data access for the day – and your phone picks the most optimal carrier, how far is that notion from picking the cheapest rate across networks for funneling your payment transactions? Based on the level of authentication provided or other known attributes – such as merchant type, location, fraud risk, customer payment history – iTunes can select across a variety of payment options to pick the one that is optimal for the app developer and for itself. And finally, who had the most to lose with Apple’s Touch ID? Carriers. I wrote about this before as well, here’s what I wrote then (edited for brevity): Does it mean that Carriers have no meaningful role to play in commerce? Au contraire. They do. But its around fraud and authentication. Its around Identity. … But they seem to be stuck imitating Google in figuring out a play at the front end of the purchase funnel, to become a consumer brand(Isis). The last thing they want to do is leave it to Apple to figure out the “Identity management” question, which the latter seems best equipped to answer by way of scale, the control it exerts in the ecosystem, its vertical integration strategy that allows it to fold in biometrics meaningfully in to its lineup, and to start with its own services to offer customer value. So there had to have been much ‘weeping and moaning and gnashing of the teeth’ on the Carrier fronts with this launch. Carriers have been so focused on carving out a place in payments, that they lost track of what’s important – that once you have solved authentication, payments is nothing but accounting. I didn’t say that. Ross Anderson of Kansas City Fed did. What about NFC? I don’t have a bloody clue. Maybe iPhone6? iPhone This is a re-post from Cherian's original blog post "Smoke is rising from Apple's Conclave"

Published: October 2, 2013 by Cherian Abraham

Isis has had a slew of announcements – about an impending national rollout and further assertion by both Amex and Chase of their intent to continue their partnership. Surprisingly (or not) Capital One has stayed mum about its plans, and neither has Barclays or Discover shown any interest. And much ink has been spilled at how resolute (and isolationist) Isis has been – including here on this blog. So does the launch reflect a maturity in the JV to tackle a national rollout, or is it being forced to show its hands? Wait..I have more questions... What about the missing partner? I have no reason to believe that CapitalOne will continue its relationship with Isis – as I doubt they learnt anything new from the Isis pilot – apart from the excruciatingly difficult orchestration required to balance multiple TSMs, Carriers, Handsets and the Secure Element. Further, there are no new FI launch partners – no BofA, no WellsFargo, no Citi – who each are capable of paying the upfront cost to be on Isis. But, even to those who can afford it – the requisite capital and operating expenditures stemming from a national rollout, should give pause when compared against the lift Isis can provide to incremental revenue via Isis wallet consumers. This is the biggest qualm for Issuers today – that Isis has all the capability to drive distribution and do secure provisioning – but none of the capacity to drive incremental card revenue. And Isis opting to profit from simply delivering merchant offers based on store proximity, with no visibility in to past payment behavior and no transactional marketing capabilities – is hardly different or better than what FourSquare already does for Amex, for example. So why bother? *Updated* There is also a total misalignment of objectives between Isis and its Issuing partners around customer acquisition. Isis charges for provisioning credentials to the wallet regardless of how many transactions that may follow. So Isis has an incentive to push its wallet to everyone with a phone even if that person never completes a contactless transaction. Where as its Issuers have an incentive to get most bang for the buck by targeting the folks most likely to use a smartphone to pay after activation. See a problem? *End Update* How much more runway does Isis have? This is the question that has been around most. How much more capital is Isis’s parents willing to plow in to the JV before they come calling? The rumored quarter a billion pot holds enough to power a national rollout, but is it enough to sustain that momentum post-launch? If those $100 Amazon Gift cards they were handing out in Austin/SLC to boost consumer adoption (a final push just prior to reporting overall usage numbers) were any indication, Isis needs to invest in a smarter go-to-market strategy. It wouldn’t be surprising if Isis had to go back to its parents for mo’ money so that it can continue to run – while standing absolutely still. Who has a recognizable brand – Isis or Amex/Chase? Isis once boasted about buying a billion impressions in their pilot markets across various marketing channels. I shudder to see the ROI on that ad spend – especially when all the Ads in the world could not help if a customer still had to get a new phone, or get a new SIM by visiting the carrier store – to do what a plastic card can do effortlessly. It’s FI partners (Chase, Amex and CapitalOne) have so far kept any Isis branding outside of their ads, and I doubt if that would change. After all, why would Amex and Chase who collectively spent about $4.2B in advertising last year care about giving Isis any visibility, when a Chase or an Amex customer still has to fire up an Isis app to use a Chase or an Amex card? Why would Amex and Chase dilute its brand by including Isis messaging – when they themselves are pitted against each other inside the wallet? For some inexplicable reason – Isis made a conscious decision to become a consumer brand instead of a white label identity, provisioning and payment platform. (And for all of the faults attributable to Google – they are a consumer brand and yet – look at all the trouble it had to make its payments efforts scale.) I believe that until Isis displays a willingness to let its Issuing partners play front and center, any support they in turn provide to Isis is bound to be non-committal. Have you counted the Point-of-Sale registers? MCX proved to be the sand in mobile payments gears since the announcement. It has had “quite the intended” effect of killing any kind of forward movement on in-store payment initiatives that required a conventional point-of-sale upgrade. Contactless upgrades at point-of-sale which have long been tied to the EMV roadmap has had a series of setbacks, not the least of which is the continuing ambiguity around Issuer readiness, merchant apathy, and roadblocks such as the recent ruling. More so, the ruling injected more ambiguity in to how proximity payments would function, which payment apps must be supported for the same debit or credit transaction etc. With retailers, Isis brings nothing new that others are unable to claim, and infact it brings even less – as there is no new context outside of store-customer-proximity that it can bring to deliver discounts and coupons to customer prospects. And it’s cringeworthy when someone claims to “help” retailers in driving incremental traffic to stores, simply because they are able to pair context and proximity among other factors. These claims are hugely suspect due to how limited their “contexts” are – and no one can blend intent, past behavior, location and other factors better than Google – and even they churned out an inferior product called Google Offers. Transactional data is uniquely valuable – but Banks have been negligent in their role to do anything meaningful. But I digress. Coming full circle: Will we ever see proximity payments realized in a way that does not include the SE? The UICC based Secure Element model has been the favored approach by Carriers, which allows device portability and to exert control on the proximity payments ecosystem. We have seen deviations from the norm – in the form of Bankinter, and the recent RBC/BellID Secure cloud – which reject the notion of an onboard Secure Element, and opts to replace it with credentials on TEE, in memory or on the cloud. There is much interest around this topic, but predicting which way this will turn out is difficult owing to where the power to effect change resides – in the hands of OEMs, Ecosystem owners, Carriers etc. And don’t forget that Networks need to subscribe to this notion of credentials outside of SE, as well. But what about an Isis wallet that decouples itself from NFC/SE? Google has toyed with such an approach, but it clearly has the assets (Gmail, Android et al) to build itself a long runway. What about an Isis that exists outside of NFC/SE? Well – why do you need Isis then? To be fair, such an approach would pale against MCX or Paydiant or a number of other wallets and offer even less reasons for merchants to adopt. Paydiant offers both a better point-of-sale integration and a quicker QR capture – which Isis will struggle to match. It’s abundantly clear – take away the SE – and just as easily, the Carrier value proposition collapses on its own like a pack of cards. That’s one risky bet. What are your thoughts about the future of Isis? I am on Twitter here, if you wish to connect. And you can find me on LinkedIn here.   This is a re-post from Cherian\'s original blog post \"Isis: A JV at odds.\"

Published: August 26, 2013 by Cherian Abraham