How Do Open Banking APIs Interface

What Are Open Banking APIs?

Banking has always had its interfaces. They’ve just changed over time. Let’s go back some years to when you were a kid when the bank was a physical branch with walls and a roof, and your parents waited in line for an available teller in order to pay a bill or deposit a cheque or just to take out printed money. Your parents would go every other Saturday morning, despite knowing that the lines were the worst on weekends. No one looked at phones because they weren’t smart—the phones, not the people. Everyone just looked at each other and waited. A line of people weaved up and down the main lobby, all of them patient and kept in check by those red velvet ropes that you’d try to sit on or maybe just swing back-and-forth until one of the poles fell over and you ruined everyone’s waiting with a loud, disruptive clang. (You were never really cut out for that waiting life, were you?) When it was your parents’ turn, you made your way to the teller who would say something like, “What can I do for you today?” This was your first experience with a banking interface.

The job of the teller was to act as a kind of messenger between your parents and their bank accounts. They asked the teller to do something—pay the telephone bill, deposit a paycheque, transfer funds—and the teller would go off and do that thing for them. The teller would perform a series of actions to process each transaction. They would write something down, walk down the counter, stamp something, sign something, scribble illegible things onto scraps of paper. And, voila! Banking happened. When it was finished, the teller would let you know that the banking requests were completed.

Modern-day banking interfaces or application programming interfaces (APIs) are just like that. They take your requests, update or process information, and give you a response to let you know whether your request was successful or not.

Things are just a little more complicated now. On top of that traditional banking model, there are many players reshaping the financial system. The federal government, industry players, and financial institutions are all pushing the industry towards a consumer-directed finance system focused on data-driven, customer-centric banking experiences. It’s a financial model known in other parts of the world as open banking, and APIs are one of the key features that will open up the traditional model in order to make consumer-directed finance possible.

So, how do banking APIs work in an open banking or consumer-directed finance system? And why are APIs a key element in making consumer-directed finance a reality?

We’re happy to explain. Just please don’t swing on the ropes.

What is an Open Banking API and How Does It Interface?

Just like a teller acts as an interface between you and your bank accounts, an open banking API acts as an interface between a third-party system and a banking system. It lets the two systems talk.

Think of an open banking API as a communication channel—just like how spoken language is the communication channel between two people. Except rather than English or French or any other spoken human language, an API uses a computer programming language (like Ruby or Python) or a data format (like JSON) along with HTTPS and URL endpoints in order to communicate. The API uses all of this technology in order to establish a secure connection between two systems so they can share information.

Now, there was a lot of technical baggage there. You might be wondering, where does HTTPS come in, and what the heck is a URL endpoint? So, let’s unpack some of these terms and explore what they do using the same customer-teller analogy.

We’ve stated that the API is the communication channel—it’s like the language between two people. But consider this: A non-bilingual, French-speaking customer can’t communicate with a non-bilingual, English-speaking teller, right? In this case, in order for the teller to receive the customer’s request and process information, the customer unfortunately must speak the same language as the teller. An API is like that, too. The API determines the rules on how to talk to it. It defines the kind of requests that can be made and how to make them. Just like how an English-speaking teller might say, “I’m sorry, but in order to process your request you, unfortunately, need to speak to me in English,” an open banking API will come with instructions on how to interact with it like, “Requests can be made using HTTPS methods on our specific URL endpoints, and responses will be provided in JSON.” Developers and third-party applications need to use the API’s language in order to communicate with it.

Now, if the API is the communication channel, then what is HTTPS, and what are URL endpoints? Let’s explore these separately and then see how they work together. HTTPS is a little more familiar, as you often see it in the URL of websites—I’m sure you’re already starting to see how these two pieces fit together. HTTPS is the request-response protocol, the foundation for how data is shared over the web. It makes it possible to share information securely because it supports Transport Layer Security encryption—it keeps things private. If the API is the language or communication channel between our customer and teller, then HTTPS is the protocol for how the two people talk. It says that the teller stands here, and the customer stands there. It defines the space that makes the conversation between the two people possible in the first place, while also ensuring that what is discussed is discussed in private. It puts up the velvet ropes and keeps other customers from requesting actions they’re not authorized to request on the behalf of our customer. HTTPS provides a secure space to exchange data.

And we can build on this. The URL endpoints are the locations from which our teller gets the information needed in order to share it with the customer. “How much money is in my chequing account?” the customer might ask. The teller would go to the account and take a look at the balance—or the endpoint—and then respond with something like, “You have $2,205.” The URL endpoints are the locations of specific information or data that an external system can request.

Why Are Open Banking APIs Important for Consumer-Directed Finance?

By this point, it should be clear why open banking APIs play a fundamental role in consumer-directed finance. APIs open up and connect core systems with external financial applications—they connect banks with financial apps—so they can communicate with one another and share financial data effectively and securely.

The ability to share financial data means more financial service providers have access to the data they need to create new financial service solutions for their customers. Fintechs and financial service tech startups finally have access to the information they need to create financial service experiences focused on improving one aspect of banking or personal finance. Startups interested in aggregating customer data from multiple financial institutions can now do that safely, so consumers can see all of their account information from multiple institutions in one location. And that’s just one example.

Open banking systems and APIs create competition, encourage innovation, and ultimately give consumers more choices and easier ways to move and manage their money. With the ability to share personal financial data and process it in innovative new apps, consumers have the opportunity to make more informed decisions about their personal finances.

If we apply consumer-directed finance to our analogy, then it’s like our customer having numerous tellers, all of them taking a proactive approach to improving our customer’s personal finances, telling our customer things they didn’t know they needed to know. APIs change the banking experience and make consumer-directed finance possible.

Seriously, though. You can’t sit on the ropes.

Up Next: