If the CTO or CIO role is already difficult in any enterprise, it becomes even more complex in financial services.
Technology leaders are no longer responsible only for infrastructure, applications, cybersecurity, or delivery. Their role now cuts across almost every business process. They are expected to understand business priorities, support revenue growth, improve operational efficiency, reduce risk, and help the organization adapt to new technology waves without disrupting critical systems.
In regulated industries, that responsibility carries additional layers of complexity.
Banks, insurers, fintech companies, asset managers, private equity firms, and wealth management companies operate in environments where reliability, security, governance, auditability, and compliance are not optional. A failed implementation, a data issue, or an integration gap can quickly become a business, regulatory, or customer trust problem.
At the same time, expectations around AI are rising fast.
PwC’s 2026 Global CEO Survey, for example, found that 56% of chief executives have seen no significant financial benefit from AI. Only 33% reported gains in either cost or revenue, and only 12% saw AI deliver both cost and revenue benefits.
This article explores three challenges, plus a bonus, that should be on the financial services CIO/CTO agenda. Together, they point to the same underlying question: how can technology leaders turn AI, data, and modernization investments into ROI over the next five years?
1. Legacy Systems and the Modernization Dilemma
For decades, banks, insurers, asset managers, and other financial institutions expanded their technology environments by adapting what they already had. Core banking platforms, mainframes, COBOL applications, SAP R/3, SAP ECC, Oracle E-Business Suite, PeopleSoft, JD Edwards, policy administration platforms, payment systems, risk engines, and proprietary applications were extended again and again to support new products, new regulations, new reporting requirements, new customer channels, and new operating models.
That approach prevailed for a long time.
When the business needed something new, teams added a customization. When a regulatory requirement appeared, they created a new report or workflow. When a merger introduced different processes, they built integrations. When a system could not support a new requirement directly, teams added a workaround, a batch process, a spreadsheet, or a manual approval layer.
The result is not a single legacy system, but a dense web of technical debt, workarounds, and dependencies that makes the environment harder to maintain, harder to understand, and harder to change.
In many financial institutions, the real complexity sits in the layers built around the core: custom logic, point-to-point integrations, undocumented dependencies, manual controls, exception flows, reporting scripts, approval chains, and business rules.
Clean Core and the need for “disciplined customization”
This is why concepts like “clean core” have become so important in ERP modernization, especially in SAP environments.
Clean core does not mean eliminating customization. That would be unrealistic in an industry that plays by a different set of rules and runs under tougher controls than most.
The point is not to remove differentiation. The point is to organize it.
In SAP terms, clean core means keeping the digital core as standardized and upgrade-stable as possible, while placing extensions, custom logic, and integrations in the right architectural layer. Instead of modifying the core directly, companies use well-defined APIs, extension models, integration services, and platforms such as SAP BTP to keep innovation separate from the core system.
That is why so many legacy ERP environments became difficult to modernize. Customization lived too close to the core. What began as necessary adaptation slowly became architectural friction. Each custom object, interface, report, or enhancement may have added value at one point in time, but together they made future upgrades, cloud migration, integration, testing, and even AI readiness more complex.
The next phase of ERP and core systems modernization is not about standardization versus customization. It is about disciplined customization.
- What should remain standard?
- What should be configured?
- What should be extended?
- What should move to an integration layer?
- What should be rebuilt as a workflow, API, data product, or AI-enabled process?
- What should be retired because it only exists as a workaround for an old limitation?
Those questions are now central to the CTO/CIO agenda because AI depends on this discipline.
Why Agentic AI makes the question more urgent
The reason is simple: AI agents cannot create much value if they are still outside the systems where work actually happens. To impact business processes, they need access to structured data, documents, business rules, permissions, APIs, transaction histories, approval flows, and operational context. They also need audit trails, human escalation paths, and clearly defined boundaries.
Many legacy environments were built for human-led processes, not for agents that can act, connect, and respond on their own. That is why modernization cannot be reduced to “rip and replace.”
In regulated industries, modernization is often more effective when done in steps. For example, a bank may keep its core banking platform in place while building an integration layer that allows account, customer, and transaction data to be used securely by digital channels, fraud models, or AI-assisted service workflows.
A company running SAP ECC may begin by reducing custom code dependencies, exposing selected business objects, moving extensions to SAP BTP, improving reporting, or preparing specific processes for a future SAP S/4HANA migration.
In that sense, modernization is not only about moving from SAP ECC to SAP S/4HANA, or from Oracle E-Business Suite, PeopleSoft, or JD Edwards to Oracle Fusion Cloud Applications. It is also about deciding how much business logic should remain inside the core, how much should move into extension and integration layers, and how the architecture can stay flexible enough to support AI, automation, and future regulatory change.
This requires two types of expertise.
- The first is legacy fluency: people who understand the current systems, the hidden logic, the customizations, the dependencies, and the operational risks.
- The second is transformation capability: people who can design modern architectures, cloud strategies, data platforms, integration layers, AI workflows, and governance models.
The hard part is that many organizations do not have enough of both.
For systems that have been running for decades, the pool of active specialists is much smaller than it used to be. And the people who still know those environments well are often deeply embedded in their organizations. In many cases, they are exactly the people companies try hardest to retain, because they hold knowledge that is difficult to replace.
That creates a real talent problem for modernization, making it necessary in many cases to work alongside a partner with deep expertise in this type of project.
2. Data Silos and the Integration Gap
Financial services is often called a “data-rich but insight-poor” industry.
The industry does not lack information. Banks, fintech companies, insurers, asset managers, and wealth management firms generate enormous amounts of it every day. On paper, that looks like a data goldmine. In practice, much of that value is trapped before it can become useful.
There are two reasons for that.
- First, the data is dispersed in silos. A customer profile may live in one platform, transaction history in another, supporting documents in a repository, advisor notes in a CRM, and reporting logic in a spreadsheet that only a few people know how to maintain. Even in highly regulated environments, Excel often becomes the hidden operating layer between systems that were never fully connected.
- Second, the data is highly sensitive. Financial services data cannot simply be opened up across the business or connected to every new tool. It has to comply with strict requirements around privacy, permissions, auditability, compliance, and internal controls.
That is why the data challenge is so difficult. CIOs and CTOs need to make information easier to access, but they also need to make sure it is accessed in the right way.
AI Exposes the data problem
AI raises the stakes even further.
Many organizations want to apply AI to processes like customer service, document processing, risk analysis, fraud detection, and compliance. But AI does not magically fix fragmented data. In many cases, it exposes the fragmentation more clearly.
If the data is incomplete, duplicated, inconsistent, locked inside disconnected systems, or difficult to govern, AI will struggle to produce reliable outcomes.
That is why data engineering and integration have become central to the financial services CIO/CTO agenda.
The goal is not to collect more data. Financial institutions already have plenty of it. The goal is to make data usable:
- Usable means trusted.
- Usable means governed.
- Usable means connected to the workflow.
- Usable means available at the moment a decision needs to be made.
The integration layer behind the insight gap
Data pipelines are what allow institutional knowledge to circulate across the business.
In financial services, that circulation has to be controlled. Think of a bank with customer data in its core platform, transaction history in another system, fraud alerts in a separate tool, and customer interactions spread across CRM and service channels. If those sources stay disconnected, every team works with a partial view.
With governed data pipelines, that context can move with the right permissions. Fraud teams can access the signals they need. Customer service can support clients without seeing unnecessary sensitive data. Compliance can trace how information was used and whether the right controls were applied.
That is what makes integration so important for AI.
AI cannot produce reliable insights from fragmented or outdated information. But financial institutions also cannot feed every model with every dataset. The data foundation has to be connected, governed, and traceable.
3. Moving Beyond Copilots to AI-Powered Processes
The third challenge is turning AI experimentation into measurable business outcomes.
Many organizations started their AI journey with copilots and productivity tools. That makes sense. These tools are easy to test and useful for individual tasks such as writing, summarizing, searching, coding, or preparing documents.
But in financial services, individual productivity does not automatically become enterprise value.
An employee may save time using AI to summarize a document, draft a message, or analyze information. But if the process around that task remains fragmented, manual, or disconnected from core systems, the business may not capture the full value of that saved time.
This is one reason AI ROI has become such a difficult topic.
PwC’s 2026 Global CEO Survey found that 56% of CEOs have seen no significant financial benefit from AI. Only 33% reported gains in either cost or revenue, and only 12% saw AI deliver both cost and revenue benefits.
For CIOs and CTOs, the next step is moving from AI as a tool people use individually to AI as part of redesigned business processes.
In financial services, this is especially relevant for document-heavy workflows such as loan review, onboarding, compliance, claims, and reporting processes.
These are strong places to start because the inefficiency is usually visible. Teams know how many documents they process, how long each one takes, how many people are involved, and where errors or delays tend to appear.
We saw this clearly in a SAP Document AI use case modeled with our ROI calculator. The process involved more than 8,000 documents per month and approximately 1,066 hours of manual work. Before automation, the estimated monthly cost was about $54K. After modeling the same workflow with SAP Document AI and SAP BTP, the estimated monthly cost dropped to about $29K, creating roughly $25K in projected monthly savings, or about $304K per year.
Bonus: Hallucinations and AI Governance
As AI moves from individual productivity into financial workflows, governance becomes much more important.
A hallucination in a low-stakes productivity task may be inconvenient. A hallucination in a financial services workflow can create business, legal, reputational, and regulatory exposure.
If AI is used to summarize compliance documentation, support fraud investigations, assist with customer communications, review loan documents, analyze portfolio information, or recommend actions inside operational workflows, incorrect outputs can have serious consequences.
That is why hallucination risk needs to be treated as a design requirement.
AI systems need clear boundaries. They need to know what they can access, what they can produce, when human review is required, and when they should escalate.
This becomes even more important with agentic AI.
Unlike traditional GenAI tools that respond to prompts, agentic systems may take actions, trigger workflows, query systems, route cases, or recommend operational decisions. That makes governance part of the architecture, not an afterthought.
For financial services organizations, strong AI governance should answer very important questions:
- What happens when the system makes a mistake?
- What data can each model access, and how are permissions enforced across teams, departments, and roles?
- If an internal chatbot is connected to multiple enterprise systems, how do organizations prevent users from accessing sensitive information outside their role or business unit?
- When should the system refuse to answer, limit its response, or require human approval?
In compliance-heavy industries, consistency can become a real advantage. Humans working under volume and time pressure often struggle to apply the same level of consistency across every document, review, and decision-support process. Properly designed AI workflows can help standardize parts of that work while keeping humans in control of final decisions.
But this only works if the architecture is ready.
If AI tools are connected to fragmented data, unclear workflows, or poorly governed systems, hallucination risk becomes harder to control. If AI is built on reliable data, bounded use cases, validation layers, and clear escalation paths, it becomes much easier to use responsibly.
Turning the CIO/CTO Agenda Into Action
These are not separate problems sitting in different corners of the organization. They are connected. A modernization project can become the foundation for better data flows. Better integrations can make AI use cases more realistic. AI can remove manual work from processes that were never redesigned. And governance can make sure speed does not come at the expense of trust, compliance, or control.
So the question is not which challenge matters most.
The real question is where to start in a way that makes the next move easier.
At Inclusion Cloud, we help financial services companies do exactly that. We work with enterprise platforms such as SAP, Oracle, ServiceNow, and Salesforce, and support teams with certified resources in AI, machine learning, data engineering, modernization, and integration.
So, if your team is looking at legacy modernization, data integration, or AI at the process level, we can help you turn that agenda into a practical roadmap.