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, the move 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. When it fails, the cause is usually an undocumented architecture. Integration dependencies are unknown, data migration boundaries are unclear, and nobody has defined how current applications relate to target banking capabilities.

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.

The architect on a modernization program has three jobs: show what the bank runs today, show how it maps to the target, and sequence the moves so nothing that matters is switched off by surprise. By hand, that is interviews, spreadsheets and drawings that are out of date when the next wave starts. AI-augmented, the architect decides the mapping rules, the integration questions and the order of the waves, and the AI does the mechanics in the tool and the model: building the components, drafting the mappings, tracing dependencies. The skill the work asks for is knowing what a correct mapping and a complete dependency view look like, and checking the draft against it.

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, grouped into Business Areas and Business Domains. For core banking work it helps to read them by function. These groupings are illustrative; check the exact domain names against the BIAN version your program uses:

Channel Services, customer-facing touchpoints: Internet Banking, Mobile Banking, Branch Operations, Contact Center 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 it shows where there are duplications, gaps, or boundary ambiguities.

The work, in sequence

Core banking architecture in Sparx EA is built in a deliberate order, and 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, and core-banking dependency. Lifecycle status, cost and risk are not typed into the repository. AI connects to the project and portfolio, IT service management, governance, risk and compliance, and IT financial management systems that already hold them, and the model stitches that data to the components. The portfolio can then be filtered, grouped, and reported by any combination of attributes, with dashboards in Prolaborate or Power BI.

Map current applications to BIAN Service Domains

This is the first analytical activity, and it is the architect's judgment at work: which Service Domains an application really implements. 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 makes the roadmap part of the architecture instead of a separate 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), 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. Agreeing on those stereotypes is the architect's call, and the AI can then apply them across the model consistently.

From model to program governance

When the portfolio, integration topology, and roadmap are one connected, well-typed model, governance views come from the structure and need little manual effort. Because Work Packages are linked to the application portfolio and the BIAN domain model, you can report on what a transformation board cares about:

Migration wave status: which waves are on track, which are delayed, and which have unresolved dependency conflicts, read from the Work Package links and the connected program data instead of re-keyed into a slide.
BIAN domain coverage: current coverage, target coverage and the gap, at the capability level instead of 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, the main input to sequencing the core replacement.

With the model as the single source, an architect who marks a dependency migrated or updates a Work Package is changing what every view shows, with no separate export. The people who read the dashboards are the board and the program office, and the architect's part is keeping the model right.

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 which core platform is 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.

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 can teach your architects to work this way on your own repository and mentor them until it sticks, or build the BIAN-aligned portfolio and migration roadmap for you and hand it over. Most teams want some of both.

Book a call

Keep reading