The constant drip of privacy concerns regarding social networks and QR payment systems like Line Pay, and where user transaction data is stored, makes the old JR East crisis look small and silly. Everything is more connected now in unexpected ways than even just 8 years ago.
It doesn’t matter how secure transaction protocols are when user transaction record data is stored on leaky servers or sold to outsiders for profit. I wrote about this earlier, the so called popularity of QR Code payment services in Japan is really about big data. In that vein we have a timely blog post on Open Loop ltransit rider privacy from Transit Center.
For a professional advocacy organization dedicated ‘to improve public transit,’ the Transit Center privacy publication is surprisingly amateurish. It raises valid concerns but reads like open loop advertising from credit card companies (Transit Center soft sponsors?), where open loop is the golden cure-all future, and the only future at that, of every transit ill with closed loop invariably portrayed as a dead era of tokens, punchcards and mag strip swipe cards. They also make MTA seem like the only transit system in America that matters because idiosyncratic MTA problems apply everywhere. Right? Wrong. Let’s take a look at their privacy blog post…<<with comments>>.
Transit agencies around the country are adopting a new generation of fare payment systems. Agencies including New York’s MTA, Boston’s MBTA, and Houston METRO are in the process of switching to what’s known as “open-loop” systems that enable riders to tap into the system using digital wallets on their phones or with their credit cards…
These technologies come with clear benefits for riders, but they also carry the risk of exposing more personal data…
<<here it comes>>
The switch to these new fare payment technologies can accelerate access to riders’ trip data by other government agencies. In New York, for instance, individuals’ MTA trip data can be retrieved much faster with the new OMNY system than with the older MetroCard system…
<<retrieve trip data quickly on a fare system where users don’t tap out…what? privacy concerns are not just government agencies btw with multiple 3rd party companies handling and processing transit fare data…which brings us to>>
The increased involvement of third parties in fare payment underscores the need for better data collection and management policies within transit agencies.
<<better as in more big data details?>>
How to Implement the Next Generation of Fare Payment Without Shredding Riders’ Privacy
Anybody experienced in dealing with bank and card company customer service could see this coming. Bank and transit operating cultures are different and they don’t mix well with outside companies running the transit gate fare concession. If you think transit privacy is a concern now, wait until face recognition transit gates become the next transit future thing.
Let’s make this simple. Open Loop (EMV and QR) and bank card EMV Closed Loop means that banks and outside payment platforms run their services at the fare gates They have transit user data, as does the transit company, so does the fare system management subcontractor like Cubic. The more places data is stored the more it’s gonna leak. This is exactly what is playing out in Japan right now because Line Pay Japan user transaction data is stored in South Korea which does not, putting it mildly, have a good secure data reputation.
That doesn’t mean that closed loop is automatically more secure, but keeping data in-house with its own closed loop transaction card in the country of origin, as JR East does for Mobile Suica, does mean that outside company access is tightly controlled. At the very least there is only one company in the country of origin to take the blame when something leaks, and only one place to plug it.
I was disappointed when Daring Fireball finally checked in on the Face ID face mask problem in the iPad Air w/Touch ID power button review. It summed up western tech journalist ignorance and indifference to a big problem that Face ID users in Asia have been dealing with since iPhone X day one. DF’s latest take on the issue in ‘Unlock With Apple Watch’ While Wearing a Face Mask Works in iOS 14.5 is even more disappointing, finally admitting that, “Prior to iOS 14.5, using a Face ID iPhone while wearing a face mask sucked.” This is pure ‘let’s not admit a problem until there’s a fix’ Apple apologia that is all too common on tech sites. DF hasn’t played straight or gotten it right when it comes to the big picture of Face ID. Then again the site is more into politics than tech these days.
I say this because there was certainly plenty of Apple arrogance when they blew off iPhone X Japanese users suffering from the notorious iPhone X NFC Suica problem. It didn’t matter because it was a iPhone problem…in Japan. It took me 3 exchanges to finally get a NFC problem free iPhone X revision B unit and I was one of the lucky ones. There were, and still are, plenty of iPhone X users fumbling in the dark. To this day iPhone X NFC problem search hits are the #1 hit on this site. Years later I am still outraged by Apple’s secrecy and denial of the issue. There was no excuse hiding the problem so that people would keep buying a defective top of the line product.
So no, I don’t think iOS 14.5 Unlock with Apple Watch is a solution for the Face ID face mask problem. It’s a stop gap until we get an ‘Apple finally figured it out’ iPhone that reviewers will gush over. And it performs like a stop gap: even in iOS 14.5 beta 2, one out of three Face ID with face mask attempts fails for me and performance is often sluggish, particularly glitchy when listening to Apple Music and using Apple Pay Suica transit.
iOS 14.5 Face ID sucks less for Apple Watch users, that’s all. People who make excuses for Apple’s hardware mistakes and missteps aren’t helping people make the right choice before plunking down hard earned money on expensive devices. Nothing is worse than having to live with somebody else’s mistake, except for having to live with somebody else’s deception.
A happy new year to everybody. When reading Junya Suzuki’s year end Apple Pay and contactless history in Japan article, I was irritated by its ‘rah rah for open loop’ ending that seemed to conclude EMV isn’t very slow and tap speed differences don’t really matter. After reading followup tweets with other IT journalists I realized that wasn’t his point at all. What Suzuki san was really saying was the total transit gate experience counts more than any particular technology package (MIFARE, FeliCa, EMV Open Loop, etc.).
Steve Jobs said the same thing about technology and products in the famous, “you have to start with the customer experience and work backwards to the technology,” 1997 WWDC video. In other words, the whole (the product) has to be larger than sum of the parts (the technology pieces that make up the product) to be a success. It’s all about how they integrate as a product into the larger whole ‘vision’ thing. JR East transit gates are great because the total experience is greater than sum of FeliCa, Suica, JREM reader and gate design technology parts added together.
There is also constant pressure to eliminate Japanese FeliCa contactless payment networks in favor EMV using the old bait and switch tactic of promoting a proprietary industry standard when the real end game is eliminating local competitors. These are issues that few journalists bother to analyze deeply and also what got Jack Ma in trouble when he blasted the Basel Accords, the traditional banking system, as an exclusive old men’s club that stifles innovation.
Power games in the world’s greatest free-for-all payments market I’ve said this many times but one of the great things about Japan many western journalists completely miss, is that Japan is the world best guinea pig test market. Especially useful for observing new payment trends at work. The market is a perfect not too big not too small size, super cohesive, and it has a long history of Osaifu Keitai mobile payments with a wide foundation of payment technologies encompassing FeliCa, EMV and QR. And there is lots of money sitting in bank accounts. This unique mix affords the careful observer a virtual front seat on the power games playing out right now after the introduction of QR based payment services like Line Pay, PayPay and dBarai (dPay).
When Docomo unveiled their dBarai app service it confused many users. What was the point of using code payments when Docomo already had dCard and the whole Mobile FeliCa iD network in place for promoting contactless payments? But it wasn’t long before Docomo linked the 2 payment services together. dBarai users can pay using 3 different backend payment choices: direct dCard billing, monthly Docomo billing, a rechargeable stored value dBarai account with cash recharge options via ATM or linked bank account.
From the user point of view it doesn’t matter when they pay with a Docomo code payment app tied and charged to their dCard on the backend, it’s the same monthly bill. But to Docomo it is very different: instead of using the iD or SMBC VISA/MC payment network on the front end, it’s the Docomo dBarai payment network. I suspect Docomo pays less of a transaction cut to the bank because they have the cash flow to assume some of the risk that banks usually assume in establied credit card network transactions. Docomo likely also leverages the daily transaction float. In short the AliPay model. The next logical step for Docomo dBarai will be P2P payments that leverage Docomo’s Mercari connection.
The value of code payments in dBarai isn’t the technology, it’s a expedient tool that Docomo leverages to circumvent the limitations and fee structure of banks and card networks to create their own flexible payment network. This wiggle room is the essential margin that drives QR Code payment empire cashbacks, point giveaways and new services. This is the epicenter of the cashless payment turf wars that pits new mobile payment players against established card and bank networks. And Apple is about to dump delicious chunk bait into this shark tank.
The Toyota Wallet multi-payment model In the Apple Pay 2020 wrap-up I mentioned Toyota Wallet as the most important trend: a Wallet app that lets users pay with a QR code or with NFC via an instant issue prepaid Apple Pay Wallet card. The Toyota Wallet iD/Mastercard has 2 Apple Pay device account numbers, one for the iD payment network and one for the Mastercard payment network. This is common for most Japanese issue payment cards on Apple Pay but it is less about NFC protocols (FeliCa, EMV) and all about dual payment network support in a single payment card. And it is not limited to Japan. In Australia there are dual payment Apple Pay cards that support both Mastercard and EFTPOS payment networks in a single card.
With Apple Pay Code Payments on the way, possibly with iOS 14.4, we have another option for multi-payment network cards: code payment and NFC payment. Apple Pay Code Payments are thought of as being only for AliPay and WeChat Pay support in China, but they are much more than that.
Apple Pay Code Payments gives mobile payment players the ability to move QR/barcode payments from an outside app and integrate them directly into an Apple Pay Wallet card. In the Toyota Wallet example below, Toyota could simply add another device account number for the QR Code payment network:
This might seem trivial but it’s important to remember some key differences of Wallet payment cards:
Direct side button Wallet activation with automatic Face/Touch ID authentication and payment at the reader.
Device payment transactions handled by the eSE without a network connection.
Ability to set a default main card for Apple Pay use.
In the Japan market Line Pay, PayPay, dBarai, Rakuten and all other new players will have the tools to create better services tightly integrated in a Apple Pay Wallet card. Docomo for example could incorporate dBarai into dCard with an additional device account number. Mix and match payment networking in one card.
In the payment network world where market share is all, card networks have held too much power for too long, exactly what Jack Ma was complaining about. I see competition as a good thing that encourages innovation and choice, mobile payments are doing that.
Looping back to the open loop beginning of this piece I think it makes sense now to realign the debate points away from focusing on technology (EMV vs FeliCa, NFC vs QR, etc.), i.e. things that can change and evolve, and focus on payment network turf wars, i.e. things that are hard to change until you see the battles lines clearly enough to create a better strategy and get where you want to go.
In the public transit arena it always comes down to this. Moving people quickly and safely by transit, managed wisely, is licensed cash flow from the fare gates. A transit company can keep control of that license to build something of greater long term value for the users and businesses of the transit card region, which can cover the nation. A transit company can give control away to someone else and let them take their cut, but just like Jack Ma pointed out before he disappeared, will there be innovation when going all in with traditional card and bank payment networks?
I still say a transit platform, especially in the mobile era of chaotic opportunity, is the best approach if a company wants to achieve the former: a system where the whole is greater than the sum of the parts. Start with the best customer experience you want to deliver and work backwards to the technology.
iOS 14.3 is the big coming out party for App Clips now that App Clip Codes are in place. Apple posted App Clip Code HIG documentation, App Clip Code Generation tools and more. There are lots of interesting tidbits and 3 ways to engage:
iPhone XS and later models with NFC reader mode: “The NFC-integrated variant uses an iPhone icon at its center that guides people to hold their device close to the App Clip Code.”
Pre iPhone XS models without NFC reader mode: “scan it using the NFC Tag Reader in Control Center.”
All iPhones using Camera app or Code Scanner: “scan-only variant uses a camera icon in its center to let people know to use the Camera app or the Code Scanner in Control Center to scan the App Clip Code.”
The guideline also states, “for NFC-integrated App Clip Codes, choose Type 5 NFC tags.” Type 5 tags are ISO 15693/NFC V used for library books, medical packaging, ski passes etc., but choose instead of use is a recommendation not a rule. Core NFC lists ISO7816, ISO15693, FeliCa, and MIFARE tag support. NFC Forum Tag definitions are:
So why is Apple going to all this trouble to market App Clip Codes? They could have done it all with QR Codes and NFC tags but App Clips are mini apps, App Store quality apps without the App Store. The branding of App Clip Codes defines a different and unique user experience. The NFC reader mode App Clip experience is slick ‘point and run’ fun, but the 2 for 1 ‘scan only or NFC embedded’ in one App Clip Code is practical: (1) physically accessible and close = NFC, (2) physically inaccessible or far away = code scan.
There will be many different App Clip user experiences running from general app launches to specific actions. Based on my Kitasando Coffee App Clip experience I would say, the quicker and more focused the App Clip experience, the more likely the user will use it again or go in for the full app. Apple’s HIG documentation emphasizes clarity and simplicity…good advice.
Prepaid transit smart cards are micro bank accounts on a card. What started as plastic in the mid 1990’s first transitioned to the cloud based mobile digital card era with Mobile Suica in 2006. Transit cards on mobile digital wallets are much more powerful and malleable than their plastic forebears, and occupy a coveted position in the mobile payments market. Credit card companies and banks spend enormous resources and effort to capture this transit fare business.
Background Many smart cards use FeliCa and MIFARE. The technology has been on the market since 1994 and one of the reasons for platform popularity and longevity are the rich application development environments they offer (Calypso is also popular but limited to transit applications).
Developers can design a card architecture as ‘smart’ (like Suica) or as ‘dumb’ (like iD) but they are all smart cards because they contain an IC chip. In Japan FeliCa powers not only company ID cards, but also transit cards (Suica, PASMO, etc.), bank payment cards (iD, QUICPay) and rechargeable prepaid eMoney cards that anybody can buy and recharge at convenience stores (WAON, nanaco, Edy). Mobile FeliCa has been in place since 2004.
Smart/Dumb card architecture depends on use case, system processing cost efficiency and need. In a transit fare system, a dumb card use case is slower centralized processing, like waiting at the store checkout for card verification to clear. A transit smart card use case is instant locally processed stored value to keep people moving through the gates because centralized processing isn’t up to the task. This is why transit cards have used the stored value local processing model…until now.
Open Loop 1.0 EMV contactless credit cards arrived on the payments scene starting in 2007 but uptake was slow. Since EMV contactless uses the same NFC A as MIFARE based transit cards, the big EMVCo members (VISA, Mastercard, American Express) came up with a great marketing idea: use EMV contactless credit cards as a transit card. Thus EMV open loop transit was born.
The current Oyster system, though very popular, is expensive and complex to administer. Contactless bank cards use existing technology, responsibility for issuing cards would lie with the banks rather than TfL, and the operating costs should be lower.
In 2017 there was a push to nudge people away from their Oyster cards and towards contactless. One announcement rang out all over London’s tube stations: Why not use your contactless bank card today? Never top up again, and it’s the same fare as Oyster.
Using bank cards in place of MIFARE Oyster cards accomplished that and because MIFARE was late to the mobile party TfL management decided decided their mobile strategy would be Apple Pay and Android Pay EMV card support. Meanwhile the bank card companies captured transaction fees from mundane transit fares at the gate, got the benefit of using the float instead of TfL, and got people into the habit of using credit cards for tiny purchase amounts. Our parents thought buying coffee with a credit card instead of small change was ridiculous because credit cards were reserved for ‘serious purchases’. Not anymore.
TfL Open Loop was judged a big success and got rave reviews from tech journalists around the world who hailed it as the future of transit ticketing: time to dump those proprietary transit smart cards and go all in with ‘open standard’ EMV open loop if you want the latest and greatest transit fare system. This gave transit agencies and the governments that run them the wrong idea that EMV is a cure all transit fare system solution.
1.0 shortcomings The problem is that EMV is not an open standard, it is owned and managed by the proprietary EMVCo that is wholly owned by the major credit card companies. EMV is a ‘one size fits all’ payments technology created for the needs of credit card companies and banks. It was never designed as a transit fare solution and will never evolve to incorporate transit needs. Experts agree:
A universal truth is that each transport market is highly unique. While EMV may be the best solution for some, the reality is that a standardized deployment of this model is not best suited to everyone.
There is no escaping the basic reality that EMV is a slow dumb smart card. It works well for what it was designed for: store purchases where card transaction latency is not a problem while the checkout terminal communicates with the bank system that has your account information.
Transit fare systems don’t have your bank account information on file, and there are limits with what the backend transit fare system can do when an anonymous bank card number appears on gate reader where long transaction latency is unacceptable. There are tradeoffs: the card gets verified but the transit bill gets settled long after the transit. This is why EMV open loop 1.0 only works for simple or flat fare structures. The result was a 2 layer fare system on London Oyster, Sydney Opal and Chicago Ventra:
Plastic and digital EMV open loop dumb card with basic fare transit for users with approved bank cards
Plastic transit MIFARE smart cards covering all fares including special fare discounts, commuter passes, etc., for everybody else
Oyster, Opal and Ventra wanted to add mobile support across the board but this meant supporting EMV and MIFARE. All of these are managed by Cubic Transportation Systems who worked with the bank card companies and came up with a new product to solve the dilemma: EMV closed loop transit dumb cards.
Open Loop 2.0 Apple Pay Ventra is this new EMV closed loop mobile transit card product, the launch gave us a first glimpse of the 3 layer fare system:
Plastic and digital EMV open loop dumb cards with basic fare transit for users with approved bank cards
Digital EMV closed loop dumb cards that cover regular fares and commute passes with special fares to be added later
Legacy plastic MIFARE transit cards for everybody else
It’s still a mixed EMV and MIFARE environment but MIFARE is limited to legacy plastic transit cards that can be bought with cash at station kiosks. But we can be sure that MIFARE will be phased out at some point.
The transit card is actually a EMV Mastercard prepaid debit card issued by 3rd party bank
The Mastercard as transit card is ‘closed loop’ and can only be used for transit and nothing else
The user must create an account to use the digital card. The transit account and prepaid/debit information is centralized and managed by the card issuer, nothing is stored value
All digital transit card management and housekeeping (adding or transferring cards, recharge, checking the balance, etc.) must be done in a separate app (Ventra App, Opal App, etc.), nothing can be done directly in Wallet
Express Transit is not part of the native EMV card architecture and has to be added as part of broader open loop support on the backend fare system by the operator and Apple, this is why Express Transit is missing in the initial test phase of digital Opal: the current Opal fare system does not support it
As this is an EMV bank card dressed up as a transit card, it is still limited by EMV card architecture and bank card network protocol. In place of local stored value it uses the bank card account model. On mobile this means all card housekeeping is in the app, users can’t create, transfer or recharge transit cards directly in Wallet like Suica, PASMO, SmarTrip or TAP. Direct reload/recharge in Wallet is not supported because the EMV format itself does not support local stored value. Apple Watch users can’t recharge EMV transit cards without the iPhone app. And like all cloud dependent services everything stops when networks goes down.
Mobile Suica does an excellent job of balancing and combining the strengths of local processed stored value performance, usability and reliability with the power of cloud attached services. It’s the gold standard of what a transit payment platform on mobile can achieve: leveraging transit card micro accounts to attach services and build business instead of giving it away to banks. Digital Opal testers familiar with Suica notice the difference and missing features:
Open Loop 3.0? For centralized cloud proponents, including Junya Suzuki, the ultimate dream is having one cloud based account using facial recognition for all payment and transit needs. Cubic and centralized account proponents are already looking to speed up London transit gates beyond slow EMV card technology with barrier free face recognition transit gates:
according to CUBIC…their ‘fastrack gateless gateline’ concept, which is currently conducting small user testing, eliminates physical barriers to form an extended corridor-like gateway that between 65 and 75 users can walk through in a minute, whilst their faces are being scanned and synced for payment with their smartphones
Personally I think the Ultra Wideband Touchless approach that leverages personal biometric authentication from the user’s smartphone secure enclave instead of having it hosted on somebody else’s cloud system is the safer and more practical way to go. Privacy advocates will agree.
The next installment of the Contactless Payment Turf Wars If nothing else closed loop EMV transit dumb cards reveal how bankrupt the ‘open loop is open’ argument really is. All Cubic and the card companies did was swap MIFARE for EMV, neither of which are open. And tap speeds are slower than ever with EMV the supermarket checkout protocol, so now we need Face ID transit gates to speed things up.
It’s fake debate. The real debate is online centralization for fare processing where everybody is forced to have a mobile account whether they need it or want it or not. And once everybody is forced to have an account to use transit the next step is forcing facial recognition.
The short term lesson here is that when transit agencies let banks and card companies run the transit fare concession they will never be free of them: there’s too much private money to be made off of running the backend services attached to public infrastructure. The long term lesson is that the mobile digital wallet solutions for Ventra, Opal, Oyster and OMNY are not about transit user convenience and all about convenience for misguided transit operators and their subcontractors.
Reader Questions Instead of answering questions or comments via Twitter etc., I’ll answer here for the benefit of all readers.
Q: Not being able to recharge within Apple Pay has nothing to do with EMV vs. stored value though, right? If anything, that should be easier (just move money between accounts).
A: It’s true that MIFARE stored value transit cards such as HOP Fastpass force users to recharge via the app. The point of the piece is that EMV transit card features are defined by the EMV format, bank card protocols and how it’s all implemented on digital wallet platforms. In short, bank issuers control the feature set on the backend. I have yet to see a recharge button on any EMV prepaid card in Apple Pay Wallet, I suspect we’ll always see most operations limited to bank issuer apps, even for transit.
C: The open loathing of banks and credit card companies is honestly quite nauseating (but understandable, considering what Japanese banks are like, apart from the credit card companies).
A: Banks and card companies have an important place in transit, but card company ‘one size solves all’ open loop marketing is misleading and profitable mischief. A good transit fare system is all about balance, flexibility and incorporating innovation such as mobile wallets, for the benefit of transit users and safe operations. Bank cards for example are a wonderfully convenient recharge backend, this is where they shine and add real value to the transit user experience.
But swapping out a native transit fare system with an outsourced bank card account system and tech package that the transit company doesn’t ‘own’ is asking for trouble. How much is the long term cost when it doesn’t solve everything as promised? Who really benefits: the transit user, the transit company, or the system partners and consultants?
These are the questions I think people should be asking and discussing. Hopefully my posts outline the issues clearly so people can discuss them to find the best fit long term solution based on local transit region conditions.
A: Yes the NSW Transport Minister calls it ‘cross-pollinating platforms”: NSW government set to announce the trial on Tuesday, which will begin mid-year and run until December. Commuters will be able to pay for Uber, Lime Bike, Ingogo Taxi or Manly Fast Ferry with their digital Opal card.