In this episode of Kongcast, I spoke with Grant McKeen and Jonathan White from IntegrationWorks about how open banking and BIAN (Banking Industry Architecture Network) work with Kong Gateway to create simplicity from complexity in the banking and financial services industry.
Check out the transcript and video from our conversation below, and be sure to subscribe to get email alerts for the latest new episodes.
Kaitlyn: Grant, can you start by giving us a quick rundown of what BIAN is and how it relates to common connectivity challenges?
Grant: BIAN is a not-for-profit organization. They’ve created an exhaustive set of services for the banking and finance industry. These resources are freely available. Member organizations of BIAN contribute to these, and they’re made of the top banking and finance services firms in the world. And they’re maintained and released just about on a yearly cycle at the moment.
Open banking is about opening up large banks' banking services to third-party providers, application developers and end users. This is mostly created through regulation in most countries and geographies. And it’s designed to create an atmosphere where third-party providers can make more functionality and better solutions for the end user and consumer than what banks are currently providing in the market.
There’s still quite a reliance on banks. Therefore, open banking APIs are very important to give them the standards, compliance, regulation and risk mitigation they require while still being very open and composable, which application developers and end users need for their solutions.
Jonathan: Open banking is a way to have banks provide a set of standardized interfaces to allow service providers and third parties into their banking services.
And BIAN itself is a group of experts and service providers in the financial industry. And what they’ve done is model the complete set of banking capabilities into an exhaustive list of what they’ve called service domains. For each service domain, they’re starting to create open API specifications for the interaction with those service domains, which supports the open banking initiative by providing those standardized interfaces.
BIAN has such a large landscape of services. They’ve created a service for every capability that a bank could reasonably be provided to perform. But no one bank, unless it’s a huge multinational, will implement every service domain.
So we need a solution that allows the consumer to pick and choose which domains to implement. And because BIAN has chopped their capabilities into such well-defined, bounded contexts, deploying the service domain of your choices is key to start implementing BIAN without needing to boil the whole ocean and deploy everything.
Kaitlyn: So what exactly is the problem that this solves?
Grant: Interoperability in the banking and finance area is very complex, fraught with a lot of danger, failed projects and large vendors. BIAN looks to solve the problem of creating simplicity from complexity in the banking and financial services industry. It’s done this by decomposing a bank's various capabilities from an exhaustive list put together from its members of some of the world's largest banks and financial service providers. And it decomposes these into service domains. And then further into API specifications that are free and open to use.
These provide an asset where application developers, banks and third-party providers can download these and create solutions based around them that are intrinsically interoperable. The interoperability that this provides means a lower cost of effort and time to develop solutions in this industry that are open banking.
Jonathan: It’s looking at creating a standardized model for banks to use. Banking architecture traditionally was very process-oriented, which caused quite a few issues. As the processes within a bank expanded, the architecture became very tangled and brittle. But by taking it back to the capabilities that a bank needs to offer and then modeling the interactions between these service domains, it was easier to model.
Grant: That’s why we created the Kobi CLI—to develop and manage those open banking interfaces. There are a lot of them in the industry. There are a lot of them in BIAN. And change happens very frequently. Making a CLI to manage the process through to a nice, lightweight API gateway like Kong makes it much easier for these smaller application developers and other banks and third-party providers to get involved in this and be a part of the fintech industry.
We’re looking for people to help us extend that to other formats, protocols and other standards. The aim of the CLI is to make it easier to integrate Kong into your environment with open banking.
Kaitlyn: How does Kong Gateway fit into this to add value over other API management solutions?
Grant: Kong is very lightweight in its approach. And through its plugin nature, you can roll only what you need. And we support that. It’s not a heavy-weight north-south API gateway. It’s a very lightweight east-west API gateway. We think that fits well with the BIAN solution for creating quick interoperability and API management solutions.
Kong can be seamlessly integrated into your existing processes through CI/CD, your security providers, all that sort of thing very, very simply. So with that and BIAN, we think this creates a very efficient and cost-effective fast start for organizations looking to integrate to create interoperability with the banking and finance sector.
Jonathan: I quite like using Kong as the API gateway because it's unashamedly developer-first. A lot of products that we get exposed to aim at what they call citizen integrators, which means everything is done through a GUI, which makes for good demos but not great developer experiences. And when you try and fit it in with a CI/CD pipeline, it just doesn’t work.
With Kong having the management APIs, decK and the portal CLIs, it fits nicer with a proper DevOps attitude, which we wanted with the CLI. We could have easily just written some ad hoc scripts to do the process, but creating a CLI means that we can include it in pipelines in the future.
Grant: We have a code, not clicks approach to integration. We feel that Kong shares this value as well.
Kong has a developer-first mentality, and everything they do seems to live and breathe this.
That fits well with our values and where we go as a company. We try and be different by design. Kong fits in with this through its approach to the role of an API gateway and provides a very lightweight, stable and performant runtime for our customers.
When you’re developing open banking solutions, having a secure, performant and reliable API gateway is 100 percent what you need. Our solution implements open banking interfaces on Kong because we feel that the BIAN interfaces on the Kong Gateway provide one of the best quickstarts you can have in the financial services and banking industry for creating functionality quickly, effectively, securely, and more importantly, reliably.
Kaitlyn: Segwaying now into exactly how this works within the banking and finance sector. How can banking and finance companies use this to their advantage?
Grant: Maintaining a list of BIAN APIs in Kong Gateway will allow the domains inside the bank to very quickly and efficiently create interoperability with each other. You’re doing that via BIAN with a standardized architecture and approach. This means you cut down on the amount of rework you’re doing. And it means that you are creating a standardized systems infrastructure for externals to integrate with.
Jonathan: I find Kong Gateway to be good because it’s such a lightweight API gateway for east-west traffic. Not such a heavy integration platform. It fits well with the open banking and BIAN API specifications because it's developer-centric. It allows us to integrate with our deployment pipelines, pull from the BIAN repository of API specifications and push nicely to the Kong Gateway. And once those specifications are deployed, we can share these with our third-party consumers to go away and build their side of the solution without worrying about the service implementation happening in the background.
Kaitlyn: How can banking and finance companies put all this together and use it to their advantage? BIAN, Kong Gateway, the CLI tool, all of it.
Grant: The CLI that we’ve developed will integrate the BIAN assets and allow you to create those directly in the Kong Dev Portal. So these are registered directly, and after that point, you can maintain them individually on a per-interface basis instead of the whole exhaustive list or in its entirety. This allows you the flexibility of choosing to update only the interfaces that matter to you or your consumers very quickly and very efficiently. So once it’s in there, it lowers the total cost of ownership of having the Kong Gateway in place and open banking interfaces.
Once you’ve created open banking interfaces and there are consumers on the other end, there can be a high cost to maintaining it from that point. Once you have interfaces, it’s tough to take them away. This allows you to go and maintain the interfaces, create them, delete them as you see fit through a nice and easy-to-use CLI without having to go through processes and change management and all that.
Kaitlyn: Awesome, and for folks interested in using and contributing to this, how would they go about that?
Jonathan: It takes away a lot of the hard work using the BIAN standards. Instead of figuring out how the interfaces will look themselves, they can instead look towards what BIAN has made available and use these interfaces and publish them through, for example, the Kong Dev Portal pretty simply. And this allows their people to start working faster. It takes away a lot of the overhead of designing the interfaces themselves.
In the demo below, Jonathan shows us Kobi, the tool that IntegrationWorks developed to integrate the BIAN repository of API specifications for service domains with the Kong Dev Portal. It allows them to pull from the official repository and push those to publish them to a developer portal so that the consumers can start looking at them.
I hope you'll join us again on January 24 for our next Kongcast episode with Freek Van der Herten from Spatie.
Until then, be sure to subscribe to Kongcast to get episodes sent to your inbox (and a chance to win cool SWAG)!
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross
