A few years back, we wrote a blog article on the Banking Industry Architecture Network (BIAN), and it has remained one of the most visited articles on our site. We’ve continued to work with banking partners and BIAN community members since then, continuing to build on our knowledge and experience of BIAN Service Landscape and supporting artefacts.
In light of that, we feel it’s appropriate to provide an updated view on how we think BIAN is progressing, and to discuss the opportunities and challenges that financial institutions should consider as they start on their BIAN journey.
First off: if you haven’t already, check out our previous article. All of the content still holds up, especially the emphasis on applying modern DevOps practices to accelerate delivery of your BIAN services. But for your convenience, we will provide a breezy summary of BIAN here as well.
What is BIAN (again)?
BIAN is a network of banking and financial institutions, software vendors, consultants and universities committed to promoting interoperability in the financial sector. Since 2008, the network has been continuously developing and refining a reference architecture for banks. As of version 14 of the BIAN Service Landscape, 340 service domains have been modelled. These Service Domains each fulfil a discrete capability that BIAN has identified as necessary for the smooth running of a bank. This is not to say that all banks need to implement all Service Domains – one of the best features of the BIAN Service Landscape is that each Service Domain is a building block that you can choose to implement if you want to.
While the Service Domains indeed represent discrete, non-overlapping capabilities, their data models all correspond to a Business Object Model which ensures that different service domains share a common terminology. So, if you decide to implement a suite of Service Domains to fulfil a particular value stream (such as, say, converting leads to customers and establishing accounts for them), then the Service Domains will be able to share relevant data without the need to translate between the two. This sort of interoperability reduces the need for custom integrations, simplifying your tech landscape, lowering ongoing operational costs, and making it easier to build additional services going forward.
BIAN provide their Service Landscape, including the Business Object Model and Semantic APIs, free of charge online. They also provide publications to support banking architects and developers to learn the intricacies of the framework, such as the BIAN Guide (which can be purchased in either hard or soft copy) and the BIAN Semantic API Practitioners Guide (which is available for free download). In addition, they also provide a range of blog articles, informative videos, and business scenario modelling tools via their main website or the BIAN portal.
What has happened in BIAN since our last article
As mentioned above, BIAN has continued to build out its Service Landscape to cater to all capabilities that a financial institution is likely to need. In addition, it has extended its suite of Semantic APIs (242 Service Domains have Semantic APIs as of version 14). In addition, different versions of the Semantic APIs have been developed for many Service Domains, including ones aligned with the ISO20022 messaging standard, and AsyncAPI definitions for supporting messaging and event-based communication.
The introduction of AsyncAPI definitions is a clear indication from BIAN that they are treating event-driven and message-driven communications as key patterns for orchestrating cross-domain business processes. This is very much a welcome addition, as it is not uncommon for banks with a high BIAN adoption to utilise a dozen or more Service Domains to support some customer interactions. Depending on how the Service Domains have been deployed, this could involve significant network latency, which would result in a heavily impacted customer experience if all the communications are chained together synchronously.
In addition to developments of the BIAN Service Landscape and supporting documentation and tools, we have seen adoption accelerate here in Australia and New Zealand. Most major banks are either implementing BIAN or preparing to do so. We are also seeing increased interest from second-tier banks, insurance companies and FinTechs. We believe that this increased interest is partly due to greater industry awareness of BIAN, but it is also a reflection of the framework being sufficiently mature that potential adopters no longer see it as a risky, bleeding-edge approach. BIAN is becoming mainstream.
But there are still barriers to adoption…
Although BIAN does indeed support interoperability in the financial sector, it is still not a turnkey solution for implementation. There are a few reasons for this:
1. Their Semantic APIs are not implementable as-is. They never have been.
The purpose of the Semantic APIs is to provide a starting point. Not only do they lack security mechanisms and standard retrieval patterns (such as bulk results of records and pagination), their data schemas are not necessarily what an individual bank would need to implement. They may contain more data fields than are required in real life – in some cases, many more – and they may need to be modified to accommodate data that’s required to support legacy components or regulatory requirements.
2. Because the data schemas are indicative rather than formal, BIAN cannot currently be relied upon for full semantic interoperability.
There may be a future in which the APIs are formalised to the point that banks can have plug-and-play interoperability with not only their in-house solutions, but also with third party providers. We are not there yet, but at the same time, waiting until we reach that perfect state risks being left behind and failing to reap the benefits that are here right now.
3. The gap between current and target states.
BIAN’s Service Landscape may look very different from a bank’s current architecture, especially if it has grown organically over the course of decades. Core banking systems often have tight coupling between capabilities, and cleaving out these capabilities is a non-trivial task.
4. Despite all the collateral that BIAN provides, there is still no one “right way” to implement BIAN’s Service Landscape.
Some banks have chosen to faithfully implement the patterns and structures that BIAN has provided, whereas others have largely just identified existing services that fulfil the capabilities of a Service Domain and labelled them accordingly. Depending on the specific constraints of your enterprise, that second option may be sufficient (at least for the time being). But the upshot of there being so many ways to “do BIAN” is that it can be hard to envisage what good looks like, which in turn makes it hard to understand the likely cost and effort at the start of the journey.
How Fusion5 can help you break through these barriers
1. We can help you to formalise your APIs and event schemas for your enterprise.
As experts in BIAN implementation, we can help fast-track the process to creating your specialised BIAN APIs and Business Object Model. We do this by drawing on our experience with API-first development in the banking sector to create specs that accommodate your legacy and regulatory constraints while remaining faithful to the principles that BIAN promotes. This gives you an API suite that drives efficient software development in-house, as well as giving you artefacts that you can share with your third-party providers so they can implement interfaces that talk seamlessly with your applications.
2. We can provide the roadmaps to help you get to where you need to go.
The current-state/target-state gap is not a problem unique to banks – we see it in every industry, and in every customer embarking on a transformation journey. Our team of strategists, enterprise architects, solution architects, designers and implementers can work with you to sketch out a path that guarantees success, minimises risk, supports co-existence of modern and legacy components, and ensures maintainability and sustainability of your solutions.
3. We can apply our knowledge and experience as BIAN practitioners to help right-size your efforts, and to provide you with clarity around your investment.
Whether you are looking to start off small, or to implement greenfield, fully contained BIAN microservices, or anything in between, you can rely on our team’s real-world experience to advise you of the opportunities and trade-offs, and to provide transparent, evidence-based guidance on the best approach for you and your organisation.
Sean Mosely | COE Lead - Architecture - Data & Integration NZ
Sean specialises in connecting strategy, architecture, and technology to help organisations simplify complexity and deliver lasting business outcomes. He brings a pragmatic perspective on integration, modernisation, and AI adoption, grounded in real-world experience.
