Industries
Financial services organizations use Sparx EA for application portfolio management, regulatory compliance architecture (DORA, Basel, Solvency II), business capability mapping using BIAN, and data architecture governance. The EA repository in financial services is not a documentation tool: it is a compliance artefact. Regulators expect documented ICT architecture, demonstrable third-party dependency mapping, and evidence of architectural governance. AI integration in financial services typically requires data residency controls: DORA Article 28 third-party risk requirements affect which AI APIs can access EA data: Azure OpenAI (configurable EU data residency) or Kernaro AI Hub (on-premises configurable) over public APIs.
Key Takeaways
BIAN (Banking Industry Architecture Network) defines 330+ standardized banking service domains: discrete units of banking capability with standardized names, definitions, and service operation patterns. Service domains include examples like Customer Offer, Credit Risk Models, Regulatory Compliance, Payment Execution, and Fraud Detection: each defined at a level of granularity that maps to a bounded capability area a system or set of systems should deliver.
In Sparx EA, BIAN service domains function as the capability reference model: the structured vocabulary against which the current-state application portfolio is mapped. An MDG profile for BIAN defines service domain elements as stereotyped components, with tagged values capturing BIAN metadata (functional pattern, service domain category, BIAN version) and relationship types that express service domain interactions.
The core BIAN use case in Sparx EA: import or model the BIAN service domain hierarchy, then map every application in the current-state portfolio to the service domains it supports. The output makes visible what is otherwise opaque in large banking organizations:
This analysis is what application portfolio rationalization boards need: and it only works if the MDG governance is consistent enough that “mapped to BIAN service domain X” means the same thing across every application record in the repository.
With EA GraphLink connecting the BIAN-mapped repository to Kernaro AI Hub, the portfolio analysis that previously required custom reports and off-line data exports becomes a natural language query interface. Architecture managers can ask: “Which service domains are covered by more than three applications?” or “Which acquired entity applications have not been mapped to BIAN service domains?” The AI query layer doesn’t replace the underlying portfolio analysis: it makes it accessible without requiring model-level Sparx EA access for every stakeholder who needs the answer.
DORA (EU 2022/2554) came into full application in January 2025. Its requirements for ICT risk management architecture, third-party ICT dependency documentation, and incident classification create a direct and specific demand for structured EA capability:
AI tools that access the EA repository are themselves ICT third-party providers under DORA Article 28: they must appear in the third-party register and be subject to the third-party risk assessment process. This is the compliance mechanism that makes public AI API integration non-viable for most European financial institutions without significant legal and compliance review.
Basel III and the EBA’s associated guidelines on ICT and security risk management require banks to document technology risk architecture in support of capital requirement models. Sparx EA maintains the technology topology: applications, infrastructure components, and their dependencies: that feeds into technology risk assessments. For Internal Capital Adequacy Assessment Processes (ICAAP), the technology risk section requires documented evidence of architectural controls; Sparx EA models are the documentation.
For insurers operating under Solvency II, the Own Risk and Solvency Assessment (ORSA) and Pillar 3 reporting requirements include technology risk. The Sparx EA repository serves as the source of truth for the technology architecture evidence that actuarial and risk teams need for ORSA submissions. A well-governed repository reduces the manual effort of assembling regulatory evidence: a poorly governed one makes it worse.
Regulatory examiners increasingly expect to see live, queryable architecture documentation: not static diagrams in SharePoint. Pro Cloud Server with role-based access control can provide examination teams with read-only access to the Sparx EA repository, giving regulators direct visibility into the documented architecture without intermediary manual extraction. This is an architectural governance posture that sophisticated financial services EA programs are moving toward.
Under DORA, any external ICT service provider that supports a critical or important business function is a critical ICT third-party provider. If the EA repository documents functions that are critical or important (and in a bank, it does), then an AI tool that accesses that repository is: at minimum: an ICT third-party provider requiring assessment and registration. For tools that cross into the critical/important function boundary, DORA Article 28 requirements apply: written contractual arrangements, exit strategies, regular monitoring, and supervisory authority visibility.
This is not a theoretical compliance risk: it is a practical constraint that has led most European banks to exclude public AI APIs from EA repository integrations and to require data residency controls that public API providers do not offer.
Azure OpenAI (EU Data Residency): Azure OpenAI Service supports EU data residency configurations: data processed within EU Azure regions, with Microsoft’s data processing agreements satisfying DORA third-party risk requirements. For banks with existing Azure tenancies and Microsoft enterprise agreements, this is the lowest-friction compliant path.
Kernaro AI Hub (On-Premises Configurable): Kernaro AI Hub can be deployed within the bank’s own infrastructure: no data leaves the bank’s network boundary. This satisfies the most stringent DORA data residency requirements and eliminates the third-party AI provider classification issue entirely. The trade-off is infrastructure and operational overhead.
What Discover Covers:
BCBS 239 (Basel Committee on Banking Supervision Principles for effective risk data aggregation and risk reporting) requires banks to show data lineage: the ability to trace reported risk figures back to their source data, through every transformation and aggregation step. Sparx EA’s data modeling capability (UML class diagrams for data entities, ArchiMate data layer for data architecture) supports the documentation of data flows and transformation logic that BCBS 239 compliance requires.
The practical challenge: data lineage documentation that lives only in Sparx EA models is only as current as the last model update. Connecting Sparx EA to data catalog tools (Collibra, Alation, Microsoft Purview) creates a bi-directional relationship between architectural-level data flow documentation and technical-level data lineage scanning: a pattern that leading CDO functions are adopting.
Financial services CDOs use Sparx EA for canonical data model documentation: the enterprise-level data entities (Customer, Account, Product, Transaction, Counterparty) that all systems must conform to. Sparx EA UML class diagrams maintain the canonical model with relationship types, cardinality, and tagged values for data ownership and stewardship. Applications map to the canonical model entities they produce and consume: creating data responsibility documentation that regulatory submissions require.
The AI opportunity for CDOs: natural language queries against the data architecture. “Which systems produce data for the Customer canonical entity and have not been mapped to the BCBS 239 data dictionary?” becomes a query rather than a manual investigation. This requires EA GraphLink connecting the data architecture models to the AI query interface: and clean MDG governance of the data entity model as the prerequisite.
Financial services organizations operate GRC (Governance, Risk, and Compliance) platforms: ServiceNow GRC, Archer, MetricStream: alongside their EA tooling. The integration point is control-to-architecture: a control in the GRC tool maps to the systems and processes it controls, which are documented in Sparx EA. Sparx EA’s API supports integration patterns that create this linkage, making regulatory control testing and evidence collection more efficient. Connect engagements scope and implement these integrations.
What is BIAN and how does it work with Sparx EA?
BIAN (Banking Industry Architecture Network) is an industry consortium that defines a standardized service domain model for banking: 330+ discrete banking capability domains with standardized names, definitions, and service operation patterns. In Sparx EA, BIAN service domains are implemented as an MDG profile with stereotyped elements representing each service domain. The current-state application portfolio is mapped to these domains, enabling structured capability analysis, gap identification, and rationalization planning against a vendor-neutral reference model.
How does Sparx EA help with DORA compliance documentation?
DORA requires documented ICT risk management architecture, third-party ICT dependency mapping, and ICT asset registers for critical and important business functions. Sparx EA is the tool for maintaining all of these: the application and technology architecture documents ICT assets; dependency relationships document third-party ICT providers; and the architecture governance process provides evidence of ICT risk management. Sparx Services configures Sparx EA with DORA-aligned MDG profiles and tagged values to ensure the repository structure satisfies regulatory evidence requirements.
What AI integration restrictions apply under DORA Article 28?
Any AI tool that accesses the EA repository and supports a critical or important business function must be assessed as an ICT third-party provider under DORA. For tools meeting the critical/important threshold, written contractual arrangements, exit strategies, and supervisory authority visibility are required. In practice: public AI APIs (without data processing agreements and EU data residency controls) are not viable for most European banks. Azure OpenAI with EU data residency or Kernaro AI Hub on-premises are the compliant paths.
How do we manage an application portfolio of 1,000+ applications in Sparx EA?
Scale in Sparx EA requires: consistent MDG governance (every application record uses the same profile, the same tagged values, the same relationship types), structured import/export processes for portfolio data that originates in CMDBs or ServiceNow, and a capability model (BIAN service domains or a custom capability hierarchy) that provides the mapping target. Without consistent MDG, the repository cannot support portfolio analysis at scale: you have 1,000 records, not a portfolio. Discover assesses the baseline; Deploy builds the repository structure; Amplify develops the team practice that maintains it.
Can Sparx EA model data lineage for BCBS 239 compliance?
Sparx EA models data architecture: canonical data entities, data flows between systems, and transformation logic: at the architectural level. This architectural data lineage documentation complements (but does not replace) technical data lineage scanning tools. For BCBS 239, the combination of Sparx EA’s architectural data model and a data catalog tool’s technical lineage provides the end-to-end traceability regulators require. Sparx Services has implemented this integration pattern with financial services clients using Microsoft Purview and Collibra.
What is the recommended AI integration path for a European bank under DORA?
Azure OpenAI Service with EU data residency configuration (Sweden Central or West Europe regions) within the bank’s existing Azure tenant, with Microsoft’s standard data processing agreement in place. This satisfies DORA’s data residency requirements and positions Microsoft as a documented ICT third-party provider that most European banks already have in their third-party register. For banks requiring zero external data transmission, Kernaro AI Hub deployed on-premises is the alternative. Discover scopes the specific configuration required.
How does Sparx EA connect to GRC tools?
Sparx EA’s REST API and database-level integration capabilities support connections to GRC platforms including ServiceNow GRC, Archer, and MetricStream. The integration pattern links control objects in the GRC tool to the architectural elements (applications, processes, data) they control in Sparx EA. EA GraphLink can extend this to AI-assisted compliance analysis: “Which DORA controls map to systems that haven’t been updated in the current architecture review cycle?” A Connect engagement designs and implements these integrations.
What does a Discover engagement cover for a financial services organization?
A financial services Discover engagement ($25K–$75K, typically 6–10 weeks) covers: MDG baseline assessment against BIAN and TOGAF profile requirements, DORA ICT asset register completeness review, data architecture assessment against BCBS 239 documentation requirements, AI integration feasibility study including DORA Article 28 third-party classification, Azure tenancy review for data residency configuration, and a prioritized recommendations report scoped to your regulatory obligations and AI integration objectives.
Financial services EA programs operate under regulatory obligations that generic EA consultancies don’t understand. BIAN, DORA, BCBS 239: these are not background context, they are the delivery requirements.
Discover ($25K–$75K): MDG readiness assessment, DORA compliance architecture review, AI integration feasibility scoped to your regulatory environment.
Connect ($50K–$185K+): EA GraphLink implementation with Azure OpenAI (EU data residency) or Kernaro AI Hub, including DORA third-party risk documentation for the integration.
Start a Discover Conversation → | Azure OpenAI Integration Guide →
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.