Project Hina - replacement card readers for TfL rail estate and buses

[Edvid]

For the first time in a while this scheme has its own section in TfL board papers (link), to be discussed at next week's Programme & Investment Committee.

3.1 TfL's current ticket reader technology has served the network well for many years and has enabled the growth of contactless payment and modern ticketing across London. However, the reader estate is now operating beyond its original design life and relies on ageing technology that is becoming increasingly difficult to maintain, support and enhance. The current platform also operates under industry security derogations, which provide a short-term solution but cannot be relied upon indefinitely.

3.2 As the equipment has aged, TfL has become increasingly constrained in its ability to introduce enhancements and respond to future customer, operational and regulatory requirements. At the same time, spare component availability is gradually reducing as equipment is repaired, maintained and expanded across the network. While current stock levels are sufficient for the medium term, the long-term sustainability of the existing reader estate cannot be assured.

3.3 Project Hina was established to address these challenges through the development of a new generation of ticket readers. Beyond replacing ageing equipment, a new reader platform would create the technical foundation for future improvements to TfL's ticketing and payments ecosystem, supporting future concessionary travel products, greater flexibility in customer propositions and the longer-term evolution of Oyster and contactless ticketing.

3.4 The programme is therefore not simply a technology replacement initiative. It is a strategic investment in the future resilience of TfL's revenue collection infrastructure, helping to ensure the continued operation of a system that supports millions of customer journeys and the collection of fare revenue across the network every day.

4.1 Since the previous update to the Committee as part of the Technology Programme, in March 2026, Project Hina has continued to progress development activities associated with the future reader platform. Further information is included in the paper on Part 2 of the agenda.

Part 2 is exempt from public consumption, so I've no idea what the current project status is. 7 months ago it was "complete software development and start testing" by the end of March 2027.

In other P&IC papers for next week (see page 27) TfL state, "the cyber incident in September 2024 continues to have an impact on our ability to deliver some projects, notably those with software development or remote access dependencies". I'd wager it's described as a Project Hina delay cause in the exempt papers too.

 

[teaspoon]

Interesting it talks about 'developing' a new reader - does this mean speccing something bespoke for one of the big suppliers to supply and fit across the entire estate?

I've been quite impressed on visits to the Netherlands with NS's combined barcode/contactless readers - the ergonomics of it feel like they work a lot better than the retrofitted barcode readers that a lot of UK TOCs are using. Being able to tap in or out without breaking stride should be high up the list of requirements (and if you watch a gateline at, say, Glasgow Central, you'll see an awful lot of that not happening.)

 

[Gaelan]

I've been quite impressed on visits to the Netherlands with NS's combined barcode/contactless readers - the ergonomics of it feel like they work a lot better than the retrofitted barcode readers that a lot of UK TOCs are using.

These do have one major flaw: it's impossible to scan a pdf barcode on your phone without bringing up Apple/Google Pay. Tickets in dedicated ticketing/wallet apps work (because they can prevent Apple/Google Pay from coming up), but tickets in a pdf, an email, etc are a huge pain.

 

[teaspoon]

Granted. I suppose there's no way of knowing the percentage of barcodes being presented in PDFs versus in-app or mobile wallet.

 

[Edvid]

Interesting it talks about 'developing' a new reader - does this mean speccing something bespoke for one of the big suppliers to supply and fit across the entire estate?

As with most stuff TfL-fare-collection-related Cubic got the Hina contract. Even after losing the big contract to Indra their existing / new equipment will still be part of the system.

 

[redreni]

Granted. I suppose there's no way of knowing the percentage of barcodes being presented in PDFs versus in-app or mobile wallet.

If you walk around with NFC turned on, I suppose. You can always turn it off if you need to use a Dutch-style barcode scanner that also reads NFC and you're not using Google Wallet or similar. Many non-London buses are already like this.

I'm not sure which TfL project, if any, has barcode readers for London buses within its scope? I thought the point of installing barcode readers at Underground stations was to allow Travelcards to be issued as barcode tickets? If so, buses need to be able to scan the barcodes. It would be a shame to bring in new card readers for London Buses without considering this requirement.

As I say, there are solutions already in widespread use in this country where buses can scan barcode tickets and also accept contactless payments.

 

[Benjwri]

Many non-London buses are already like this.

The apps for these buses turn off express transit when a ticket is open

 

[redreni]

The apps for these buses turn off express transit when a ticket is open

Right, but that's not to say somebody hasn't got a PlusBus ticket as a PDF that they want to scan, in which case it's up to them to make sure their phone isn't configured to give away money to any appropriately configured reader that gets close to it.

 

[Zeremony]

I'm not sure which TfL project, if any, has barcode readers for London buses within its scope? I thought the point of installing barcode readers at Underground stations was to allow Travelcards to be issued as barcode tickets? If so, buses need to be able to scan the barcodes. It would be a shame to bring in new card readers for London Buses without considering this requirement.

I agree, all Travelcards include bus travel, so barcode readers on buses would be essential

 

[CyrusWuff]

The installation of barcode readers at (selected) Underground stations is for cross-London Single and Return tickets. Oyster/Smartcards (or Pay As You Go) are the replacement for magnetic stock for Travelcards.

 

[redreni]

The installation of barcode readers at (selected) Underground stations is for cross-London Single and Return tickets. Oyster/Smartcards (or Pay As You Go) are the replacement for magnetic stock for Travelcards.

Hmm.

Of those, only TOC Smartcards are suitable for Two Together or Network Railcard holders. Only certain sales channels will issue day Travelcards on a Smartcard, and if you want an Outboundary Super Off-Peak day Travelcard, you're screwed when CCST is withdrawn.

 

[MrJeeves]

Oyster/Smartcards (or Pay As You Go) are the replacement for magnetic stock for Travelcards.

Thank goodness for Oval to remove our Super Off-Peak Travelcards before an alternative for ITSO support needs to be found!

 

[lookapigeon]

I wonder how the future planned technology would enable barcode tickets to be read at speed - certainly from anecdotal evidence it seems that people faff a lot more when having barcoded tickets, whether it's selecting the right app/file, to getting the scan angle right to get the gate to accept the ticket.

Maybe people are just too absorbed in their phones to realise they are getting off and need to exit - you see the same thing when people get off the tube, completely plugged in, can't get their phone to operate the gates to exit with a backlog building up behind them.

I'm also curious as to how they would move away from the current tri-reader model, given the ubiquity of the hardware and how embedded it is in the design. Even when I went through a future Oval project enabled station, they had the tri-reader attached to a pole, but only accepting the SWR smartcard to tap out with.

I suppose also the other option for this would be to develop the backend software further to allow a concession association with a unique card ID, like you can do with an Oyster.
Can certainly see the original limits of the Oyster software as it was only ever designed with the scope of being a closed-loop fare system.

 

[Deerfold]

The apps for these buses turn off express transit when a ticket is open

Oh, if only.
I've had to have payments refunded taken when presenting a barcode.

 

[Adam Williams]

As with most stuff TfL-fare-collection-related Cubic got the Hina contract. Even after losing the big contract to Indra their existing / new equipment will still be part of the system.

Sigh. Does nobody ever learn?

 

[redreni]

I wonder how the future planned technology would enable barcode tickets to be read at speed - certainly from anecdotal evidence it seems that people faff a lot more when having barcoded tickets, whether it's selecting the right app/file, to getting the scan angle right to get the gate to accept the ticket.

Maybe people are just too absorbed in their phones to realise they are getting off and need to exit - you see the same thing when people get off the tube, completely plugged in, can't get their phone to operate the gates to exit with a backlog building up behind them.

It is my belief that people are too ready to have their phones requisitioned for various transactional purposes and are consequently trying to do too many different things with them within a short space of time or simultaneously. Displaying a barcode ticket in one app and having a digital Railcard available for inspection on another all while trying to hold a conversation and read a news article on the same device isn't necessarily always conducive to best flow.

I know I am an old fuddy duddy and I wouldn't mind if young people were simply better and more dextrous at multi tasking on their phones and switching quickly between apps, but it is my experience that they're not always particularly good at it and they cause delays.

 

[Haywain]

It is my belief that people are too ready to have their phones requisitioned for various transactional purposes and are consequently trying to do too many different things with them within a short space of time or simultaneously. Displaying a barcode ticket in one app and having a digital Railcard available for inspection on another all while trying to hold a conversation and read a news article on the same device isn't necessarily always conducive to best flow.

I know I am an old fuddy duddy and I wouldn't mind if young people were simply better and more dextrous at multi tasking on their phones and switching quickly between apps, but it is my experience that they're not always particularly good at it and they cause delays.

I disagree. The problem is fare collection hardware that is designed to perform several different functions in such a way that it is unable to distinguish which option should be chosen when several are available. It's simply poor design.

 

[CyrusWuff]

Sigh. Does nobody ever learn?

At a guess, the alternative would be for TfL to pull the plug on the Cubic Hina reader (which would likely trigger a hefty penalty payment to Cubic) and for Indra to start again from scratch, delaying the project more.

Given TfL currently exclusively use Cubic gates, that would likely cause Indra issues in terms of designing the interface between the new reader and the gate as I doubt Cubic will give Indra unfettered access to a gate so as to protect their intellectual property.