BIAN stands for the Banking Industry Architecture Network, a global not-for-profit association that defines a semantic standard for banking. It was formed in 2008 by banks and solution providers who wanted one shared architecture, describing what banking functions must do rather than how systems implement them.

What is BIAN, and why does it exist?

BIAN, the Banking Industry Architecture Network, is a global not-for-profit association of banks, solution providers, consultants, integrators and academic partners. Formed in 2008, it exists to define one semantic standard for banking, covering nearly every architectural layer a financial institution relies on, from business functions to information exchange.

The BIAN Association describes its own founding purpose in one clear sentence. "The Banking Industry Architecture Network (BIAN) is a global, not-for profit association of banks, solution providers, consultancy companies, integrators and academic partners with the shared aim of defining a semantic standard for the banking industry covering almost all the well-known architectural layers" (BIAN 2nd Edition, section 1.1.1). That founding idea, one shared vocabulary instead of dozens of proprietary ones, still drives everything the association publishes today.

The association grew beyond its founding banks and solution providers. Standards bodies such as ISO and IFX later joined, together with academic partners, widening BIAN's perspective across the industry. The underlying goal has stayed constant: improving integration through an architecture built on services.

What does a Service Domain actually contain?

The Service Domain is BIAN's core building block, a defined slice of banking functionality with its own semantic meaning. The full collection of Service Domains forms the Service Landscape, BIAN's overview of the functional capabilities that make up a bank.

The book states this plainly: "The main fundamental building block within the BIAN Reference Architecture is the 'Service Domain'" (section 1.1.3). Each Service Domain captures a specific piece of banking meaning, such as handling a payment instruction or maintaining a customer record, independent of any particular software product.

Together, these Service Domains form the Service Landscape, BIAN's map of every functional capability a bank needs. That landscape acts as the reference point banks and vendors use to compare, integrate, or replace individual capabilities without redesigning everything else.

Why is BIAN described as a semantic standard?

BIAN is semantic because it defines what banking activities must accomplish, not how software should carry them out. That separation keeps the standard stable over time, since implementation technology changes far faster than the underlying banking concepts it describes.

The book is explicit about this design choice: "BIAN is semantic. It describes what needs to happen/needs to be known and not how and what with this should be implemented" (section 1.3). A bank replacing its payment engine, for example, can keep the same BIAN definitions even as the underlying technology changes completely.

BIAN documents these semantics using the ArchiMate and UML notations, and the association has published guidance on applying its deliverables within the TOGAF framework. It does not, however, prescribe a single implementation methodology of its own.

When would a bank actually use BIAN?

Banks turn to BIAN when they need a shared vocabulary for integration projects, vendor selection, or API design. Because BIAN is exhaustive and covers all domains of banking activity, it works equally well for core banking, payments, or compliance-driven initiatives.

BIAN's own documentation calls this exhaustiveness a defining trait: "BIAN is exhaustive. It covers all domains of banking activity" (section 1.3). Between 2018 and 2021, the association placed particular emphasis on standardizing API specifications, extending that broad coverage into the practical world of system-to-system integration.

Adopting BIAN typically lowers integration costs and increases reuse of existing capabilities across a bank's systems. It also gives FinTechs and RegTechs a faster way to understand how a complex banking organization is structured internally.

One shared banking vocabulary

BIAN gives banks and vendors a common semantic language for what banking systems must do, leaving the how entirely up to each organization.

Frequently asked questions

BIAN was formed in 2008 by a group of banks and solution providers who wanted a shared semantic standard for financial services. Over time, other standards bodies such as ISO and IFX joined, along with academic partners, broadening BIAN's scope and its industry credibility.

No, BIAN is deliberately not a technical implementation standard. It documents what banking functions and information must exist, using notations like ArchiMate and UML, but leaves the actual technical build to each bank or software vendor to decide independently.

The Service Landscape is BIAN's term for the complete collection of Service Domains that together describe a bank's functional capacity. It acts as an overview map, showing how individual semantic services relate to one another across the wider banking architecture.