Telecommunications, Cable & Utilities

Providing the essentials to credit risk managers

Basically, a blockchain is a permissionless, distributed database that maintains a growing list of records in a linear, chronological ledger.

As thought leaders in every industry make predictions for what 2016 will bring, I’m guessing there will be a few constants. New couples will marry. Some couples, sadly, will divorce. Young and old will move – some into first homes – others downsizing or making moves cross-country for work. And waves of individuals will clamor to the latest devices – a new iPhone7, perhaps. The Apple rumors are already flying. Yes, no big surprises, right? But, do you know what all of these very standard life events have in common? These transitions often result in shifts in consumer data, sometimes making people more difficult to track and contact. New last names, new addresses, new phone numbers. Suddenly, the consumer data that companies and lenders have on file are dated, and when it comes time to reach out to these individuals, it’s a challenge to connect. But that is just the beginning. The Federal Communications Commission (FCC) is increasing its efforts to register consumer complaints and taking aggressive actions to stop companies from making unsolicited phone calls. And the penalties are steep. Fines per individual infraction can be anywhere from $500 to $1,500. Companies have been delivered hefty penalties in the thousands, and in some cases millions, of dollars, over the past few years. All have questions and are seeking to understand how they must adjust their policies and call practices. Now those multiple attempts to call and find a consumer can cost you – big time. No more “shotgun” approaches to identifying and using phones. It’s simply too risky. The Telephone Consumer Protection Act (TCPA), enforced by the FCC, has been around since 1991, but regulations have been closely scrutinized over the past year since the FCC announced a new ruling last summer to clarify hot topics. In their July paper, they aim to communicate the definition of an “auto-dialer,” consent-to-call rules, how to address the reassignment of cell phone numbers, and the new requirement for “one call” without liability. In short, the Declaratory Ruling has opened the door to even greater liability under the TCPA, leaving companies who place outbound customer calls at-risk for compliance violations. Some are projecting the TCPA rules will continue to become even more expansive in 2016, so companies must really assess their call strategies and put best practices in place to increase right-party contact rates. Suggestions include: Identify landline and cell phones for TCPA compliance with dialer campaigns Focus on right- and wrong-party contact to improve customer service Score phones or apply cut-off scores based on the confidence of the number or match Scrub often for updated or verified information Establish a process to identify ported phones Determine when and how often you dial cell phones Provide consumers user-friendly mechanisms– such as texting “STOP” or “UNSUBSCRIBE” – to opt-out of receiving TCPA-covered communications. Review the policies and practices of third-party vendors to ensure they are not sending communications violating the TCPA With the huge advancements in mobile technology and the ever-changing digital landscape, it’s challenging to keep up, but regulators are cracking down on violations, and a slew of lawyers are ready to file on behalf of unhappy consumers dialed one-too-many times. Beyond a best-practice review, tools and systems are available to identify the right number for those moving and changing consumers. And I’m sure we can all agree, those life events will continue to happen in 2016. Marriages, divorces, moves, new devices. They’re coming. As a result, it’s necessary to track the resulting changes to consumer data. Only then will you have a shot at avoiding negative customer experiences and fines.

Businesses must be vigilant and apply comprehensive, data-driven customer intelligence to thwart breaches and the malicious use of breached information.

The financial services industry continues to face mounting pressures to meet the highest standards of data reporting and accuracy. New regulations and mandates are introduced regularly, impacting the way companies do business. And a more credit-educated consumer base is seeking insights into their own credit data, providing a separate second of eyes that demand accuracy. Not only has the Fair Credit Reporting Act (FCRA) set requirements on dispute investigation and response, but the Consumer Financial Protection Bureau (CFPB) is also paying close attention. Recent announcements indicate the CFPB wants more information about the credit eco-system to gain more data about consumer disputes. According to the CFPB, it’s a joint problem – “the NCRAA’s, data furnishers, public record providers, and consumers all play roles which affect the accuracy of the information with credit reports.” And it’s not just the big banks that are being targeted with fines. The CFPB has made it clear it will also direct attention to certain nonbanks and financial products. In today’s data-driven environment, there are roughly 12,000-plus data furnishers, resulting in more than one billion pieces of information being updated on a monthly basis. Over 220 million consumers have some form of credit information attached to them, and transactional data is flowing all the time. Fail to update and a furnisher will quickly see flaws in their reporting. In fact, a recent study revealed an estimated 2.1% of contact info goes bad if unattended for more than one month. Clearly, achieving data quality is an ongoing investment for any organization, but companies often lack a clean plan. Some data furnishers fail to report, or elect to report to just one bureau, even though providing better data will result in a more complete and accurate credit profile. So how do you tackle the challenge of data quality? Organizations should consider implementing these six steps: Review data governance. Correct errors in data submissions. Complete an audit of data submissions. Evaluate disputes and resolutions. Compare data to peers and the industry. Review existing policies and processes. Follow these steps and your organization will earn a reputation among both regulators and consumers for clean, credible data. Plus, the investment in better data will reduce the need to resolve future disputes and fines. To learn more about meeting your FCRA responsibilities and best practices around data quality, check out our on-demand webinar or data integrity services site.

It’s official. Millennials have surpassed Baby Boomers in population size, according to the US Census. And while they are quick to adopt the “selfie” and all things social, they have been slow to embrace the world of credit. Sure, there’s been increased regulation over the past decade, and coming into adulthood in the midst of the Great Recession hasn’t helped. But don’t count Millennials out of the credit game just yet. A deeper, more segmented view of this digital-dependent generation shows a very diverse population with plenty of opportunity for lenders. Plus, their sheer size in numbers and $200 billion in annual buying power demand financial institutions evolve to accommodate this massive market. As Gen Y comes of age, there is growing evidence they are open to building and growing their personal credit history. But if financial institutions wish to capture the attention and business of this demographic, they must adapt, leveraging deeper segmentation insights with more effective prospecting strategies to reach them. Experian's data reveals key trends in terms of how this generation is utilizing credit, tips and tools to find the most credit-ready individuals, and strategies to grow the thin-file Millennials as they come of age. “Given the significance millennials play in financial services and the credit marketplace, it is crucial to understand this influential consumer segment and how they use credit as a tool,” said Michele Raneri, vice president of analytics and business development. “While this generation may not look like they are on the right track financially, it’s important to keep in mind that credit scores are built on credit experiences, and while this generation has been slower to use credit, they have plenty of opportunities to build a positive credit history.” To learn more about Millennials and credit, visit Experian.com/millennials.

As the electronic signature industry matures and acceptance of e-signatures increases, so does the need for more robust, flexible options in authentication.

Critical for businesses being confronted first party fraud is to understand fraud management vs. credit risk management. First party fraud is...

Surveillance and fraud staging are the seemingly benign and often-transparent account activities that fraudsters undertake after an account has been compromised but before that compromise has been detected or money is moved.

I would talk about three opportunities that the energy utility vertical could and should take advantage of.

Understanding the importance of customer experience to business strategy and performance

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.

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.

By: Teri Tassara In my blog last month, I covered the importance of using quality credit attributes to gain greater accuracy in risk models.  Credit attributes are also powerful in strengthening the decision process by providing granular views on consumers based on unique behavior characteristics.  Effective uses include segmentation, overlay to scores and policy definition – across the entire customer lifecycle, from prospecting to collections and recovery. Overlay to scores – Credit attributes can be used to effectively segment generic scores to arrive at refined “Yes” or “No” decisions.  In essence, this is customization without the added time and expense of custom model development.  By overlaying attributes to scores, you can further segment the scored population to achieve appreciable lift over and above the use of a score alone. Segmentation – Once you made your “Yes” or “No” decision based on a specific score or within a score range, credit attributes can be used to tailor your final decision based on the “who”, “what” and “why”.  For instance, you have two consumers with the same score. Credit attributes will tell you that Consumer A has a total credit limit of $25K and a BTL of 8%; Consumer B has a total credit limit of $15K, but a BTL of 25%.   This insight will allow you to determine the best offer for each consumer. Policy definition - Policy rules can be applied first to get the desirable universe.  For example, an auto lender may have a strict policy against giving credit to anyone with a repossession in the past, regardless of the consumer’s current risk score. High quality attributes can play a significant role in the overall decision making process, and its expansive usage across the customer lifecycle adds greater flexibility which translates to faster speed to market.  In today’s dynamic market, credit attributes that are continuously aligned with market trends and purposed across various analytical are essential to delivering better decisions.  

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.