Direct Answer: BIAN (Banking Industry Architecture Network) is an industry consortium that defines a standardised reference architecture for banking operations, structured around discrete Service Domains — bounded areas of banking capability with well-defined responsibilities and interfaces. In Sparx EA, BIAN provides a reference package structure for organising your application portfolio against industry-standard service domain boundaries. The practical value: instead of mapping your application landscape against an internally-invented capability model, you map it against an externally-validated, banking-specific framework that regulators and vendors recognise. BIAN does not replace TOGAF or ArchiMate — it complements them as a domain content layer. A BIAN-aligned EA model in Sparx EA accelerates core banking transformation planning, supports application rationalisation, and provides a structured vocabulary for regulatory compliance architecture under DORA and Basel III.
Key Takeaways
- BIAN provides a banking-specific reference architecture of approximately 350 Service Domains that can be imported into Sparx EA as a structured package model.
- BIAN aligns with ArchiMate at the application and business layers — Service Domains map naturally to Application Components and Business Functions.
- Core banking transformation programmes benefit significantly from a BIAN-mapped current-state model: it makes consolidation opportunities visible and provides a vendor-neutral target state framework.
- DORA and Basel III compliance architecture is more tractable when built on a BIAN foundation — the service domain boundaries create natural ICT risk assessment units.
- EA GraphLink can surface BIAN-based portfolio analysis to AI tools, enabling natural language queries against your banking architecture model.
What BIAN Is and Why It Matters for Banking EA
BIAN is a not-for-profit industry consortium with membership from major banks, technology vendors, and consultancies. Its core output is the BIAN Service Landscape — a hierarchical model of banking operations organised into Business Domains (e.g., Sales and Service, Operations, Risk) and decomposed into approximately 350 Service Domains.
Each Service Domain is defined by:
- Purpose: what banking function the domain is responsible for
- Service Operations: the specific capabilities it provides (Initiate, Update, Retrieve, Execute, Notify — BIAN’s standardised operation types)
- Information exchange: the data objects that flow between domains
The value for enterprise architects is a pre-built, industry-validated capability taxonomy. You do not need to invent what banking capabilities look like. BIAN has already defined them, with cross-vendor consensus. This matters when you are presenting application rationalisation findings to a CTO or board — the framework is recognisable, defensible, and externally validated.
BIAN is currently at version 12 (as of 2025). The Service Landscape and supporting documentation are available from the BIAN website to members and, in reference form, publicly.
Importing and Structuring BIAN in Sparx EA
BIAN does not ship as a built-in MDG Technology within Sparx EA, but the BIAN Service Landscape can be imported and structured in several ways:
Package-based model import. The BIAN Service Landscape can be modelled as a reference architecture package using ArchiMate Business Capability or Application Component elements, structured to mirror the BIAN domain hierarchy. Some EA practitioners use XMI import from community-maintained BIAN packages; others build the structure manually from the BIAN specification.
MDG extension for BIAN stereotypes. A custom MDG Technology profile can define «BIANServiceDomain» and «BIANServiceOperation» stereotypes, allowing BIAN elements to carry standard tagged values (BIAN Version, Domain ID, Service Operations, Business Area). This makes BIAN elements distinguishable from custom application elements and enables structured reporting.
Package organisation. A practical package structure for BIAN in Sparx EA mirrors the BIAN Business Area hierarchy: top-level packages for each Business Area (Sales and Service, Operations and Execution, Risk and Compliance, etc.), with child packages for each Service Domain within that area.
The recommended approach for active transformation programmes is the MDG-extended model: it provides clean separation between BIAN reference content and organisation-specific application elements, and it enables EA GraphLink to query BIAN-mapped portfolio data accurately.
The Core Banking Transformation Use Case
Core banking transformation is among the most complex and expensive programmes a bank undertakes. A typical scenario: a bank running a legacy core banking platform (T24, Finacle, Flexcube, or a custom system built in the 1990s) is evaluating replacement options. The business problem is not “which new platform should we choose” — it is “what does our current state look like, what are we dependent on, and what is the right migration sequencing?”
BIAN in Sparx EA addresses this directly:
Current state mapping. The first step is mapping existing applications against BIAN Service Domains. Which Service Domains are currently supported by the legacy core? Which are partially supported (creating shadow systems or manual workarounds)? Which are supported by third-party point solutions? The result is a BIAN coverage heat map — a visual representation of where the current application landscape maps against the industry-standard service domain model.
Consolidation opportunity identification. A BIAN-mapped current state makes redundancy visible. If four applications all claim to support the Customer Management Service Domain, that is a consolidation signal. If a Service Domain has no supporting application but generates regulatory reporting obligations, that is a gap requiring attention before any migration begins.
Target state definition. BIAN’s service domain boundaries provide a natural unit of decomposition for target state architecture. Rather than drawing the target state from scratch, the architecture team evaluates which Service Domains the candidate core banking platform covers natively, which require bolt-on solutions, and which will be decommissioned. The BIAN framework gives vendors and the internal team a shared vocabulary.
Migration roadmap structuring. BIAN Service Domain boundaries also define practical migration phases. Domains with fewer inter-domain dependencies (defined in BIAN’s Service Operation catalogue) are candidates for early migration. High-dependency domains — typically those at the centre of the BIAN service network, like Account Management — require more complex sequencing.
Connecting BIAN to TOGAF ADM
BIAN and TOGAF are complementary, not competing. TOGAF provides the process framework for architecture development — the ADM phases (Preliminary, Architecture Vision, Business Architecture, Information Systems, Technology, etc.). BIAN provides the content reference model for banking domain architecture.
A typical integration in Sparx EA:
- ADM Phase B (Business Architecture): Build the business capability model using BIAN Business Areas and Service Domains as the reference framework. The capability map IS the BIAN service landscape, with your organisation’s current maturity assessed against each domain.
- ADM Phase C (Information Systems): Map your application portfolio to BIAN Service Domains. This produces the BIAN coverage model.
- ADM Phase E/F (Opportunities, Migration): Use the BIAN coverage gaps and redundancies to structure the transformation roadmap.
The TOGAF ADM package structure in Sparx EA can be extended to include BIAN reference packages at each relevant phase, creating a traceable link between the architecture development process and the domain content model.
Regulatory Alignment: DORA and Basel III
DORA (Digital Operational Resilience Act) requires EU financial institutions to assess and govern ICT risk at a granular service level, including critical ICT third-party dependencies. BIAN Service Domain boundaries create natural ICT risk assessment units. For each Service Domain, architects can document the supporting ICT systems, the third-party providers, the resilience requirements, and the recovery time objectives. This is directly addressable in a Sparx EA model with DORA-specific tagged values on Service Domain elements.
Basel III compliance architecture — specifically around credit risk, operational risk, and liquidity reporting — requires traceability from business process to data source to risk calculation. A BIAN-aligned model provides the business process taxonomy; linking BIAN Service Domains to data architecture (canonical data models, data flows) and to regulatory reporting elements creates a traceable compliance architecture. This is more maintainable in Sparx EA than in a collection of spreadsheets, and significantly more queryable via EA GraphLink.
EA GraphLink and BIAN-Based Portfolio Intelligence
With a BIAN-aligned model in Sparx EA and EA GraphLink connected, the architecture team can expose banking portfolio intelligence to AI tools and BI dashboards. Examples of queries EA GraphLink enables:
- “Which BIAN Service Domains are supported by more than two applications?”
- “Which Service Domains in the Risk domain have applications with a lifecycle status of Under Review?”
- “Which third-party ICT providers support BIAN Service Domains classified as critical under DORA?”
These queries, accessible via Kernaro AI Hub’s natural language interface, replace manual spreadsheet compilation with live model-driven answers. The accuracy of the answers depends entirely on the quality of the BIAN mapping and the discipline of the MDG governance underneath it.
FAQ
What is BIAN and who produces it? BIAN (Banking Industry Architecture Network) is a not-for-profit industry consortium that defines a standardised reference architecture for banking operations. It is organised around approximately 350 Service Domains — bounded areas of banking capability with defined service operations and information exchanges. Members include major banks, technology vendors, and consultancies. The BIAN Service Landscape is the primary output and is used as a reference architecture for banking transformation programmes globally.
Is BIAN built into Sparx EA? No. BIAN does not ship as a built-in MDG Technology in Sparx EA. However, the BIAN Service Landscape can be imported as a structured package model, and a custom MDG Technology profile can define BIAN-specific stereotypes and tagged values. Some community-maintained BIAN packages for Sparx EA are available, or the model can be built manually from the BIAN specification.
How does BIAN map to ArchiMate in Sparx EA? BIAN Service Domains map naturally to ArchiMate Application Components (representing applications that implement the domain) and Business Capabilities (representing the organisational ability the domain enables). BIAN Service Operations map to Application Services. The combination — BIAN content modelled using ArchiMate notation — provides a standards-compliant, industry-specific architecture model.
Can I use BIAN and TOGAF together in Sparx EA? Yes. TOGAF provides the ADM process framework; BIAN provides banking domain content. A typical integration maps BIAN Service Domains as the business architecture content in TOGAF ADM Phase B, the application-to-BIAN mapping in Phase C, and BIAN coverage gaps as inputs to the migration roadmap in Phases E and F. Sparx EA supports both frameworks natively and allows a single integrated model to span both.
How does BIAN help with DORA compliance? DORA requires EU financial institutions to assess ICT risk at a granular service level. BIAN Service Domain boundaries create natural ICT risk assessment units. For each domain, architects can document supporting ICT systems, third-party providers, resilience requirements, and recovery time objectives in the Sparx EA model with DORA-specific tagged values. This produces a traceable, auditable ICT risk register aligned to banking operations.
What is the difference between BIAN Service Domains and bank-specific capabilities? BIAN Service Domains are an industry-standard taxonomy — externally defined and vendor-neutral. Bank-specific capabilities are internally-defined concepts that may not align to any external standard. Using BIAN as the reference provides a defensible, externally-validated framework for investment decisions and regulatory conversations. Banks often maintain a mapping between BIAN domains and their own internal capability language.
How long does it take to build a BIAN-mapped portfolio model in Sparx EA? For a mid-size bank with 100–300 application components, a BIAN-mapped current-state model typically takes six to twelve weeks: two to three weeks for BIAN structure setup and MDG configuration, and four to nine weeks for the application mapping work (which requires engagement with application owners across the organisation). Quality of the outcome depends on the available application inventory data and the discipline of the mapping process.
Can EA GraphLink query a BIAN-based model? Yes. EA GraphLink reads element types, stereotypes, tagged values, and connectors from the Sparx EA repository. A BIAN-aligned model with governed MDG stereotypes and populated tagged values is highly queryable via EA GraphLink — enabling AI tools and BI dashboards to answer banking portfolio questions in natural language or structured dashboard form. BIAN structure with poor MDG governance produces the same AI query quality problems as any other poorly-governed model.
AI on Top of Your Banking EA Repository
The Sparx Services Connect offering brings EA GraphLink to banking EA repositories — enabling AI-powered portfolio intelligence on top of your BIAN-mapped application landscape.
Whether you are mid-transformation or beginning your current-state mapping, Connect provides the connectivity layer that makes your architecture model a live strategic asset.
