Fintech companies such as Stripe have demonstrated that application program interfaces (APIs) can help financial services companies win in the payments space. The bigger question for the financial services industry as a whole: Will banks shift their technology strategies and ride the coattails of APIs developed by technology firms?
Banks have been slow to adopt open APIs for many reasons. Some have issues merging legacy frameworks and systems, others believe that using external APIs increases security and regulatory risk, and a few simply fear the unknown. No matter the reason(s) for non-adoption, the marketplace has not waited for banks to get the memo. Customers have become accustomed to functional applications and have noticed the service gap between Google/Amazon/eBay/Twitter and bank interfaces.
A solid interface can meet customer technology expectations but the right API deployment can also deliver revenue. Several technology companies are already riding APIs directly to the bank. Matt Murphy and Steve Sloane at TechCrunch report that “Salesforce reportedly generates 50 percent of its revenues through APIs, eBay nearly 60 percent and Expedia a whopping 90 percent.” A shift in bank strategy could offer similar returns over time. In previous articles, we discussed the need for banks to deliver value with their APIs, here are a few places where banks can look for inspiration and directly integrate functionality.
Banks Shift Focus from Customer to Developer (B2D)
Business-to-Developer (B2D) is a relatively new concept but one that should be discussed amongst financial services strategists. The theory is pretty simple. Build your API platform base for developers and allow developers to innovate on it. In theory, developer innovations will target products and services to specific customer needs and expectations, improving uptake and recurring use. In addition to these benefits, brand appreciation will also improve. Customers who had previously been nagged by sales agents will now be able to quickly find and use the products they actually want or need.
No Need to Build In-House
There are not many reasons to reinvent the wheel and re-develop technologies in house. If security/regulatory risks are holding your organization back, assess and compare the risks present in building your own API from scratch. Developing in-house costs time and money. In addition, there is no guarantee that an API built in-house will perform better or provide more security than one already tested in the market. In fact, home grown APIs can exhibit security flaws which may not be obvious until late in testing or deployment.
A general strategic consideration — if possible, save development time and cost and improve functionality by aggregating several existent micro level APIs into one multi-functional API.
Thinking about what functionalities to include in an API can be a bit overwhelming. At most recent count, there are about 16,000 public APIs rending all kinds of services. Before getting bogged down in research, decide what functionality you want your API to have. Then, look externally to find APIs that have built the services you want to integrate. Why? Because somewhere in the API stack (most likely) is a platform that has market tested the services you need. At the very least, you can learn from the successes and failures of APIs that have already been tested.
A Few Top Performers
Will your bank’s API require payments, fraud detection, AI, telephony, location based data and maps, CRM, email, site search, or crypto currency wallets? There’s an API for that. Google, Twitter, eBay, Slack, Facebook, LinkedIn, Pinterest, IBM Watson, Stormpath, Amazon, and MailChimp, are a few shining examples of API deployment and adoption. Technology companies have done a fantastic job of determining customer needs and service requirements. Banks, less so. Look no further than the Wells Fargo over-cross-selling debacle and you’ll see the strategic mismatch – products being pushed often do not match the services customers seek. Open API strategies can change that.