NFC in Public Transit

NFC in Public Transit: Mobile Ticketing and Open-Loop Payments

Transit is one of the highest-volume NFC deployment environments on the planet. A major city subway system may process 5 million NFC taps per day across thousands of gates. This guide covers the technical architecture of both proprietary closed-loop transit systems and the open-loop EMV contactless standard that is transforming urban ticketing.

System Architecture Overview

A transit NFC system consists of five layers:

Closed-Loop Systems

Closed-loop transit cards store value or passes directly on the card. The reader makes pass/fail decisions locally without a real-time back-office connection.

Technology choices:

FeliCa (Type 3 NFC) dominates Japanese and some Asian transit because its 212/424 kbit/s data rate and stateless authentication allow gate throughput at walking pace — critical for Tokyo station volumes. Most Western systems use NFC-A (ISO 14443-4) which achieves sufficient gate throughput at 106 kbit/s with optimised polling.

Open-Loop EMV Contactless

Open-loop transit uses the same contactless payment card or mobile wallet that the passenger uses for retail purchases. The transit operator becomes a merchant processing EMV contactless transactions.

Transaction flow:

1. Passenger taps card or phone at validator
2. Validator reads EMV application data (PPSE, SELECT AID, GPO)
3. Validator sends authorisation to acquiring bank
4. Bank confirms balance; gate opens
5. Back-office aggregates daily journeys for fare capping
6. Day's total settled as single bank transaction at midnight

Open-loop advantages: no card issuance infrastructure, immediate adoption with existing bank cards, no top-up friction. Disadvantages: ~300 ms bank authorisation latency (vs <100 ms for closed-loop offline validation), interchange fees, dependency on network connectivity.

Fare capping is the feature that makes open-loop equitable: the back-office caps daily or weekly spend at the equivalent of a day pass or weekly ticket, crediting back excess charges automatically. Transport for London's open-loop implementation (launched 2012) is the global reference.

Mobile NFC Ticketing

Smartphones use HCE (Host Card Emulation) or a hardware secure-element to emulate transit credentials.

HCE transit: The transit app stores a tokenised credential in software. The nfc-controller routes the reader's ISO 14443-4 APDU commands to the app's HCE service. Requires the phone to be awake; most Android implementations require screen-on or Express Mode to allow transactions with the screen off.

SE-based mobile: Apple Pay transit (in supported cities) stores a transit pass in the Secure Element of the iPhone. Express Transit mode allows taps without Face ID or screen wake — achieving parity with physical card tap speed. This is possible because the SE can respond to APDUs independently of the main processor.

Gate Throughput Engineering

Transit gates are engineered for 60–120 passengers per minute. NFC interaction budget:

Achieving this requires ISO 14443-4 transport layer optimisation: maximum frame size in ATS, SFGT (Start-up Frame Guard Time) minimised in the card's ATS response, and reader polling tuned to single-technology (no multi-tech poll loop in gate context).

NFC in Ride-Hailing and Micro-Mobility

Bike-share and scooter platforms use NFC-enabled locks. The rider taps their phone on the NFC reader embedded in the lock, which sends a Bluetooth unlock command over BLE after validating the NFC handshake. This pattern combines NFC's trusted proximity model with BLE's range for the actual unlock signal.

Fraud and Security

Transit fraud vectors and defences:

See also: NFC Payments How It Works | MIFARE Classic Security Analysis | NFC Relay Attack Explained | ISO 14443 Protocol Deep Dive