💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction

When people talk about investment banking (IB) systems, they usually picture flashy trading screens or ultra-low-latency matching engines. In reality, an IB division is closer to one long pipeline. Deals are sourced, examined through due diligence, priced, issued as securities, traded, and finally closed out through settlement, where cash and securities actually change hands. That whole flow is implemented in software.

This article focuses on stitching that entire flow together, from deal to settlement, as a single picture. In particular it covers the three-tier front, middle, and back office structure; the OMS that manages orders and the EMS that manages execution; pre-trade and post-trade limits; the T+1 settlement cycle and central counterparties (CCPs); and the data layer of market, reference, and position data. At the end it lays out how legacy systems, typified by mainframes and batch jobs, are being modernized toward an event-driven, streaming design.

One thing to make clear up front: this is a general systems and architecture educational article, not investment or legal advice. Details such as settlement cycles, clearing rules, and reporting obligations may vary by jurisdiction and firm. For any real implementation or regulatory question, always confirm with your firm's compliance department. The code and schemas here are illustrative concepts, not something to run in production as-is.

The IB Business Domain and End-to-End Flow

At a high level, IB connects issuers who want to raise capital with investors who want to deploy it. In between, the bank advises, underwrites and issues securities, intermediates trades in the market, and trades on its own account. All of this activity ultimately converges on the unit of a trade, and every trade must be closed out through settlement.

Drawn as a single lifecycle, the whole flow looks like this.

Deal sourcing Due diligence Valuation Issuance Trading Settlement

(Sourcing) ──▶ (Diligence) ──▶ (Valuation) ──▶ (Issuance) ──▶ (Trading) ──▶ (Settlement)

│ │ │ │ │ │

│ find │ financial, │ DCF, │ pricing, │ orders and │ match, confirm,

│ opportunities │ legal, and │ relative │ bookbuild, │ execution, │ clear, exchange

│ CRM, pipeline │ business review│ value, risk │ allocation │ fills, update │ cash and

│ │ data room(VDR) │ │ │ positions │ securities

▼ ▼ ▼ ▼ ▼ ▼

[FRONT OFFICE] ────────────────────────────────────▶ [MIDDLE OFFICE] ────▶ [BACK OFFICE]

creates deals and trades risk and control settle, record

The early stages (sourcing, diligence, valuation, issuance) sit closer to advisory and underwriting work, while the later stages (trading, settlement) belong to the capital markets and the secondary market. Once a deal reaches issuance and comes to market, it fragments into countless trades that are traded and settled day after day. In other words, a deal happens once, but trading and settling the resulting security happens continuously.

The systems characteristics of each stage can be summarized as follows.

| --- | --- | --- | --- |

The thing to notice in this table is that the further left you go, the more low-frequency and document-centric the work becomes, and the further right, the more high-frequency and transaction-centric. So the emphasis of the design differs too. The front end is about collaboration and access control, while the back end is about integrity and throughput.

The Three-Tier Front, Middle, and Back Office Architecture

When slicing IB systems by organization, the most common axis is front, middle, and back office. These three tiers are a physical departmental split, but they are also boundaries of systems responsibility.

┌───────────────────────────────────────────────────────────────────┐

│ FRONT OFFICE │

│ The revenue-generating front line. It creates deals and trades. │

│ - Dealmakers/bankers: sourcing, diligence, valuation, issuance │

│ - Traders/sales: quotes, orders, execution │

│ Systems: CRM, pricing, OMS, EMS, market-data terminals │

└───────────────────────────────────────────────────────────────────┘

│ trade capture

▼

│ MIDDLE OFFICE │

│ Control and validation. It guards and shapes what the front made.│

│ - Risk management: market/credit/liquidity risk, limit monitoring│

│ - Trade validation: validation, P&L calculation │

│ - Compliance: regulatory checks, surveillance │

│ Systems: risk engine, limit management, P&L system │

│ confirmed trade

▼

│ BACK OFFICE │

│ Record and completion. It turns trades into real movements. │

│ - Settlement: match, confirm, clear, settle │

│ - Accounting/reconciliation: ledger records, reconciliation │

│ - Custody: safekeeping, corporate actions │

│ Systems: settlement engine, ledger, reconciliation system │

Comparing the responsibilities of the three tiers:

| --- | --- | --- | --- |

An important idea here is that a single trade changes state as it passes through the three tiers. A trade filled in the front is validated in the middle and settled in the back. What makes this flow smooth is so-called STP (Straight-Through Processing), moving a trade automatically from start to finish without human intervention. The higher the STP rate, the fewer errors and delays.

OMS and EMS — Order and Execution Management

The heart of front-office trading is two systems, the OMS and the EMS. Their names are similar and easy to confuse, but their roles are clearly different.

- The OMS (Order Management System) manages what, how much, and for whom to order. It receives instructions from portfolio managers, creates orders, passes them through pre-trade limit checks, and reflects fills into positions and accounting. Its viewpoint is portfolio, compliance, and record.

- The EMS (Execution Management System) manages how to execute the order in the market. It routes orders across multiple exchanges and liquidity pools, slices them with algorithms (for example VWAP, TWAP), and optimizes execution quality while watching real-time prices. Its viewpoint is market, speed, and execution quality.

The relationship and order flow between the two look like this.

Portfolio manager

│ order intent

▼

┌──────────────┐ pre-trade check OK ┌──────────────┐

│ OMS │ ─────────────────────▶ │ EMS │

│ create order │ │ smart routing│

│ pre-trade │ ◀───────────────────── │ algo execute │

│ update pos │ fills reported │ multi-venue │

└──────────────┘ └──────┬───────┘

│ │ order routing

│ fills → positions and accounting ▼

▼ ┌──────────────┐

[to middle and back office] │ Exchange/ECN/ │

│ dark pool/CCP │

└──────────────┘

Many firms use an OEMS that fuses OMS and EMS into one. The boundary between the two may vary by firm and vendor. The table below summarizes the key differences.

| Aspect | OMS | EMS |

| --- | --- | --- |

| Core question | What and how much to order | How to execute |

| Main viewpoint | Portfolio, compliance | Market, execution quality |

| Typical features | Order creation, pre-trade, positions | Routing, algorithms, real-time prices |

| Latency sensitivity | Relatively low | Very high |

| Main users | PM, middle office | Traders |

| Data retention | Long term (audit, record) | Short term (execution window) |

The OMS Order State Machine

An order is a living object. It is created, approved, sent to market, partially or fully filled, and cancelled or rejected. Modeling these state transitions as an explicit state machine is central to OMS design. Below is a Python example that shows the concept.

from enum import Enum

class OrderState(Enum):

NEW = "new" # created (not yet validated)

PENDING_RISK = "pending_risk" # awaiting pre-trade check

APPROVED = "approved" # passed limits, ready to execute

ROUTED = "routed" # sent to market/EMS

PARTIALLY_FILLED = "partially_filled"

FILLED = "filled" # fully filled

CANCELLED = "cancelled"

REJECTED = "rejected" # rejected, e.g. limit breach

Only allowed transitions are defined (others are errors)

ALLOWED = {

OrderState.NEW: {OrderState.PENDING_RISK, OrderState.REJECTED},

OrderState.PENDING_RISK: {OrderState.APPROVED, OrderState.REJECTED},

OrderState.APPROVED: {OrderState.ROUTED, OrderState.CANCELLED},

OrderState.ROUTED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

OrderState.REJECTED,

OrderState.PARTIALLY_FILLED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

}

def transition(current, target):

if target not in ALLOWED.get(current, set()):

raise ValueError(f"invalid transition: {current} -> {target}")

return target

Example: normal flow

state = OrderState.NEW

state = transition(state, OrderState.PENDING_RISK)

state = transition(state, OrderState.APPROVED)

state = transition(state, OrderState.ROUTED)

state = transition(state, OrderState.PARTIALLY_FILLED)

state = transition(state, OrderState.FILLED)

print("final state:", state.value)

By spelling out the allowed transitions, you can prevent impossible state moves, such as re-routing an already-settled order, at the code level. It is also important that the terminal states (FILLED, CANCELLED, REJECTED) have no further transitions.

Execution and Fill Message Schema

Orders and fills travel between systems as messages. The industry standard is the FIX protocol, but on internal event buses they are often expressed in formats like JSON. Below is a conceptual example of an execution report message.

{

"message_type": "execution_report",

"order_id": "ORD-2026-0007781",

"client_order_id": "PM-ALPHA-4412",

"exec_id": "EXC-99381",

"symbol": "AAPL",

"side": "buy",

"order_qty": 10000,

"cum_qty": 6000,

"leaves_qty": 4000,

"last_qty": 2000,

"last_price": 231.45,

"avg_price": 231.10,

"currency": "USD",

"exec_type": "partial_fill",

"order_status": "partially_filled",

"venue": "XNAS",

"transact_time": "2026-07-01T14:32:05.123Z",

"settlement_date": "2026-07-02"

}

Here cum_qty (cumulative filled), leaves_qty (remaining), and avg_price (average fill price) are key fields when handling partial fills. Notice that settlement_date is stamped as the next business day after transact_time. This is exactly the T+1 settlement cycle discussed below.

Risk and Limit Management

As trades pile up, risk balloons quickly without control. So the middle office sets limits and monitors them before and after trades. Here it is important to distinguish pre-trade limits from post-trade limits.

┌──────────────────────────────────────┐

create order ─▶│ PRE-TRADE limit check │

│ - max quantity/amount per order │

│ - exposure limits by name/sector/ccy │

│ - credit limits (counterparty) │

│ verdict: pass -> execute / breach -> │

│ reject or warn │

└──────────────────┬───────────────────┘

│ pass

▼

execution and fill

│

┌──────────────────▼───────────────────┐

update pos ──▶│ POST-TRADE limit monitoring │

│ - cumulative position, VaR, loss limit│

│ - intraday/end-of-day exposure │

│ verdict: breach -> alert, hedge, │

│ consider forced unwind │

└──────────────────────────────────────┘

- Pre-trade limits are preventive controls that stop an order before it reaches the market. They are latency-sensitive and must be decided very fast (usually in milliseconds). So limit data is often cached in memory and checked there.

- Post-trade limits are detective controls that monitor accumulated positions and P&L after fills. They recompute risk metrics such as VaR (Value at Risk), send alerts on breaches, and prompt hedging or reduction.

A common pitfall in limit management is double counting. If the exposure reserved at the pre-trade check and the exposure reflected after the fill diverge, you may perceive limits as larger or smaller than they really are. So it is essential to reserve the limit on order creation and to unwind it exactly on fill, cancel, or reject. The specific limit types and formulas may vary by firm and regulation.

Settlement and Clearing — The World of T+1

A filled trade is not the end. The buyer must pay, and the seller must deliver the security. This actual exchange of cash and securities is settlement, and the process of netting and guaranteeing obligations in between is clearing.

Three key concepts first.

- Settlement cycle: how many days after the trade date (T) settlement occurs. T+1 means settlement on the business day after the trade date. Many markets have moved from the older T+2 to T+1. That said, it may vary by product, market, and jurisdiction.

- CCP (Central Counterparty): an institution that steps in between buyer and seller to become the counterparty to each. Through this, the CCP absorbs the counterparty risk of "what if the other side does not perform."

- DVP (Delivery versus Payment): a principle that binds securities delivery and cash payment atomically, preventing a situation where only one side is fulfilled. It prevents the accident of "I paid but did not receive the security."

The flow from fill to settlement, drawn as a sequence:

Trading CCP(clearing) CSD(depository) Cash settlement

(trade fills) (payment/bank)

│ │ │ │

T │ match │ │ │

│────────────────▶│ │ │

│ │ novation │ │

│ │ CCP steps in as │ │

│ │ counterparty │ │

│ │ netting reduces │ │

│ │ settlement count │ │

│ │ │ │

T │ confirm and │ │ │

│ instruct │───────────────────▶│ │

│ │ │ match settle instr │

│ │ │ │

T+1│ │ DVP settlement │ │

│ │ deliver sec ◀────▶│ pay cash │

│ │ │◀───────────────▶│

│ │ │ (atomic) │

▼ ▼ ▼ ▼

position final risk cleared ownership move funds move

Shortening the settlement cycle from T+2 to T+1 puts substantial pressure on systems, because confirmation, instruction, and funding must all be finished within a single day. Comparing the systems implications of the two:

| Aspect | T+2 (traditional) | T+1 (compressed) |

| --- | --- | --- |

| Settlement slack | Two days | One day |

| Back-office processing | Overnight batch is fine | Same-day close, more automation |

| Error correction | Relatively roomy | Tight correction window, STP essential |

| Cash/securities funding | Comfortable | Pre-positioning and forecasting matter |

| Counterparty risk | Longer exposure window | Shorter window (improved) |

| Systems requirement | Batch tolerated | Near real-time, event-driven preferred |

The lesson here is that shortening the cycle is not a simple rule change but a pressure that pushes back-office systems from batch toward near real time. If confirmation is delayed, it leads to settlement fails, which incur cost and regulatory risk. Specific settlement cycles and clearing rules may vary by market, product, and jurisdiction, so they must be confirmed.

The Data Layer — Market, Reference, and Position

What ultimately holds up IB systems is data. Data divides broadly into three kinds by nature, each with different storage, update, and integrity needs.

┌──────────────────────────────────────────────────────────────┐

│ MARKET DATA │

│ - real-time quotes, trades, indices. thousands to millions │

│ of ticks per second │

│ - character: ultra-high frequency, time series, latency │

│ - storage: in-memory/time-series DB, streaming │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ REFERENCE DATA │

│ - instrument master, issuer, calendar, currency, rating, │

│ identifiers (ISIN etc.) │

│ - character: low-frequency change, integrity first, shared │

│ - storage: relational master DB, golden source (MDM) │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ POSITION DATA │

│ - holdings, average cost, P&L, exposure │

│ - character: updated by trades, needs reconciliation, audited│

│ - storage: ledger/position store, fits event sourcing well │

└──────────────────────────────────────────────────────────────┘

│

market + reference + position ──▶ input to risk, P&L, and limits

Comparing the nature of these three data types:

| --- | --- | --- | --- |

Reference data is quiet but the most dangerous. A single wrong instrument identifier can spread that error across every system from front to back. So the standard practice is to designate one golden source and unify it through master data management (MDM).

Position Table Example

Since positions are the object of reconciliation and audit, defining the schema clearly matters. Below is a SQL example that shows the concept.

CREATE TABLE positions (

position_id BIGINT PRIMARY KEY,

account_id VARCHAR(32) NOT NULL,

instrument_id VARCHAR(32) NOT NULL, -- references reference golden source

quantity DECIMAL(20, 4) NOT NULL, -- negative means short position

avg_cost DECIMAL(20, 6) NOT NULL,

currency CHAR(3) NOT NULL,

market_value DECIMAL(20, 4), -- revalued with market data

unrealized_pnl DECIMAL(20, 4),

as_of_date DATE NOT NULL,

last_updated TIMESTAMP NOT NULL,

CONSTRAINT uq_position UNIQUE (account_id, instrument_id, as_of_date)

);

-- Query today's positions for a given account

SELECT instrument_id, quantity, avg_cost, market_value, unrealized_pnl

FROM positions

WHERE account_id = 'ACC-ALPHA-01'

AND as_of_date = CURRENT_DATE

ORDER BY market_value DESC;

The key points are that instrument_id points to the reference data golden source, and that a uniqueness constraint is placed on the (account_id, instrument_id, as_of_date) combination. This prevents duplicate position records for the same account, instrument, and date.

Regulation and Audit

IB systems sit in the middle of regulation. Trades must be reported to supervisors, and all activity must be traceable and reproducible after the fact. From a systems standpoint this leads to two requirements.

- Trade reporting: the details of a filled trade must be reported to regulators or trade repositories within set deadlines. The reporting format and fields may vary by market, product, and jurisdiction.

- Audit trail: who did what, when, and why must be recorded immutably. You must be able to reproduce every state change of an order from creation through fill to settlement.

Especially important for audit is the immutable log. Instead of overwriting state, you stack every change append-only, so you can retrace the state at any point in time. This idea connects naturally with the event sourcing discussed below.

[order created]──▶[passes limit]──▶[routed]──▶[partial fill]──▶[full fill]──▶[settled]

▲ ▲ ▲ ▲ ▲ ▲

└────────────────┴────────────────┴──────────┴────────────────┴────────────┘

every transition recorded with timestamp and actor in an immutable log

→ full history of any order reproducible at any time (audit, regulation)

The point to stress here is that audit requirements shape the architecture. Rather than "let us bolt on logging later," it is far safer to design from the start so that every state change is recorded as an event. Specific reporting obligations and retention periods may vary by regulation and firm, so confirm with your compliance department.

Legacy and Modernization

Many IB systems are rooted in decades-old mainframes and overnight batch. There is a reason: they are stable, accurate, and strong at bulk transactions. But in an era of T+1 settlement, real-time risk, and event-driven integration, a batch-centric structure becomes a bottleneck.

[past: batch-centric] [present: event-driven]

day: trade capture (piled into files) the moment a trade occurs

───────────────────── publish event (streaming)

night: overnight batch runs │

- recompute positions ├─▶ real-time position update

- compute risk ├─▶ real-time risk and limits

- generate settle instructions ├─▶ near-real-time settle instr

───────────────────── └─▶ immediate audit log

next day: verify results, fix errors (minimize delay, strengthen STP)

problem: errors found only next day benefit: instant reflection/detection

fragile under shorter cycle suited to a shorter cycle

Comparing the character of batch and streaming:

| Aspect | Batch (legacy) | Streaming (modern) |

| --- | --- | --- |

| Processing time | Set time (mainly overnight) | The moment an event occurs |

| Latency | Hours | Seconds, milliseconds |

| Error discovery | Next processing cycle | Near real time |

| T+1 fit | Tight, risky | Suitable |

| Audit | Snapshot-centric | Event history naturally captured |

| Transition difficulty | Stable but rigid | Complex early, flexible long term |

The direction of modernization is usually incremental, not a big-bang replacement. A common approach is the strangler pattern: leave the legacy ledger in place, put an event bus in front of it, and attach new consumers over time. Introducing event sourcing has the added benefit that audit trail and reproducibility come along naturally. That said, the dichotomy of "batch bad, streaming good" is dangerous. There are still many areas, such as overnight settlement and reconciliation, where batch remains the right fit. Modernization is a means, not an end, and which parts to make event-driven may vary by firm's situation.

Common Pitfalls

Here are the pitfalls that come up repeatedly when designing the end-to-end flow.

- Blurring tier boundaries: if the front takes on settlement logic or the back takes on trading logic, responsibilities get tangled and control collapses. Tier boundaries are control boundaries.

- Neglecting reference data: a trivial error in the instrument master spreads firm-wide. Starting without a golden source and MDM becomes hard to manage later.

- Missing limit integrity: if reservation and reflection diverge, you misperceive limits. Unwind reservations exactly on fill, cancel, and reject.

- Underestimating settlement fails: delayed confirmation or instruction leads to settlement fails, which incur cost and regulatory risk. There is no slack under T+1.

- Retrofitting audit: bolting on logging later makes reproduction impossible. Record state changes as events from the start.

- Reckless modernization: forcing a working batch into streaming can lose stability. Choose according to purpose.

- Ignoring clock sync: if timestamps across systems drift, audit and reconciliation drift too. Time synchronization looks trivial but is important.

Closing

An IB system is linked as one long pipeline, from the first moment of sourcing a deal to the final settlement where cash and securities change hands. The front office creates trades, the middle office guards them, and the back office completes them. Across that flow run orders through the OMS and EMS, risk monitored by pre-trade and post-trade limits, settlement upheld by T+1 and CCPs, and the data of market, reference, and position holding it all up.

Understanding this whole picture lets you gauge, when you touch any one system, how that change ripples through the entire pipeline. And when modernizing legacy, it lets you judge "what to change and why" from the perspective of tiers and data.

To stress it again, this is a general architecture educational article. Specific details such as settlement cycles, clearing rules, and reporting obligations may vary by jurisdiction and firm, so before any real application, always confirm with your firm's compliance department and relevant experts.

References

- ISO 20022 financial messaging standard: https://www.iso20022.org/

- SWIFT (global financial messaging): https://www.swift.com/

- DTCC (US clearing and settlement, T+1 material): https://www.dtcc.com/

- FIX Trading Community (FIX protocol): https://www.fixtrading.org/

- Investopedia — T+1 settlement explained: https://www.investopedia.com/terms/t/t1.asp

- Central counterparty clearing (Wikipedia): https://en.wikipedia.org/wiki/Central_counterparty_clearing

- Apache Kafka documentation (event streaming): https://kafka.apache.org/documentation/

- Martin Fowler — Event Sourcing: https://martinfowler.com/eaaDev/EventSourcing.html

- Delivery versus payment (Wikipedia): https://en.wikipedia.org/wiki/Delivery_versus_payment