BIAN and Sparx EA: Enterprise Architecture for Banking Transformation

The short version: BIAN (the Banking Industry Architecture Network) gives banks a standardized reference architecture built from discrete Service Domains — bounded areas of banking capability, each with defined responsibilities and interfaces. Modeled in Sparx EA, BIAN becomes the package structure you map your application portfolio against — an externally validated, banking-specific taxonomy rather than one your team invents from scratch. It does not replace TOGAF or ArchiMate; it sits alongside them as a content layer that accelerates core banking transformation, exposes consolidation opportunities, and gives regulatory work under DORA and Basel III a defensible structure.

For an enterprise architect inside a bank, the hardest part of any transformation is rarely the modeling notation. It is agreeing on what the bank actually does, at a level of detail both the business and the technology teams will sign off on. BIAN exists to settle that argument before it starts.

What BIAN is, and why it matters for banking EA

BIAN is a not-for-profit industry consortium whose membership spans major banks, technology vendors, and consultancies. Its core output is the BIAN Service Landscape: a hierarchical model of banking operations grouped into Business Domains — Sales and Service, Operations and Execution, Risk and Compliance, and others — and decomposed into several hundred Service Domains.

Each Service Domain carries three things:

• Purpose — the banking function the domain is responsible for.
• Service Operations — the specific capabilities it provides, expressed through BIAN’s standardized action verbs such as Initiate, Update, Retrieve, Execute, and Notify.
• Information exchange — the data objects that flow between domains.

The payoff for the architect is a pre-built, industry-validated capability taxonomy. You do not have to invent what banking capabilities look like — BIAN has already defined them with cross-vendor consensus. That matters most in the room where it counts: when you present application rationalization findings to a CTO or a board, an externally recognized framework is far harder to argue with than a model your own team drew up last quarter.

The standard moves in major versions. BIAN published version 13 in mid-2025, and the Service Landscape and supporting documentation are available from the BIAN website — in full to members, and in reference form publicly.

You are not mapping your landscape against a capability model you invented. You are mapping it against one regulators and vendors already recognize.

Importing and structuring BIAN in Sparx EA

BIAN does not ship as a built-in MDG Technology inside Sparx EA, but the Service Landscape can be brought in and structured several ways.

Package-based model import

The Service Landscape can be modeled as a reference architecture package using ArchiMate Business Capability or Application Component elements, structured to mirror the BIAN domain hierarchy. Some practitioners use XMI import from community-maintained BIAN packages; others build the structure by hand from the specification.

An MDG extension for BIAN stereotypes

A custom MDG Technology profile can define «BIANServiceDomain» and «BIANServiceOperation» stereotypes, letting BIAN elements carry standard tagged values — BIAN Version, Domain ID, Service Operations, Business Area. This keeps BIAN reference content distinguishable from your own application elements and makes structured reporting possible.

Package organization

A workable package layout mirrors the BIAN Business Area hierarchy: a top-level package per Business Area, with child packages for each Service Domain inside it.

For an active transformation program, the MDG-extended model is the one to reach for. It draws a clean line between BIAN reference content and organization-specific application elements, and it is the structure that makes downstream reporting and portfolio queries reliable rather than approximate.

The core banking transformation use case

Core banking transformation is among the most complex and expensive programs a bank will run. The familiar scenario: a bank on a legacy core — T24, Finacle, Flexcube, or something custom-built in the 1990s — is weighing replacement options. The real question is rarely “which platform do we buy.” It is “what does our current state actually look like, what depends on what, and in what order do we move?”

A BIAN-aligned model in Sparx EA answers each of those in turn.

Current-state mapping

You start by mapping existing applications onto BIAN Service Domains. Which domains does the legacy core fully support? Which are only partially covered — propping up shadow systems or manual workarounds? Which lean on third-party point solutions? The output is a BIAN coverage heat map: a single picture of where your landscape sits against the industry-standard model.

Consolidation opportunities

A BIAN-mapped current state makes redundancy impossible to miss. Four applications all claiming the Customer Management Service Domain is a consolidation signal. A domain with no supporting application but live regulatory reporting obligations is a gap that has to close before any migration begins.

Target-state definition

BIAN’s domain boundaries give you a natural unit of decomposition for the target state. Instead of drawing it from a blank canvas, the team assesses which Service Domains the candidate platform covers natively, which need bolt-on solutions, and which get decommissioned. Vendors and your internal team end up speaking the same vocabulary.

Migration sequencing

Those same boundaries shape practical migration phases. Domains with few inter-domain dependencies — readable from BIAN’s Service Operation catalog — are early-migration candidates. The high-dependency domains at the center of the service network, Account Management chief among them, demand the most careful sequencing.

The business problem is never “which platform should we buy.” It is “what do we depend on, and in what order do we move?” BIAN turns that into a structured answer.

Connecting BIAN to the TOGAF ADM

BIAN and TOGAF are complementary, not competing. TOGAF supplies the process — the ADM phases that carry an architecture from vision through migration. BIAN supplies the banking content reference model that fills those phases. A typical integration in Sparx EA looks like this:

• ADM Phase B (Business Architecture): build the capability map from BIAN Business Areas and Service Domains, with your organization’s current maturity assessed against each domain. The capability map is the BIAN Service Landscape.
• ADM Phase C (Information Systems): map the application portfolio to BIAN Service Domains, producing the coverage model.
• ADM Phases E and F (Opportunities, Migration): turn the coverage gaps and redundancies into the structure of the transformation roadmap.

The TOGAF ADM package structure in Sparx EA extends naturally to hold BIAN reference packages at each relevant phase, giving you a traceable link from the architecture development process to the domain content model.

Regulatory alignment: DORA and Basel III

DORA (the Digital Operational Resilience Act) requires EU financial institutions to assess and govern ICT risk at a granular service level, critical third-party dependencies included. BIAN Service Domain boundaries hand you ready-made ICT risk assessment units. For each domain, architects can record the supporting ICT systems, the third-party providers, the resilience requirements, and the recovery time objectives — all directly addressable in a Sparx EA model through DORA-specific tagged values on the domain elements.

Basel III compliance architecture — credit risk, operational risk, liquidity reporting — depends on traceability from business process to data source to risk calculation. A BIAN-aligned model supplies the business process taxonomy; linking those Service Domains to data architecture (canonical data models, data flows) and to regulatory reporting elements yields a traceable compliance architecture. Held in Sparx EA, that is dramatically more maintainable than the same logic scattered across a folder of spreadsheets.

From a BIAN model to portfolio intelligence

The reason to govern the BIAN structure carefully is what it unlocks afterward. A well-stereotyped model with populated tagged values is one you can interrogate, not just read. The kinds of questions a transformation lead actually asks become answerable straight from the model rather than from a manual spreadsheet pass:

• Which BIAN Service Domains are supported by more than two applications?
• Which domains in the Risk area have applications with a lifecycle status of Under Review?
• Which third-party ICT providers support Service Domains classified as critical under DORA?

Sparx EA can surface answers like these through its built-in model search, document generation, and reporting — and, where the team has a BI layer, by extracting the governed model into a dashboard. Either way, the precision of the answer depends entirely on the precision of the mapping. A BIAN structure with weak MDG governance produces vague answers no matter how it is queried; a disciplined one produces answers a CTO can act on.

Frequently asked questions

For the wider picture of how a disciplined repository becomes a strategic asset, see how we help manage the application portfolio and why teams standardize on Sparx EA for work at this scale.