Short answer. The reliable move is to wrap the core, not replace it. You place an integration layer of APIs and an event stream in front of the 20-year-old system, run AI models against that layer, and leave the core processing transactions untouched. Roughly 7 in 10 full core-replacement programs run over budget or over schedule, so wrapping reaches production in months instead of betting the bank on a rewrite. Ableneo shipped 34 production AI projects in 2025 and about 4 of 5 reached production, because the AI sits beside the core, not inside it.
A 20-year-old core banking system is not the problem people assume it is. The COBOL or Java monolith that runs accounts, ledgers, and settlement is usually stable, well understood, and audited. The problem is access. The core was designed to process batches overnight, not to answer a question in 200 milliseconds while a customer waits. AI needs the second behaviour, so the work is to build the access layer the core never had, not to tear the core out.
The pattern that works is the strangler fig. You place an integration layer in front of the core, expose the data and functions the AI needs as APIs and events, and route new AI-driven journeys through that layer. The core still owns the record of truth. The AI reads from a governed copy and writes back through controlled interfaces. Over time more journeys move to the new layer, and the core does less, but no single release bets the bank on a rip-and-replace.
Three moves carry most projects:
Ableneo has run this pattern inside financial-services clients across Slovakia, the Czech Republic, and Austria, including ČSOB, Erste, and UNIQA. Of the 34 production AI projects shipped in 2025, 94% used large language models, and the ones tied to legacy cores reached production because the integration layer came first and the model came second.
For a bank or insurer in Central Europe, the core is the system supervisors care about most, so anything you attach to it inherits regulatory weight. Under the Digital Operational Resilience Act, in force across the EU since 17 January 2025, an AI model that reads from or writes to a core banking platform is an ICT asset supporting a critical function. It falls under ICT change management, testing, and monitoring the same way the core does. Bolting an AI service onto the core without registering it and controlling the change is a DORA finding waiting to happen.
The EU AI Act adds a second layer. A model that scores credit or prices insurance on data drawn from the core is high-risk under Annex III, which brings obligations for human oversight, logging, and technical documentation. The integration layer is where those obligations become practical: it is the single place to log every model call, enforce human sign-off, and prove the AI never bypassed a control the core enforces. Build the layer for compliance, not only for connectivity, and one piece of architecture answers both the resilience question and the accountability question.
Wrap the core, not replace it: an integration layer of APIs and events runs the AI while the 20-year-old core keeps processing transactions untouched.
Timing breaks first. A 20-year-old core runs on batch cycles, so the balance an AI model reads at 10:00 may reflect last night’s position, not this morning’s. When a model makes a decision on stale data, the error is silent until reconciliation. Instant payment rails make this sharper. SEPA Instant settles in under 10 seconds with no callback window, so a fraud model that was built to score a transaction after an overnight batch has no time to act. The second thing that breaks is data quality: fields that a human teller interpreted by convention for two decades arrive at the model as blanks, codes, or free text. The model does not know the convention, so it treats noise as signal. Neither failure is about the AI itself; both come from feeding a real-time model from a system that was never asked to speak in real time.
No. Full core replacement is the most expensive and riskiest route, and it fails often enough that most banks now avoid it for AI specifically. Industry analyses of large core programs put budget and schedule overruns above 100% on the majority of full replacements. The wrapper approach reaches production in months, not years, because it changes nothing inside the core. You add an integration layer, you govern it, and you decommission core functions only when a replacement has proven itself in parallel. Replacement may still be the right long-term call for other reasons, but it is not a prerequisite for putting AI to work.
Change data capture is the bridge. Instead of waiting for the nightly batch, you capture each committed change in the core’s database and publish it to an event stream the model subscribes to. The model then works from a near-live view without adding load to the core and without changing a line of core code. For reads, a dedicated operational data store or read replica gives the model a fast, isolated copy to query. For writes, the AI recommends an action through an API and the core applies it under its own controls, which keeps the record of truth in one place and the model’s latency off the core’s critical path.
Three things follow immediately. First, register the AI system and its integration layer in the ICT asset inventory with an owner and a risk classification, because an unregistered component is treated as an ungoverned one. Second, run the addition through formal ICT change management, with testing and a rollback path, since the core supports a critical function. Third, if the model or its data pipeline comes from a vendor, that vendor is an ICT third party under DORA Articles 28 to 30, which means a contract with audit rights, a place in the register of information, and a documented exit plan. The integration layer makes all three easier, because it is the one boundary where every AI interaction with the core can be logged and controlled.
Map the data the AI actually needs and how fresh it has to be, before writing any model. Most legacy integration failures trace back to a mismatch between the freshness the use case demands and the freshness the batch core delivers. Once that map exists, pick one journey where the value is clear and the data is reachable, wrap the core functions it touches, and ship that single journey to production under full governance. One governed journey in production teaches more than a year of architecture diagrams, and it gives every later journey a proven layer to build on. Access first, one journey second, scale third.
Ableneo builds AI inside regulated production environments, not around them. The team’s work with banks and insurers on 20-year-old cores starts with the integration layer and the governance that DORA and the EU AI Act require, then adds the model, which is why roughly 4 of 5 Ableneo projects reach production against an industry backdrop where most AI pilots do not. Ableneo understands legacy core banking and insurance platforms as well as the models that run beside them, so the AI ships and the core keeps running. See how this fits an end-to-end programme on our AI transformation approach.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.