What Is a Target Operating Model?
A Target Operating Model (TOM) is a structured description of how an organisation intends to operate in the future to deliver its strategy. It is not an organisational chart, and it is not a technology roadmap — although both of these are components of a TOM. Rather, it is a comprehensive blueprint that defines how people, processes, technology, governance, and data will work together to deliver services, manage risk, and create value. In banking, a TOM answers fundamental questions: How will we process payments in three years? Where will our operations teams be located? Which systems will we use and which will we decommission? How will regulatory reporting work? Who makes decisions and how are they escalated?
The concept of an operating model is not new, but the discipline of deliberately designing a target operating model — as opposed to simply documenting the current state — has become essential in financial services over the past two decades. The pace of regulatory change, the pressure to reduce costs, the acceleration of digital transformation, and the frequency of mergers and acquisitions mean that banks can no longer allow their operating models to evolve organically. Without a deliberately designed target state, organisations drift — accumulating technical debt, creating organisational silos, and building processes that serve internal convenience rather than client needs or regulatory expectations.
A well-designed TOM provides a north star for transformation. Every project, every investment decision, and every organisational change can be assessed against the target model: "Does this move us closer to or further from where we want to be?" Without this reference point, large organisations make fragmented decisions that optimise individual functions at the expense of the whole.
Why Banks Need Target Operating Models
Banking is one of the most operationally complex industries in the world. A single trade in a global investment bank touches front-office trading systems, middle-office risk and booking platforms, back-office settlement and reconciliation engines, regulatory reporting feeds, client reporting systems, and accounting ledgers — often spanning multiple legal entities, time zones, and regulatory jurisdictions. Managing this complexity without a coherent operating model is like navigating without a map.
Regulatory expectations have made operating model design a supervisory priority. The European Central Bank's Supervisory Review and Evaluation Process (SREP) assesses whether banks have adequate internal governance and operational frameworks. The Bank of England's PRA expects firms to demonstrate they can identify, map, and manage their important business services. The FCA requires firms to maintain adequate systems and controls. In all cases, regulators want to see that banks have thought deliberately about how they operate — not just today, but where they are heading.
Cost pressure is another powerful driver. Banking operations are expensive. A mid-size European bank may spend EUR 500 million to EUR 1 billion annually on operations, technology, and infrastructure. Without a target model that drives rationalisation, standardisation, and automation, costs escalate as legacy systems are maintained alongside new platforms, duplicate functions persist across business lines, and manual processes continue long after they should have been automated.
Client expectations have shifted dramatically. Institutional clients expect real-time reporting, same-day settlement, digital onboarding, and seamless multi-channel interaction. Retail clients expect mobile-first experiences, instant payments, and personalised services. Delivering on these expectations requires an operating model that is designed for speed, flexibility, and digital delivery — not one that evolved from paper-based processes in the 1990s.
Risk management is fundamentally connected to operating model design. Operational risk, technology risk, third-party risk, and conduct risk are all shaped by how the organisation operates. A fragmented operating model with unclear accountability, manual handoffs, and inconsistent controls creates risk concentrations that can — and regularly do — result in operational failures, regulatory sanctions, and financial losses.
Current State vs Target State
Every TOM design begins with understanding two things: where you are now (the current state operating model) and where you want to be (the target operating model). The gap between these two states defines the transformation programme.
The current state operating model documents how the organisation actually operates today. This is not how it is supposed to operate according to policy documents written three years ago, and it is not how senior management believes it operates. It is the reality on the ground — including all the workarounds, manual interventions, shadow IT solutions, and informal processes that staff have developed over time. Documenting the current state honestly is one of the most challenging parts of TOM design, because it requires acknowledging inefficiencies, legacy constraints, and organisational debt that many stakeholders would prefer to ignore.
The target operating model describes the intended future state. It is designed deliberately, based on strategic objectives, design principles, and constraints. The target state represents an achievable, realistic improvement — not a theoretical ideal that ignores the practical realities of migration, regulatory requirements, and budget limitations. A good TOM is aspirational but grounded; it stretches the organisation while remaining credible.
The gap analysis between current and target states produces the transformation backlog — the set of changes that must be implemented to move from where you are to where you want to be. This backlog spans all TOM dimensions: organisational restructuring, process redesign, technology migration, governance changes, and data architecture improvements.
The Five Dimensions of a Target Operating Model
A comprehensive TOM is defined across five interconnected dimensions. Designing one dimension in isolation leads to an unbalanced model — for example, implementing a new technology platform without redesigning the processes it supports, or restructuring the organisation without updating governance frameworks.
1. People and Organisation
This dimension defines who does the work, where they are located, how they are organised, and what skills they need. It covers organisational structure (business-aligned vs functional, centralised vs federated), location strategy (onshore, nearshore, offshore), headcount planning, role design, job families, skills frameworks, and career paths. In banking, people and organisation decisions are heavily influenced by regulatory requirements — for example, the PRA's expectations around substance and control in the booking entity, or the ECB's requirements for senior management presence in the eurozone.
2. Process
This dimension defines how work gets done — the end-to-end workflows, standard operating procedures, exception handling paths, and handoff points between teams, systems, and legal entities. Process architecture in a TOM includes the process hierarchy (from enterprise-level value chains down to desktop procedures), process ownership, standardisation decisions (which processes are globally standardised vs locally adapted), and process performance targets (STP rates, cycle times, error rates).
3. Technology and Infrastructure
This dimension defines the systems, platforms, and tools that enable operations. It covers the application landscape (core banking, trading, settlement, reconciliation, reporting), infrastructure (on-premise, cloud, hybrid), integration architecture (APIs, messaging, file transfers), and the technology roadmap (what gets migrated, what gets decommissioned, what gets replaced). In banking, technology decisions are constrained by market infrastructure dependencies (SWIFT, CLS, CSDs, CCPs), vendor ecosystems, and regulatory requirements around data residency and operational resilience.
4. Governance and Controls
This dimension defines how decisions are made, how risks are managed, and how performance is monitored. It covers decision rights (who can approve what), committee structures (steering committees, operating committees, risk committees), escalation paths, the three lines of defence model, internal controls framework, policy hierarchy, and regulatory reporting obligations. Governance is particularly critical in banking because of the supervisory expectation that firms can demonstrate clear accountability and effective oversight.
5. Data and Information
This dimension defines how data flows through the organisation, where the golden sources of truth reside, how data quality is maintained, and how information is used for decision-making, regulatory reporting, and client servicing. It covers data architecture, data lineage, data governance (ownership, stewardship, quality rules), master data management, and analytics capabilities. In banking, data is subject to extensive regulatory requirements — from BCBS 239 principles for effective risk data aggregation to MiFID II transaction reporting.
The Five Dimensions of a Target Operating Model
Common Triggers for TOM Redesign
Banks do not typically redesign their operating models as a matter of routine. TOM redesign is usually triggered by a significant event or set of pressures that make the status quo untenable.
Mergers and acquisitions. When two banks merge or one acquires another, the combined entity inherits two sets of everything — two sets of processes, two technology platforms, two organisational structures, two governance frameworks. A TOM redesign defines the unified future state, driving decisions about which platform to retain, which processes to standardise, where to locate teams, and how to govern the combined operation.
Regulatory change. Major regulatory initiatives — such as the introduction of operational resilience requirements, changes to settlement cycles (T+1), new reporting mandates (EMIR Refit, DORA), or supervisory findings — can require fundamental changes to how a bank operates. A TOM provides the structured framework for responding to these requirements holistically rather than through tactical, piecemeal fixes.
Digital transformation. The shift from legacy, batch-processing architectures to real-time, cloud-based, API-driven platforms is not just a technology change — it requires redesigning processes, reskilling people, updating governance, and restructuring data flows. A TOM ensures that digital transformation is approached as an integrated operating model change, not just an IT project.
Cost pressure. When a bank needs to reduce its cost-to-income ratio — whether due to competitive pressure, shareholder expectations, or regulatory capital constraints — a TOM redesign identifies structural cost reduction opportunities: shared services, location arbitrage, process automation, platform rationalisation, and organisational simplification. These are not achievable through incremental cost-cutting; they require a redesigned operating model.
Client experience improvement. When client feedback, Net Promoter Scores, or competitive benchmarking indicate that the bank's operational performance is not meeting market expectations, a TOM redesign can reorient the operating model around client outcomes rather than internal organisational boundaries.
TOM Design Principles
Before beginning the detailed design of a target operating model, it is essential to establish design principles — the rules and guidelines that will govern design decisions throughout the programme. Design principles provide consistency, prevent scope creep, and give the design team a framework for resolving trade-offs.
Effective TOM design principles for banking typically include:
Client-centricity. The operating model is designed around client outcomes and service levels, not internal organisational convenience. Every design decision is assessed against the question: "Does this improve the client experience?"
Simplification. Complexity is the enemy of operational efficiency and risk management. The target model should reduce the number of systems, process variants, organisational layers, and governance bodies wherever possible.
Standardisation with justified exceptions. The default position is global standardisation of processes and platforms, with local variations permitted only where required by regulation, market infrastructure, or demonstrable client need. Every exception must be justified and documented.
Scalability and adaptability. The model should accommodate growth in volumes, new products, new markets, and new regulatory requirements without requiring a fundamental redesign.
Automation first. Manual processing is the exception, not the rule. The default assumption is that processes will be automated unless there is a specific reason why human intervention is required.
Clear accountability. Every process, every system, and every data set has a single accountable owner. Shared accountability is avoided because it leads to diffused responsibility and gaps in oversight.
Regulatory compliance by design. Compliance requirements are built into the operating model from the outset, not bolted on as an afterthought. This includes regulatory reporting, data residency, operational resilience, and supervisory expectations.
Banking Example: Post-Acquisition TOM Redesign
Consider a mid-size European bank — let us call it NordBank — with headquarters in Stockholm, operating primarily in the Nordic markets. NordBank acquires Baltic Finance, a regional competitor with operations in Estonia, Latvia, and Lithuania. The acquisition doubles NordBank's customer base and adds three new operating jurisdictions.
Before the acquisition, NordBank's operating model was relatively straightforward: a single technology platform, centralised operations in Stockholm, and standardised processes across its Nordic markets. Baltic Finance, however, operates on a completely different technology stack, with decentralised operations in each Baltic country, locally developed processes, and separate governance structures.
Post-acquisition, NordBank faces immediate challenges. It is running two core banking platforms, two payment processing engines, two reconciliation systems, and two sets of regulatory reporting pipelines. Operations staff in the Baltic entities follow different procedures from their Nordic counterparts. There are two separate risk frameworks, two sets of policies, and two governance structures. The cost of running duplicate operations is EUR 45 million per year — costs that the acquisition business case assumed would be eliminated through synergies.
NordBank's board mandates a TOM redesign to define the unified future state. The design programme runs for four months and covers all five dimensions:
People and organisation: The target model establishes a shared services centre in Tallinn for transaction processing, retaining front-office and client-facing functions in each local market. Stockholm becomes the centre of excellence for risk, compliance, and regulatory reporting. Headcount across the combined operations is reduced by 18% through elimination of duplicate roles and automation.
Process: All core processes (payments, lending, KYC, regulatory reporting) are standardised on NordBank's existing process frameworks, with local adaptations only where required by Baltic regulatory requirements. Process ownership is assigned to senior managers in Stockholm with local process stewards in each market.
Technology: The target state consolidates onto NordBank's core banking platform, with Baltic Finance systems decommissioned over an 18-month migration. A new cloud-based data warehouse is implemented to serve both Nordic and Baltic reporting requirements.
Governance: A unified governance framework is established with a single Operating Committee, regional risk committees, and clear decision rights aligned to the new organisational structure.
Data: A golden source strategy is defined, with NordBank's data warehouse as the single source of truth for regulatory and management reporting. Data migration from Baltic Finance systems is planned as part of the technology workstream.
The TOM provides the blueprint for a three-year transformation programme. Without it, NordBank would have made fragmented decisions — migrating one system here, restructuring one team there — without a coherent view of the end state. The TOM ensures that every project, every investment, and every organisational change moves the combined entity toward a deliberately designed future.
In the next module, we will explore how to link TOM design to corporate strategy, conduct a current state assessment, and build the business case for transformation.