Tag: FeliCa

Final frontiers: How Suica 2.0 will solve the IC fare region barrier problem and much more

The Suica cross region problem, no thru transit going from the Suica area to the TOICA area for example, is a well known and criticized shortcoming of the Transit IC system. There has been some recent progress with cross region thru transit commuter passes but barriers remain for regular Suica use, a headache for both local residents and longer distance travelers. Despite all the fancy technology, the cheapest cross region thru transit fare choice is paper tickets.

The entire Suica/PASMO service region is huge but covers less than half of the entire JR East rail network

A lesser known Suica barrier remains on the JR East network: Suica service region gaps. Currently there are 3 Suica regions: Tokyo, Sendai and Niigata. There are also some curious gaps between them illustrated below:

The Tokyo~Sendai Suica Gap
The Tokyo~Niigata Suica Gap

Fortunately this is all about to change for the better.

Filling the Suica gaps
In 2019 JR East CEO Yuji Fukusawa said the company planned to have 100% Suica deployment by March 2022 but that didn’t happen. Why? Transit use killing COVID, the resulting red ink and redeployed resources are a big reason of course, but system development snags certainly contributed to the missed deadline. There was also a shift from a narrow focus of a lower cost Suica system to a wider focus of Suica 2 in 1, Cloud Suica and a cloud based central fare processing system. JR East’s Suica vision is evolving to a wider, transit service platform encompassing a range of technologies, with FeliCa as one component of a larger whole and flexible new system.

In October 2022 JR Central announced that TOICA is expanding to all JR Central lines and stations. The pressure is now on JR East to complete their delayed Suica rollout to all stations first. But there is something else: it’s an open secret that JR East hosts the TOICA system. JR Central would not make such a big TOICA commitment publicly unless JR East had a new system in place to facilitate the expansion. This new system, which I call Suica 2.0, starts operation on May 27 in the Tohoku region.

The launch brings Suica to 45 stations in the Akita, Aomori and Morioka regions but only 9 of these are fully automatic transit gate installations similar to what you find in Tokyo area stations (the same new QR equipped gates shown in the press announcement are installed in Yoyogi station). The rest, 36 in all, are Suica 2.0 validators. Performance is an obvious concern. Suica users are accustomed to the fastest transit gate fare processing speeds on the planet. Will Suica 2.0 performance satisfy an Suica 1.0 experienced customer base with high expectations? To understand how Suica 1.0 fare gates achieve speedy performance apart from FeliCa technology, we need to examine why Suica regions exist and how they relate to transit gate performance.


Suica stands for “Super Urban Intelligent CArd” (but there is also ‘IC’ in the name for integrated chip) and was designed for heavily used urban transit as a smart card recreation of visually inspected paper commuter passes. JNR (pre JR East) researchers wanted to eliminate the time it took urban commuters to pull their magnetic commuter pass out of a wallet or case and feed it into the ticket gate slot. This clogged up major station gates at rush hour. The researchers also wanted a centrally processed card system but the networks and processing power of that time could not deal with the rush hour traffic volume. So the Suica architecture was built around locally transit gate processed stored fare (SF) balance from the card. Instead of centrally processed payments, fares are processed at the station level and synced with the central server, said to be about 6 times a day.

Transit gates have very little memory, most of it dedicated to their main task of local processing Suica fare at the exit point. Low overhead is a necessity. They can’t hold massive fare tables, hot card lists, dead card lists and so on. Only the bare minimum information required to do the local processing job is periodically synced with the central server. Limiting fare processing to specific heavy use regions is a necessary strategy in keeping the local fare processing overhead low and speedy. This is why a Tokyo Suica/PASMO region transit exit gate only processes the fare from a Suica or PASMO (or any Transit IC card) that started the journey in the same region. It’s also the reason why Transit IC cards are generally limited to 200 km point to point trips in their respective local regions, though there are some interesting loopholes.

It’s the same situation writ large with different transit IC card regions. Border stations like Atami (Suica and TOICA) have 2 sets of exit gates: one for travelers from the Suica region, one for travelers from the TOICA region. Suica/TOICA cross region thru transit is limited to special cross region commuter passes and those are limited to specific cross region stations, again to keep the local processing overhead low.

Atami Station has 2 sets of gates for IC card travelers from difference regions.
The Gotemba line is another JR Central TOICA line that docks with JR East Suica at Kōzu Station.

It’s important to note however that IC coverage extensions to border stations with 2 sets of different gates and cross region commuter passes, are very recent 2021 developments. This is the JR Group companies laying the foundation to remove IC transit barriers in the near future. Because Suica 2.0 can process any and all Transit IC fare configurations, transit gate memory limits for local processing are no longer a concern. The barriers will come down when gate hardware•firmware is updated and Suica 2.0 cloud servers are in place.

Suica 1.0 local processing vs Suica 2.0 cloud processing
But transit gate performance is a concern. Does this mean that with all Suica fare processing migrating to the cloud users can kiss the good old speedy Suica gate experience goodbye? JR East says no. In fact they say Suica will get even faster with central server processing. Really? Recent comments from JR East suggest a 10ms network overhead. Suica 1.0 is rated at 200ms for fare processing though in reality the performance feels faster thanks to the large NFC RF hit area of Suica gate readers.

JR East New Suica System press release 2023-04-04

Conceptually, Suica 2.0 is simply going back to what the creators of Suica originally envisioned: centralized fare processing. Specifically the Suica fare processing hockey puck is moving from the station level to centralized cloud servers. The Suica card itself is exactly the same as it is now, the transit gates still handle all mutual authentication read~write functions. Hopefully Suica 2.0 performance will be just like it is now:

The original aims of Cloud Suica with lower costs and flexibility are still there, the JR East Suica 2.0 press release builds on those with emphasis on a distributed server processing system for both Suica service expansion (more stations and no region barriers) and service functions (all kinds of cloud linked services). Let’s examine the new kinds of services JR East is promising to deliver with Suica 2.0.

① Barrier Free Suica transit with no more region gaps. A main goal of Suica 2.0 and bigger than it might seem. Eki-Net Shinkansen eTickets are already ‘barrier free’ with Suica, through clever use of Shinkansen transit gates, but Ticketless Limited Express trains are stuck with Suica barriers such as the Tokyo to Sendai Hitachi and Tokiwa Limited Express trains. Suica users have long complained that service gaps forces them to travel with paper tickets, or they are forced to pay in cash at the exit gate because they tapped in with Suica in Tokyo and forgot the Suica barriers. This problem, and many more barrier Suica gap issues will be eliminated.

② Automated Fare Discounts Part 1: Commute Plan Lite. This is similar to the recently launched Off-Peak Commuter Passes, think of it as short term ‘commute plan lite’ with tons of options. You buy a discounted fare option for certain routes, use times or frequency and it’s automatically linked with your Suica. And unlike the current Suica App method, the items are added in the cloud, not written and stored on the card itself.

③ Automated Fare Discounts Part 2: Fare Discount Gift Coupons. In a similar vein, fare discount reward coupons for store purchases with Suica can be automatically gifted with a tap at the payment terminal. Kinda like the old free parking ticket with store purchase gimmick only far more useful.

④ Linked MaaS services. JR East has been experimenting with MaaS programs like RingoPass but linking MaaS services with Suica 1.0 is a real pain. Suica 2.0 should make bundling much easier, it’s also an opportunity to clean up the current mess of apps.

Reality check and missing pieces
Glossy JR East press releases are one thing but reading between the lines of the Suica Service Roadmap there are hints of missing pieces. Suica 2.0 is all about eliminating physical transit barriers but in the mobile app era there are lots of software barriers that need to be addressed too. Right now JR East online services are hosted in a bunch of apps that don’t fit together very well. It’s a maze of walled gardens: lots of service apps each with different accounts and login, making them work together is a real pain. The real problem is there is no one app to see and manage all the services and tickets attached or linked to your Suica.

A few things need to happen to make Suica 2.0 truly useful.

  • My JR East ID 2.0
  • Cloud savvy Suica App with plug-in services
    • The current version of Suica App lives a double life: one half pulls things off the Mobile Suica cloud, one half does local housekeeping attaching Commute Plans, Green Car Seat Tickets and recharges to Suica card. Meanwhile Shinkansen eTickets, MaaS and other online services live in different apps with different accounts IDs. Wouldn’t it be nice to have all these services living in one cloud savvy Suica App that shows and manages everything attached to your Suica? Absolutely yes please.
  • Local Processing Fail-Safe?
    • We all know that cloud and mobile services fail. Stuff happens. Safe railroad operation requires fail-safe design. Japanese IT journalists like to pooh-pooh FeliCa and Suica reliability, heaping praise on how ‘fail-safe’ the Transit for London open loop Oyster system is. But London transit doesn’t have to deal with major earthquakes, tsunami, typhoons, torrential rain and flooding, train communication cable arsonists, communication cable damaging trackside fire disasters, not to mention sarin gas and cable cutting terrorists. Japanese tend to take safety and security for granted but these infrastructure risks are very real. They have all happened. Suica 2.0 will be a highly centralized system, the higher the centralization, the higher the associated risks when it fails.

      Does Suica 2.0 have a fail-safe backup? Here’s a possible, and from emerging details, likely scenario. We all know programmers don’t like using a new API for mission-critical programs unless they have to. They like to stick with what they already have for compatibility with a smooth gradual transition strategy to the new API. Same for Suica 2.0. Automatic Suica transit gates could be upgraded with both the Suica 1.0 ‘Suica Region local processing API’ and the new Suica 2.0 ‘Region-Free central processing API’. If something goes wrong with the Suica 2.0 central servers, the exit gates switch to reliable local processing Suica 1.0 API mode to keep passengers moving with station level fare processing or perhaps regional level fare processing depending on the JR East distributed server setup. Long story short, If this backup is not in place we can expect this to happen.

Suica 2.0 rollout and the QR Eki-Net Connection
We’ll find out how well Suica 2.0 works on May 27…hopefully it will be a happy marriage of ‘truth in the card’ Suica Stored Fare balance + central fare processing. The important point is that all Transit IC card barriers will eventually go away when Suica 2.0 is deployed across the entire JR East system. People can travel anywhere on the transit IC network not having to think about barrier nonsense, just like paper tickets. Sounds great but when does it happen?

JR East says the Suica region barriers will drop by 2026, at the latest, when Suica 2.0 is rolled out across the entire JR East network. Suica 2.0 starts in Tohoku May 27, Tokyo gets the Suica 2.0 update this summer (2023), Sendai is next, followed by Niigata. At the same time all Suica gaps will be filled, all stations currently without Suica will be wired. We will find out if Suica 2.0 is really faster than Suica 1.0 but the 3 year rollout, roughly 1 year per current Suica region, certainly looks like a lot of system optimization work is padded into the schedule.

An interesting point here is that QR Eki-Net service starts in the very same Suica 2.0 Tohoku launch region which means that QR Eki-Net uses the same Suica 2.0 fare validation system. Suica 2.0 does QR too. When Suica 2.0 goes wide, so does QR. It’s one package with 2 parts as shown in the Suica Service Roadmap: the Suica 2.0 Platform and a ‘new’ (and unnamed) Ticketing system, which might be the venerable (and earthquake hardened) JR Group MARS system updated for the mobile transit era.

And when does seamless cross region IC transit for Suica, TOICA, et al. happen? Hopefully the JR Group is coordinating so that the Suica 2.0 rollout is mirrored by the other JR Group companies. The JR Central TOICA announcement certainly suggests so. Slight differences are already apparent: JR East prefers cloud connected Suica 2.0 validators at unmanned stations. JR Central and JR West prefer the bus style approach of having on board enter and exit validators for rural lines with unmanned stations. Either way is fine, just get it done as quickly as possible. Let the Transit IC barriers drop away into the past where they belong. Because with Suica 2.0 in place and barriers gone, the way is also cleared for fare capping, automated discounts, specialty ticketing and lots of new cloud based transit services.

This post was originally published 2023-02-27 and was reposted with the latest information from JR East on 2023-04-04.

Related post: Thoughts on Suica 2.0

Super Suica Cloud

A Japanese friend once told me that when Suica first came out, young people in Tokyo sent Suica cards to hometown families to use for coming to Tokyo. But parents and grandparents sent them back saying, “we can’t use them,” even when they could use them in their local area.

What they were really saying was, ‘Suica doesn’t get us the same transit perks we do using local paper tickets or mag stripe cards.’ There has long been a huge gap between transit services available in major cities which ‘don’t work’ in one way or another for those in outlying areas.

That’s the challenge facing the Japanese transit IC card system. Being able to use a Suica or ICOCA transit card in the sticks isn’t enough, local region services must be attached to make it worthwhile for people living outside major city areas. Transit IC has to evolve if it is going to be useful in the mobile era with proliferating smartphone payment apps vying for a piece of the national transit pie.

Now that we have a clearer vision of how Suica 2 in 1 Region Affiliate cards address this problem and how they are central to JR East’s MaaS strategy, it’s time to look at evolving JR East cloud services and how they fit into that strategy. There are a number of new cloud service parts that have come on line over the past year, or are coming soon…some visible, some not.

Taken together they comprise what I call ‘Super Suica Cloud’ following my earlier definition of Super Suica: a collection of mobile focused transit and payment infrastructure services that can be shared with or incorporate other company services, or be hosted by JR East for other companies. MaaS is an elastic term that holds a lot of flashy concepts, but I think JR East is aiming for something more low-key but practical, a Japanese Multimodal MaaS if you will.

The immediate concrete end-goals are service expansion with cost reduction; elimination of duplicate or proprietary dedicated infrastructure in favor of open internet cloud technology. With that in place the next goal is tight integration of transit payment services that work everywhere but also deliver tailored services for local regions. Let’s examine the parts.

Mobile Suica
People assume that Mobile Suica does everything mobile, but basically it’s a station kiosk in the sky. Put money in for a transit card, put money in for a recharge, or a commuter pass, a day pass, and so on. Issuing, recharging and managing Suica cards on mobile devices is what Mobile Suica was built for.

As the world’s first mobile transit card service, Mobile Suica has made a lot of progress over the years expanding support to include Android, Apple Pay and wearables, but the work isn’t done until any mobile device from anywhere can add Suica. And since Mobile Suica hosts Mobile PASMO (launched in 2021) and almost certainly the forthcoming Mobile ICOCA (coming early 2023), getting those on an equally wide digital wallet footing is just as important.

As the face of all things Suica on mobile devices, the smartphone app could have many more things plugging into it, like Hong Kong’s Octopus App. So far however, JR East has chosen, wisely in my opinion, to keep it limited to basic housekeeping, breaking out ticketing and MaaS functions to separate apps.

Suica Fare Processing • JESCA Cloud
This is the traditional Suica network system centerpiece that locally processes touch transit stored fare on station gates and touch e-Money payments in stores. The station gate fare side is getting a major new expansion on May 27, 2023 with a simplified cloud based Suica transit fare network rolling out to 44 Tohoku area JR East stations. This new Cloud Suica area closely aligns with recently launched Suica 2 in 1 Region Affiliate cards.

Cloud Suica 2023 additions (Orange) and Suica 2 in 1 cards below

The store payment side also has a simplified cloud based FeliCa payment network and a name: JESCA-Cloud. System details are vague but Cloud Suica transit fare and JESCA Cloud store payments appear to do the same thing: move transaction processing off local hardware and onto the cloud. Fast processing time is very important at transit gates, Suica tap times are the fastest out there. Those familiar with the Suica system say Cloud Suica will spilt it 50% local processing / 50% cloud processing. Dumber terminals, smarter cloud that still offers great Suica service…we hope.

One difference Cloud Suica has from a similar effort by JR West for ICOCA, is that Cloud Suica supports all the standard Suica features like commuter passes that cloud ICOCA does not. An interesting side note is that JR East hosts the processing for JR Central’s TOICA transit card network, they can certainly put the new Cloud Suica backend to good use expanding TOICA coverage in rural lines like the Minobu line.

ID Port
Comb through recent JR East press releases and you’ll find 3 service announcements built around ID PORT, a “cloud based ID verification solution” from JREM (JR EAST MECHATRONICS CO., LTD), the company that builds Suica infrastructure.

  • Maebashi City TOPIC MaaS service (November 2020): Local MaaS discount services provided by TOPIC that use Suica with My Number card address and age to verify eligibility:
Maebashi City TOPIC MaaS service links Suica and My Number Card to unlock services
(Japanese Railway Engineering January 2022, No.215)
  • Suica Smart-Lock (December 2021): registered Suica card access a variety of access services provided by ALLIGATE:
CyclunePedia bike parking
  • Mamorail (March 2020): a notification service for parents or caregivers, the first service based on ID-PORT. A registered Suica or PASMO (child) triggers a email notification when tapped at the transit gate with station and time info emailed to the parent’s/caregiver’s device.

All of the announcements have 3 components: a transit card (Suica), ID-PORT, 3rd party services attached to Suica (or PASMO) using ID-PORT as the system glue. Most of these are either in testing or ‘coming soon’. What is ID-PORT?

ID-PORT is explained on the JREM site, but the first public mention in an NTT Data PDF document from November 2020 is more revealing: “The Open MaaS Platform and supporting Multimodal MaaS”. The JR East Suica MaaS strategy is outlined with various scenarios that indicate ID-PORT is the JREM side with MaaS services on the NTT Data side. In other words a co-venture.

NTT Data Journal: A multi-model open MaaS platform

The job of ID-PORT is that it acts as the middle man ID verification glue linking a registered Suica (or similar Transit IC card) with various 3rd party services such as special ticketing, access and discounts.

The interesting thing about the ID-PORT and NTT Data MaaS platform reveal is that the timing coincides with Sony’s release of FeliCa Standard SD2, the next generation FeliCa architecture used for Suica 2 in 1 cards. One of the little discussed new SD2 features is ‘FeliCa Secure ID’. Here is Sony’s diagram of how it works.

Sony FeliCa Standard SD2 FeliCa Secure ID

Look familiar? Yep, ID-PORT sure looks like FeliCa Secure ID in action. The JREM ID-PORT page is more rounded out, incorporating non-FeliCa ID verification methods like QR and bio-authentication and many different services. ID-PORT has already been added to JESCA-Cloud and CardNet so that linked services are widely available on store payment terminals, not just Suica transit gates. In sum it represents MaaS and Account Based Ticketing in action with ID-PORT at the center.

JREM ID-PORT

MaaS and Account Based Ticketing in action
MaaS and Account Based Ticketing are the new hotness now that people realize open-loop doesn’t solve everything as banks and card companies want us to believe. Fare Payments Platform provider Masabi explains it this way:

Account Based Ticketing (ABT) shifts the fare collection system from being ‘card centric’, meaning the ticket holds the journey information and right to travel, and moves this to the back office. Moving the ticket information to the back office holds a number of benefits. It means passengers no longer need to buy a ticket or understand fares to travel and instead they use a secure token, typically either a contactless bank card, mobile phone or smartcard.

In this scenario FeliCa Secure ID is a secure token, ID-PORT is the secure token platform using the secure token to link ticketing and services together. That sounds nice but when will we see it in action? I think we already are.

Eki-Net Account Based Ticketing
As explained above, ABT attaches tickets from the cloud to a secure token, in this case Suica. By this definition Eki-Net Shinkansen eTickets represent JR East’s first step into ABT ticketing. Eki-Net uses registered accounts and credit cards purchase and attach eTickets to Suica. These eTickets do not use Suica prepaid stored fare nor is any eTicket information written to the Suica card, the eTicket system uses Suica as a secure token. JR Central smart EX is a similar ABT service and let’s not forget the web-only multi-lingual JR-East Train Reservation service that provides some ABT ticketing for inbound visitors.

Will JR East ABT implement the ‘no longer need to buy a ticket’ part of the Masabi ABT vision? I doubt it. Shinkansen eTickets are much lower ABT hurdle: lower passenger volume on far fewer transit gates than regular Suica gates. The complexity of interlocking non-Shinkansen Japanese transit systems and the vast array of fare schedules, such as higher paper fares vs cheaper IC fares, don’t easily straitjacket into an open-loop or ABT fare box, and it doesn’t fit the JR East business model.

Suica 2 in 1 region extras
There are services besides ticketing attached to a ‘secure token’ Suica. One of the important things easy to miss in the Suica 2 in 1 rollout are extra region features not available in regular Suica. Disability Suica cards for example. These are finally due to launch on Suica and PASMO cards in October 2022, but disability Suica 2 in 1 cards are already available in region affiliates.

There are also region affiliate transit points, one of the services that ID-PORT is advertising for JR East MaaS. Transit points all ‘just work’ automatically the same way. Points are earned from recharge and transit use and automatically used as transit fare. The user doesn’t do anything except tap the bus card reader. No registration, no setup. I wish JRE POINT had an option to work this way.

Transit points mimic the scheme of old regional transit mag strip card like Nishitetsu that gave ¥1,100 with a ¥1,000 recharge. Those features were popular (automatic simplicity in action again). PayPay used a similar strategy to quickly build a large customer base but pissed everybody off later as they got big and started changing bonus rate returns like used underwear. That won’t happen with Suica 2 in 1 cards as region transit points are locked in by local government subsidies to the region affiliates.

AOPASS transit points, different regions have different point returns but they all work the same way.

Streamlined simplicity, integration, regionality
Despite the la-la-land promise of MaaS and Account Based Ticketing, the ‘just works’ angle is crucial for people to actually use it. One of the current problems with Mobile Suica, Eki-Net, JRE POINT and the MaaS services JR East advertises is that is each service is a separate app + registration + attach cards process. This needs to be streamlined into a single simple JR East sign-on service option like Sign in with Apple that works across multiple services. I suspect ID-PORT is the glue between Mobile Suica and JRE POINT that keeps those registered services automatically linked even if the Suica ID number changes. A good sign because the JR East cloud needs a lot dynamic linking.

There is also the larger problem of integration outside of JR East, such as the current state of multiple online ticketing services; Eki-Net for JR East, EX for JR Central, Odekake-net for JR West, and so on. It would bet great to have a common app that plugs into every online ticketing service. At the very least JR Group companies need to integrate eTicketing the same way they have always integrated paper ticketing for one stop service in their own apps.

The bigger question is do Super Suica Cloud parts (ID-PORT / Mobile Suica / Cloud Suica) scale beyond JR East to include other JR Group companies (JR West, JR Central, etc.) and potential region affiliates nationwide? If increased services with reduced costs is their MaaS goal, JR East needs to step up to the plate and share. Infrastructure sharing with backend integration is the only way forward for all. Japanese transit has always excelled at physical interconnection, the cloud service side needs the same level of interconnectedness.

There are cultural angles too. Japanese have a passion for hunting down local perks, bargains and discounts. People complain about Eki-Net (deservedly) but they sure scramble and swamp the system getting those time limited discount eTickets like crazy pre-COVID era Black Friday midnight Christmas shopper crowds rushing into the store.

There is also the traditional cultural value of promoting local economies. As the saying goes, cities are only healthy in the long term when local economies are healthy too. If JR East is really serious about promoting regional MaaS, they’ve got to aggressively offer linked services that clearly promote regions. There are many region programs that visitors are simply not aware of. JR East can do a lot simply linking them to discount coupons, limited offer eTickets and such that appeal to the bargain hunter Japanese mind. The key is being creative and nimble like QR payment players.

The JR East MaaS region affiliate strategy was conceived long before the COVID crisis, yet COVID also presents a golden opportunity to invest in regions and promote working remotely. The world has changed and transit has to change too, the biggest risk is doing nothing, staying with the status quo. The emerging Japanese MaaS vision is unique in that Japan has a golden opportunity of leveraging the national Transit IC card standard into something new, taking it into the next era…if old rivalries and sectarian interests don’t get in the way and blow it, that is. Either way the next few years will be a very interesting time for Japanese transit.

Some related posts
Super Suica Reference
Suica 2 in 1 Region Affiliate List
Suica 2 in 1 mobile challenge

Bad Suica App reviews, real or urban legend?

Suica App user reviews are relentlessly bad, rip after rip of ‘this software sucks’. Never a good thing to say. Here’s the thing however, when you dig into the reviews most of them have little to do Suica App. It’s also really weird that many reviewers/users seem to think they need Suica App for using Suica at the transit gate. They don’t.

Why are people even using Suica App anyway? You don’t need it to add Suica to iPhone, you don’t need it to recharge Suica. All these things can be done in Wallet app. And now that people are working remotely, there is much less demand for purchasing commuter passes, the biggest reason for using Suica App in the first place. But there is one good reason for using Suica App: setting up Auto-Charge. Set that and you’ll never have to use Suica App.

There’s an important difference to know about Auto-Charge vs. regular recharge in Suica app and Wallet app: auto-charge is locally processed via the transit gate Suica NFC reader. It’s instantaneous and doesn’t care about your iPhone network connection.

Wallet and Suica app recharge are processed via the iPhone (or Apple Watch) network connection. Apple Pay talks with iCloud and Mobile Suica, the transaction is processed online and relayed back to Apple Pay, the recharge amount is added to Suica card. Many network hoops.

There is a message the Mobile Suica twitter account puts out regularly: make sure your smartphone has a robust network connection and don’t use free WiFi when recharging Suica or using Suica App. A bad WiFi connection fools Suica App users into thinking their iPhone is connected to the internet when it is not. This is a particular problem with carrier Wi-Fi SIM auto-connect that bypasses a solid 4G/5G connection and automatically connects to an extremely unstable or overloaded carrier WiFi instead. WiFi on trains and in stations is never reliable and should be turned off when using recharging Suica in Wallet or using Suica App.

Which brings us to an interesting Suica App user review titled “It’s a real urban legend” which explains all the crap talk about Mobile Suica boils down to people trying to recharge at rush hour in transit gate areas with a crapped out carrier or free WiFi connection…the perfect Suica App killer situation. The reviewer recommends “recharge in a calm place at calm time,” to which I heartily agree. Or better yet, ditch network recharge altogether and use Suica NFC Auto-Charge. It will never fail you.

Hidden Assumptions

Jonathan Seybold said it best in his Computer History Museum interview video, many arguments can be easily demolished by pulling out the hidden assumptions. In our attention span challenged social media era it’s all too easy to believe things at face value. Few people invest time and brain energy to analyze and question arguments to find and examine hidden assumptions.

A reader of this blog might come away thinking I am not a fan of open loop transit fare payments and despise EMV contactless and QR Code payment technology. That would be a mistake. I don’t hate them, everything has its place. I simply don’t agree with ubiquitous assumptions that EMV or QR or open loop are cure alls for every transit fare payment situation that they are praised to be…usually because ‘everybody uses’ bank issued contactless payment cards or smartphone payment QR apps. It’s a one size fits all mentality that blinds people from seeing hidden assumptions. It’s very important to see how all the pieces, seen and unseen, fit together. After all, transit companies and their users have to live with transit infrastructure choices for decades.

In a recent twitter thread Reece Martin thought it would be nice if Canada had a nationwide transit card. This is something Japan has had since 2013 when the Transit IC interoperability scheme was put in place that made the major transit IC cards compatible with each other, but they did this without changing the hardware. The various card architectures were left untouched and linked with system updates, a use-the-same-card backend solution. China on the other hand created a national transit card with the China T-Union • PBOC 2.0 standard that replaced all older transit cards with locally branded T-Union cards, a get-a-new-card hardware solution.

A nationwide Canadian transit card is a great idea but as Samual Muransky answered in the same thread, why bother with ‘obsolete’ dedicated transit cards when everybody uses EMV contactless bank cards and EMV is the new standard. Let’s examine some hidden assumptions at play here.

Assumption #1: Everybody has contactless credit/debit cards
The open assumption here that everybody has bank issued credit or debit payment cards is not the case and varies by country, demographics, age, etc. Most people in some countries do, but even so there will always be people who don’t. Transit cards always have the advantage of being available at station kiosks to anyone with cash.

Assumption #2: because of assumption #1 open loop (credit/debit cards) is better than closed loop (dedicated ticketing) for paying transit fare
The hidden assumption is that open loop covers everything but it does not. Specific transit services such as individual commuter passes, discounted fares for disabled/elderly/children are practically impossible to attach and use with bank payment cards. The best that transit systems and payment networks can do with open loop is fare capping or special discounts when applied universally. The age-old pay ‘x’ times and get one free concept. Open loop works best for occasional transit users.

The limitations of open loop on large complex transit systems like Transport for London is easy to see. Despite a long campaign to eliminate the venerable Oyster transit card and migrate users to EMV open loop, TfL threw in the towel and upgraded the Oyster system recently. To date TfL has not offered a digital version of the closed loop Oyster card. In short, dedicated transit cards will always be with us.

Assumption #3: EMV contactless is the NFC standard
The NFC Forum recognized long ago that credit card companies and transit companies have different needs and objectives. To that end the NCF Forum has 2 basic NFC standards, one for contactless payments (NFC A/B but only A is really used) and one for transit (NFC A-B-F). All NFC devices must support NFC A-B-F for NFC Forum certification.

Assumption #4: EMV contactless for transit is safe and secure
There are many hidden assumptions packed into the words ‘safe and secure’: not everybody agrees on what safe is and what level of security is secure. Things also change depending on the situation and the design. I have covered transit gate reader design in many other posts but recap some basics here.

Steve Jobs famously said that designing a product is a package of choices. I have often said that EMV contactless is supermarket checkout payment technology but that’s not a put down, it’s the truth of what EMVCo were aiming for when they grafted NFC-A to their EMV chip for contactless cards.

Because of wide deployment with no direct control, the original EMV contactless spec had a latency window to work reliably even with crappy network installations, and the slow speed has sometimes been cited as a security risk. NFC-A (MIFARE and EMV) transaction speeds are rated for a theoretical 250ms but are usually 500ms on open loop transit gates. Suica is always 200ms, often faster. The speed gap is due to gate reader design, the network lag of centralized processing vs local stored value processing, and the different RF communication distances for NFC-A and NFC-F. JR East presentation slides explain the transaction speed differences.

  • Japanese station gates are designed to be capable of 60 passengers per minute. To do this the conditions are:
    • Processing time of fare transaction has to be within 200ms
    • RF communication distance is 85mm for physical cards and smartphones
  • European station gates are designed to be capable of 30 passengers per minute:
    • The processing time takes 500ms
    • RF communication distance is 20mm for physical cards, 40mm for smartphones
016l
Presentation slide from the NFC Forum Japan meeting, July 2016
018l
Presentation slide from the NFC Forum Japan meeting, July 2016

The Suica transaction starts from the 85mm mark while MIFARE and EMV contactless cards start at the 20mm mark. Because of the greater RF communication distance Suica transactions start much earlier as the card travels toward the reader tap area. It you look closely at the 2nd slide you can see that smartphones have a slightly earlier EMV/MIFARE RF transaction starting at the 40mm mark (the 1.1A/m boundary) due to the larger smartphone antenna, physical EMV cards with smaller antennas are limited to 20mm. This is why smartphones seem faster than physical cards on NFC-A gates. Suica physical cards have a larger antenna and the same RF transaction distance as smartphones.

NFC-A transaction speed is slower because it has to be on top of the reader before it can start. This is also the limitation with optical based QR and bar codes, the transaction only starts when the smartphone screen is close enough to the reader for an error free scan. Transit gates using these technologies are not designed for smooth walk through flow.

The speed difference is clearly seen on the Nankai VISA Touch open loop gates: the transaction starts when the card is physically on top of the reader:

Here is Suica style transit gate for comparison:

One of the smart things Nankai is doing in the test phase (limited to a few key stations) is keeping EMV/QR gates separate from standard FeliCa gates. This is practical. Regular users go through the faster regular gates, the occasional open loop or QR users go through slower EMV/QR gates. Keeping different readers separate and clearly marked helps keep walk flow smooth and crowding down at busier stations. The Nankai program has been put on pause for another year due to the collapse of inbound travelers in the COVID pandemic. It’s a trial run as Osaka area transit gear up for an anticipated inbound travel boom in connection with Expo 2025, that may, or may not pan out.

The Nankai VISA Touch gates are designed for physical cards, Apple Pay works but without Express Transit. That’s a plus as Apple Pay EMV Express Transit on TfL and other open loop systems (OMNY) has come under scrutiny for a potential security risk with VISA cards that allows ‘scammers’ (in lab settings) to make non-transit charges to Apple Pay VISA cards via Express Mode, something that is not supposed to be possible.

Timur Yunusov, a senior security expert at Positive Technologies…said a lack of offline data authentication allows this exploit, even though there are EMVCo specifications covering these transactions.

“The only problem is that now big companies like MasterCard, Visa and AMEX don’t need to follow these standards when we talk about NFC payments – these companies diverged in the early 2010s, and everyone is now doing what they want here,” he said.

Security researcher: Flaw in Apple Pay, Samsung Pay and Google Pay makes fraud easy for thieves, Techepublic

In other words, Apple removing Apple Pay bio-authentication to promote EMV Express Mode for open loop transit puts Apple Pay at the mercy of lax card network payment operation practices who don’t follow their own rules. Not that it’s a real problem in the field but accidents do happen, such as this incident on Vancouver BC TransLink that a reader forwarded:

Just a moment ago, I nearly got dinged on my CC while sitting on a high seat near a door which is where one of the validators are located. The validator picked it up from the backside rather than the front side where the tap area is located. Also, somehow, my iPhone authorized the transaction when I only want to return to the home screen instead.

If the open-loop was implemented in a way where the card must be pre authorized before the card can be tapped at a validator, it wouldn’t get me in a situation where I need to deal with customer service to dispute some charges. Good thing this time, transaction was declined so nothing related to this charge showed up in my account.

Smartphone users be careful around the backside of Vancouver BC TransLink pole readers

And then there is data privacy, a far larger and long term problem is how open loop transit user data is stored and used. Apple always says they don’t know what Apple Pay users are doing as the data stays private. Fair enough, but the same doesn’t apply to the bank card companies. Open loop payment platforms in Japan, like stera transit, love to promote the customer data reporting services they provide to transit companies.

Plastic transit IC cards are basically private, they have a card number but nothing else. Credit/debit cards have your entire profile coming along with your open loop use and stera report a subset of this in their reports. And where is this data stored? In Japan, in Korea, somewhere else, wherever stera has a data sub-contractor? Payment transaction companies have been burned, repeatedly, when caught storing Japanese card transaction data outside of Japan…but they keep doing it again when everybody’s back is turned. This problem isn’t going away because of flimsy laws, lax industry practices and last but not least: personal data is a valuable commodity.

There is also the aspect of the price of cost effectiveness. When data processing stays in the country of origin, that means local employment and tax revenue feeds the national economy. When data processing goes outside the country, those are lost. This kind of discussion never takes place when it comes to transaction data processing, which it should, especially when publicly funded transit operators are involved.

Open loop is only part of a larger picture
Canadian transit would certainly benefit from a Japanese transit IC system approach with compatibility on the backend, or even the China T-Union approach of a national card spec that is locally branded but works everywhere.

To come back to the beginning, my point isn’t about slamming EMV or QR open loop transit, just the assumptions that they solve everything. They have their place in intelligently designed fare systems but only constitute part of the larger transit fare system picture. And as I have pointed out many times, card companies have little interest in improving the EMV standard for transit needs. They want to capture transit fare business without investing. The focus will always be the supermarket checkout lane that EMV was designed for.

There will always be a risk involved when ignoring the hidden assumptions of EMV open loop as a one size fits all solution. Dedicated transit cards will always be necessary. Every transit system is unique and deserves the best solution for the transit company and the riders they serve.

Related post: USA Transit Fare System Evolution

Mobile FeliCa evolution: FeliCa without the FeliCa chip

Mobile FeliCa is a Java Card applet on a secure element (SE). If the right applet is present with the right keys, and the CLF (contactless front-end) is configured to route Type F frames to the SE, you can enable Mobile FeliCa on any SE.

FeliCa Dude

FeliCa Dude did his usual public service of posting Mobile FeliCa details for the latest Pixel 6 devices. There wasn’t any change from Pixel 5, so no global NFC Pixel for inbound visitors. Nevertheless it’s a good opportunity to review some important recent developments that have taken place behind the scenes on the Android Mobile FeliCa side and examine some possible post Mobile FeliCa 4.1 scenarios. Things have changed a lot even if most users don’t notice any difference.

The chart outlines Mobile FeliCa on Google Pixel developments based on information from FeliCa Dude’s tweets.

Mobile FeliCa 4.0 (Pixel 4) freed Android device manufacturers from having to use embedded secure element + NFC chips from the FeliCa Networks supply chain. Any FAST certified secure element will do. Mobile FeliCa is pre-installed on all Pixel 4 and later models but only enabled for JP models. Other Android manufacturers selling Mobile FeliCa capable devices in Japan are likely doing the same. This development has resulted in a number of inexpensive Osaifu-Keitai SIM-Free smartphones released by Chinese manufacturers recently that are selling well. Hopefully it will have wider implications for inexpensive global NFC Android devices with pre-installed, and enabled, Mobile FeliCa. There are lots of people in Hong Kong who would buy one to use Octopus.

Mobile FeliCa 4.1 (Pixel 5/Pixel 6) introduced multiple secure element domains. This allows the device manufacturer to ‘own’ the eSE and load or delete Java Card applets. FeliCa Dude thinks that multiple secure element domains (MSED) might play a part in the MIC digital My Number Card due to launch on Osaifu Keitai devices in 2022 (now delayed until April 2023). My Number card uses NFC-B but MSED allows the Mobile FeliCa secure element to host it anyway, an interesting development.

Mobile FeliCa 4.2 or 5.0? The next version of Mobile FeliCa (MF) will hopefully support FeliCa SD2 next generation features that shipped in November 2020, features that power Suica 2 in 1 Region Affiliate Transit Cards launched in March 2022. These cards need to be on mobile for future MaaS service plans outlined by JR East which cannot happen until SD2 features are added.

The improvements in MF 4.1 certainly give Android device manufacturers the ability to update it over the air but don’t hold your breath. Standard industry practice to date has been ‘buy a new device to get new features’. Apple has been somewhat better in this regard: MIFARE support was added in iOS 12 for Student ID cards and iOS 15 fixed some Calypso bugs on ‌iPhone‌ XR/XS and ‌iPhone‌ SE.

An old FeliCa Dude Reddit post comment regarding Asus smartphones illustrates the pre-MF 4.0 situation: “any phone that lists ‘NFC’ compliance must support Type F (FeliCa), but as there is no Osaifu-Keitai secure element <aka Mobile FeliCa secure element>, you will be limited to reading and potentially charging physical cards: you cannot use the phone as a card itself.”

That was then, this is now.

People assume FeliCa support requires a FeliCa chip but this is not true. The evolution of hardware independent preinstalled Mobile FeliCa 4.x is very clear: the ‘FeliCa chip’ from Sony/FeliCa Networks requirement is long dead and gone. Manufacturers like Xiaomi may claim they make special models and add FeliCa chips just for the Japanese market, but that’s just marketing BS: they run Mobile FeliCa on the same NXP or Thales NFC chipsets they use everywhere.

Modern smartphones supporting FeliCa don’t have a FeliCa chip, everything from EMV to FeliCa and MIFARE runs on any GlobalPlatform certified secure element on any Android device. And in the case of Google Pixel 4 and later Mobile FeliCa is preinstalled in all models but disabled on non-JP models (some people have succeeded in activating Mobile FeliCa via rooting). This is likely the same scenario for other Android manufacturers who ship Mobile FeliCa capable devices in Japan as they source the same NFC chipsets from NXP or Thales that Google does.

Hopefully the sum of recent Mobile FeliCa developments, along with Garmin Suica, Fitbit Suica and WearOS Suica support, indicate that Mobile FeliCa Osaifu Keitai services will, eventually, become standard on Android devices as they have been on all iOS and watchOS devices since 2017.

Last updated 2023-04-01