Modernizing Core Banking Systems: A Strategic Guide for Financial Leaders

As banks lean into enterprisewide agentic AI adoption, they are once again confronting a familiar reality: their most critical core banking workloads are decades old applications that have become bottlenecks for AI adoption and modernization initiatives. Analysts estimate that over 40% of banks still use COBOL‑based core systems, and 45 of the world’s top 50 banks[1] continue to rely on mainframe applications for mission-critical operations, underscoring how deeply these platforms remain embedded in global finance. For years, technology leaders have understood the need to modernize these cores but lacked a practical, low‑risk path to do so within acceptable timeframes and costs. Today, the rise of agentic AI is changing that equation, offering a unifying strategy that powers new enterprise workflows while also providing the capabilities needed to map, transform, and modernize these mainframe-based core systems.

The Mainframe Application Challenge

Large financial institutions allocate 70 to 85% of their IT budgets to maintain older systems[2]. That spending keeps the lights on but leaves little room to build new capabilities or respond to shifting customer expectations. The challenge goes beyond cost; mainframe application architectures are monolithic and batch-oriented, making it difficult to deploy new features, integrate with modern digital channels, or support real-time data flows. The talent equation compounds the problem, with 71% of mainframe teams reporting understaffing and the pool of COBOL-proficient engineers continuing to shrink.

How AI Accelerates Mainframe Modernization

AI has changed the economics of core banking modernization. Services like AWS Transform for mainframe and development tools such as Kiro now enable banks to compress multi-year migration programs into months[3], reducing the manual effort necessary, project risk, and overall transformation costs associated with modernizing the mainframe platform.

These AI-powered capabilities analyze millions of lines of code, automatically extracting business logic, mapping dependencies, and integrating outputs with agentic coding tools to build modern cloud-native equivalents quickly. They also surface undocumented business rules and hidden dependencies that manual analysis often misses. Banks gain a clearer understanding of their own systems while simultaneously building the path forward.

Modernized, API‑first architectures are rapidly becoming the foundation for deploying agentic AI at scale in banking. Monolithic applications on mainframes and their corresponding batch‑oriented integrations struggle to provide the real‑time data streaming and event‑driven orchestration that AI agents depend on, often forcing complex workarounds and limiting impact. Modernization is not just about retiring old technology; it is about building the data and integration platform that makes AI‑driven banking possible.

Strategic Modernization Patterns

The monolith running on the mainframe is not just the core banking system, generally it’s far larger with decades of satellite systems wired directly into the core ledger including Payments, fraud detection, compliance, onboarding, lending workflows, and reporting. What started as a clean ledger became a tightly coupled web of interconnected systems. The industry calls it a big ball of mud. Engineers call it spaghetti code. Either way, the result is the same: changing one function risks breaking dozens of others. When many banks talk about “core modernization,” they are referring to this entire web of payments, statements, fees, fraud/AML, and all of the integration layers, rather than the ledger alone. This makes it critical to decide what product or functionality stays close to the core versus what edge components to decouple and modernize first.

When a bank is ready to modernize, the first step is not migration. It’s decomposition. The goal is to assess the monolith, define which functions belong in the core ledger, and identify which are satellite systems that grew inward. From there, the non-core functions surface until the essential ledger operations stand on their own.

Once the core functions are identified, banks face two clear choices: replace it with a modern core platform like Thought Machine, Finxact, Mambu, or others, or build a custom core internally. Both paths lead to the same outcome: a composable, decoupled architecture where the ledger does what a ledger should do and everything else operates independently. Product teams ship faster. Systems scale on their own. AI agents orchestrate across services in real time. This is what business innovation looks like when the core is no longer holding it back.

Reimagining with AWS Transform for mainframe and Kiro

Reimagining is the process of re-architecting an application to align with the realities of today’s business demands. Reimagine allows banks to target any architectural pattern and technology stack, while also providing an opportunity to redefine the functionality of core systems. When existing applications constrain the business, reimagining provides a pathway to introduce functional overhauls such as modern UIs, real-time capabilities, new product features, and the ability to break existing monoliths into product-aligned business functions. The reimagining pattern supports both technology and business objectives, enabling banks either to rewrite existing applications onto enterprise-standard tech stacks or to reimagine the underlying business processes supported by the existing system completely.

Banks use AI to extract business logic from existing systems, then leverage that intelligence to design and build entirely new cloud-native architectures. This is where modernization becomes business reinvention.

Option A: Build a New Custom Core

Technical approach: The reimagine pattern follows three phases:

1. Reverse Engineering (AWS Transform): AWS Transform analyzes mainframe source artifacts and extracts business logic, analyzes data relationships, documents dependencies, and generates comprehensive technical documentation from the mainframe source. The business logic extraction capability decomposes monolithic applications into constituent business functions, producing exportable natural language requirements that both technical and business stakeholders can understand. Data lineage analysis and automated data dictionary generation give teams complete visibility into the data landscape. Activity metrics analysis using SMF records identifies active and unused components, enabling data-driven decisions about what to migrate and what to retire.
2. Forward Engineering (Kiro): Kiro uses spec-driven development with human-in-the-loop validation to generate modernized application code, create Infrastructure as Code templates, and modernize database layouts. Teams define microservices architecture, API contracts, and data models based on current business needs, not inherited constraints. Steering files give the agent persistent knowledge about the project’s conventions, technology stack, and coding standards. Kiro generates three living documents automatically (requirements, design, and implementation tasks) that teams review and refine before code generation begins, ensuring traceability from extracted business rules through to implemented microservices. The AI-powered approach applies Domain-Driven Design principles to identify natural bounded contexts within existing applications. A dedicated target database generation step transforms data structures (IMS DB, IDMS, Db2) into modern cloud-native schemas that support the microservices architecture while preserving data integrity and business rules.
3. Deploy and Test: Microservices deploy to AWS using compute options including Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), AWS Lambda, and AWS Fargate, with Amazon DynamoDB, Amazon Aurora, or other AWS database services for storage. Infrastructure provisioning is through AWS CloudFormation, AWS Cloud Development Kit (CDK), or Terraform.

Central to the reimagine approach is human-in-the-loop validation with built-in traceability. AI-generated specifications and continuously validated code through structured review gates, where domain, risk, compliance, and technology teams confirm business logic interpretation, verify architectural boundaries, and ensure applications meet all requirements. Every extracted business rule, generated specification, and migration output is traceable and approved before it enters a production modernization program.

How AI reduces risk: AWS Transform automates the reverse engineering phase, producing comprehensive business logic documentation and dependency maps that might take months to assemble manually. Kiro’s spec-driven development creates an auditable chain from extracted business rules to new microservices, with human review gates at each stage. The Strangler Fig approach allows new components to coexist with the mainframe during transition, with both systems operating simultaneously through application-to-application, application-to-data, and data-to-data integration. Banks validate each modernized component in production before retiring the corresponding mainframe function, eliminating big-bang cutover risk.

It is worth noting that microservices are not universally the best target architecture. Modular monoliths or macroservices may be more appropriate when data consistency or transactionality is required. The key is selecting an architecture that aligns with both current needs and future aspirations.

Business value: Complete elimination of technical debt, a modern architecture designed for cloud-native scalability, and a path to deploying new capabilities. This pattern enables banks to build the composable, event-driven architectures that agentic AI requires for real-time orchestration.

Customer results:

• Itaú achieved a 96% reduction in discovery time, an 82% reduction in forward engineering process, and overall, a 75% reduction in their modernization timeline. (Itaú 2025 re:Invent Session)
• Danske Bank achieved 60% overall acceleration with 4x forward engineering velocity, 80% faster documentation, and 50% code reduction (session)

Best for: Banks ready to rethink their core banking model with strong executive mandate for transformation. Ideal when the existing systems constrain business innovation, when there is a clear vision of the target operating model, and when competitive pressure demands rapid feature deployment.

To learn more about the reimagine pattern:

• Check out this blog: Reimagining your mainframe applications with agentic AI and AWS Transform
• Get started with this workshop: Mainframe to Microservices: Reimagine with AWS Transform & AI Agents

Option B: Replace with Commercial Off-the-Shelf (COTS) Solutions

Some banks may benefit from adopting commercial core banking platforms from vendors like Thought Machine, Mambu, 10x, Pismo, Finxact, and others. These platforms offer pre-built functionality for deposits, loans, payments, and other modules that banks can use out of the box.

Best for: Regional banks or institutions with standard banking operations that do not require highly differentiated core processes. This option works well when speed-to-market and reduced development burden outweigh the need for customization.

Trade-offs: Lower upfront development costs and faster deployment, but ongoing licensing fees, limited differentiation, vendor lock-in, and potential constraints on future innovation. Functional parity with previous systems is not maintained, as COTS platforms bring their own process models and data structures that the bank must adapt to. Consider this path when your competitive advantage comes from customer experience, distribution, or specialized products rather than core banking operations.

Making the Right Choice

Selecting the right pattern requires an honest assessment of your institution’s circumstances, and it starts with recognizing that most large-scale core banking transformations are not a single play but a portfolio of decisions.

Programs typically follow an 80/20 distribution: most applications are best served by functionally equivalent modernization that preserves existing business logic exactly as it runs today, while the remaining 20% benefit from reimagining with functional overhauls that unlock new business value. This is why disposition planning matters before any modernization begins. Banks must assess the monolith, define which functions are essential core ledger operations versus satellite systems that grew inward over time, and map each domain to the right approach, whether that is functional equivalence, reimagination, or retirement.

For the components that call for reimagination, two patterns apply:

Choose Reimagine, Custom Build when existing systems constrain business innovation, there is strong executive mandate with a clear vision of the target operating model, and you need functional changes such as converting batch processes to real-time capabilities.

Choose Reimagine, COTS Replacement when you have standard banking operations without unique differentiating requirements, speed-to-market is paramount, and core banking is not a competitive differentiator.

Without this disposition clarity, institutions risk applying the wrong pattern to the wrong component.

Getting Started: A Practical Roadmap

Customer experience shows that starting small, learning quickly, and scaling what works is the most effective approach to core modernization.

1. Secure executive sponsorship. Ensure C-suite leadership understands the strategic imperative, timeline expectations, and resource requirements. Without this foundation, programs stall.
2. Assess readiness and map your landscape. Inventory your existing environment, identify dependencies, assess source code availability, and evaluate team capabilities. Use AI-powered discovery tools like AWS Transform to map your current state more comprehensively than manual approaches allow.
3. Identify a bounded domain for your first proof of concept. Select a business capability or module that is relatively self-contained but meaningful enough to demonstrate value. Good candidates include statement generation, interest calculation engines, fee processing, or specific product lines. Avoid starting with the most complex, mission-critical modules.
4. Define success metrics. Establish clear KPIs around cost reduction (infrastructure, licensing, maintenance), deployment velocity (time from code to production), business agility (time to launch new products), and system performance. Include both technical and business metrics.
5. Pilot AI-powered tools. Start with platforms like AWS Transform for mainframe to understand what automated approaches can deliver on your specific codebase. A focused proof of concept validates tool effectiveness and builds organizational confidence before committing to full-scale migration.
6. Build feedback loops and iterate. Implement comprehensive testing (automated regression, performance, and business validation), establish governance for ongoing decisions about what to preserve, change, or retire, and build continuous improvement into your approach.

The Strategic Imperative

The AI agentic market in financial services is projected to grow from $691 million in 2025 to $6.7 billion by 2033.[4] Banks that have modernized their core platforms will capture a disproportionate share of that value. Every quarter spent maintaining existing applications is a quarter not spent building the capabilities that will matter in 2030.

The question for banking leaders anymore is not whether to modernize, but which pattern aligns best with their institution’s risk tolerance, timeline, and strategic objectives. The banks that move decisively will be the ones best positioned to compete in an AI-driven financial services landscape. With the technology barriers that once made executives hesitant now gone, the next question is how quickly banks will move. A practical first step is to try out the workshop internally, and then partner with your AWS account teams to get started with a concrete modernization roadmap.