APIs: Powering payments, igniting growth and pioneering the future of banking

If you’re familiar with IBM’s MQ technology – middleware that enables applications to communicate by exchanging messages that are literally queued up – then you’ll understand the concept of two applications talking to each other. APIs perform this function, but in a much simpler way, facilitating the exchange of data very quickly and easily. Another advantage APIs have over traditional methods is that they are much easier to maintain and update, meaning that there is very little downtime.

Payment systems built using legacy middleware and old-fashioned databases are slow, processing messages in a linear fashion, creating bottlenecks in processing. Those built using APIs are multi-threaded and therefore much faster as they can process numerous messages at once. In terms of streamlining real-time payments, APIs can enable financial institutions and payment processors to handle large volumes 24 hours a day, seven days a week, in a way that just wasn’t possible with traditional methods.

Personal finance tool Mint is an example of how APIs can make financial services much more functional for end users. Mint users can connect their checking accounts, savings accounts, mortgages and the like to Mint and see all of their personal finance activities in one place, and it does this through APIs. It pulls the information from users’ accounts at various banks and other financial institutions by making a request via an API with whichever service provider it needs to pull the data from, and the request is instantly fulfilled.

The whole concept of open banking is based on APIs. Open banking is the principle of customers being able to consent to share their banking information with third parties to enable all kinds of innovative, user-friendly services. While open banking has been effectively realized in the UK and across much of Europe, it’s still a way behind in the US at the moment. Mint has managed to build a successful financial management tool, but it’s had to do so the hard way, by building an API for each bank and institution it links to.

Every bank has its own API, built to its own set of standards. Another financial services provider can connect their own API to the first bank’s API, though to do so they’ll need to develop some kind of integration layer so the APIs can effectively communicate. And they’ll need to repeat this for every other bank or service they want to link to, because there is currently no industry-wide standardization.

Therefore, banks that want to connect their API to instant payments services like RTP and FedNow would need to build two separate integration layers. However, at Form3, we want to make it simple for our clients to connect their banks to payment services, which is why we have created a single payments API through which clients can link to the Fed and The Clearing House all in one place. One simple integration opening up multiple payment services. Even beyond that, Form3 is using our APIs to connect banks globally – using the same set of API’s for access to rails across the globe like FPS in the UK, Sepa instant in EU and more. 

It’s this kind of standardization that banks should be looking for when implementing their own API strategy. The fewer integrations your tech team has to do behind the scenes, the more time they’ll have to work on other features and functions that customers will actually see.   

When choosing a technology partner, banks need to look for an organization that has agnostic APIs capable of connecting to multiple services not just right now, but in the future as well. While there is no industry standard per se, Form3 is leading the market in taking a standardized approach to connecting financial services together. And if you need further proof, check out our API documentation.

Watch our webinar on demand for a comprehensive discussion with Silicon Valley Bank, GFT and Publicis Sapient at how API technology is shaping a more seamless, integrated and customer-focused future in the financial industry.