There is a lot to be fixed in the banking industry. In dealing with retail banks, consumers continue to have a multitude of bad experiences for a vast array of tasks. These tasks can be anything from the mundane to the complex, but they all stem from a similar issue.
Banking is a massive industry, and most modern banks are several decades old at least. With the pace of current technological growth, consumers’ expectations are not being met. Changing an app’s flow, altering a modern website’s database connections, changing the caching layer - these tasks, although non-trivial, are fairly easy to implement in modern software driven companies. For a bank, these are massive undertakings.
The first mover disadvantage
A well known problem in economics is associated with the first mover advantage. In a new industry, the first movers generally gain an advantage in that relevant industry through gaining traction in the market. As the market and technology progresses, the first movers make mistakes, improve processes, and iterate. This involves a capital and time investment, but the payoff is always worth it if the company manages to keep ahead of the pack.
The downside to this, is that as a technology and industry develops, the late entrants get to drop into the market with the wisdom of their competitors’ mistakes. This reduces the barrier to entry and gives them a head start. This process is particularly harmful to industries that move quickly. Players can enter and leave the market often and freely, changing the landscape considerably and driving growth.
The banking industry, and other capital and regulatory intensive industries, are not quick movers. In fact, a lot of banking infrastructure still sits on mainframes written in COBOL from the 1970s. As a result of being slow movers and first entrants into the market, consumers’ expectations are consistently not met.
Small pieces of pie
In this post I will focus on a small piece of the banking pie: customer authentication when confirming transactions. Some countries don’t even use two-factor authentication (2FA) on banking transactions (for example some US banks) largely due to the disadvantage mentioned above.
The flow for 2FA is as follows, focusing only on the transaction:
- Transaction is sent to the banking system by the customer
- Customer receives a One Time Password (OTP) via text (SMS) or email
- Customer inputs OTP onto banking website/app/etc
- OTP is validated and transaction is let through
This adds a much needed layer of security to transactions, but has its own flaws. Two of the largest are as follows:
- Any changes to the authentication delivery mechanism can be problematic
- eg: Cell phone lost, try to change OTP delivery to email, attempts to send OTP to cell phone to change OTP delivery to email. This has happened so many times I’ve lost count
- OTP delivery can be intercepted
- Email is fairly insecure, SMS encryption is trivial to break
Another channel
The implementation of OTP above uses a second one way channel to drive the user back into the main channel. A different approach could be to use a second two way channel, having the user do the confirmation on the receiver channel. An example:
- User receives text message asking for confirmation
- User responds to the text message with confirmation as instructed
- System processes the SMS on the other side, and validates the transaction
A follow on approach could be to mix the channels, two way and one way, to further increase security. From a high level:
- User requests transaction in channel 1
- User receives confirmation request in channel 2
- User sends confirmation taken from channel 1 via channel 2
- Channel 1 receives confirmation from channel 2
- Channel 1 confirms transaction
This implementation would increase security while maintaining a great UX experience for customers by limiting the channels and shaping the workflow accordingly.
2W2FA
For now, we will call this Two-Way Channel Two Factor Authentication (2W2FA). Using technology available to all users, unique identifiers, and what amounts to a complex OTP, we can implement 2W2FA fairly trivially.
An example workflow for 2W2FA is as follows:
- User requests transaction through the first channel, the website
- User gets push notification on their banking application, the second channel
- User reads notification, accepts the notification
- “Would you like to process the transaction X?”
- The website then displays a QR code
- The banking app requests user to scan QR code
- QR code is scanned and verified
- Transaction is approved on the website
In the background, various checks can be done to ensure authenticity of the requests between the first and second channels. The QR code verification can take various forms, the simplest being sending up a SHA256 hash of the content back to the first channel/main server.
The above implementation brings the control of the entire 2FA flow for the user into the bank’s domain, resulting in increased security and a better UX experience. Using an application brings the 2FA in line with a users identity, as with email, without the security concerns. Identity-based 2FA is ideal, and more than achievable given the unibiquity of constants in the user’s current online landscape (email, Facebook, Twitter, etc).
Conclusion
The implementation outlined above 2W2FA, while being imperfect, gives a markedly better experience to the consumer. The costs of deploying this strategy are fairly minimal as all channels currently already exist. Current channels for 2FA can be used as backups.