Insight · Industry

Digital Banking Architecture: Core Banking Modernization with Sparx EA and BIAN

By Sparx Services · July 6, 2025 · 9 min read

Core banking modernization — moving from a monolithic platform such as Temenos T24, FIS Profile, or Finastra Fusion to a composable, API-first architecture — is one of the highest-risk, highest-value change programs a financial institution can undertake. It fails most often not because the technology is wrong, but because the architecture is undocumented: integration dependencies are unknown, data migration boundaries are unclear, and the relationship between current applications and target banking capabilities is undefined.

Sparx EA is where the current-state application portfolio is documented, mapped to BIAN Service Domains, and connected to a migration roadmap — so the transformation starts from a known position instead of a guess.

Why core banking modernization is an architecture problem

The monolithic legacy

Core platforms like Temenos T24, FIS Profile, Finastra Fusion, and Silverlake Axis were designed in an era of batch processing and tightly coupled subsystems. They manage the system of record for current accounts, savings, loans, and payments through internal data stores, proprietary APIs, and processing logic that is deeply intertwined. Channel applications, product engines, risk systems, and regulatory reporting are all wired directly into the core.

That coupling creates the modernization problem. When a bank wants to replace or componentize its core, it discovers that:

Integration dependencies are undocumented. Nobody has a complete list of which downstream systems call which core APIs, at what frequency, with what data contracts.
Data migration boundaries are unclear. The core database typically holds data spanning multiple logical domains — customer records, product definitions, transaction histories, and ledgers are co-mingled in a schema designed for performance, not separation of concerns.
Decommission sequencing is unknown. Without a complete map of what depends on the current core, program managers cannot sequence the decommission safely.

These are architecture documentation failures, and they are solved by building the architecture model before the transformation begins — not during delivery, when the gaps become costly.

What composable banking requires

The target state most banks are moving toward replaces the monolith with loosely coupled, API-first components that correspond to distinct banking capabilities. The BIAN Service Domain model provides the canonical decomposition. A composable platform is governed by clear domain boundaries (each Service Domain owns its data), published API contracts (all inter-domain communication goes through documented APIs), and orchestration patterns (complex processes such as account opening are implemented as orchestrated API sequences, not monolithic transaction logic). Getting there requires knowing exactly what the current state is — which is why Sparx EA and BIAN together are the right foundation.

BIAN Service Domains in practice

The BIAN model

BIAN is an industry association that defines a canonical Service Domain model for banking. A Service Domain is a self-contained banking capability with a defined scope, a defined set of control records (the data it owns), and a set of behavior qualifiers (the operations it performs). BIAN defines over 300 Service Domains, organized into functional domains:

Channel Services — customer-facing touchpoints: Internet Banking, Mobile Banking, Branch Operations, Contact Centre Operations, ATM Network Operations.
Customer Management — customer lifecycle: Customer Profile, Customer Relationship Management, Prospect Management, Customer Servicing.
Product Management — the product catalog and lifecycle: Product Directory, Product Agreement, Current Account, Savings Account, Consumer Loans, Mortgages, Credit Cards.
Operations — back-office operations: Payment Execution, Nostro Reconciliation, Currency Exchange, Clearing and Settlement, Position Keeping.
Risk and Compliance — regulatory compliance: Regulatory Reporting, Compliance Reporting, Financial Accounting, Fraud Evaluation, Credit Risk Operations.

BIAN gives you a reference for what a bank's current applications should map to — and where there are duplications, gaps, or boundary ambiguities.

The work, in sequence

Core banking architecture in Sparx EA is built in a deliberate order. Each step depends on the one before it.

Inventory the current-state portfolio

Model every application in the banking estate as an ArchiMate Application Component in Sparx EA. Each component carries tagged values defined by a custom BIAN MDG profile: primary BIAN domain, the specific Service Domains it implements, a system-of-record flag, technology status (Current, Legacy, Strategic, or Decommission target), core-banking dependency, and integration count. The portfolio can then be filtered, grouped, and reported by any combination of attributes — directly from the repository, without manual pivot tables.

Map current applications to BIAN Service Domains

The first analytical activity. The mapping reveals duplication (two or more applications implementing the same Service Domain — multiple customer stores, multiple product catalogs, multiple payment engines), gaps (Service Domains with no current coverage, often run by ad hoc processes), and misalignment (applications that straddle BIAN boundaries — the hardest components to componentize). Without this mapping, the program is building toward a target without knowing where it starts.

Document the integration topology

Capture integration through ArchiMate Application Interfaces. Each component exposes interfaces representing its integration points, connected by Application Interaction relationships carrying metadata: integration standard (REST/JSON, SOAP/XML, batch file), direction, trigger type, and criticality (P1 real-time, P2 same-day, P3 batch). This is what enables safe migration sequencing — when you need to replace the current-account module, the interface view shows every downstream system that calls its APIs.

Build the target canvas and migration roadmap

The BIAN Architecture Canvas is an ArchiMate Application-layer view of the future platform, organized by Service Domain cluster, showing which domains each technology component provides and which API contracts govern their interactions. The roadmap lives in the ArchiMate Implementation and Migration layer as Work Packages — each linked to the components it delivers, the components it retires, its predecessor dependencies, and the BIAN domains it addresses. That linkage is what makes the roadmap architecture-grade rather than a Gantt chart.

MDG design for BIAN banking architecture

A BIAN-aligned MDG Technology profile for core banking modernization defines a small set of stereotypes:

«BIAN-Application» extends the ArchiMate Application Component with BIAN-specific tagged values: BIAN_Domain, BIAN_ServiceDomains (multi-value), SystemOfRecord (boolean), TechStatus (Current | Legacy | Strategic | Decommission), CoreBankingDependency (boolean), and BIANAPIConformance (Conformant | Partial | Non-conformant | N/A).

«BIAN-WorkPackage» extends the ArchiMate Work Package with MigrationWave, BIANDomainsAddressed (multi-value), and CoreBankingPhase (Pre-migration | Migration | Post-migration).

These stereotypes are defined in the MDG technology XML and applied through the Sparx EA stereotype picker — so every architect on the program applies consistent classification without relying on naming conventions or free-text notes.

From model to program governance

The payoff of building the portfolio, integration topology, and roadmap as a connected, well-typed model is that governance views fall out of the structure rather than out of manual effort. Because Work Packages are linked to the application portfolio and the BIAN domain model, you can report on what genuinely matters to a transformation board:

Migration wave status — which waves are on track, which are delayed, and which have unresolved dependency conflicts, read from the Work Package links rather than re-keyed into a slide.
BIAN domain coverage — current coverage versus target coverage versus gap, at the capability level rather than the project level.
Decommission schedule — which applications are due for retirement in each window, what they depend on, and which still have open integration dependencies.
Core-banking dependency map — every application with a direct core dependency, by migration status, which is the critical input to sequencing the core replacement.

Maintaining the model as the single source means a tagged-value change by an architect — marking a dependency migrated, updating a Work Package's status — is reflected wherever that view is consumed, without a separate manual export.

Frequently asked questions

What is BIAN and why does it matter for core banking modernization?

BIAN, the Banking Industry Architecture Network, is a non-profit association that publishes a reference architecture for banking — the Service Domain model, which decomposes banking into over 300 bounded domains, each with defined scope, data ownership, and API contracts. It matters because it gives a transformation a shared language for mapping current applications to target components. Without a reference model, stakeholders use different terms for the same capabilities, making a coherent roadmap impossible.

Which core banking platforms does Sparx EA work with architecturally?

Sparx EA is platform-agnostic — it documents the architecture of the banking estate regardless of the core in use. The BIAN mapping applies equally to Temenos, FIS, Finastra, Silverlake, Thought Machine, and cloud-native cores such as Mambu and 10x. The goal is to understand which Service Domains each platform provides and where the gaps and duplications are.

How long does the BIAN mapping exercise take?

For a mid-sized bank with 50 to 150 in-scope applications, the mapping typically takes four to eight weeks. It depends on how well the current portfolio is documented, the availability of technical subject-matter experts for each application, and the complexity of the integration topology. We run it through a structured workshop series combined with repository analysis.

What is the biggest architecture mistake in core banking transformation programs?

Beginning vendor selection and contract negotiation before documenting the current-state integration topology. Banks select a vendor on capability demos, then discover during implementation that integration complexity is far greater than assumed — integrations thought to be simple REST calls turn out to be business-critical batch processes. Document the as-is architecture (see Paralysis to a Plan) before committing to a replacement.

Map your core before you replace it

We build your BIAN-aligned application portfolio and migration roadmap in Sparx EA — so your transformation starts from a documented position, not an assumption.

Book a call →

Keep reading