IT Strategy for Banks: A Practical Guide for Swiss CTOs

An IT strategy for a bank is a funded, sequenced plan that links the bank’s business goals to its core systems, data, cloud, security and talent. It is not a list of technologies. The strategies that hold up name the business outcomes first, then the architecture and operating model needed to reach them, and then the order of delivery and the regulatory constraints along the way. This guide walks through that process for banks and financial institutions in Switzerland and Europe.

TL;DR

• Start from business outcomes (customer journeys, cost-to-serve, risk), then derive the architecture. Technology choices come last.
• Infrastructure change is where the money goes. When a new regulation or product lands, most of the bill is in adapting the systems you already run.
• Legacy modernization fails more often on team structure and culture than on code. Plan for platform teams that own services end to end.
• AI only pays off once the data layer is fixed. Fix siloed data before you add agents.
• Treat compliance as a design input: automate controls and monitor continuously instead of auditing at a point in time.

Table of Contents

• What a bank’s IT strategy has to decide
• Step 1: Assess what you have
• Step 2: Set the target architecture
• Step 3: Make legacy modernization an organizational project
• Step 4: Plan the cloud move around compliance
• Step 5: Fix the data layer before adding AI
• Step 6: Treat regulation as input, not as a late-stage check
• Our perspective
• A 90-day starting plan
• FAQ
• Work with us on your IT roadmap
• Sources

What a bank’s IT strategy has to decide

A useful strategy answers five questions, in this order.

1. Which business outcomes must IT enable in the next three years? Faster onboarding, a new wealth-management channel, lower run costs, tighter regulatory reporting. Each outcome gets an owner on the business side.
2. What is the target architecture? Which core stays, which is wrapped by APIs, which is replaced, and what sits in the cloud.
3. What is the data strategy? Where data lives, who owns it, and how it reaches analytics, AI and regulators.
4. What is the operating model? How teams are organized, how they are funded and how they work with the business.
5. What are the risk and compliance boundaries? Outsourcing, operational resilience, data protection, AI governance.

If a strategy document cannot answer these in a few pages, it is a technology wish list. Teams that do this well keep the business and IT roadmap in a single document, reviewed by the same steering group.

Step 1: Assess what you have

Before any target state, you need an honest inventory. For most established banks this means:

• Application landscape: every system, its owner, age, vendor support status, integrations and run cost.
• Core banking dependencies: which products and channels depend on which core modules, and how tightly.
• Data flows: where customer, transaction and risk data is copied, transformed and reported.
• Skills: who actually understands the legacy components, and how many years of that knowledge remain in the building.
• Third parties: outsourcing and cloud providers, with exit options.

The output is a heat map of business criticality against technical health. The systems that are both critical and fragile become the first modernization candidates. This is also the place where an external view helps. Our technology consulting and IT strategy work usually begins with exactly this assessment, so that the roadmap rests on facts rather than on the loudest stakeholder.

Step 2: Set the target architecture

Rarely does a bank replace everything at once. The realistic patterns are:

The cost side deserves attention. When a new regulation or product lands, the bill is mostly in adapting systems you already run: apps, front ends, integrations and backend authorization. A cleaner, more modular architecture lowers that bill for every future change.

For banks that want to build new digital channels on top of the existing core, see how we approach digital banking development. For those who need to validate a new product quickly, an MVP and fintech software development track limits the exposure before you commit to a full build.

Step 3: Make legacy modernization an organizational project

The most common reason modernization stalls is not the technology. In a speech by T. Rabi Sankar of the BIS, infrastructure upgrades are paired with cultural change: the speech calls reengineering the culture of innovation within banks perhaps the most important requirement. A move from monolith to microservices does not work if the bank keeps siloed, project-based teams that hand work over a wall.

What to do instead:

• Form platform-oriented teams that own a service across its lifecycle: build, run, monitor, improve.
• Align teams to customer journeys such as onboarding or mortgages, with business and IT people in the same team. The principle is easy to test internally: can a team ship a change to its journey without asking three other departments?
• Fund products, not projects. A project ends and the knowledge leaves. A product team keeps it.
• Invest in skills. The same BIS speech argues that human expertise, not software alone, is the differentiator, and that banks need internal incentives for upskilling and for data and digital literacy at every level.

When the internal team is stretched, extension is a legitimate tool as long as knowledge stays in the bank. Our product engineering and team extension services are built around senior engineers working inside your delivery structure, not beside it.

Step 4: Plan the cloud move around compliance

Cloud is where the strategy meets the regulator. Many institutions plan cloud migration around compliance, and the approach that works best is continuous compliance: security controls are automated and raise real-time alerts instead of waiting for point-in-time audits.

In practice for a Swiss bank:

• Classify workloads first. Not every workload carries the same sensitivity. Decide what can move, what needs specific safeguards and what stays on premises.
• Treat outsourcing rules as a design requirement. Involve compliance, legal and risk from the first workshop, not at the approval gate. Confirm current FINMA requirements with your own compliance function before fixing a design.
• Codify controls. Encode policies as code and monitor them continuously, so evidence for auditors is a by-product of operations.
• Keep exit options real. Document how you would move a critical workload to another provider or back in-house.

Operational resilience is a supervisory focus too. In its 2025 annual report, FINMA describes how it identifies systemic and operational risks through inspections, audits, stress tests and data surveys. A strategy that treats resilience as an architectural property, with tested recovery paths and clear dependencies, is easier to defend in those conversations.

Our technology consulting work on cloud migration follows this sequence: classify, design controls, migrate in waves, monitor.

Step 5: Fix the data layer before adding AI

Many banks want AI agents this year. The strategy question is whether the data underneath can support them. In an April 2025 BIS speech, the point is made that generative AI may become a competitive necessity in banking. The same speech notes that many banks carry tech debt and that their data storage is siloed and not optimized for firm-wide analysis, and that generative AI requires data and infrastructure to be effective.

A sensible sequence:

1. Inventory and classify data by domain, owner, quality and sensitivity.
2. Create a governed data platform with lineage, access control and quality monitoring.
3. Pick two or three use cases with measurable value, typically in internal operations: compliance checks, document handling, service automation.
4. Put model governance in place before production: validation, monitoring, human oversight, audit trail.
5. Scale what works.

A BIS working paper on supervisory technology adds an organizational finding worth borrowing. Among the 112 financial authorities surveyed, the establishment of a dedicated suptech unit is the most critical factor in increasing the number of deployed applications, and public cloud adoption is associated with a higher probability of implementing AI tools. The sample is regulators, not commercial banks, so treat it as a pointer rather than a benchmark. Still, a small central team with a mandate for data and AI is a pattern many banks can copy.

If you are planning this step, our data services, AI services and AI agent development pages describe how we build the data foundation and the agents on top of it. Our article on AI adoption as a strategic approach goes deeper on prioritization.

Step 6: Treat regulation as input, not as a late-stage check

Banks working across Switzerland and the EU face overlapping rules. The EBF argues in its Simply Competitive report that horizontal digital regulations often clash with sector-specific needs, and that excessive regulatory complexity weakens European competitiveness. Whatever your view on the policy debate, the strategic consequence is practical: design systems so that rule changes are configuration and data changes, not rebuilds.

Concretely:

• Keep regulatory logic in a separate, well-documented layer instead of scattering it across applications.
• Automate regulatory monitoring so that new requirements are mapped to affected systems quickly.
• Keep reporting data traceable from source to submission.

For background on the compliance side of digital banking, see our overview of digital banking regulatory compliance, and the ComplianceAspekte case study for an example of an AI co-pilot built for a compliance platform.

Our perspective

First, strategy documents rarely fail on ambition. They fail on sequencing. A bank that tries to modernize the core, move to the cloud and deploy AI agents in the same year usually delivers none of them well. We prefer a roadmap with one structural change per phase, each paying for the next.

Second, the integration layer is where strategy becomes real. Our approach is custom integration with the banking infrastructure you already run, so that new products can ship while the core is being modernized behind them. That is why we plan the integration layer together with your compliance and architecture teams from the start.

Third, AI agents are an operating model decision before they are a technology decision. Which tasks does an agent own, who reviews its output, and what happens when it is wrong? Banks that answer those questions before the build get value faster.

Finally, we are optimistic. Banks that fix their data and team structure now will find agent-based services far easier to adopt than those that wait.

— Igor

A 90-day starting plan

If you are a CTO or head of digital transformation starting from scratch, this is a realistic first quarter.

• Days 1 to 30: Interview business leaders. Write down five outcomes with owners. Build the application and data inventory.
• Days 31 to 60: Draft two or three architecture options with costs, risks and dependencies. Run them past compliance, risk and security.
• Days 61 to 90: Choose one option, define phases, name the platform teams and funding model, and agree the first two delivery milestones with the board.

Keep the output short. A ten-page strategy that people read beats a hundred-page one that they do not.

FAQ

What should an IT strategy for a bank include?

It should include business outcomes with owners, a target architecture, a data strategy, an operating model and a risk and compliance framework. It also needs a phased roadmap with funding. If any of these is missing, teams will fill the gap with their own assumptions.

How long does a bank IT strategy take to build?

A focused first version usually fits into a quarter: inventory, options, decision. The strategy then needs yearly review, because regulation, technology and business priorities move. Delivery of the roadmap itself runs over several years.

Should a bank replace its core banking system?

Not by default. Wrapping the core with APIs or modernizing it domain by domain often carries less risk. Replacement makes sense when the core is out of vendor support and cannot be extended in a viable way. The decision should rest on cost, risk and business impact from your own assessment.

How should banks approach AI in their IT strategy?

Start with data quality and governance, then pick a few internal use cases such as compliance or service automation. According to a BIS speech, many banks’ data storage is siloed and not optimized for firm-wide analysis, so fix that before scaling. Add model validation and human oversight before production.

Work with us on your IT roadmap

We help banks, wealth managers and fintechs turn the assessment into a delivery plan and then deliver it. Start with our IT strategy and technology consulting page, or read our case study on building a new digital banking experience for AMINA. You can reach the team through our contact page.

Sources

• T. Rabi Sankar, Transformational technologies and banking (BIS)
• FINMA Annual Report 2025: Resilience
• AI, fintechs, and banks (BIS)
• Making suptech work: evidence on the key drivers of adoption (BIS)
• Simply Competitive (EBF)

Recommended

• Customer Onboarding in Banking: A Swiss Guide for 2026
• Driving Financial Digitalization in Switzerland: Trends, Projects, Collaboration
• Banking Security Standards: How Banks Ensure Cyber Security