“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.