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!

4 comments

  1. Ahh! It’s like listening to a history lesson, however …

    Let’s not forget that the online authorisation following the initial ODA should only cover the initial trip (even though the cost of the initial trip might not be known), unless the transit operator authorises for a larger amount (even though the transit operator doesn’t know that the customer will make additional trips that day), in which case the traveller might be declined for a round trip of 2 x $3 fares because they don’t have $15 in their account (let’s say they have $7), in which case they can’t get home.

    The transit operator does not therefore have the information necessary to allow the second trip unless the card issuer accepts the liability for additional travel that day (much like a petrol pump in the UK).

    ODA is the answer to the speed challenge, but an offline authentication followed by a post-travel authorisation request for a potentially unknown travel amount and a liability shift to the issuer … really?

  2. David, you rightly point out that ODA only covers counterfeit risk and that financial risk can only be addressed by a full online authorization. However, the value of that authorization should fit with the rules as defined by the card brands who have worked with the transportation industry to create rules to balance risk between the card issuer and the operator, for what is, in the most part, a low value transaction.

    More on this in a future post!

  3. David,

    Here in the USA multiple merchants have voiced interest in Offline Data Authentication ODA – in other words Counterfeit Protection – and they fully appreciate the risk of the consumer no longer having sufficient funds at time of authorisation – the Financial Risk. Even merchants selling expensive are asking for ODA to deal with those occasions where the network is down, the person looks worthy – if only the card is genuine – the sale is would be worth the risk.

    the other comment is that merchant acknowledge that 100% online is nice to have but frankly 100% availability of the network is a dream worth dreaming.

  4. Let’s also be clear that the risk model only applies to domestic cards. There is no international risk model agreement. So, for foreign cards, the first ride risk coverage for the operator (merchant) taken by the domestic issuer banks does not apply. It is up to the operator whether they accept the risk of foreign cards. If these cards do not offer ODA, then it is a no brainer to reject them.

Leave a Reply to David GriffithsCancel reply

Discover more from Consult Hyperion

Subscribe now to keep reading and get access to the full archive.

Continue reading


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.