Skip to Content

The Banking Industry Architecture Network (BIAN): Defining the Service Landcape

The Banking Industry Architecture Network (BIAN) is an independent organization that was created in 2008 to define standards and best practices for service-oriented architecture in the banking industry.  BIAN’s main goal is to reduce the integration costs that banks incur when they combine software obtained from multiple sources.  BIAN’s members include leading banks, vendors of banking applications, and service providers.


In my SDN article Getting Started with the Banking Industry Architecture Network (BIAN), which elaborates on BIAN’s value proposition for the banking industry and outlines the organizational structure, I mentioned that BIAN is breaking down banking functionality into discrete modules, and defining service interfaces to those modules.  BIAN calls this breakdown the Service Landscape.  Let’s examine what the Service Landscape looks like.

The figure below is a high-level schematic of the Service Landscape that BIAN is in the process of defining.  BIAN is working on an updated Service Landscape that will be working its way through the ratification process.


The figure reveals that the Service Landscape is structured a hierarchical, functional decomposition of banking functionality.  The highest level of the hierarchy is Business Area.  A Business Area is a very broad grouping of banking application functionality.  Business Areas are broken down into Business Domains.  A Business Domain is a coherent set of capabilities and responsibilities. 

Business Domains break down into Subdomains.  For example, the Markeing Business Domain of the Sales & Service Business Area breaks down into the following Subdomains:

  • Campaign  management  (plan and manage campaigns)
  • Campaign automation (support campaign execution)
  • Lead management (define lead criteria, supply leads)

The Business Area / Business Domain / Subdomain structure helps to make the Service Landscape more manageable than it would be if it were simply a flat space of functional modules.

BIAN services define interfaces to Subdomains; in other words, a Subdomain is a module that exposes service interfaces.  The Servce Landscape is being built up gradually, and a lot of work is going on to define services for the Subdomains that have already been identified. 

It’s important to know that a service of one Subdomain can depend on a service of another Subdomain.  Thus, although the Business Area / Business Domain / Subdomain breakdown is strictly hierarchical, cross-dependencies among Subdomains are allowed and in fact are necessary to support cross-domain business processes.  Also, note that the Service Landscape is not itself a breakdown of processes or of organizatinal structure.

In future blogs, we’ll take a look at how BIAN defines services for Subdomains.  We’ll also examine how BIAN goes about modeling business objects and message exchange, and how those models fit into the Service Landscape.

You must be Logged on to comment or reply to a post.
  • Thank you David for sharing your thoughts on BIAN.

    As you have indicated “…BIAN’s main goal is to reduce the integration costs that banks incur when they combine software obtained from multiple sources…”

    In today’s environment most banks have a process for KYC and AML and this has come about due to the pressure from the regulators. The logical progression of this would be the use of pattern recognition software for detecting suspicious activities and potential frauds. This could be insider assisted frauds, online banking, account take over, identity theft, ATM frauds etc. Frauds have a direct impact on the bottom line of banks and therefore need to be detected and closely monitored.

    In order to detect these, banks need software (which is currently available) that will address:

    – Pattern discovery through data mining
    – Profiling
    – Hybrid solutions with rules, neural networks, artificial intelligence and statistical functions

    These high end analytical systems requires integration with the core banking systems, in addition to the other satellite systems, which have the relevant data pertaining to the modules mentioned in the Service Landscape under the heading ‘Operations & Execution’.

    Will such BI and AI tools be included in the Service Landscape under the heading of ‘Analytics’? If so, under which category…is it ‘Finance & Risk Valuation’?

    • The answer to your question is not a simple yes or no.  Some fraud detection requires simple checks against a blacklist, while some requires heavy analytics, as you’ve mentioned. Thus, there is no single Domain responsible for fraud detection.

      The Finance & Risk Valuation domain,  breaks down into the following subdomains:

      •     Credit Risk Valuation
      •     Market Risk Valuation
      •     Liquidity Risk Valuation
      •     Operational Risk Valuation
      •     Financial Accounting Valuation
      •     Profitability Valuation