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

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

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

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.

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!


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.