Recently, the Banking Industry Architecture Network (BIAN) published version 8.0 of its financial industry reference architecture ( This provides a comprehensive model of the business capabilities, business scenarios, service domains and business objects used in banking and other financial services.

It stands to reason that such a standard reference model should itself be expressed in a standard notation, to foster its adoption, and BIAN recognized this need. BIAN version 8.0 has therefore been expressed in the ArchiMate 3 language. The core of the BIAN reference model is its Service Landscape. This consists of discrete non-overlapping building blocks of business capacity that exchange services. Such a building block is called a service domain and is best represented in ArchiMate using the Capability concept. The interactions between the service domains realize the business activities that make a bank a bank. On top of this Service Landscape sits the Capability Landscape, the top level of which is shown below. As you can see, it also uses the ArchiMate Capability concept.


BIAN 8.0 Capability Landscape


The Service Landscape itself is a deep structure of business areas (Groupings in ArchiMate), consisting of business domains that in turn contain service domains, both modeled as Capabilities. A structure organizing these elements in the form of a value chain is shown below. As you can see, a single picture doesn’t do it justice (and you need a large monitor to view it all), so you can better explore the full structure at the link above.


BIAN 8.0 Service Landscape as Value Chain


The expression of the BIAN model in ArchiMate has been a joint effort by BIAN and The Open Group, the stewards of the ArchiMate standard. The full details of this mapping can be found in the document “ArchiMate® Modeling Notation for the Financial Industry Reference Model: Banking Industry Architecture Network (BIAN)” published by The Open Group.

To explain the use of BIAN in ArchiMate, The Open Group has published a case study whitepaper co-authored by one of us (Patrick), which uses the fictitious but realistic Archi Banking Group as an example. In this blog, we want to give you an impression of what this is about, picking and choosing some of the juiciest bits. For the full case study, please refer to the whitepaper.

Archi Banking Group is the result of the acquisition of several banks in different countries, as most international banks are nowadays. This has come with the typical challenges of integration and cost control. In particular its fragmented information is becoming a compliance risk and the challenges of ‘open banking’ (e.g. PSD2) are difficult to meet. A high-level assessment of this state of affairs is shown below, using ArchiMate’s Motivation concepts and a Course of Action to express how it intends to deal with requirements on electronic reporting to regulatory authorities.


Assessment of the Archi Banking Group Board and Regulatory Authority Drivers


As stated above, integration is a key concern for Archi Banking Group, in particular in the Payments domain. The eligibility for integration of specific service domains is analyzed by looking at the application functions that support these domains. This is shown with colors in the view below, which also depicts how these service domains relate to the principles, goals and the main driver of Profitability, also central to the previous figure.


Integration Eligibility of Service Domains


Further into the implementation, solution candidates are mapped to the service domains. The internal contenders are shown below.


Payment Support with Internal Solution Alternatives


Next to these internal alternatives, Archi Banking Group issues an RFP for service providers. Clarity for these external contenders is created by using BIAN’s Common Vocabulary and reference framework and expressing the architecture diagrams in the ArchiMate language. Expressing all alternatives in the same way allows for an equal comparison of their support for Archi Banking’s key requirements, such as straight through processing (STP), flexible compliance, functionality, interoperability, instant customer position, and of course cost.

The case study continues on from here, showing in much more detail how the solution (adapting one of the internal systems) is selected, with technology choices such as the use of a rule management system to perform automated exception handling and compliance rule management, in order to support the STP services. One of the many views of this is shown below, depicting the main applications involved in Payments and the business processes they support.



Application Usage for Payments


The case study goes further down into the IT infrastructure needed to support these applications. It also discusses the use of an API layer aligned with BIAN’s API Initiative, and the alignment of Payments services with the ISO 20022 standard, one of the other foundational standards that underpin the BIAN reference architecture.

Moreover, it describes how the implementation is planned and executed in several transition phases, encompassing everything from organizational and business process change down to technical implementation. All these steps are organized according to the phases of the TOGAF Architecture Development Method.

This blog is much too short to cover everything that is offered by the BIAN standard and the case study example, but we hope this has given you a foretaste tempting you to explore further. If you want to know more, please don’t hesitate to get in touch!


Share on LinkedIn