Contactless bank cards not safe

According to Katie Morley from the Telegraph:

Millions of passengers across Britain could be left stranded under plans for every bus in Britain to go cashless despite widespread security fears over contactless technology.

She goes on to say:

Which? said that despite nine in ten of its members owning a card with a contactless option, 40% of them had not used it for at least 12 months, opting instead to pay via chip-and-pin.

This is odd, because TfL has found that in London, c. 25% of journeys are now paid for using contactless bank cards rather than Oyster or paper tickets.

She also asserts:

Busses in Scotland and Northern cities such as Manchester, Leeds and Sheffield are looking to copy London busses which do not allow travellers to pay by cash onboard, according to plans outlined in a major report by the UK Cards Association, a body which represents the payments industry.

This kind of justifies her headline:

Millions of travellers could be stranded under plans for every bus in Britain to go “cashless”

Except that it is not true. Yes, our work at TfN has plans for rolling out modern smart ticketing technologies across the north of England. Yes, there are current plans for contactless payments cards to be accepted by the largest bus operators across the UK. But they have not committed to banishing cash from buses like London has.

And when London did stop accepting cash on buses, were millions stranded? No.

A funny thing happened on the way to the Forum

The Tomorrow’s Transactions Forum, that is. I arrived in good time (it’s always best to add on a few minutes to give yourself time to buy a ticket) for the 7.39 Flying Glacier to Waterloo via Misery and Degradation. 

 

Of course, Woking station has changed a lot since this picture was taken. There’s a Flying Coffee Bean on Platform 2 now.

Hurrah! When I got into the ticket hall I discovered that they have installed machines to allow you to pick up a ticket that you have purchased online. Great. I have the excellent The Trainline app on my iPhone and it is integrated beautifully with Apple Pay. So you look up the tickets you want, hit “Pay with Apple Pay”, thumb it and away you go. When you get to the station you just thumb it again and tap your iPhone on the machine, it shows you the list of tickets you have purchased, you choose the ones you want and hey presto your tickets pop out.

Brilliant.

Except it isn’t. The machines don’t work this way. You have to take a payment card with you and insert it into a slot and then type in a confirmation number that you were sent by e-mail. It’s actually quicker just to go to one of the other machines and buy your ticket in the usual way.

Joined Up Thinking (Not)

The new machine on the block.

I don’t get it. Surely the Apple Pay token used to buy the ticket can be matched to the Apple Pay token presented at the machine? You should only need to put the card in if you’re forgotten your phone or it is out of battery (and even then they should do it by implementing PARs properly).

Surely South West Trains, when they were planning these machines a few years ago, had at least heard about mobile phones even if they hadn’t actually seen any. And surely they had noticed that something was going with contactless technology? Perhaps one of the South West Train’s Executive Board had overhead their servants talking about “tapping” cards to ride the bus in London and never asked what they meant? Or did they just take it be a some new lingo below stairs, a slang term for writing out a cheque?

They must just have thought that contactless was something happening to other people.

This left me wondering if other train-like options are adopting contactless. I thought I’d give it a try at Heathrow, so I downloaded the Heathrow Express and tried a couple of times to buy a ticket to see if I could use Apple Pay, but the app asked me to scan in my credit card (presumably for some hello-1996 card-not-present transaction) then crashed, so I never to got to see it in action.

So much for joined-up thinking. The whole world is moving to contactless and mobile and the most up-to-date technology on the newest machines installed (I see they got rid of the machine for connecting by video link to customer service) is the decade-old chip and PIN reader. Come on.

Queue at Woking

OK, so sometimes there’s a bit of queue.

Why can’t we buy our tickets on our phones while riding the bus on the way and then just tap and collect when we get to the station?

The only improvement in the ticket purchasing experience at Woking station since it opened on 21st May 1838 — you still stand in line, they still take cash, they still give paper tickets — is that you no longer have to fill out a “reason to travel” form, and I wouldn’t put it past Theresa May to have these re-introduced in time for the next election.

Open-loop payment in transit

In my previous blog, I talked about the trends in smart ticketing systems leading to account-centric and open-loop payments which I want to consider in more detail in this blog.

‘Open-loop’ Payments

‘Open-loop’ is the term used for transit payment instruments which can also be used for generic payments outside of the transit system. By contrast, traditional transit payment smart cards (such as Oyster in London) have required customers to convert their money to transit-only funds stored in a transit account and used to pay for travel. Customers have been prepared to do this because of the benefits of speed of access to the transit system without having to stop to purchase tickets. However, the down-side is that they have to periodically load funds to their CTCs, such funds then being unavailable for other purposes unless a refund from the CTC is sought.

There are many payment instruments emerging, but the one which is currently most ubiquitously accepted by merchants is EMV, the smart debit and credit standard used by the large payment networks including MasterCard, Visa and American Express whose members are the banks. These Payment Schemes are currently lobbying the transit sector for their open-loop cards to be accepted as payment instruments within transit.

This approach has the obvious benefits that (i) fewer CTCs need to be issued by the transport operator, and (ii) customers can arrive in a city from anywhere in the world and travel using the bank cards in their pockets.

The leading example of open-loop payments in transit is London where all Oyster readers have accepted contactless EMV (cEMV) payment cards from across the globe since 2014. Other transit schemes already committed to rolling out acceptance of cEMV open-loop payments include the national OV-Chipkaart scheme in the Netherlands and MTA in New York.

UKCA Transit Framework Model

The country with the most practical experience of a large-scale open-loop payment transit deployment is the UK, and, in particular, Transport for London which now sees more than one million journeys per day using ‘contactless payment cards’, the generic term used to described all EMV-compliant contactless devices, including ApplePay.

The deployment in London was pioneering and occurred before any models existed for cEMV use in transit. Subsequently, a payment model framework has been developed by the UK Cards Association (UKCA) in conjunction with the transport industry. The Association’s members issue the vast majority of debit and credit cards in the UK.

UKCA has identified three models which are described below. Two of the models are ‘pay as you go’ (PAYG) and the third model assumes that a ‘travel right’ or PAYG balance has already been purchased.

The important point to understand is that UKCA models 1 and 2 exploit EMV payments and are therefore bound to EMV-issuing banks, which are communicated with via the Merchant Acquirer. These models are different from transit account-centric solutions which could accept pre-payment from any payment instrument, not just bank cards. Furthermore, the ‘token’ used to identify the passenger in the account-centric solutions can be either an open-loop (CPC) or a closed-loop (CTC) token.

This last point is important in relation to ‘unbanked’ passengers. It has been shown (e.g. Ventra in Chicago) that cEMV technology cards can be issued to the unbanked and used as smart ticketing ID tokens to access pre-purchased transit products.

Trends in smart ticketing

I’ve been thinking a lot about smart ticketing system trends in recent months. It is a subject of interest to a lot of our clients.

Card-centric ‘Closed-loop’ Systems

At the front-end of a smart ticketing system, the customer needs a way of allowing the system to determine whether to let him travel or not. Conventionally, this has been a ticket in the customer’s hand, allowing a reader to check the customer’s right to travel. When smart ticketing systems emerged in the ‘offline’ world of the 1990s, storing the ‘travel right’ on the smart card was seen as the only way to design the architecture. Such systems are ‘card-centric’ or ‘card-based’. In most cases, to-date, these are implemented with Contactless Transit Cards (CTCs); i.e. cards specific to ‘transit’ (with, perhaps, a few permitted ancillary uses). Because the CTCs operate in a closed environment (i.e. it is not ‘general’ payment instrument), these systems are termed ‘closed-loop’.

Even where system components (e.g. station gates) were online, they were unable to perform online travel authorisations fast enough to meet the entry/exit speed requirements of the Transit industry. This reinforced the need for the data (travel rights and value) to be stored on the smart cards, for access at the point of presentation. This architecture became a massively distributed data management problem. Furthermore, a lost card could mean a lost PAYG balance, or a lost travel right.

To accommodate this architecture, some Payment Schemes (e.g. MasterCard and Visa) published specifications for Contactless Payment Cards (CPCs) embodying data storage areas in the card, which could potentially be used to store transit tickets; sometimes called ‘Transit Data Areas’. However, the Payment Schemes have not made availability of such data storage mandatory, and issuers have not yet issued CPCs to these specifications, widely. The fact that a transit operator will currently see few of these cards and therefore cannot rely on data being present is a severe inhibitor to the use of CPCs with this ticketing functionality.

Implementation of TDA would probably need to be an international trend before being worth trying to exploit it. (For example, the UK Cards Association (UKCA) has said that UK banks will never issue CPCs with this functionality on them.)

Shift to Account-centric Systems

In an increasingly on-line world, we are seeing a shift toward account-centric systems; where customer accounts are held in a back-office, and a token to securely identify the relevant account for the travel right is stored ‘in the cloud’. The result is an architecture that is much easier to manage, maintain and extend. It becomes easier to know your customer and make new offers, such as ‘loyalty’. This approach will also accommodate potential future developments in technologies used to identify customers/accounts, such as beacons and biometrics, and is therefore more future-proofed than a card-centric approach. However, it can be more difficult to be responsive at the point of use, compared with card-based architectures. Careful design of the system is needed to ensure that customer passage is not impeded.

Such account-centric schemes can be either:

  • Closed-loop: the card is a CTC (i.e. it is transit-scheme-specific), however, the balance and status information is maintained at the back-office (where the fare calculation are also performed),
  • Open-loop: the card is a CPC (i.e. it is a general payment instrument).

The use of a CTC in an account-centric environment may seem strange, since the advantage of the CTC (everything available at the point of presentation) seems to be lost when referencing the account at the back-office. However, using a CTC in such an environment can be an economically-attractive first step in migrating from a card-centric scheme to an account-centric scheme. This approach permits the transition to occur without the need to upgrade the readers in the field to accommodate a new Payment Scheme card. Hence ‘transition to account-based’ can be achieved prior to, and independently from ‘introduction of a new card-type’. This may be considered desirable, in that, the problems of each change will occur separately, and can be managed independently.

Smart Ticketing Solution Taxonomy

Taxonomy of smart ticketing solutions

I’ve produced a ‘taxonomy’ matrix which groups smart ticketing solutions:

  • On the ‘Payment Type’ axis there are open-loop and closed-loop payment (i.e. cEMV which works most anywhere vs transit-only balance).
  • On the ‘Centricity’ axis, there are:
    • Customer Medium (which includes cards, phones and ‘wearables’ such as watches);
    • Transit accounts in back-office;
    • Payment Scheme with connection to the EMV infrastructure via a Merchant Acquirer.

In general, cEMV cards cannot be written to by the transit reader. There is a specification for the Transit Data Area in EMV , but it has not gained any significant usage. Equally, Payment-Scheme-centric solutions cannot use transit cards. Hence two cells are greyed out below.

In my next blog, I will look in more detail at Open-loop payments in transit and our work at TfL leading to the UKCA models since this is what most of our transit clients are asking us about from Transport for the North in the UK to NZTTL in New Zealand.

Our live five for 2016

Well, however superficial they might be, there’s no doubting the popularity of the end of year roundup and predictions for the coming year. We don’t argue with the box office down at CHYP End, so here we go with our now-traditional “live five” transaction technology trends for 2016. But, first of all, I think we need to take a look at how we did with our live five for 2015 before you can decide whether to pay any attention at all to this live five! Let’s see how we did!

  1. In-App Payments. This was a good shout. The discussions around payments becoming invisible and vanishing into apps are now common currency and the trend toward retailers wanting to shift payments inside their app so that they can deliver the best service to customers was well established before Walmart Pay came on the scene.

    Target is reportedly developing a mobile wallet that customers can use to pay for goods with their smartphones, according to three unnamed sources who spoke to Reuters… also confirmed that Kohl’s plans to release a payment service called Kohl’s Pay in the fall of 2016 that would be part of the retailer’s existing app.

    [From Target thinks it has enough customer trust to get into the mobile wallet game – Quartz]

    It seems natural to me that retailers will take advantage of mobile technology to get closer to customers and there are plenty of opportunities to provide services into their apps. Just recently, McKinsey called in-app “the new battleground” for shopping (McKinsey on Payments, October 2015) and noted that what they called “repetitive interaction” (what we call “relationship” in the Consult Hyperion “3Rs” model) is way to generate more value for customers.

  2. The Three Party Party. I think we scored a bullseye here, with ChasePay the surprise announcement of Money2020. We knew nothing about the ChasePay plans when we predicted big moves away from the traditional four-party model in retail payments, we based the prediction on work that had been underway for some other clients, particularly in the field of mobile options for domestic schemes.

    Gordon Smith, CEO of Consumer & Community Banking at JPMC Chase Cards, introduced Chase Pay as a mobile payments solution that provides a “true omnichannel” payments experience – in-store, in-app and online purchases – and built the case for why he believes Chase Pay will be a formidable force in payments… Chase Pay will not support NFC.

    [From Chase Pay Mobile Wallet Launches — With MCX As A Partner]

    In a world of mobile phones there just isn’t the same pressure for global solutions as there has been in the past and if you look around the world you can see a clear resurgence in bank-centric three-party schemes: Russia, Turkey, India and so on.

  3. Privacy as a Proposition. This didn’t develop as we’d expected, despite the increased pressure because of massive, continuous and damaging data breaches throughout the year. I’m not entirely sure why (e.g.) banks didn’t develop more privacy-centric propositions — a good example being tokens for adult services — but I suppose they have decided that there are other more strategically important parts of the identity business to focus on.
  4. Blockchain. Wow, Another bullseye. It was definitely the year of the replicated distributed shared ledger formerly known as the blockchain, although I must agree with this commentator on the Innotribe conference that it is not wholly clear to many people exactly why:

    In front of a large group of finance professionals, “blockchain experts” and audience alike agreed that blockchains were the wave of the future – despite a complete lack of consensus on what a blockchain is. Or even why one is needed.

    [From Why Big Banks Got Blockchains Wrong in 2015 – CoinDesk]

    We are a small company, and statistically insignificant in the great sea of IT spending. But the nature of our work makes us a useful weathervane for clients and I can tell you that we have had way more blockchain-specific consulting work this year than even a reckless hypemerchant like me would have predicted (and not only in financial services). Luckily for us, being early into this space allowed us time to develop a more general approach to thinking about shared ledgers from a business perspective that has worked well in helping our customers to evolve their positions.

  5. ID for the Internet of Things. I think we can claim that there is widespread recognition of the problem now and a first few steps towards a solution with the major chip platforms working to bring secure hardware (e.g., Intel’s Enhanced Privacy ID) to devices. Given some of the work that Consult Hyperion has been doing for clients in this area, I think I might go so far as to say that I finished the year more optimistic about the possibilities here although I still think we have a long, long way to go to make the thingternet as safe and productive space.

Having looked back, then, and established that our live five does indeed have some value for organisations looking to establish their strategic priorities, I’ve had a look at the projects that Consult Hyperion has been working on around the world and identified what I think are five key transaction technology trends for our clients in the coming year.

Deep Purple

Now, of course, I’m playing a game here. I don’t want to give away any of the really cool stuff that our teams are working on for clients in business, NGO and government sectors right now, but I do want to make predictions that I already sort-of know will come true because we are already working with the technologies so that I can look clever! So, with that in mind, here’s the new live five that you can expect to see organisations focus on in the coming year:

  1. Amazonisation. Now that everyone is agreed that APIs are the right away to deliver services into the marketplace, some organisations are going further and structuring themselves around APIs, helping not only external customers but internal functions to benefit from a more flexible and functional mechanism for co-operating. Now, in 2016 it will be PSD2 that will undoubtedly spur many of our clients to develop strategies for either providing or consuming bank APIs.

    Successful internet giants, like Salesforce, Amazon, Google, Twitter, and Facebook, have been active to offer APIs to third parties. Salesforce has earned more than half of its revenue through APIs, not from its own user interface. Twitter, Netflix, and Google handle billions of transactions through APIs daily. And we can say Amazon has been a pioneer with open APIs – the online retail giant already had an Amazon Store API back in the early 2000’s.

    [From APIs – the core of a new economy, really? : DisruptiveViews]

    It is really interesting to try and think what this kind of restructuring around APIs will be mean for financial services organisations, and I’m looking forward to working with our teams to find ideas for transforming their businesses.

  2. Mobile ID and Authentication. The focus for solving “identity problems” is shifting to the mobile device. Whether it is in payments, ticketing, inclusion or in straight identity applications, the mobile phone will be the mass market solution to the problems of recognition, relationships and reputation (those “3Rs” again). We have said repeatedly that a model based on strong authentication against a local revocable token held in tamper-resistant memory deliver the right platform. The announcement of Google’s scheme for replacing passwords with mobile phones is sure to be followed by a similar announcement of an “Apple Smart ID” or something similar, the mobile operator’s Mobile ID Connect service is being deployed and I’m sure that other schemes will be launched.
  3. EMV Next Generation. You might be thinking that it’s all quiet on the EMV front now that the US roll-out is under way, but some of our clients have started to develop their strategies and tactics around the EMV Next Generation specifications and I expect to see momentum grow throughout the year. There are, as far as I can see, three strands to strategy for them to consider: first is that we are reaching the limits of the cryptography currently employed and must look at replacing it long before it becomes a vulnerability in the marketplace, second is that there is pressure for value-added merchant propositions (e.g., coupons, loyalty and so on) within the standard and the third is that “legacy” EMV (which still hasn’t been fully rolled out in the US) will be with us for another fifteen years or so. For each organisation, looking at the drivers and blocks around each of these is central to its retail payment strategy.
  4. The Push for Push. In the UK, the faster payment service (FPS), is well established, has been fantastically successful and has enabled things on top of it already, like Pingit and Paym and so on, and there’s more to come. That is also happening in other countries have started to go down that route. The one great exception was always the US because the Federal Reserve has no regulatory mandate to make the banks there implement an instant payment system, and so we all thought it would be some time before instant payments appeared in the US. Actually, however, in the last couple of months there has been raft of announcements coming out of the US: The Clearing House (TCH) is working with VocaLink, Dwolla are experimenting with APIs, NACHA is moving to same day and so on. Even in the US instant payments will feature heavily across the next year and as they spread they will shift industry focus to push payments. As Tom Noyes said earlier this month,

    As I’ve stated before, no engineer would design a payment system to operate the way we do today (see Push Payments).

    [From Changing Economics of Payments – Noyes Payments Blog]

    I agree. There are good reasons for thinking that pull payments are a hack to get around the dumb payment networks of the past and, personally, I see push dominating in the long run.

  5. Transparency as the “win-win-win. Given the considerable confusion about what shared ledgers are, how they work and what the impact of different architectural choices on business models is, you might be forgiven for thinking that the technology will stall. But we think that there has been a focus on the wrong drivers. Blockchains are only one form of shared ledger and they aren’t automatically cheaper or even more efficient than (for example) databases. Shared ledgers do, however, have a couple of interesting characteristics that will reshape some markets. One of them is transparency and, in the short term, this can be the core of a win-win-win involving customers, institutions and regulators.

I’m naturally very curious what you all think about these choices so please do not be shy in the comments below! Along with our other consultants, I’ll be speaking on these themes at a number of events across the coming year and really look forward to discussing them with you.

Wombling free

You all watch Only Connect, right? I was amazed to see a question I knew the answer to due to our nerdiness in specifying the software for Transport for London’s Tri-reader that works with Oyster, contactless EMV and even ITSO.

The question was, what do the following have in common (see image)?

Only Connect TfL Underground

Four clues are revealed one by one. The sooner you supply the link, the more points you get. All four were revealed and no-one knew the answer.  As the image shows, London Underground gate error codes, was the answer. COME ON GUYS!

Technology roadmapping

In 2005 when we performed an update to our biometrics and identification technology roadmap for the UK police, body odour was a ‘technology’ that was looking interesting, but not mature enough. The idea was that if dogs can do it, why might it not be automated. And identical twins have a unique smell, apparently.

Police biometrics techs 2005

We identified policing applications of biometrics and identification technologies, one of which was automated identification of police officers. At that time, each Force had it’s own warrant cards (so there was no confidence in what they should look like) and there was no way of using them with machines to authenticate the cardholder as an ‘officer of the lieu’ and grant them access to building and machines.

Automated identification of police officers

We foresaw the benefits of a national police warrant smart card and were retained to specify the standard which is used today across the Forces.

More recently, the technology roadmapping I have been involved in has been for transport applications. As well as the usual technologies in this space (mobile apps with 2-D bar-code; contactless payment cards; NFC mobile devices emulating contactless cards) we have also been thinking about more interesting stuff. Such as USB contactless readers used at home for fulfilment of tickets or value direct to smart cards. Or mobile devices with Bluetooth Low Energy (BLE) interacting with beacons waking the app up to present the appropriate form of ticket for the time and place. And, or course, NFC devices with the Host Card Emulation (HCE) API allowing them to escape the tyranny of the Secure Element (SE) and Trusted Service Managers (TSMs).

You’ll not be surprised to hear that we are still tracking the technology of person identification via body odour. I look forward to being sniffed by a transit gate before being allowed onto the train platform in the near future.

Managing the join

Since 2008 we have been working with Transport for London to allow contactless payment cards (CPCs) to be accepted wherever Oyster cards are accepted. This was first achieved in December 2012 on buses (which are flat fare in London) using a retail payment model. The next step was to introduce a distance-based payment model to allow all the other transport modes to be included which have zoned fares. This was launched in September 2014.

All the convenience of Oyster (such as not having to queue to buy tickets and fares capping so that you do not need to understand the fares structure) but using a card already in your pocket. Whether you are local or just visiting. But this is for London only. And the solution is based on a risk model that knows the maximum charge for a single journey is not very much. The delivery of such a solution relies on the intelligence migrating from the card to the back office. TfL’s back office to allow acceptance of CPCs for transit is complex and took several years to build.

In early 2012 the TfL payment and security models for contactless payment card acceptance in London where pretty much complete and the rest was ‘mere implementation’. TfL asked us to help them consider how it might work if they offered their back office as a service to transport operators outside of London. These might be in the UK, or potentially anywhere in the world (though different payment model are likely to apply outside of the UK). We discussed at length the notion of using your ‘card as a token’, be it a payment card, Oyster, ITSO or, potentially, other secure contactless tokens. Eventually, the ideas were parked to allow TfL to focus on delivery of the system for London in conditions of extreme austerity.

Meanwhile, we were hired by the SEFT (South East Flexible Ticketing) programme to specify the rail validators that could accept ITSO as well as contactless payment cards. At the time, Transport for Greater Manchester was just starting to procure such a back office for their region. We pointed out to SEFT that this CPC back-office-for-tranist stuff is complex and not standardised. It was therefore decided to not include any interfaces to the payment card back office at that time and the SEFT validator specification was ‘mothballed’ for the time being.

Spare a thought for the traveller buying long-distance rail tickets that include travel within the London area. London supports Oyster and CPCs (and a few specific train operator ITSO products, but not many at this point in time). Some train operating companies are implementing 2-D barcode, and some are trying ITSO. But the only technology commonly read across the UK currently and for the foreseeable future is the cardboard ticket with magnetic stripe. Basically, any ticketing innovation is scuppered at the boundary between London and the rest of the UK. This problem is what our friends at Trainline call ‘managing the join’.

Hopes for contactless payment being accepted for transit outside of London were recently dashed with the announcement that Transport for Greater Manchester has sacked their back office supplier. And anyway, it has been speculated that CPCs only work within London because London is a special case and it could not work anywhere else because the operators will not co-operate and/or the fares are too high for the risk model to work.

Enter the cavalry in the form of the UK Cards Association. They are leading a project with the Department for Transport and others (including representing train and bus operators) to develop a contactless transit framework for the UK by the end of 2015. The project to date has identified three contactless transit models:

  • Standard retail model for transit: pay as you go model with a known fare, for buses and trams (like TfL bus retail model).
  • Contactless for transit model: pay as you go model where the fare is aggregated at the end of the day or journey leg, for multi-mode operators (like TfL distance-based model).
  • Card as Authority to Travel (CAATT) model: pre-purchase model.

This last model could be just what we need for ‘card as a token’ or ‘managing the join’ as we have called it. The idea is the customer:

  1. Purchases their ticket online and associates it with their CPC.
  2. Can view their purchase on their statement.
  3. Uses their CPC as their ticket on a train.

Watch this space …

Secure-enough transit mobile ticketing

ITSO with HCE app and Handy

This year, I’ve been mostly working on ITSO ticketing in NFC mobiles devices with HCE and without secure elements. ITSO is the e-ticketing specification supported by the Department for Transport in the UK.

So far, high level design, risk analysis and proof of concept have been carried out by our team. Suitable controls are being developed. We are heading towards a trial this year on live schemes. More details to follow in next few weeks. But for now, see page 10 of the latest ITSO News.

 

Bring Your Own Token

I’ve just attended the Smartex Transport Card Forum (TCF) 2014 annual two-day event where I was presenting. The first day was about requirements and we heard from Passenger Focus that customer convenience is high on the list. Over and over we heard others repeating that convenience is a key requirement. At the end of day 1 I took a stroll through Oxford for half an hour and then caught a bus to my hotel. As the bus approached, I realised that I might be in trouble. Three or four smart card emblems were on display in the window, none of which I recognised. I boarded the bus and asked whether they accept cash. “Yes,” was the reply. I tendered my Scottish £10 note. “But not those,” he said. “We used to, but our systems no longer accept them. The other bus company might take them.”

Not having the energy to argue, and feeling a very inconvenienced customer indeed, I got off and continued to walk until I found a taxi happy to take my £10. In fact, none of the taxi drivers I used over the last two days batted an eyelid at the dazzling array of Scottish notes I tendered. I joked with one of them that no-one knows what Scottish notes should look like, so I make them myself at home in Edinburgh. He asked if he could borrow the machine, but he was not inclined to refuse my money.

The next day, the morning started with presentations from suppliers about how they are starting to roll out remote download of smart tickets to ITSO cards. If you find one of the suppliers’s terminals (or you have registered and have one of their contactless readers installed on your PC) and you have obtained the right operator’s card, you can have the ‘convenience’ of not having to buy or collect a ticket immediately before boarding. Basically, this is aimed at the frequent traveller in restricted geographical areas and seems to deliver Oyster-like convenience. And in addition, this could be extended to long-distance rail, something not offered by Oyster.

Right now, Transport for London (TfL) offers what I would term Choose Your Own Token (CYOT). You can travel anywhere on the Oyster network (bus and all forms of rail: tube, train, DLR, tram) using either an Oyster card or a contactless payment card. You don’t need to worry how much the journey costs and you are guaranteed to be charged the best fare and that will be capped after a certain amount of travel within a certain time period. None of the details of which I need to know; you simply trust TfL to always give you the best deal.

Now that’s what I call convenience — unless you neither have an Oyster card nor a contactless payment card. Or you happen to be outside of London, say, in Oxford, trying to board a bus with Scottish money. So, no, we are not really close to general customer convenience.

There are examples of existing tokens already being used to access multiple services, which include:

  • Utah ski pass being accepted on local buses during the validity period of the ski pass. The Super Pass includes round-trip travel on UTA ski buses and TRAX light rail. To gain free access on UTA Ski Buses and TRAX light rail it is necessary to both tap in and tap out with the Super Pass card.
  • Larger cities in Estonia allow residents to purchase “virtual” transportation tickets linked to their ID cards. Period tickets can be bought at public kiosks. Customers have the option of e-mail or SMS notification when the ticket is about to expire, or of setting up automatic renewal. To use the virtual ticket, customers must carry their ID card with them whenever they use public transport. During a routine ticket check, users are asked to present their ID card, which is then inserted into a special device. Ticket information is stored in a central database, not on the ID card itself. Thus, to order a ticket, it is not necessary to have an ID-card reader.
  • British Columbian driving licence being used to access various government services such as health.
  • In the next phase of TfL’s Ticketing Project (FTP), TfL plans to allow season pass holders to associate a contactless payment card with the season pass. This will be their first us of payment cards as tokens and will mean that the customer will not need to also carry an Oyster card.

However, again, these all rely upon the customer obtaining the appropriate token that is accepted, whereas the real convenience vision I have for a country such as the UK which may never have a national electronic ID (eID), is what I call Bring Your Own Token (BYOT). Certain standardised tokens that meet common security requirements and we all carry anyway would be used to prove to any merchant that we are good to pay for their services, or we are eligible for them. I don’t care what that token happens to be, so long as I have one with me at all times. I don’t expect all other customers to use the same token as me and I have a vision of a variety of such tokens being accepted and there being a central service (in the cloud, of course) which all merchants or service providers use to verify eligibility of the token.

Some say that it would be impossible to get all the parties to agree to sign up to such a central token verification service. And to them I say, look at TfL. After several years of negotiation with the Train Operating Companies (TOCs) operating in the London area, agreement was achieved that TfL collects all the Oyster or contactless payment card ‘taps’ on Oyster readers for trains, calculates the journey, deduces the fare payable by the customer, collects the fare from the customer and distributes the portion of the fare due to the TOCs.

It is no longer tenable to say TfL achievements are only possible because London operators are regulated. The TOCs are deregulated and they have agreed to trust TfL to reimburse them fairly without knowing how many journeys passengers have actually made using Oyster or payment cards. Like the taxi drivers, the TOCs would rather be paid than not, unlike the bus operator in Oxford.


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.