Enterprise Capability Mapping
An enterprise capability map is the foundation of process architecture in TOM design. It provides a structured, hierarchical view of what the organisation does — its capabilities — independent of how it does them (processes), who does them (organisation), or what systems support them (technology). This abstraction is powerful because it allows the TOM designer to assess the organisation's functional completeness, identify gaps and overlaps, and make design decisions without being constrained by current organisational structures or legacy technology.
A capability is defined as the ability to perform a particular business function. For example, "Trade Settlement" is a capability — the ability to settle trades. How the bank settles trades (the process), which team settles them (the organisation), and which system is used (the technology) are separate design decisions that flow from the capability definition.
Building a Banking Capability Map
A banking capability map is typically structured in three to four levels of decomposition:
Level 1 capabilities represent the major functional areas of the bank. For a universal bank, these might include:
- Client Management
- Product Management
- Sales and Origination
- Trade Execution and Order Management
- Post-Trade Processing
- Risk Management
- Compliance and Regulatory
- Finance and Accounting
- Technology and Operations Support
- Data and Analytics
Level 2 capabilities decompose each Level 1 capability into its constituent parts. For example, "Post-Trade Processing" decomposes into:
- Trade Capture and Booking
- Confirmation and Affirmation
- Clearing
- Settlement
- Reconciliation
- Corporate Actions
- Asset Servicing
- Client Reporting
Level 3 capabilities provide further granularity. For example, "Settlement" decomposes into:
- Settlement Instruction Generation
- Settlement Matching
- Failed Trade Management
- Settlement Funding
- CSD/ICSD Connectivity
- Cross-Border Settlement
- Settlement Reporting
Level 4 capabilities reach the most granular level, representing specific functional components. For example, "Failed Trade Management" decomposes into:
- Fail Identification and Alerting
- Fail Root Cause Analysis
- Counterparty Communication
- Partial Settlement Processing
- Buy-In / Sell-Out Management
- Penalty Calculation and Reporting (under CSDR)
Using Capability Maps in TOM Design
Once the capability map is built, it becomes a powerful analytical tool:
Gap analysis. Overlay the current state onto the capability map — which capabilities exist, which are missing, and which are immature? For a bank expanding into a new asset class, the capability map immediately reveals which capabilities need to be built or acquired.
Heat mapping. Colour-code capabilities by maturity, strategic importance, cost, risk, or performance. A heat map showing low maturity in high-strategic-importance capabilities immediately identifies investment priorities.
Rationalisation. Identify capabilities that are duplicated across business lines, legal entities, or geographies. If three entities each have their own reconciliation capability, the capability map makes this visible and supports the case for consolidation.
Vendor alignment. Map vendor products and services to capabilities, identifying where the bank relies on external providers and where in-house capability is critical.
Process Hierarchy: L0 to L4
While capability maps describe what the organisation does, the process hierarchy describes how it does it — the end-to-end workflows, procedures, and work instructions that operationalise each capability. A well-designed process hierarchy provides a single, navigable structure for all process documentation in the bank.
Level 0 — Enterprise Value Chain
The L0 view is the highest-level representation of the bank's end-to-end operations. It shows the major process domains and how they connect to deliver value. For a securities services business, the L0 value chain might be:
Client Acquisition → Account Opening → Order Management → Execution → Clearing → Settlement → Asset Servicing → Reporting → Client Exit
The L0 is strategic — it is used in board presentations, regulatory submissions, and strategic planning. It rarely changes unless the bank's fundamental business model changes.
Level 1 — Process Groups
L1 decomposes each L0 domain into major process groups. For example, the "Settlement" domain at L0 decomposes into:
- Securities Settlement (DVP/RVP)
- Cash Settlement
- FX Settlement
- Derivatives Settlement
- Failed Settlement Management
- Settlement Reporting
L1 process groups are owned by senior managers and form the basis of operational management reporting.
Level 2 — Process Maps
L2 contains the detailed process maps — the BPMN diagrams that document how each process group operates end-to-end. For example, "Securities Settlement (DVP/RVP)" at L2 would include a complete BPMN process map showing:
- Settlement instruction receipt and validation
- Matching with counterparty instruction
- Pre-settlement checks (position, cash, collateral)
- Instruction submission to CSD
- Settlement confirmation receipt
- Exception handling for failed settlements
- Status reporting and client notification
L2 is the workhorse of process architecture — it is used by operations teams, auditors, compliance officers, and change managers on a daily basis.
Level 3 — Procedures
L3 contains detailed procedures — step-by-step instructions for performing specific tasks within an L2 process. For example, within the "Securities Settlement" L2 process, a Level 3 procedure might be:
"Processing a Failed Settlement Due to Insufficient Securities Position"
This procedure would detail:
- How to identify the fail in the settlement system
- How to investigate the position shortfall
- How to communicate with the portfolio manager or trader
- How to request a securities lending arrangement
- How to resubmit the instruction once the position is available
- How to update the fail log and report to management
Level 4 — Work Instructions
L4 contains the most granular documentation — system-specific work instructions that tell a user exactly which screens to navigate, which buttons to click, and which fields to populate. L4 documentation is essential for training new staff and for business continuity purposes but changes frequently as systems are upgraded.
Banking Capability Model: Post-Trade Processing
Value Chain Analysis for Banking
Value chain analysis is the process of examining the bank's L0 value chain to understand where value is created, where costs are concentrated, and where operational risk resides. In a TOM context, value chain analysis helps prioritise which parts of the operating model to redesign first and where to focus investment.
Primary activities are those that directly contribute to delivering the bank's products and services to clients. In a securities services business, primary activities include trade capture, execution, clearing, settlement, asset servicing, and client reporting. These activities are where the bank earns its revenue and where client experience is determined.
Support activities enable the primary activities but do not directly generate revenue. These include HR, finance, IT operations, risk management, compliance, and facilities management. Support activities are often candidates for shared services, centralisation, or outsourcing because they are not differentiating.
Management activities provide strategic direction, governance, and oversight. These include strategy development, performance management, board and committee governance, and regulatory engagement. Management activities must remain close to the business and are rarely candidates for offshoring or outsourcing.
The value chain analysis reveals the bank's cost distribution across activities. In many banks, a disproportionate share of cost is concentrated in support activities — particularly technology infrastructure and change — rather than in the primary activities that generate revenue. This insight drives TOM design decisions: if 40% of operations cost is in reconciliation (a support activity), this is a clear candidate for automation and consolidation.
Process Standardisation vs Localisation
One of the most consequential decisions in TOM design is the degree of process standardisation. Banks that operate across multiple countries, legal entities, or business lines face a constant tension between global standardisation (efficiency, consistency, scalability) and local adaptation (regulatory compliance, market specificity, client preferences).
The Case for Standardisation
- Cost efficiency: A single process is cheaper to maintain, monitor, and improve than multiple variants.
- Quality consistency: Standardised processes deliver consistent outcomes regardless of location or team.
- Scalability: New volumes, products, or markets can be absorbed by existing processes without redesign.
- Talent mobility: Staff can transfer between locations and teams without retraining.
- Technology alignment: A single process supports a single technology platform, avoiding the cost of maintaining multiple system configurations.
The Case for Localisation
- Regulatory requirements: Different jurisdictions have different regulatory requirements that cannot be met by a single global process. For example, KYC requirements in Germany differ from those in Singapore.
- Market infrastructure differences: Settlement processes differ between markets because the CSDs, CCPs, and market rules differ. A process designed for Euroclear cannot be used unchanged for DTCC.
- Client expectations: Different client segments in different markets may have different service expectations, reporting requirements, or communication preferences.
The Decision Framework
A structured approach to standardisation vs localisation uses a three-tier classification:
Tier 1 — Globally standardised. The process is identical everywhere, with no local variants. Candidates include internal processes that do not touch clients or external market infrastructure — for example, internal management reporting, performance monitoring, or risk aggregation.
Tier 2 — Standardised with controlled variants. The core process is globally standardised, but specific steps are configured differently to meet local requirements. Each variant is documented, justified, and subject to governance approval. Candidates include client-facing processes where the core flow is universal but specific steps differ by jurisdiction — for example, client onboarding (global flow with local KYC variants).
Tier 3 — Locally designed. The process is fundamentally different in each location because local requirements dominate. This tier should be small — processes classified here must be justified by a genuine regulatory or market infrastructure requirement, and each is reviewed periodically to assess whether standardisation has become possible.
Process Ownership Frameworks
Process ownership is a governance mechanism that assigns clear accountability for each process in the hierarchy. Without defined ownership, processes become orphaned — nobody is responsible for keeping documentation current, nobody monitors performance, nobody drives improvement, and nobody is accountable when things go wrong.
The Process Owner Role
The process owner is a senior manager who is accountable for the end-to-end performance of a process. Their responsibilities include:
- Ensuring process documentation is accurate, complete, and current
- Defining and monitoring process KPIs (STP rates, cycle times, error rates)
- Approving changes to the process
- Ensuring the process complies with regulatory requirements and internal controls
- Driving continuous improvement
- Resolving cross-functional issues and escalations
- Representing the process in governance forums
In banking, process ownership is typically aligned with the senior management function (SMF) framework. The process owner for settlement, for example, would be the Head of Settlement or a director-level manager who can be held accountable by both the bank's leadership and by regulators.
Process Stewards
In addition to process owners, large banks appoint process stewards — operational managers who manage the process on a day-to-day basis within a specific location, entity, or team. Process stewards ensure that their local execution of the process conforms to the globally defined standard, escalate issues to the process owner, and provide local input into process improvement initiatives.
Governance of Process Ownership
A process governance board or equivalent committee provides oversight of the process ownership framework. This body reviews process performance across the enterprise, approves significant process changes, resolves disputes between process owners and business line leaders, and ensures that the process architecture remains aligned with the TOM.
Banking Example: Trade Lifecycle Capability Model
Consider a global investment bank designing its target operating model for the trade lifecycle — from the moment a trade is executed on the trading desk to the point where it is fully settled, reconciled, and reflected in the bank's books and records.
The capability map for the trade lifecycle is structured as follows:
L1: Trade Execution
- L2: Order Management
- L2: Electronic Trading and Algo Execution
- L2: Voice Execution
- L2: Trade Confirmation (Client-Facing)
L1: Trade Processing
- L2: Trade Capture and Booking
- L2: Trade Enrichment and Validation
- L2: Trade Matching (Internal)
- L2: Regulatory Trade Reporting (MiFID II, EMIR, Dodd-Frank)
L1: Clearing
- L2: CCP Clearing (Exchange-Traded)
- L2: CCP Clearing (OTC)
- L2: Bilateral Netting
- L2: Margin Management (Initial and Variation)
L1: Settlement
- L2: Settlement Instruction Generation
- L2: Pre-Settlement Matching
- L2: CSD/ICSD Connectivity
- L2: DVP/RVP Settlement
- L2: FX Settlement (CLS and Non-CLS)
- L2: Failed Trade Management
- L2: Settlement Reporting
L1: Reconciliation
- L2: Trade Reconciliation (Front-to-Back)
- L2: Position Reconciliation
- L2: Cash Reconciliation (Nostro)
- L2: Depot Reconciliation
- L2: P&L Reconciliation
L1: Asset Servicing
- L2: Corporate Actions Processing
- L2: Income Collection (Dividends, Coupons)
- L2: Tax Reclaim Processing
- L2: Proxy Voting
The capability map reveals several critical insights for TOM design:
Duplication. The bank discovers that trade reconciliation is performed independently by three separate teams — one in the front office (trading desk reconciliation), one in middle office (risk reconciliation), and one in back office (settlement reconciliation). Each team uses different tools, different data sources, and different frequency. The TOM target state consolidates reconciliation into a single function with a single platform and a single data source, eliminating duplication and improving data consistency.
Capability gaps. The capability map reveals that "Failed Trade Management" operates at Level 1 maturity — it is a reactive, manual process with no predictive analytics. Under the incoming T+1 settlement regime, failed trades will become significantly more costly and visible. The TOM target state elevates this capability to Level 4, with predictive analytics identifying likely fails before they occur and automated workflows for resolution.
Process standardisation opportunities. Settlement instruction generation follows different processes for equities, fixed income, and derivatives — three separate processes with three separate teams. The capability map makes this visible and supports the case for a single, asset-class-agnostic settlement instruction process that handles all instrument types through configurable rules rather than separate workflows.
Technology rationalisation. Mapping technology to capabilities reveals that the bank uses 7 different reconciliation platforms across the trade lifecycle (one for each reconciliation type, with some types using multiple tools). The TOM target state consolidates to a single reconciliation platform with configurable matching rules, reducing technology cost, simplifying support, and enabling a single view of reconciliation status across all types.
The process hierarchy for the trade lifecycle is built from the capability map:
- L0: Trade Lifecycle (Client Order to Settled Position)
- L1: Trade Execution → Trade Processing → Clearing → Settlement → Reconciliation → Asset Servicing
- L2: Detailed process maps for each L1 group (approximately 25 BPMN process maps in total)
- L3: Detailed procedures for each L2 process (approximately 80 procedures)
- L4: System-specific work instructions for each technology platform
Process ownership is assigned at L1 level: the Global Head of Trading Operations owns Trade Execution, the Head of Middle Office owns Trade Processing, the Head of Clearing owns Clearing, and so on. Each L2 process has a designated process steward in each operating location.
The standardisation decision framework is applied to each L2 process:
- Tier 1 (Globally standardised): Trade capture, trade enrichment, all reconciliation types, internal reporting
- Tier 2 (Standardised with variants): Settlement instruction generation (variants by CSD), regulatory trade reporting (variants by jurisdiction), corporate actions (variants by market)
- Tier 3 (Locally designed): Tax reclaim processing (fundamentally different in each jurisdiction)
This process architecture becomes a core component of the TOM, defining not just how the bank will operate but providing the structural framework for process ownership, technology alignment, performance measurement, and continuous improvement.
In the next module, we will explore the organisation and governance dimension of TOM design — how to structure teams, define roles, design governance frameworks, and make location decisions.