All posts by Cherian Abraham
This post is in response to the recent Bankinter story of NFC payments at the point-of-sale without requiring SE – and the lack of any real detail around how it plans to achieve that goal. I am not privy to Bankinter’s plan to dis-intermediate the SE, but as I know a wee bit about how NFC works, I thought a post would help in clearing up any ambiguity as to how Card emulation and Host Card emulation differs, upsides, challenges – the whole lot. Back in December of 2012, Verizon responded to an FCC complaint over its continued blocking of GoogleWallet on Verizon network. The gist of Verizon’s response was that as GoogleWallet is different to PayPal, Square and other wallet aggregators in that its reliance on the phone’s Secure Element – a piece of proprietary hardware, lies behind the reason for Verizon denying GoogleWallet from operating on its devices or network. Verizon continued to write that Google is free to offer a modified version of GoogleWallet that does not require integration with the Secure Element. Now Software Card Emulation was not born out of that gridlock. It had been always supported by both NXP and Broadcom chipsets at the driver level. Among operating systems, BlackberryOS supports it by default. With Android however, application support did not manifest despite interest from the developer community. Google chose to omit exposing this capability via the API from Android 2.3.4 – may have to do with opting to focus its developer efforts elsewhere, or may have been due to carrier intervention. What very few knew is that a startup called SimplyTapp had already been toiling away at turning the switch back on – since late 2011. Host Card What? But first – let’s talk a bit about Card Emulation and how Host Card Emulation (or SE on the Cloud) differs in their approach. In the case of GoogleWallet, Card Emulation represents routing communication from an external contactless terminal reader directly to the embedded secure element, dis-allowing visibility by the operating system completely. Only the secure element and the NFC controller are involved. Card Emulation is supported by all merchant contactless terminals and in this mode, the phone appears to the reader as a contactless smart card. Google Wallet, Isis and other NFC mobile wallets rely on card emulation to transfer payment credentials to the PoS. However the downsides to this are payment apps are limited to the SE capacity (72kb on the original embedded SE on Nexus S), SE access is slower, and provisioning credentials to the SE is a complex, brittle process involving multiple TSM’s, multiple Carriers (in the case of Isis) and multiple SE types and handsets. Host Card Emulation (or Software Card Emulation) differs from this such that instead of routing communications received by the NFC controller to the secure element, it delivers them to the NFC service manager – allowing the commands to be processed by applications installed on the phone. With that, the approach allows to break dependency on the secure element by having credentials stored anywhere – in the application memory, in the trusted execution environment (TEE) or on the cloud. The benefits are apparent and a couple is noted: NFC returns to being a communication standard, enabling any wallet to use it to communicate to a PoS – without having to get mired down in contracts with Issuers, Carriers and TSMs. No more complex SE cards provisioning to worry about Multiple NFC payment wallets can be on the phone without worrying about SE storage size or compartmentalizing. No need to pay the piper – in this case, the Carrier for Over-the-air SE provisioning and lifecycle management. Card Issuers would be ecstatic. However this is no panacea, as software card emulation is not exposed to applications by Android and host card emulation patches that have been submitted (by SimplyTapp) have not yet been merged with the main android branch – and therefore not available to you and I – unless we root our phones. Which is where SimplyTapp comes in. SimplyTapp appealed to an early segment of Android enthusiasts who abhorred having been told as to what functionality they are allowed to enable on their phones – by Google, Carriers or anyone else. And to any who dared to root an NFC phone (supported by CyanogenMod) and install the Cyanogenmod firmware, they were rewarded by being able to use both SimplyTapp as well as GoogleWallet to pay via NFC – the former where credentials were stored on the cloud and the latter – within the embedded SE. So how does this work? SimplyTapp created a Host Card Emulation patch which resolves potential conflicts that could arise from having two competing applications (SimplyTapp and GW) that has registered for the same NFC event from the contactless external reader. It does so by ensuring that upon receiving the event – if the SimplyTapp app is open in the foreground (On-Screen) then the communication is routed to it and if not – it gets routed to GoogleWallet. This allows consumers to use both apps harmoniously on the same phone (take that ISIS and Google Wallet!). SimplyTapp today works on any NFC phone supported by CyanogenMod. Apart from SimplyTapp, InsideSecure is working on a similar initiative as reported here. You get a wallet! And you get a wallet! Everyone gets a wallet! Well not quite. What are the downsides to this approach? Well for one – if you wish to scale beyond the enthusiasts, you need Google, the platform owner to step up and make it available to all without having to root our phones. For that to happen it must update the NFC service manager to expose Host Card emulation for the NXP and Broadcom chipsets. And if Google is not onboard with the idea, then you need to find an OEM, a Handset manufacturer or an Amazon ready to distribute your amended libraries. Further, you can also expect Carriers to fight this move as it finds its investment and control around the secure element threatened. With the marked clout they enjoy with the OEM’s and Handset manufacturers by way of subsidies, they can influence the outcome. Some wonder how is it that BlackberryOS continues to support Host Card Emulation without Carrier intervention. The short answer may be that it is such a marginal player these days that this was overlooked or ignored. The limitations do not stop there. The process of using any cloud based credentials in an EMV or contactless transaction has not been certified yet. There is obviously interest and it probably will happen at some point – but nothing yet. Debit cards may come first – owing to the ease in certification. Further, Closed loop cards may probably be ahead of the curve compared to Open loop cards. More about that later. *Update: Latency is another issue when the credentials are stored on the cloud. Especially when NFC payments were called out last year to be not quick enough for transit.* So for all those who pine for the death of secure elements, but swear fealty to NFC, there is hope. But don’t set your alarm yet. So what will Google do? Let’s consider for a moment that Google is down with this. If so, does that represent a fork in the road for Google Wallet? Will the wallet application leverage HCE on phones with inaccessible Secure Elements, while defaulting to the Secure Element on phones it has? If so, it risks confusing consumers. Further – enabling HCE lets other wallets to adopt the same route. It will break dependency with the secure element, but so shall it open the flood gates to all other wallets who now wants to play. It would seem like a pyrrhic victory for Google. All those who despised proximity payments (I am looking at you Paypal & Square!) will see their road to contactless clear and come calling. As the platform owner – Google will have no choice but to grin and bear it. But on a positive note, this will further level the playing field for all wallets and put the case for contactless back – front and center. Will Google let this happen? Those who look at Google’s history of tight fisted control over the embedded SE are bound to cite precedent and stay cynical. But when it comes down it, I believe Google will do the right thing for the broader android community. Even on the aspect of not relinquishing control over the embedded SE in the devices it issued, Google had put the interests of consumer first. And it felt that, after all things considered it felt it was not ready to allow wanton and unfettered access to the SE. Google had at one point was even talking about allowing developers write their own “card emulation” applets and download them to the SE. Broadcom also has an upcoming quad-combo chip BCM43341 that has managed to wrap NFC, Bluetooth 4.0, Wi-Fi and FM Radio, all on a single die. Further, the BCM43341 also supports multiple Secure Elements. Now, I also hear Broadcom happens to be a major chip supplier to a fruit company. What do you think? This is content was originally posted to Cherian's personal blog at DropLabs.
Big news [last week], with Chase entering in to a 10 year expanded partnership with Visa to create a ‘differentiated experience’ for its merchants and consumers. I would warn anyone thinking “offers and deals” when they hear “differentiated experience” – because I believe we are running low on merchants who have a perennial interest in offering endless discounts to its clientele. I cringe every time someone waxes poetic about offers and deals driving mobile payment adoption – because I am yet to meet a merchant who wanted to offer a discount to everyone who shopped. There is an art and a science to discounting and merchants want to identify customers who are price sensitive and develop appropriate strategies to increase stickiness and build incremental value. It’s like everyone everywhere is throwing everything and the kitchen sink at making things stick. On one end, there is the payments worshippers, where the art of payment is the centre piece – the tap, the wave, the scan. We pore over the customer experience at the till, that if we make it easier for customers to redeem coupons, they will choose us over the swipe. But what about the majority of transactions where a coupon is not presented, where we swipe because its simply the easiest, safest and the boring thing to do. Look at the Braintree/Venmo model, where payment is but a necessary evil. Which means, the payment is pushed so far behind the curtain – that the customer spends nary a thought on her funding source of choice. Consumers are issuer agnostic to a fault – a model propounded by Square’s Wallet. Afterall, when the interaction is tokenized, when a name or an image could stand in for a piece of plastic, then what use is there for an issuer’s brand? So what are issuers doing? Those that have a processing and acquiring arm are increasingly looking at creative transaction routing strategies, in transactions where the issuer finds that it has a direct relationship with both the merchant and the consumer. This type of selective routing enables the issuer to conveniently negotiate pricing with the merchant – thereby encouraging the merchant to incent their customers to pay using the card issued by the same issuer. For this strategy to succeed, issuers need to both signup merchants directly, as well as encourage their customers to spend at these merchants using their credit and debit cards. FI’s continue to believe that they can channel customers to their chosen brands, but “transactional data doth not maketh the man” – and I continue to be underwhelmed by issuer efforts in this space. Visa ending its ban on retailer discounts for specific issuer cards this week must be viewed in context with this bit – as it fuels rumors that other issuers are looking at the private payment network option – with merchants preferring their cards over competitors explicitly. The wild wild west, indeed. This drives processors to either cut deals directly with issuers or drives them far deeper in to the merchant hands. This is where the Braintree/Venmo model can come in to play – where the merchant – aided by an innovative processor who can scale – can replicate the same model in the physical world. We have already seen what Chase Paymentech plans to do. There aren’t many that can pull off something similar. Finally, What about Affirm, the new startup by Max Levchin? I have my reservations about the viability of a Klarna type approach in the US – where there is a high level of credit card penetration among the US customers. Since Affirm will require customers to choose that as a payment option, over other funding sources – Paypal, CC and others, there has to be a compelling reason for a customer to choose Affirm. And atleast in the US, where we are card-entrenched, and everyday we make it easier for customers to use their cards (look at Braintree or Stripe) – it’s a tough value proposition for Affirm. Share your opinions below. This is a re-post from Cherian's personal blog at DropLabs.
At midnight yesterday, Google sent me an email on how the new GoogleWallet update will now allow me to store my “Citi MasterCard” online. As other Google Wallet aficionados may recall (Bueller..? Bueller..?), Citi was the lone holdout in Google Wallet’s journey to the cloud and its race to conformity. Though to the untrained eye the Google Wallet app experience was mostly uniform irrespective of the card used to pay at the point-of-sale, behind the scenes, if the Citi MasterCard was used, Google had to do things one way versus another way for the rest of the brood. Furthermore, sharing the precious real estate that is the Secure Element with Citi meant that Google had very little room to maneuver. Embedded SEs, despite being newer to market than SIM-based SE’s, were limited in storage versus other chips. The initial embedded SEs that Google Wallet relied on had about 76KB memory, which once you factor in all the trimmings that come with provisioning a card to SE (MasterCard PayPass applet among others), left very little wiggle room. So Google, forced by a number of factors (resistance from the carriers and issuers, rising costs and complexities attributed to the multiple TSM model, a lack of SE space to accommodate future provisioning) migrated to the cloud — and left a MasterCard proxy on the wallet that it could use to funnel transactions through. The only standout to this model was the umbilical cord to the original Google Wallet partner: Citi. I had predicted last September that the partnership’s days were numbered. When the wallet is Google’s, and it needs to both reclaim the space on SE and reduce the provisioning or account management costs that it owes to its TSM (FirstData), the only reason for it to carry the torch for Citi would be if Google Wallet customers demanded it. But it so happens that any returns for items purchased using Google Wallet untill today had also been slightly broken. If you bought an item using the virtual MasterCard then the returns followed one route; of you purchased an item via the Citi card then returns were handled a different way. Additionally, It was disappointing for a customer to see “Paypass Merchant” instead of “McDonalds” and “Sent” instead of “$25.54″ when paying with the Citi card in GoogleWallet(unless one was planning to hide a fastfood habit from a spouse). A small mess – especially when it should be attributed to powers beyond the partnership, but still a mess for Google who demands conformity in customer experience across all its offerings. In the end, this partnership served no broader purpose for either partner to keep alive for any longer. Google is ready to move on beyond Wallet 1.0 and realizes that it can do so without issuers in tow. Furthermore, it had been expected for a better part of three months that Google will launch its partnership with Discover and this puts Google as an indispensable element back in the mobile payment narrative. For the issuers who were originally courted by Google Wallet in its early days this serves as validation, that they were correct in choosing to stay away. But that is no excuse for ignoring what Google and others are building as a parallel framework to the value-added services (credit card rewards being one) card issuers use to show that customers will choose them over Google. (But if Google could tout interchange relief to merchants as an incentive to court them, don’t you think a Google Rewards program will be close behind, supported by credits redeemable the Google Play store? Once again, it’s not an if, but when.) Finally, where does this leave Citi? Citi is a global institution with enough smart people at their end to make up for lost time. Google Wallet did not become the boogeyman that issuers feared back in 2011, and Citi can afford to roll out its own mobile initiatives in a measured pace at a global scale. And there had been rumblings of a Citi wallet all through 2012 and we may see it soon manifest outside of the U.S. before Citi attempts to do so here. Google may have opted to cut the cord so that there is no ambiguity when that happens. But they still have both Citi and FirstData to thank for bringing it to the prom. You dance with the one that brung ya…or something like it. Do you think this means GoogleWallet is now adrift, loyal to its own quest? What’s next for Citi? What do you think? Please leave your opinions below. This is a re-post from Cherian's personal blog at DropLabs
First, it aims to drastically reduce payment acceptance costs through any and all means and Secondly – keep merchant data firmly within their purview. MCX – MerChants reduX: The post that follows is a collection of thoughts around MCX, why it deserves respect, and yet how it is indeed mortal and bleeds like all others. For those who are not familiar with MCX – it’s a consortium of over 30 leading national retailers with a singular purpose – that is, to create a seamlessly integrated mobile commerce platform. The website for MCX is http://www.mcx.com. The consortium is led by merchants like Walmart, Target, CVS, BestBuy, Gap, Sears etc. By 2012, the mobile payments space was fragmented as it is, which itself may have precipitated the launch of MCX. And to a number of solutions looking for traction, things ground to a halt when MCX conceptualized to the merchants a solution that needed no costly upgrades and a promise to route the transaction over low cost routing options. My friends on the issuer side privately confide that MCX has infact succeeded in throwing a monkey wrench in their mobile payment plans – and merchant acceptance looks to be ambiguous around incumbent initiatives such as Isis and GoogleWallet, as well as for alternative payment initiatives. It had been easy to call it mere posturing and ignore it in the early days, but of late there is a lot of hand wringing behind the scenes and too many furrowed brows, as if the realization finally struck that merchants were indeed once again crucial to mobile payment adoption. MCX – It’s raison d’etre Meanwhile, the stakeholders behind MCX have been religious in their affirmation that MCX lives by two core tenets: First, it aims to drastically reduce payment acceptance costs through any and all means and Secondly – keep merchant data firmly within their purview. I can’t seem to think that the latter was any more than an after thought, because merchants individually can choose to decide if they wish to share customer preferences or Level III data with third parties, but they need all the collective clout they can muster to push networks and issuers to agree to reduce card acceptance costs. So if one distils MCX down to its raison d’etre, then it looks that it is aimed squarely at No.1. Which is fair when you consider that the merchants believe card fees are one of their biggest operating expenses. In 2007, 146,000 convenience stores and gas stations nationwide made a total of $3.4B in profits, yet they paid out $7.6B in card acceptance costs(Link). And MCX is smart to talk about the value of merchant data, the need to control it, yada yada yada. But if that were indeed more important, Isis could have been the partner of choice – someone who would treat customer and transaction data as sacrosanct and leave it behind for the merchants to fiddle with(vs. GoogleWallet’s mine..mine..mine.. strategy). But the same way HomeDepot was disappointed when they first saw GoogleWallet – no interchange relief, incremental benefits at the point-of-sale, and swoops all their data in return, Isis also offers little relief to MCX or its merchants, even without requiring any transaction or SKU level data in return. 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. And creating a platform for merchants to deliver coupons, alerts to opted-in customers. 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. 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. Did we say Apple? 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 NFC? If NFC was originally meant to seamlessly and securely share content, what better way to sign that content, to have it be attributable to its original author, or to enforce one’s rights to said content – than to sign it with one’s digital signature. Identity is key, not just when enforcing digital rights management on shared content, but also to secure commerce and address payment/fraud risk. Back to MCX. The more I read the more it seems MCX is trying to imitate Isis in competing for the customer mindshare, in attempting to become a consumer brand – than simply trying to be a cheaper platform for payment transactions. As commerce evolved beyond being able to be cleanly classified under “Card Present” and “Card Not Present” – as transactions originate online but get fulfilled in stores, merchants expect rules to evolve alongside reality. For example, when customers are able to order online, but pick up in-store after showing a picture ID, why would merchants have to pay “Card not Present” rates when risk is what we attribute higher CNP rates to, and why is there an expectation of the same amount of risk even in this changed scenario? And beyond, as technology innovation blurs the lines that neatly categorized commerce, where we replace “Card Present” with “Mobile Present”, and mobile carry a significant amount of additional context that could be scored to address or quantify risk, why shouldn’t it be?. It’s a given that networks will have to accommodate for reduced risk in transactions where mobile plays a role, where the merchant or the platform enabling the transaction can meaningfully use that context to validate customer presence at the point-of-sale – and that they will expect appropriate interchange reduction in those scenarios. MCX – A brand like Isis or a platform? But when reading portions of the linked NRF blog, and elsewhere – it reflects a misplaced desire on MCX’s part to become a consumer facing solution – an app that all MCX partners will embrace for payment. This is so much like the Isis solution of today – that I have written about – and why it flies in the face of reason. Isis – the nexus between Carriers and FI’s – is a powerful notion, if one considers the role it could play in enabling an open platform – around provisioning, authentication and marketing. But for that future to materialize, Isis has to stop competing with Google, and must accept that it has little role to play by itself at the front end of the funnel, and must recede to its role of an enabler – one that puts its partner FI brands front and center, allows Chase’s customers to pay using Chase’s mobile app instead of Isis, and drives down the fraud risk at the point of sale by meaningfully authenticating the customer via his location and mobile assets Carriers control, and further – the historical data they have on the customer. It’s those three points of data and the scale Isis can bring, that puts them credibly in the payments value chain – not the evaporating control around the Secure Element. In the same vein, the value MCX brings to merchants – is the collective negotiating power of over 30 national merchants. But is it a new consumer brand, or is it a platform focused on routing the transaction over the least cost routing option. If its the latter, then it has a strong parallel in Paypal. And as we may see Paypal pop-up as legal tender in many a retailer’s mobile apps and checkout aisles going forward, MCX is likely to succeed by emulating that retailer aligned strategy than follow a brand of its own. Further, If MCX wants customers to pay using less costly means – whether they be private label, prepaid or ACH – then it and its partners must do everything they can to shift the customer focus away from preferred payment methods and focus on the customer experience and resulting value around loyalty. MCX must build its value proposition elsewhere, and make their preferred payment methods the bridge to get the customer there. Another example where the retailer focused too much on the payment, and less so on the customer experience is the Safeway Fast Forward program. The value proposition is clear for the customer – Pay using your Safeway Fast Forward card number and a self assigned PIN for simpler checkout. However to set up your account, the customer must provide a State issued ID (Drivers License) and on top of it – his Social Security Number(Safeway Fast Forward Requirements Here). What customer would, for the incremental convenience of paying via his Fast Forward Card and PIN, be willing to entrust Safeway with his Social Security Number? Clearly Safeway’s Risk team had a say in this and instead of coming up with better ways to answer questions around Risk and Fraud, they introduced a non-starter, which killed any opportunity for meaningful adoption. MCX & adoption So where does that leave MCX? Why will I use it? How will it address questions around adoption? It’s a given that it will have to answer the same questions around fraud and authentication during customer on-boarding or at a transactional level. Further, its not enough these days to simply answer questions pertaining to the customer. Further, one must address questions relating to the integrity and reputation of the device the customer use – whether that be a mobile device or a Laptop PC. But beyond fraud and auth, there are difficult questions around what would compel a techno-luddite who has historically paid using a credit instrument to opt for an ACH driven(i am guessing) MCX payment scheme. Well, for one: MCX and its retail partners can control the purchasing power parity of MCX credits. If they so wish, and after aggregating customer profiles across retailers, MCX determines that the Addams family spends a collective $400 on average per month between all the MCX retailers. MCX could propose that if instead, the Addams family were to commit to buy $450 in MCX credits each month, they could increase their purchasing power an additional $45 credits that could be used on specific retail categories (or flat out across all merchandise)? Would Morticia be interested? If she did, what does that mean to MCX? It eliminated having to pay interchange on approx $500, and further it enabled its partners to capture an incremental spend of 10% that did not exist before. Only merchants will be able to pull this off – by leveraging past trends, close relationships with CPG manufacturers and giving Morticia new reasons to spend in the manner they want her to. But then again, where does MCX stop in providing a level playing field for its partners, and step back – so that merchants can start to compete for their customers and their spend? And finally, can it survive the natural conflicts that will arise, and limit its scope to areas that all can agree – for long enough for it to take root? Should MCX become the next Isis or the next Paypal? Which makes most sense? What do you think? Please leave your opinions below... (This blog post is an adaptation of its original post found - http://www.droplabs.co/?p=662)
I'm here in Vegas at the Mobile2020 conference and I am fascinated by my room key. This is not the usual “insert in to the slot, wait for it turn green or hear it chime” key cards, these are “tap and hold to a door scanner till the door opens” RFID key card. It is befitting the event I am about to attend – Money2020 – the largest of its kind bringing together over 2000 mobile money aficionados, strategists and technologists from world over for a couple of days to talk about how payment modalities are shifting and the impact of these shifts to existing and emerging players. Away from all the excitement of product launches, I hope some will be talking about one of the major barriers for consumer adoption towards alternate payment modalities such as mobile – security and fraud. I was in Costa Mesa last week and in the process of buying something for my wife with my credit card, triggered the card fraud alert. My card was declined and I had to use a different card to complete my transaction. As I was walking out, my smartphone registers a text alert from the card issuer – asking me to confirm that it was actually I who attempted the transaction. And If so, Respond by texting 1 – if Yes Or 2 – if No. All good and proper up till this point. If someone had stolen my card or my identity, this would have been enough to stop fraud from re-occurring. In this scenario the payment instrument and the communication device were separate – my plastic credit card and my Verizon smartphone. In the next couple of years, these two will converge, as my payment instrument and my smartphone will become one. At that point, will the card issuer continue to send me text alerts asking for confirmation? If instead of my wallet, my phone was stolen – what good will a text alert to that phone be of any use to prevent the re-occurrence of fraud? Further if one card was shut down, the thief could move to other cards with in the wallet – if, just as today, there are no frameworks for fraud warnings to permeate across other cards with in the wallet. Further, fraud liability is about to shift to the merchant with the 2013 EMV Mandate. In the recent years, there has been significant innovation in payments – to the extent that we have a number of OTT (Over the Top) players, unencumbered by regulation, who has been able to sidestep existing players – issuers and card networks, in positioning mobile as the next stage in the evolution of payments. Google, PayPal, Square, Isis (a Carrier consortium formed by Verizon, T-Mobile and AT&T), and a number of others have competing solutions vying for customer mind share in this emerging space. But when it comes to security, they all revert to a 4 digit PIN – what I call as the proverbial fig leaf in security. Here we have a device that offers a real-time context – whether it be temporal, social or geo-spatial – all inherently valuable in determining customer intent and fraud, and yet we feel its adequate to stay with the PIN, a relic as old as the payment rails these newer solutions are attempting to displace. Imagine what could have been – in the previous scenario where instead of reaching for my card, I reach for my mobile wallet. Upon launching it, the wallet, leveraging the device context, determines that it is thousands of miles away from the customer’s home and should score the fraud risk and appropriately ask the customer to answer one or more “out-of-wallet” questions that must be correctly answered. If the customer fails, or prefers not to, the wallet can suggest alternate ways to authenticate – including IVR. Based on the likelihood of fraud, the challenge/response scenario could include questions about open trade lines or simply the color of her car. Will the customer appreciate this level of pro-activeness on the issuer’s part to verify the legality of the transaction? Absolutely. Merchants, who so far has been on the sidelines of the mobile payment euphoria, but for whom fraud is a real issue affecting their bottom-line, will also see the value. The race to mobile payments has been all about quickly shifting spend from plastic to mobile, and incenting that by enabling smartphones to store and deliver loyalty cards and coupons. The focus need to shift, or to include, how smartphones can be leveraged to address and reduce fraud at the point-of-sale – by bringing together context of the device and a real-time channel for multi-factor authentication. It’s relevant to talk about Google Wallet (in its revised form) and Fraud in this context. Issuers have been up in arms privately and publicly, in how Google displaces the issuer from the transaction by inserting itself in the middle and settles with the merchant prior to firing off an authorization request to the issuer on the merchant’s behalf. Issuers are worried that this could wreak havoc with their inbuilt fraud measures as the authorization request will be masked by Google and could potentially result in issuer failing to catch fraudulent transactions. Google has been assuaging issuer’s fears on this front, but has yet to offer something substantial – as it clearly does not intent to revert to where it was prior – having no visibility in to the payment transaction (read my post here). This is clearly shaping up to be an interesting showdown – would issuers start declining transactions where Google is the merchant of record? And how much more risk is Google willing to take, to become the entity in the middle? This content is a re-post from Cherian's personal blog: http://www.droplabs.co/?p=625
Learn More Image
