Short answer. No. Most AI use cases in banking and insurance run successfully on top of an untouched core system through an integration layer: an API wrapper, an event stream, or a replicated data store. Full core replacement is a multi-year, eight- to nine-figure program that should be justified on its own transaction-processing and cost-to-serve merits, not treated as a prerequisite for AI. Of the 34 production AI projects Ableneo shipped in 2025, the large majority ran against an existing, unreplaced core system.
Banks and insurers with 15 to 25-year-old core platforms almost never need to touch the core to ship an AI use case. Three integration patterns cover most of what a first AI project needs, and none of them require a rip-and-replace program.
The first is an API wrapper: a modern service layer sits in front of the mainframe or core banking package and translates requests into a format the core already understands. The AI system, a fraud model or a document processing agent, calls the wrapper, never the core’s native interfaces or its COBOL, PL/I, or proprietary batch logic. The second is event streaming or change data capture: the core’s transaction log feeds a message bus, and AI systems subscribe to the events they need in near real time, without querying the core directly. The third is data replication: a nightly or hourly copy of core data lands in a separate store, typically a lakehouse or a data warehouse, purpose-built for AI and analytics workloads so the read load never touches the production transaction system.
Ableneo’s roughly 80% delivery rate, four of five AI projects that start reach production, holds specifically because most of that work is scoped against an integration layer, not against a core replacement timeline that would push delivery out by years.
From 2 December 2027, high-risk AI systems under Annex III of the EU AI Act, including credit scoring and life and health insurance risk assessment and pricing, carry full obligations: a documented risk management system, data governance controls, technical documentation, human oversight, and logging. The Digital Omnibus pushed that deadline back from its original date of 2 August 2026. None of those obligations depend on which system the AI reads from. A bank that waits for a core replacement before building the required governance around a live credit-scoring model is not managing risk, it is delaying compliance.
DORA adds a second layer that CIOs in Slovakia, Czechia, and Austria feel directly. Since January 2025, financial entities must maintain a register of ICT third-party dependencies and run risk management and resilience testing across every critical system, including any integration layer that sits between AI and the core. An API wrapper or an event bus is not a side project once an AI system depends on it; it is a component in the register, with its own risk owner and its own resilience requirements.
Full core replacement is not a prerequisite for AI. Most use cases run through an API wrapper, an event stream, or a replicated data store instead.
Wrapping means building a service layer, usually a set of REST or gRPC APIs, that exposes discrete, well-defined operations the core already performs: check balance, post transaction, retrieve policy status. The wrapper does not rewrite the core’s business logic; it standardizes access to it. Engineering effort typically goes into three things: authentication and authorization for the new callers, translating the core’s native data formats into a modern schema, and adding a caching or queuing layer so bursts of AI-driven calls do not overload a system built for batch, not real time. A well-built wrapper for a single domain, payments, claims, or account servicing, is usually a project measured in months, not years.
Wrapping stops being sufficient in three specific situations: when the core cannot support the latency an AI use case needs (real-time fraud scoring against a system with a four-hour batch cycle will not work no matter how good the API layer is), when the core’s data model is missing information the AI needs and cannot be extended without a core-level change, or when the vendor has declared end-of-life and no further APIs, patches, or extensions will ship. In those cases, the decision to modernize the core is real and should be made, but it is a separate business case from the AI project, with its own ROI built on operating cost, staffing risk, and product velocity, not on AI enablement alone.
Build a narrow slice of both together, scoped to one use case. Building a comprehensive API layer for the entire core before picking an AI use case is how integration projects stall for 18 months with nothing shipped. The faster path is to pick one AI use case with a clear owner and a measurable outcome, then build only the API endpoints, event topics, or replicated tables that use case needs. Ableneo’s production track record, 34 shipped projects across banking, insurance, telecom, and energy in 2025, consistently favors this narrow-scope-first sequencing over a big-bang integration layer built ahead of demand.
Under DORA, any ICT system supporting a critical or important function must be entered in the register of information, mapped for interdependencies, and included in the institution’s ICT risk management framework. An API wrapper, event bus, or replicated data store that an AI system depends on for a regulated function, credit decisions, claims payouts, transaction monitoring, meets that bar. That means assigning an internal risk owner to the integration layer itself, not just to the AI model or the core system, and including it in incident response and resilience testing scope, including threat-led penetration testing for entities in scope of TLPT.
Three things, in order. First, confirm the specific data the use case needs and where it already exists, most of it is usually already exposed somewhere. Second, pick the lightest integration pattern that meets the latency and volume requirement: wrapper before event stream, event stream before full replication, replication before any core change. Third, name a single accountable owner for the integration layer’s uptime, security, and DORA register entry before the AI system goes live, not after an incident forces the question.
Ableneo shipped 34 production AI projects in 2025 across four countries and seven industries, and 94% of that work involved LLMs running against existing systems, not systems rebuilt for the occasion. Working with financial institutions in the Erste Group network, with ČSOB and Česká spořitelna, and with UNIQA’s Slovak and Austrian operations gives a direct, repeated view of what a 15 to 25-year-old core can and cannot support, and where the integration layer, not the core, is the real engineering problem. Ableneo’s AI transformation practice scopes the integration pattern before it scopes the model, which is why the average client returns for 1.7 projects rather than one.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.