The ongoing COVID-19 crisis has been ruthlessly exposing fragile business models and weak balance sheets across a whole range of industries but perhaps never more so than in the travel business. In fairness, no one could have anticipated a global, government dictated total shutdown and no business models could ever be flexible enough to support such an improbable scenario. Still, it’s become clear that many travel industry companies are effectively broke and that the payments model they rely on is broken. Going forward we need a better and more sustainable approach to payments in the industry.
Most travel industry payments rely on payments cards so it’s worth starting by recapping on how most card payment models work. When a cardholder makes a payment to a merchant – either in store or, increasingly, on-line, this is routed to the merchant’s card acquirer. The acquirer has a direct relationship with the merchant in the same way that a card issuer has a direct relationship with cardholders and the acquirer will route the payment request to the relevant issuer – usually by sending the request to a payment scheme who uses the card number to identify the correct issuer. If the issuer approves the transaction then the response is routed back through the same path and the purchase completed. This is no different from any other card payment, although there are hidden complexities where the merchant is an online travel agent sourcing flights, hotels, etc from multiple underlying vendors. However, that’s a detail.
For those of you not familiar with the UK payment industry, PaymentsUK is the trade body formed following the reorganisation of the regulatory structure. It has (I’m paraphrasing, of course) three main roles: advocacy, thought leadership and collaborative innovation. I had the good fortune to attend their Customer Engagement event in the City the other day (I called it the “PaymentsUK coffee morning” on Twitter!) to see them present their initial August 2015 report “World-Class Payments in the UK” to a variety of different stakeholders. I have to say, and this is genuinely not a facile supplication because we provide paid professional services to the organisation, that it’s a really good report and I urge you to look at it. It is short, well-structured and to the point in setting out their priority areas for the coming year. The priority areas are access, payment identities, enhanced data and “request to push”. (I stress that I’m using my labels here, not theirs!)
Access is of course a priority of the Payment Systems Regulator (PSR) as well so it is no surprise to see it as a top priority for PaymentsUK. They call for simpler, more open access to the payments infrastructure for Payment Service Providers (PSPs) and have rightly identified this as their most important deliverable.
Payment identity relates to the issue of the correct identification of payment counterparties. Personally, I think this is much more complicated than it sounds. At one level it seems straightforward to say that when someone enters a payment destination (such as a sort code and account number) they should be provided with confirmation of the name of the beneficial owner of that destination. This is so they can be sure they are sending money to the right person because there are no end of problems with people sending money to the wrong account via the Faster Payments Service (FPS) and then asking the banks to get it back for them. This raises real issues to do with privacy and these need to be carefully thought through to avoid a Chernobyl of personal information downstream. My personal preference would be to start work on looking at the idea of “payment names” so that someone could send money to £dgwbirch rather than some strings of digits that they can easily get wrong.
Enhanced data is to do with adding reference and remittance advice to electronic payments. Due to the current limitations of our rather ancient infrastructure, payments advice is limited to a few alphanumeric characters. This may well change in the future when systems shift over to more advanced protocols, but I think we should look at an interim solution along the lines of the URL shorteners (e.g., bit.ly) that we are all familiar with on the Internet. There might be a way of generating a short alphanumeric code that can be included in payment advice as a pointer to more detailed structured remittance information that the recipients can interrogate.
Finally, the issue of replacing a great many kinds of pull payment with some form of “request to push” payment makes complete sense. I rather think that in the long run all payments will become either push payments or request to push payments. There is a very interesting discussion have right now about whether request to push should be implemented as a layer on top of FPS (along the lines of a PingIt or a Zapp) or whether it should be implemented as a separate scheme with its own scheme rules.
The only part of the report that I am not sure about is the inclusion of account switching as a PaymentUK issue. I understand the relationship, but from my point of view account switching is a banking industry issue and it needs a much better solution than the current expensive and not terribly effective Current Account Switching System (CASS) in order to meet the government’s goals for enhanced competition in the sector. Here my personal preference would be to open up a work stream to look at account number portability, although as I have written extensively about before I think this should be implemented through a virtual account number system linked to a payment name system (my “70” solution) rather than by inter organisational account number portability.
In summary, I think that PaymentsUK have made a real contribution to the sector with their initial report and I look forward to seeing how they take these work streams forward, recognising the need to work closely with the PSR but also with other relevant industry bodies (such as techUK) to start making these real improvements to our payment system in reasonable timeframes.
Subscribe to our newsletter
You have successfully subscribed to the newsletter
There was an error while trying to send your request. Please try again.
