Category: Transit and Travel

Account-based ticketing workshops

18th December 2016by Consult Hyperion2 Comments

We’ve been having a lot of fun in recent months leading workshops for transport operators about account-based ticketing. Sharing our recent experience with clients such as the UK’s Transport for London (TfL) and Transport for the North (TfN), Hungary’s BKK, New Zealand’s NZTTL, Belgium’s De Lijn and Stockholm’s Storstockholms Lokaltrafik (SL) and Singapore’s LTA.

The workshops are designed to help transport operators who are new to account-based ticketing understand the issues and options, including how Open-Loop bank cards can be blended with existing smart ticketing. A typical agenda covers the following subjects:

Trends

Customer propositions should drive everything
Smart ticketing trends
Technology roadmap
Benefits of ABT and Open-Loop

Architecture

Basic architecture overview
Generic architecture
Open loop vs closed loop (the back office)
Providing for the unbanked

Open-Loop solutions

Open loop implementatons in other countries
The 4-party model for payments
Transit Transaction Models (’Models 1-3’)
Transit Charging Framework (generic, global)

Compliance

EMV
PCI DSS
Working with a QSA

Our latest workshop was sponsored by Mastercard and hosted by Swedbank in Riga, Latvia, and had an audience of 40 including:

Transport operators
Government bodies
Industry suppliers
Media

We are looking forward to leading more similar workshops in 2017 across Europe.

Riga workshop sponsored by Mastercard and hosted by Swedbank.

Discussing a 'strawman' solution for Riga's needs. — Discussing a ‘strawman’ solution for Riga’s needs.

ODA is a good thing, and not only for transit operators (are you listening USA?)

22nd August 2016by Consult Hyperion4 Comments

Following the success of Transport for London’s (TfL) Contactless Payments program, a project Consult Hyperion have contributed to since 2008, transportation agencies around the world are following TfL’s lead looking to bring the same convenience to their own customers. Operators are migrating from a world where customers have to exchange real money into transit money before they can ride on a bus or a subway, to a world where you simply tap your bank issued contactless credit or debit card on the transit reader.

The Problem

As brilliant as this new world of transit payment is, it does expose the operator to some level of risk as well as deliver a variety of benefits. I’ll address other risks and benefits in later posts, but for now I want to focus on the risk of accepting a counterfeit bank card in exchange for free travel.

Of course, the benefit of accepting payment cards for transit is that you can reduce the cost of card issuance through using the card customers already have in their pocket. Customers benefit from being able to pay for transit the same way they make other retail purchases every day. With this approach you get the additional benefit of payment card security and you don’t have to rely on proprietary cryptographic techniques that could one day expose your system to fraud. Easy, right?

Well, it’s not quite that simple.

While bank chip cards come with a toolkit of security options for card issuers to use, the majority of issuers of EMV cards in the US today have only implemented one of those options required for the domestic online-only market.

To understand the issue, remember that all EMV cards generate a unique code called a cryptogram which only the card issuer can validate. So for each transaction, the card details and cryptogram are captured and sent for direct verification with the card issuer, who returns a message to accept or decline the transaction to the merchant.

However, this ‘online-only’ option is not suitable for transit operators.

One issue for transit operators is rate of customer throughput. In cities looking to implement open loop payments for transit (the acceptance of EMV cards), there is a need to handle large numbers of passengers passing through the subway gates or boarding buses. There is not enough time, in this fast moving environment, to wait for each transaction to be authorised online by the card issuer, and there are genuine health and safety risks to slowing down people moving through the system. Hence the strict time limits on transactions:

[Shashi Verma, TfL] said “contactless cards could now deliver transaction times in under the crucial 500ms at which longer queues begin to form”.

http://www.telegraph.co.uk/technology/news/10990294/Tube-to-adopt-contactless-payment-cards.html

“Agencies who have carried out NFC pilots argue that a device must have a transaction time of less than 500ms to be viable, and prevent passenger delays at turnstiles.”

http://www.masstransitmag.com/blog/10615616/nfc-the-mass-transit-payment-revolution

Looking at the how the transit transaction times break down in detail, we find that:

There is some time spent by the reader to detect a card and determine what type of card it is. This should take in the order of 10ms but may increase if different card technologies are accepted at the transit reader
Then there is a longer period of time where the card and the reader exchange some data that typically takes anywhere from 300 to 400ms on contactless bank cards currently-issued.
Finally, the typical times for a card issuer authorisation that we have observed are anything from 500 to 2000ms.

As you can see, adding these times together we are well over the 500ms target the transit industry is seeking.

Now, transit merchants could take the risk on one transaction and check with the card issuer that everything is ok with the card while the customer is making their first journey. If the issuer declines the transactions, the transit operator could put the card on a hotlist to prevent further travel. Seems reasonable? The trouble with this is there is an opportunity for the intrepid fraudster to develop a simple mobile application that looks to a contactless reader like a normal payment card, but in fact, for each transaction, generates a new identifier that will sidestep the transit hotlist.

How Offline Data Authentication helps

There is another option available to card issuers in the EMV toolkit that helps the transit operator meet their 500ms target and also mitigates the risk from counterfeit cards – Offline Data Authentication (ODA). ODA is a method that allows the reader to determine the authenticity of the card and the card issuer using the cryptography provided in contactless bank card chips and readers. Using ODA has the following effect on the transaction time, now that we don’t need to go check with the issuer to authenticate the card:

As before, the time to detect the card and allow the card and the reader to exchange data remains the same, about 310 – 410ms
Now, the time to carry out ODA now adds around 50ms, meaning a new total transaction time of 360 – 460ms

This meets the 500ms target.

It’s time for ODA to be mandated for all Contactless

Contactless bank chip cards personalised with ODA, as mandated in most payment scheme regions, allows transit operators and other merchants alike to mitigate transaction risk by authenticating the card offline. If transit operators can prove the card is genuine and not on their own hotlist, they can open the gates or let the customer on the bus. The next step for the operator will be to get card issuer authorization while the customer is making their first journey. Now they have all the information they need to decide if the customer can make the second journey or not.

While transit operators in established contactless bank chip card markets (outside the US) can introduce open loop payments safe in the knowledge that contactless cards are all going to be supporting ODA, in the US, the picture is less than clear. Migration to bank chip cards is still in its first year, there are very few contactless card products issued and mobile payments such as Apple Pay and Android Pay represent the largest use of ‘contactless’. While transport operators are looking to accept contactless bank cards, they cannot risk doing so until the US domestic cards are ODA capable. If the card brands and US banks want a slice of the US transit market ODA must be at the top of the to-do list.

(By the way, ODA is not just beneficial for transit operators; there are other merchants where this technology can also be helpful. For example, following a natural disaster where communications go down but merchants still need to keep trading to ensure essential supplies get to the right people, or merchants who wish to offer quicker processing at peak periods).

The solution at TfL was simple and effective. If a contactless bank card is presented that does not support ODA, it is rejected and the customer is not allowed to travel. When ApplePay was launched in the US, not all implementations supported ODA and these were also rejected at TfL gates. By the time ApplePay launched in the UK, this problem had been fixed. From a customer support perspective, the US needs to be in a position where all cards have ODA and not just some. Transit operators don’t want to block brands (but could do to avoid confusion). It will be impossible to put a message across to customers that some can use the system and others can’t due to something obscure and technical like ODA!

‘Secure enough’ mobile ticketing

29th June 2016by Consult HyperionLeave a comment

We’ve been working with ITSO on how to implement ‘ITSO with HCE’ since January 2015. In January 2016 we presented at Transport Ticketing in London about the work that we had done to date and this was also summarised in an article in the BCS ITNow magazine.

We have since produced a Functional specification for how ITSO with HCE will work in Phase 1. In addition we have produced minimum security requirements that will have to be met by ITSO with HCE implementations. Currently we are helping ITSO determine how ITSO with HCE implementations will be tested and certified by ITSO to ensure that they are secure enough to be allowed to be used on live ITSO schemes.

We continue to work with ITSO on moving ITSO with HCE forward. Here is the latest from ITSO about plans to pilot ITSO with HCE on a live ITSO scheme in West Yorkshire.

Working together with West Yorkshire Combined Authority, Transport for the North, Ecebs, Penrillian and Consult Hyperion, ITSO will be leading on a trial, due to commence in September 2016, which uses HCE-enabled mobile phones on a live ITSO scheme.

Beacons in Transit

24th June 2016by Consult Hyperion2 Comments

You’ve probable heard about Bluetooth Low Energy (BLE) Beacons being used to help the visually impared navigate on their own around public transport systems. This has been trialled in Bucharest on buses and in London Underground. These are examples of relevant information being pushed to users’ smart phones based upon their location. Other similar use cases might include telling passengers when they are approaching the stop at which they plan to get off, or telling them that their selected vehicle is about to arrive.

The use case I am more interested in is the one that allows passengers to travel without paying upfront and be charged afterward based on the journey that they took. We implemented this with TfL in London using contactless bank cards and it has become known as ‘Aggregated Pay As You Go’. This works well, but relies upon the passenger rembering to ‘tap in’ and ‘tap out’ to mark the end point of each leg of the journey in order that the back office can calculate the journey taken. Appropriate charges are made to the passenger’s bank card account at the end of the day.

Beacons could be used in implementations for this use case. Such a beacons trial is to be carried out in 2017 in West Yorkshire as part of the Transport for the North’s Integrated and Smart Travel (I&ST) programme.

The aim is to automatically determine the bus journey taken by the passenger and charge on a PAYG basis. Therefore, we need to know accurately where the passenger gets on and off the bus. This information will be determined by a smart phone app by interacting with beacons and sent to the back office where the charge is calculated and payment taken.

The trial, commissioned by West Yorkshire Combined Authority (WYCA), will be used to determine:

whether the passenger experience is favourable;
whether BLE technology can deliver sufficient location accuracy; and
how the journey timestamp and location information sent to the back office in such a way that can be trusted and not open to fraud.

What is the impact of Brexit on the blockchain?

24th June 2016by Consult HyperionLeave a comment

[this space intentionally left blank]

Contactless bank cards not safe

28th April 2016by Consult HyperionLeave a comment

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

22nd April 2016by Consult Hyperion

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.

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.

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

17th March 2016by Consult Hyperion4 Comments

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

17th March 2016by Consult Hyperion3 Comments

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

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.

Transport for the North

2nd January 2016by Consult Hyperion1 Comment

Cash still accounts for 48% of transactions in the UK, according to Moneybox on BBC R4 just now. As part of this programme, Shashi Verma from Transport for London was being interviewed about the acceptance of contactless payment cards (which we helped him design and implement from 2008-2014) on TfL modes of transport. The interviewer asked about the famous ‘capping’ provided by Transport for London (TfL) to all travelling customers using contactless. Shashi explained that using contactless bank cards is guaranteed to be cheaper than buying a ticket. Not just the same price, but cheaper. Guaranteed.

But what about the “Premium on the Poor,” as the programme called it? Now that buses in central London do not accept cash how can those without contactless cards travel by bus. Shashi’s answer was simple: they can use cash to buy an Oyster card. I believe they can also use their cash to buy tickets in ticket machines off the bus, but this was not mentioned and would also be more expensive than using Oyster.

But why was I so interested in this programme about things I already know about?

It’s because Chyp have been appointed Development Partners to Transport for the North (TfN). Since 7 December 2015 we have been working with TfN in Leeds to help them prepare designs, implementation plans and business cases sufficient to inform George Osborne’s budget in March 2016. Assuming all goes well, in March, the Chancellor will allocate sufficient fund to TfN to allow improved smart ticketing systems to be delivered across the north of England.

My particular role in the TfN project is to lead the Design stream of work proposing what should be implemented, where and when. It is a really interesting project and in many ways it will be more challenging than London. Will it be ITSO, or EMV? We’ll have to wait and see. Que sera, sera …