Target Operating Model (TOM) Framework

What is a Target Operating Model?

A Target Operating Model (TOM) is a blueprint that describes HOW an organisation executes its strategy. It connects strategic intent with operational delivery across processes, organisation, technology, data, governance, and controls.

Why Target Operating Models Matter

Without a TOM:

• Strategy disconnected from execution
• Unclear accountabilities (who does what)
• Process inefficiencies and duplication
• Technology sprawl and integration chaos
• Inability to scale

With a TOM:

• Clear line of sight from strategy to execution
• Defined roles, responsibilities, and decision rights
• Optimised end-to-end processes
• Integrated technology architecture
• Scalable, repeatable operations

TOM Components Framework

┌─────────────────────────────────────────────────────────────┐
│                        STRATEGY                             │
│     (What we aim to achieve and why)                        │
└────────────────────────┬────────────────────────────────────┘
                         │
         ┌───────────────┴───────────────┐
         │   TARGET OPERATING MODEL      │
         │   (How we will deliver)       │
         └───────────────┬───────────────┘
                         │
    ┌────────────────────┼────────────────────┐
    │                    │                    │
┌───▼────┐      ┌────────▼────────┐     ┌────▼─────┐
│PROCESSES│      │ ORGANISATION    │     │TECHNOLOGY│
│        │      │ (People & Roles)│     │          │
└───┬────┘      └────────┬────────┘     └────┬─────┘
    │                    │                    │
    └────────────────────┼────────────────────┘
                         │
              ┌──────────┴──────────┐
              │                     │
         ┌────▼─────┐     ┌────────▼────────┐
         │   DATA   │     │   GOVERNANCE    │
         │          │     │   & CONTROLS    │
         └──────────┘     └─────────────────┘

6 Components of a TOM

1. Processes: End-to-end workflows (BPMN)
2. Organisation: Roles, responsibilities, structure (RACI, org chart)
3. Technology: Systems, platforms, integration (architecture diagrams)
4. Data: Data flows, quality, governance (data lineage)
5. Governance: Decision rights, committees, policies (RACI for decisions)
6. Controls: Risk & control framework (RCM, 3LOD model)

TOM Design Methodology

Phase 1: Strategic Context

Objective: Understand the strategy that the TOM must enable

Key Questions:

• What is our strategic ambition (3-5 year horizon)?
• What are our strategic priorities?
• What capabilities must the TOM deliver?
• What constraints exist (regulatory, budget, cultural)?

Outputs:

• Strategy summary (1-page)
• Strategic objectives
• Capability requirements
• Success criteria for the TOM

Example: Investment Bank Trade Processing TOM

STRATEGIC CONTEXT

Strategic Ambition (2025-2028):
Become the leading Tier-2 investment bank for mid-cap equity trading
in UK and EU markets, delivering best-in-class execution and post-trade services.

Strategic Priorities:
1. Expand into EU markets (Germany, France) → Requires multi-jurisdiction operations
2. Grow AUM by 40% → Need scalable operations without proportional cost increase
3. Achieve STP rate >95% → Reduce manual interventions and errors
4. Meet T+1 settlement deadline (May 2024) → Faster processing required

Capabilities Required:
• Multi-asset, multi-jurisdiction trade processing
• Real-time risk monitoring and limit management
• Automated reconciliation and exception management
• Scalable middle office (handle 50% growth without headcount increase)
• Regulatory reporting for FCA, ESMA, BaFin

Constraints:
• Budget: Max £5M capex for transformation
• Timeline: Must be operational by Q2 2025
• Regulatory: MUST comply with FCA, MiFID II, EMIR
• Technology: Leverage existing OMS (Fidessa), no rip-and-replace

Success Criteria:
• STP rate >95% (vs 78% today)
• Cost-to-trade reduced by 30%
• T+1 settlement achieved (100% compliance)
• Zero regulatory breaches
• Support 15,000 trades/day (vs 10,000 today)

Phase 2: Current State Assessment

Objective: Understand what exists today and identify pain points

Assessment Areas:

1. Process Assessment

• Map as-is end-to-end processes (BPMN)
• Identify handoffs, delays, rework
• Measure cycle time, throughput, error rate

2. Organisation Assessment

• Document current org structure
• Identify roles, FTE count, skill gaps
• Map RACI for key processes
• Assess spans of control, reporting lines

3. Technology Assessment

• Inventory systems and applications
• Map data flows and integrations
• Identify technical debt, redundancy
• Assess scalability, availability

4. Data Assessment

• Map data lineage (source → transform → destination)
• Assess data quality issues
• Identify reconciliation breaks
• Document data ownership

5. Governance & Controls Assessment

• Review decision-making processes
• Map risk & control framework
• Identify control gaps, redundant controls
• Assess regulatory compliance

Current State Assessment Template

Quantified Current State Metrics

Phase 3: Target State Design

Objective: Design the future-state operating model that enables strategy

Target State Design Principles

Define 5-7 design principles that guide TOM decisions:

Example Design Principles:

1. End-to-End Accountability: Each process has one accountable owner
2. Automation First: Automate repeatable tasks; humans handle exceptions
3. Single Source of Truth: Data entered once, reused everywhere
4. Scalability: Operations support 50% growth without proportional cost increase
5. Risk-Aware: Controls embedded in process, not bolted on
6. Customer-Centric: Process design prioritises customer experience
7. Regulatory by Design: Compliance baked into operations, not retrofit

Component 1: Process Design (To-Be)

Process Transformation Example: Trade Lifecycle

As-Is (Current State):

[Trade Execution] → [Manual Trade Capture] → [Trade Validation (Manual)] →
[Position Update (Manual)] → [Confirmation (Manual)] → [Settlement Instruction (Manual)] →
[Settlement Reconciliation (Manual)] → [P&L Calculation (Manual)]

 Duration: 24 hours (T+0 to T+1)
 Manual touchpoints: 8
 STP Rate: 78%

To-Be (Target State):

[Trade Execution] → [Auto Trade Capture] → [Auto Validation] →
[Real-Time Position Update] → [Auto Confirmation] → [Auto Settlement Instruction] →
[Auto Reconciliation] → [Real-Time P&L]

 Duration: <1 hour
 Automated touchpoints: 7/8 (95%+)
 STP Rate Target: >95%

Process Design Documentation:

• BPMN 2.0 process maps (as-is vs to-be)
• Swimlane diagrams (roles and handoffs)
• Exception handling flows
• Control points embedded in process

Component 2: Organisation Design (To-Be)

Organisation Design Principles:

• Consolidate: Reduce fragmentation (3 sub-teams → 1 unified team)
• Skill-Based: Organise by capability, not product
• Flat Structure: Remove unnecessary management layers
• Clear Accountability: RACI for all processes

As-Is Organisation Structure:

Middle Office Manager
    ├── Trade Support Team (6 FTE)
    ├── Reconciliations Team (5 FTE)
    └── Corporate Actions Team (4 FTE)

Issues:
• Duplication (each team validates trades independently)
• Handoffs slow process (ticket-based workflow)
• Tribal knowledge (each team has specialists)

To-Be Organisation Structure:

Head of Middle Office
    ├── Front-to-Back Processing Team (8 FTE)
    │   └── End-to-end ownership (trade validation → settlement)
    └── Exception Management Team (3 FTE)
        └── Handle breaks, escalations, complex scenarios

Benefits:
• -4 FTE (through automation + consolidation)
• Faster resolution (no handoffs)
• Clear accountability (one team owns trade lifecycle)

RACI Matrix (To-Be):

Component 3: Technology Architecture (To-Be)

Architecture Principles:

• Hub Architecture: Central trade processor (replace point-to-point)
• API-First: Modern integration (RESTful APIs)
• Cloud-Native: Scalable infrastructure (AWS/Azure)
• Real-Time: Event-driven architecture (Kafka)

As-Is Technology Landscape:

OMS → Trade Capture → Position System → Clearing → Settlement
  ↓         ↓              ↓             ↓          ↓
[14 systems with 47 point-to-point integrations]

To-Be Technology Architecture:

                    ┌─────────────────┐
                    │  TRADE HUB      │
                    │  (Central)      │
                    └────────┬────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
     ┌────▼─────┐      ┌─────▼────┐      ┌─────▼──────┐
     │   OMS    │      │ Clearing │      │ Settlement │
     │ (Fidessa)│      │ (LCH)    │      │ (Euroclear)│
     └──────────┘      └──────────┘      └────────────┘
          │                  │                  │
          └──────────────────┼──────────────────┘
                             │
                   ┌─────────▼────────┐
                   │   DATA LAKE      │
                   │   (Reporting)    │
                   └──────────────────┘

Technology Stack (To-Be):

• Trade Hub: Murex (or FIS Quantum) - central trade processor
• Integration Layer: MuleSoft (API management)
• Event Bus: Apache Kafka (real-time messaging)
• Data Platform: AWS S3 + Snowflake (data lake + warehouse)
• Monitoring: Splunk + Grafana (operational monitoring)

Component 4: Data Architecture (To-Be)

Data Principles:

• Single Source of Truth: Trade data entered once (OMS), reused
• Golden Source: Trade Hub is authoritative source for position, P&L
• Data Quality: Validation at source, automated reconciliation
• Data Lineage: Full traceability (audit trail)

Data Flow (To-Be):

[OMS] → Trade Data → [Trade Hub] → Enrichment + Validation
                          ↓
            ┌─────────────┼─────────────┐
            │             │             │
        Position      Settlement      P&L
         Data          Instructions   Calculation
            │             │             │
            └─────────────┼─────────────┘
                          ↓
                   [Data Lake]
                          ↓
                    [Reporting]
                (Regulatory, Management, Client)

Data Ownership: | Data Domain | Golden Source | Data Owner | Consumers | |-------------|---------------|------------|-----------| | Trade Data | OMS (Fidessa) | Front Office | Middle Office, Risk, Finance | | Position Data | Trade Hub | Middle Office | Risk, Finance, Front Office | | Settlement Data | Trade Hub | Middle Office | Operations, Finance | | P&L Data | Trade Hub | Finance | Front Office, Risk, Senior Management |

Component 5: Governance (To-Be)

Governance Structure:

┌─────────────────────────────────────────────────────────────┐
│ BOARD OF DIRECTORS                                          │
│ Accountable for strategy and risk appetite                 │
└────────────────────────┬────────────────────────────────────┘
                         │
         ┌───────────────┴───────────────┐
         │                               │
┌────────▼────────┐             ┌───────▼────────┐
│ EXEC COMMITTEE  │             │ RISK COMMITTEE │
│ Strategic       │             │ Risk Oversight │
└────────┬────────┘             └───────┬────────┘
         │                               │
┌────────▼───────────────────────────────▼────────┐
│ OPERATING COMMITTEE                             │
│ Day-to-day operations, escalations             │
│ Members: COO (Chair), CFO, CRO, Heads of FO/MO/BO│
│ Frequency: Weekly                               │
└────────┬────────────────────────────────────────┘
         │
         └──────► [Middle Office, Front Office, Back Office]

Decision Rights (RACI):

Component 6: Controls (To-Be)

Three Lines of Defence Model:

1st Line (Business Operations):

• Own and manage risk
• Perform first-line controls (trade validation, limit checks)
• Escalate breaches and issues

2nd Line (Risk & Compliance):

• Define control framework
• Monitor control effectiveness
• Challenge first line

3rd Line (Internal Audit):

• Independent assurance
• Audit control effectiveness

Embedded Controls (examples):

Phase 4: Gap Analysis & Roadmap

Gap Analysis:

Implementation Roadmap:

YEAR 1 (2024)
Q1: Foundation
• Define TOM (complete design)
• Secure budget (£5M approved)
• Establish governance (committees, RACI)
• Technology vendor selection (Trade Hub RFP)

Q2: Build
• Procure Trade Hub (Murex)
• Start technology build (infrastructure, APIs)
• Pilot organisation restructure (1 team)
• Design training programme

Q3: Integrate
• Trade Hub integration (OMS, Clearing, Settlement)
• Data migration (historical trades)
• Process automation (validation, recon)
• User Acceptance Testing (UAT)

Q4: Deploy
• Go-live Trade Hub (phased: pilot desk → all desks)
• Organisation restructure complete
• BAU handover
• Post-implementation review

YEAR 2 (2025)
Q1-Q2: Optimise
• Achieve STP >95%
• Fine-tune processes
• Continuous improvement

Q3-Q4: Scale
• Expand to EU markets
• Onboard additional asset classes
• Benefits realisation review

Phase 5: Benefits Realisation

Target Benefits (3-year view):

3-Year Business Case:

INVESTMENT:
Year 0: £5M capex (technology, implementation, org change)

BENEFITS:
Year 1: £2M (partial year, ramp-up)
Year 2: £7.7M (full run-rate)
Year 3: £7.7M (full run-rate)

NPV (3-year, 10% discount): £8.2M
ROI: 164%
Payback: 18 months

TOM Design Templates

1. TOM Charter (1-pager)

TARGET OPERATING MODEL: Trade Processing Transformation
SPONSOR: Chief Operating Officer
OWNER: Head of Middle Office
TIMELINE: Jan 2024 - Dec 2024

STRATEGIC CONTEXT:
Expand into EU markets, achieve T+1 settlement, improve STP to >95%

TOM SCOPE:
• Processes: Trade lifecycle (execution → settlement)
• Organisation: Middle Office restructure (15 → 11 FTE)
• Technology: Implement Trade Hub platform
• Data: Single source of truth for position/P&L
• Governance: Establish Operating Committee
• Controls: Embed automated controls in Trade Hub

SUCCESS CRITERIA:
• STP rate >95%
• Cost per trade reduced by 30%
• T+1 settlement 100% compliant
• Zero regulatory breaches

BUDGET: £5M
APPROVED BY: Board (Date: 15 Dec 2023)

2. Component Design Template

COMPONENT: Technology Architecture

AS-IS:
• 14 systems with point-to-point integrations
• Fragile, difficult to maintain
• No real-time view

TO-BE:
• Hub architecture with central Trade Hub
• API-first integration
• Real-time event-driven

DESIGN DECISIONS:
• Trade Hub vendor: Murex (selected via RFP)
• Integration platform: MuleSoft
• Hosting: AWS cloud

MIGRATION APPROACH:
• Phase 1: Pilot with 1 trading desk (Q3 2024)
• Phase 2: Roll out to all desks (Q4 2024)
• Phase 3: Decommission legacy (Q1 2025)

RISKS:
• Vendor implementation delays (Mitigate: Fixed-price contract with SLAs)
• Data migration issues (Mitigate: 3-month parallel run)

TOM Governance

TOM Steering Committee

Purpose: Oversee TOM design and implementation Frequency: Monthly Members: COO (Chair), CFO, CRO, CTO, Head of MO, Project Manager

Responsibilities:

• Approve TOM design
• Resolve cross-functional issues
• Monitor progress vs roadmap
• Approve changes to scope/budget

TOM Workstreams

Need Expert Support?

Designing a Target Operating Model requires cross-functional expertise, stakeholder alignment, and change management discipline. If you're undertaking an operating model transformation, regulatory change, or M&A integration, contact our team for a consultation.

Template Version: 1.0 Last Updated: January 2025 Compatible With: Financial services, professional services, manufacturing License: Free for commercial use with attribution