Today, blockchain/shared-ledger and artificial-intelligence technologies are getting a lot of press, but there is an older and simpler technology that is ready to use now and is comparatively easy to implement. It is changing how payments are done in a way that financial institutions need to carefully think through.
Application Program Interface is a familiar technology that’s been around for a dozen years. In essence, it is a set of defined routines, protocols, and/or tools for building software applications in such a way that software components in disparate systems can interact to accomplish a transaction, monetary or other.
The technology now is used to attach a function or action in one computing system to a function or action in another computer in such a way that the two can interact to perform a process or routine that neither could complete alone.
When you use your mobile device to make a payment, the connection made via an API exists only for as long as the phone’s system and the financial system need to interact to complete the process. For those few seconds, the affected function behaves as a single entity. Changes made by one system will alter things in the other, and these alterations will persist after the exchange ends. Because the API’s two systems don’t just shove data back and forth but can act for the moment as if they were a single, unified system, the technology could be opening the door for fintech inventions to do payments.
While APIs in some form have been around for quite a while, what has been happening recently is that they are serving as an efficient and comparatively low-cost way of connecting non-bank fintech systems to bank-processing systems and, importantly, bank systems of record.
In this capacity, APIs are not serving simply in their original role of intermediary. This is something that needs to be thought through beyond the technology level. From the customer’s viewpoint, the API may be masking the fact that there is a regulated financial entity doing the actual processing of the payment, often to the fintech’s brand and marketing advantage.
Both survey and behavioral research have shown that after a dozen or so transactions within a 30-day period, most customers may lose recognition that it is a bank or credit union that is actually performing the transaction. They’ll see the transaction as something the app does and associate the service with the app’s brand, not the bank’s.
One reason leading banks are trying to get out in front by being the source of the app is to maintain their presence with the customer on the other end of API-enabled transactions. It’s the same conundrum banks went through when they let customers use each other’s ATMs, but on a much larger and much faster-moving scale.
Because customers using non-bank APIs to access their bank may no longer see what their bank or credit union is providing to the transaction, it might not be too long before the non-bank entity comes to be seen by the customer as the party extending all the protections that people trust their bank or credit union to provide.
Yet, while it may seem surprising, some of the most innovative banks seem to have concluded that extending the trust people have in financial institutions to non-bank providers of payment apps is either inevitable, a net positive, or both. (The term Trojan Horse does come to mind.) My bet is we will see most financial institutions following the leaders in deciding the increased customer count and traffic is worth the trade-off.
Long before blockchain becomes a standard way of doing banking, and perhaps before A.I. gets beyond its current early phases in automating banking and payments, the humble API might become the technology that most revolutionizes how people make payments. For banks and credit unions, it is time to either pull up the drawbridge or get out in front and be the provider of the API. Deciding which, or what combination, is best is a product-strategy decision, not a technology decision. And if you’re a banker, it’s one that needs to be made before a non-bank on the other side of the API makes it for you.
—George Warfel • GWarfel@haddonhillgroup.com