APIs (application programming interfaces) have become a huge part of the conversation surrounding data sharing and digitization at financial institutions. An API bridges different data sources and applications to bring information and insights into one easy-to-use interface. The potential that an API offers is undeniable. At a base level, they present opportunities to:
- Scale quickly
- Improve customer experience
- Acquire actionable data
However, before jumping on the API bandwagon, it is important for financial institutions to note that the excitement surrounding the potential of this technology has generated some misconceptions or ‘myths’.
There is much to be accomplished by financial institutions that use APIs, but there are definitely limits and things to carefully consider before diving into the movement. In a webinar on API misconceptions, “Busting API Myths at the Intersection of Banking and FinTech,” the seven biggest API myths were discussed with questions answered.
Myth #1: APIs Only Solve Technical Problems
It can be argued that APIs don’t actually solve technical problems at all. Instead, they offer solutions to well thought out business problems. When considering utilizing an API, organizations should start with the business need and purpose in mind, as this is the only way to truly measure whether the use of an API is successful.
Also, consider many different factors, like mission critical features, direction of data flow, batch or real time transfers, the cadence of source system data, data warehouse usage, etc. All of these factors can influence whether an API is a viable option to help solve the business problem.
Myth #2: APIs Can’t Be Hacked
Because an API is an ‘opening’ to a system’s data, this notion is false. As with other technologies, both accidental and malicious events can jeopardize any system. At a minimum, it is recommended that financial institutions have three things in place to ensure adequate security.
First, is the utilization of https. Second, an authentication model/mechanism like OAuth needs to be in place. Finally, physical and software security practices must be in place as well. Security is top of mind for most financial institutions, and an API should be treated no differently. Always take precautions because an API is at risk of being hacked, just like anything else.
Myth #3: APIs Solve All Interface Problems
There are a few different mechanisms to transfer data between applications. The key is to match the need with the right mechanism, and not all interface needs are best met by an API. For example, some data is needed in real time and some isn’t. If the data is not time sensitive, a batch transfer (when large amounts of data are transported at scheduled times) may do the trick.
However, certain data is needed in real time, and this is where an API makes sense from a business standpoint. In addition, this embedded solution allows a single app to collect data from multiple sources. The aggregation of real-time data collected from multiple sources allows the user to make unique inferences from the data. This type of solution is where the highest value can be derived from an API.
Myth #4: All APIs Are Created Equal
While a secure and functional API could be developed in a few days, this doesn’t mean every API built through different processes are of the same caliber. Some APIs are just better built and allow for things like a greater depth of data access, better security, automated testing, deployment controls and documentation, to name a few.
Myth #5: With an API, We Can Access All of the Data Needed
In determining what functions an API should have, it is essential to ask questions around who needs access to data and what data needs to be accessed. For instance, there are several key pieces of data that a financial institution probably doesn’t want to be fully available, including things like personal information, trade secrets, corporate intellectual property, etc. An API’s design may limit access to data for many good reasons, so the idea that an API will provide access to all data is false.
Myth #6: As Long as an API Doesn’t Change, It Will Always Function the Same
When an API is made public it implies a commitment from the developer to everyone who uses the API that it will continue to function as advertised. However, like all software, APIs evolve and are updated. Therefore, bugs and the need for forward-thinking improvements are an inevitable reality.
APIs should constantly be tested to ensure proper functioning. Organizations also need to be cautious to ensure that internal developers manage compatibility with previously released capabilities to guarantee correct functionality.
Myth #7: APIs Will Scale Indefinitely
By design, APIs may not scale indefinitely. Controls need to be put in place to protect the system, as the API gives others access to back-end resources. This can be done through throttling or metering.
Other limiting factors pertaining to APIs are bandwidth limits, processing limitations and database read-and-write limits. Just because an API can help scale an institution does not mean it can do so indefinitely, given the various limiting factors often put in place to help protect and keep the core application base safe and secure.
APIs are the foundation of tomorrow’s banking ecosystems. For financial institutions that use them effectively, they can reduce costs, improve efficiency, and help the bottom line.
Despite the potential value, the number of banks and credit unions with mature API programs remains relatively small. Most organizations have a handful of APIs in place and most are being used in rather traditional ways (fraud and security processes). Similarly, most financial institutions do not have a formal API strategy, and do not know the ROI potential.
API development, management and deployment are crucial capabilities for the future of digital banking. But, in the near future, only those organizations that move beyond the limited uses being seen today will be prepared for delivering value in the new banking ecosystem.