BIAN and Sparx EA: Enterprise Architecture for Banking Transformation

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 sits alongside TOGAF and ArchiMate as a content layer, and it gives core banking transformation, consolidation decisions and regulatory work under DORA and Basel III a defensible structure.

For an enterprise architect inside a bank, the hardest part of a transformation is rarely the modeling notation. The hard part is agreeing on what the bank does, at a level of detail both the business and the technology teams will sign off on. BIAN settles that argument before it starts. The architect's job then becomes mapping every application to the domains it supports, showing where the bank has overlap and gaps, and sequencing the moves.

Done by hand, that mapping is workshops, spreadsheets and months of chasing application owners. Done AI-augmented, the architect decides how a domain is defined, which applications count as covering it and what the roadmap has to answer, and the AI does the mechanics of building the structure, drafting the mappings and checking them in the model. The skill that asks of the architect is judgment: knowing what a good mapping looks like and checking every draft against it.

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 Areas (Sales and Service, Operations and Execution, Risk and Compliance, and others) and Business Domains, 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. BIAN has already defined what banking capabilities look like, with cross-vendor consensus. That matters when you present application rationalization findings to a CTO or a board: an externally recognized framework is harder to argue with than a model your own team drew up last quarter.

The standard moves in major versions, so record which version your model uses. The Service Landscape and supporting documentation are available from the BIAN website, in full to members and in reference form publicly.

Map your landscape against a capability model that regulators and vendors already recognize, and the argument about whose taxonomy to use never starts.

Importing and structuring BIAN in Sparx EA

BIAN does not ship as a built-in MDG Technology inside Sparx EA. The Service Landscape can be brought in and structured in 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 such as BIAN Version, Domain ID, Service Operations and 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 reporting and portfolio queries reliable.

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 questions that decide the program are what the current state looks like, what depends on what, and in what order to 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.

BIAN turns “what do we depend on, and in what order do we move?” into a structured answer.

Connecting BIAN to the TOGAF ADM

BIAN and TOGAF work together. 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 easier to maintain than the same logic scattered across a folder of spreadsheets.

From a BIAN model to portfolio intelligence

A well-stereotyped model with populated tagged values is one you can interrogate. The questions a transformation lead asks become answerable from the model instead of 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?

The modern way to answer them is to leave cost, risk and lifecycle values out of the repository and out of hand-maintained tagged values. Use AI to connect to the systems that already hold that data: project and portfolio management, IT service management, governance, risk and compliance, and IT financial management. The architecture model stitches the data together around the BIAN structure and shows the relationships, and dashboards in Prolaborate or Power BI present it. The effort is lower, the result is easier to maintain, and the picture stays current. The precision of every answer still depends on the precision of the mapping, which is the architect's work.

Frequently asked questions

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