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

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

Introduction

When people talk about banking IT, most material focuses on retail banking — deposits, lending, the core banking ledger. Investment banking (IB) systems look completely different. Instead of millions of accounts, you handle dozens of deals; instead of thousands of transactions per second, you handle workflows that span months. Transaction volume is tiny, but a single deal can be worth hundreds of millions to billions of dollars, and material non-public information (MNPI) flows through these systems — so the cost of a control failure is enormous.

This article is for engineers who are designing or maintaining IB division systems for the first time. It assembles the business domain map, the deal lifecycle, conflict checks, the technical implementation of Chinese walls (information barriers), bookbuilding, syndicated loan administration, document management, and regulatory reporting into a single picture. We also cover the Korean capital markets context (the Financial Investment Services and Capital Markets Act and related regulations).

Note that this article is a technical resource from a systems design perspective. It is not investment or legal advice. Always confirm regulatory matters with your compliance department.

The IB Business Domain Map

The IB division can be divided into five broad domains.

+---------------------------------------------------------------+

| Investment Banking Division |

| |

| +-----------+ +-----------+ +-----------+ |

| | ECM | | DCM | | M&A | |

| +-----------+ +-----------+ +-----------+ |

| |

| +------------------+ +---------------------------+ |

| +------------------+ +---------------------------+ |

| |

| Shared infra: deal pipeline / conflict check / Chinese wall |

| document mgmt / insider lists / reg reporting |

| / CRM |

+---------------------------------------------------------------+

Comparing the system requirements of each domain:

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

The biggest difference from retail is that **everything revolves around the deal**. The first-class object in the system is not the account but the deal, and teams, documents, approvals, and information access rights all hang off it.

The Deal Lifecycle and Pipeline Management

A deal typically passes through these phases.

[Origination] [Execution] [Closing] [Post-Close]

| | | |

idea/pitch --> mandate won --> due diligence --> marketing/ --> pricing

| | | bookbuilding |

v v v | v

conflict check engagement deal room open insider list allocation,

(pre-screening) letter signed (VDR/documents) expanded settlement,

fee billing

post-close / league tables

The core requirements of a deal pipeline management system:

- **Stage-based state management**: every deal sits in exactly one stage, and stage transitions happen only through approval events.

- **Probability-weighted pipeline**: multiply each stage by its success probability to aggregate expected fee revenue. This is the headline metric on management dashboards.

- **Team membership coupled to information access**: the moment someone joins a deal team they become subject to Chinese wall controls and a candidate for the insider list.

- **Audit trail**: who viewed or modified which deal information, and when, must be fully recorded. It is the first thing regulators ask for during an examination.

Enforcing stage transitions in code matters. Manage the pipeline in spreadsheets and you will, without fail, end up with deals that bypassed the conflict check.

Conflict Checks — Block It Before You Take the Deal

A conflict check verifies, before accepting a new mandate, that it does not conflict with existing deals and client relationships. For example, if you are pitching to advise on the sale of Company A while already advising Company B on acquiring Company A, you cannot take both sides.

From a systems perspective, the conflict check is a **gate in the deal creation workflow**.

-- The core conflict query: detect active deals that touch

-- the same or related target companies

SELECT d.deal_id,

d.deal_type,

d.stage,

c.company_name,

r.relation_type -- TARGET / ACQUIRER / ISSUER / SPONSOR

FROM deal d

JOIN deal_company_rel r ON r.deal_id = d.deal_id

JOIN company c ON c.company_id = r.company_id

WHERE d.stage NOT IN ('CLOSED', 'DEAD')

AND c.company_group_id IN (

-- expand to the corporate group of the new target

SELECT company_group_id FROM company

WHERE company_id = :new_deal_target_id

);

Practical points:

- **Expand to the corporate group (affiliates)**. Checking only the target company misses conflicts with deals involving group affiliates.

- Search must be **based on legal entity identifiers**. String matching on company names is unreliable due to typos and abbreviations. Manage LEI codes or national business registration numbers as master data.

- The result feeds a **compliance review queue**, not an automatic approval. The system detects candidates, a human decides, and the rationale is recorded.

Implementing the Chinese Wall in Systems

The Chinese wall is the control that blocks information flow between the IB division (the private side, which holds MNPI) and research or sales and trading (the public side). In Korea, information barrier requirements are mandated under the Capital Markets Act conflict-of-interest provisions. Technically it is implemented in three layers.

Layer 1 — Entitlements (access control)

Deal information is deny-all by default and opens only through deal team membership.

Example deal-level access policy (policy engine input)

policy:

resource: deal/PRJ-FALCON

default: deny

rules:

- effect: allow

subjects:

- group: deal-team/PRJ-FALCON # deal team members

- group: compliance-surveillance # compliance (standing access)

actions: [read, write]

- effect: allow

subjects:

- group: ib-management # division management

actions: [read-summary] # summary only, no documents

- effect: deny

subjects:

- group: research # research explicitly blocked

- group: sales-trading

actions: [read, write, read-summary]

override: true # takes precedence over allow

Key design principles:

- **Use project code names**. Even in deal list screens, users without entitlements should see only the code name — or not see the deal at all.

- **Systematize wall crossing**. When a public-side employee must temporarily join a deal, compliance approval, insider list registration, time-boxed access grant, and automatic revocation at expiry must be bound into a single workflow.

- Record every grant and revocation as events, and support **point-in-time queries** over the entitlement set. You must be able to answer instantly who could access this deal on March 15 — that is what regulatory examinations demand.

Layer 2 — Watermarking

Deal documents must be traceable to their source if leaked. Apply per-user dynamic watermarks at view or download time.

Applying a dynamic watermark at document view time (conceptual)

from pypdf import PdfReader, PdfWriter

from reportlab.pdfgen import canvas

from io import BytesIO

def apply_watermark(src_pdf: bytes, user_id: str, deal_code: str) -> bytes:

stamp_buf = BytesIO()

c = canvas.Canvas(stamp_buf)

text = f"{deal_code} / {user_id} / {datetime.datetime.utcnow().isoformat()}"

c.setFont("Helvetica", 7)

c.setFillColorRGB(0.6, 0.6, 0.6, alpha=0.4)

repeated diagonal watermark

c.saveState()

c.translate(300, 400)

c.rotate(45)

for y in range(-400, 400, 60):

c.drawString(-250, y, text)

c.restoreState()

c.save()

stamp_buf.seek(0)

stamp = PdfReader(stamp_buf).pages[0]

reader = PdfReader(BytesIO(src_pdf))

writer = PdfWriter()

for page in reader.pages:

page.merge_page(stamp)

writer.add_page(page)

out = BytesIO()

writer.write(out)

return out.getvalue()

Some institutions combine visible watermarks with invisible ones based on metadata or steganography. What matters is that every watermarking event is tied back to the access log.

Layer 3 — Logging and surveillance

- Every view, download, print, and share of a deal document is captured as structured logs (who, when, what, from where).

- Compliance runs **anomalous access detection** batches: access attempts by non-team users, bulk downloads in a short window, changed access patterns of soon-to-depart employees, and so on.

- Logs are stored in append-only storage (WORM storage or hash chains) to prevent tampering. Set retention policies aligned with applicable record-keeping regulations.

MNPI Management and Insider Lists

An insider list is the register of people who accessed MNPI for a specific deal. The EU Market Abuse Regulation explicitly obliges issuers and advisers to maintain insider lists, and Korean firms operate equivalent controls to address the insider trading provisions of the Capital Markets Act (Article 174).

CREATE TABLE insider_list_entry (

entry_id BIGINT PRIMARY KEY,

deal_id BIGINT NOT NULL REFERENCES deal(deal_id),

person_id BIGINT NOT NULL REFERENCES person(person_id),

reason VARCHAR(200) NOT NULL, -- registration reason (team, wall cross, external adviser)

obtained_at TIMESTAMP NOT NULL, -- when MNPI access began

notified_at TIMESTAMP, -- when the person was formally notified

removed_at TIMESTAMP, -- when removed from the list

removed_reason VARCHAR(200),

created_by VARCHAR(50) NOT NULL,

created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

);

-- Insider lists must preserve correction history, so no UPDATEs:

-- changes are handled as new rows plus invalidation of prior rows

-- (bitemporal pattern)

CREATE INDEX idx_insider_deal ON insider_list_entry (deal_id, obtained_at);

CREATE INDEX idx_insider_person ON insider_list_entry (person_id, obtained_at);

Operational points:

- Keep the insider list **auto-synchronized with deal team membership**, but provide a manual registration path for outsiders (law firms, accountants, even financial printers).

- On registration, send the mandatory notice (MNPI possession, trading restrictions, legal liability) and record the acknowledgment.

- Integrate with the personal account dealing (PA dealing) pre-clearance system so that an employee on an insider list is automatically blocked from trading the relevant security.

The Bookbuilding System — Demand Capture and Allocation

The highlight of ECM/DCM deals is bookbuilding. You collect demand (price, quantity) from institutional investors, construct the demand curve, set the issue price, and allocate the offering. In Korean IPOs, the institutional demand forecast process is governed by Korea Financial Investment Association rules.

The core models of a bookbuilding system are the order and the allocation.

Simplified allocation engine (conceptual)

Real allocation combines qualitative review (anchor investors,

long-term holding profile); this shows only the pro-rata skeleton.

from dataclasses import dataclass

@dataclass

class Order:

investor_id: str

quantity: int # requested quantity

limit_price: int # limit price; market orders treated as top of range

investor_grade: str # internal grade: ANCHOR / LONG_ONLY / HEDGE / RETAIL_INST

GRADE_WEIGHT = {"ANCHOR": 1.5, "LONG_ONLY": 1.2, "HEDGE": 0.8, "RETAIL_INST": 1.0}

def build_demand_curve(orders, price_grid):

"""Cumulative demand per price level: sum of orders at or above the price"""

return {

p: sum(o.quantity for o in orders if o.limit_price >= p)

for p in price_grid

}

def allocate(orders, final_price, total_shares):

eligible = [o for o in orders if o.limit_price >= final_price]

weighted = sum(o.quantity * GRADE_WEIGHT[o.investor_grade] for o in eligible)

allocations = {}

remaining = total_shares

for o in sorted(eligible, key=lambda x: GRADE_WEIGHT[x.investor_grade], reverse=True):

share = int(total_shares * o.quantity * GRADE_WEIGHT[o.investor_grade] / weighted)

share = min(share, o.quantity, remaining)

allocations[o.investor_id] = share

remaining -= share

leftover shares get redistributed under explicit rounding rules (omitted)

return allocations, remaining

What matters in the system design:

- **Order amendment history**: investors amend and cancel orders during the bookbuilding window. Every version must be preserved, and orders after the cutoff time must be rejected by the system.

- **Real-time aggregation of the demand curve**: the syndicate desk watches book coverage (demand over supply) in real time. Event-sourcing the order stream and aggregating through materialized views fits well.

- **Explainability of allocation outcomes**: allocation is rife with disputes and regulatory scrutiny. All inputs (grades, weights) and every manual adjustment must be recorded, and manual adjustments must require a reason.

- **Conflict controls**: allocations to in-house funds or affiliates go through a separate approval path or are blocked.

Syndicated Loan Administration — A Multi-Year Operations System

A syndicated loan is a structure where multiple financial institutions jointly lend to one borrower. The arranger organizes the deal, and the agent bank handles interest calculation, principal and interest distribution, and notices between borrower and participants for the life of the loan. LMA (Europe) and LSTA (US) standard documentation are the de facto industry standards.

The core data the system must manage:

| Area | Content |

| --- | --- |

| Facility structure | Tranches such as Term Loan A/B, RCF, and their limits |

| Participant shares | Commitment amounts per institution, assignment history |

| Drawdowns/repayments | Drawdown requests, interest periods, repayment schedules |

| Interest and fees | Base rate plus margin, commitment fees, arrangement fees, agency fees |

| Distribution | Pro-rata calculation and payment of interest, principal, and fees per participant |

A fee distribution calculation example:

Distribution per participant at end of interest period (conceptual)

from decimal import Decimal, ROUND_HALF_UP

def distribute_interest(total_interest: Decimal, participations: dict) -> dict:

"""participations: {institution_id: outstanding_amount}"""

total_outstanding = sum(participations.values())

result = {}

allocated = Decimal("0")

items = sorted(participations.items())

for inst, amount in items[:-1]:

share = (total_interest * amount / total_outstanding).quantize(

Decimal("0.01"), rounding=ROUND_HALF_UP)

result[inst] = share

allocated += share

The last institution absorbs the rounding residue — totals must match

last_inst = items[-1][0]

result[last_inst] = total_interest - allocated

assert sum(result.values()) == total_interest

return result

The trickiest operational areas:

- **Assignments (secondary trading)**: when a participant assigns its share to another institution, the basis for interest and principal distribution changes from that point. You need a point-in-time share ledger keyed by assignment effective date.

- **Rounding policy**: distribution totals must reconcile to the cent. Define and test the residue absorption rule explicitly.

- **Agency notice obligations**: rate fixings, drawdown notices, and default events carry deadlines. Timer and escalation features in the workflow engine are essential.

Acquisition Finance Limits and Exposure Management

Acquisition finance (LBO financing, bridge loans) puts the bank balance sheet directly at risk, so limit management is central.

- **Borrower and corporate group limits**: under single-counterparty credit limit rules, exposure is aggregated at the corporate group level.

- **Underwriting limit vs hold limit**: distinguish the temporarily large exposure at underwriting from the final hold position after sell-down, with separate limits for each. When sell-down stalls (a hung deal), the hold limit gets breached — the system must track sell-down plan versus actual.

- **Pipeline exposure**: committed but undrawn amounts also count as potential exposure.

Exposure aggregation concept:

Total exposure (corporate group G)

= sum of drawn balances (all borrowers in the group)

+ sum of undrawn commitments x credit conversion factor (CCF)

+ sum of underwriting positions (unsold portion)

Limit checks run both at new-deal approval and in the daily batch

Deal Document Management — Versions and Signatures

In M&A and syndication, documents are nearly the entire deliverable. Requirements:

- **Version control**: contract drafts go back and forth dozens of times. You need a version tree (who branched from which version), redline generation, and execution-version designation.

- **VDR (virtual data room)**: during due diligence, the sell side uploads materials and bidders review them. Differentiated access scopes per bidder, view logs, and a Q&A workflow are standard features.

- **E-signature integration**: assemble the signature package (signers, positions, ordering), send, track completion, and archive the executed version — all as one workflow. Wiring the signature-complete event to trigger the deal stage transition (for example, contract signed) improves pipeline data quality.

- **Retention and legal hold**: when a deal dispute arises, you must be able to place a deletion freeze (legal hold) on all related documents.

Regulatory Reporting and the Korean Capital Markets Context

In Korea, IB business is governed by the Financial Investment Services and Capital Markets Act and the Financial Investment Business Regulations. From a systems perspective, the reporting and disclosure duties you meet most often include the following (exact requirements vary by timing and institution type — always confirm with compliance):

- **Securities registration statements and prospectuses**: filed via the DART electronic disclosure system for ECM/DCM issuance. Deal system data is the source data for these filings.

- **Retention of demand forecast records**: IPO bookbuilding orders and allocations carry retention duties under association rules.

- **Major shareholder and affiliate transaction reporting, conflict-of-interest records**: operation records of information barriers and wall-crossing approvals are examination targets.

- **Regulatory examination response**: access logs, insider lists, and conflict check records must be quickly queryable as of any point in time.

The design implication is clear. Do not defer regulatory reporting to a separate system later — **the deal system data model itself must be report-ready (immutable history, point-in-time queries)**.

CRM Integration

IB CRM differs from sales CRM. Coverage bankers manage meetings with client executives, pitch history, and deal opportunities. Integration points:

- The conflict check consumes CRM relationship data (who covers which company, past deal history) as input.

- When a deal reaches the mandate stage, the CRM opportunity is promoted to a pipeline deal and the two IDs cross-reference each other.

- However, **the Chinese wall applies to the CRM too**. If deal details leak to the public side through the CRM, the entire control collapses. Synchronizing only deal existence and the code name into the CRM is the safe choice.

Example Data Model

The relationships among core entities as an ERD:

+--------------+ +-------------------+ +--------------+

+--------------+ +-------------------+ +--------------+

| company_id PK|---+ | deal_id PK | +---| person_id PK |

| lei | +--<-| deal_type | | | side (pub/pr)|

+--------------+ | expected_fee | |

^ | probability | |

| +-------------------+ |

| | | | |

+------+--------+ | | +-------+----------+

| DEAL_COMPANY_ |---------+ | | |

| REL | +--------+-----+ +-----+------+ +-+----------+

| ACQUIRER/ | +--------------+ +------------+ | LIST_ENTRY |

+---------------+ +--------------+ +------------+ +------------+

| order_id PK |

| deal_id FK | +-----------------+ +----------------------+

| qty / price | +-----------------+ +----------------------+

| superseded_by | | facility_id PK |---| facility_id FK |

+---------------+ | deal_id FK | | institution_id |

| tranche_type | | commitment_amt |

+---------------+ | limit_amt | | effective_from/to |

| ALLOCATION | | margin_bps | +----------------------+

+---------------+ +-----------------+

| order_id FK |

| alloc_qty |

| adjusted_by |

+---------------+

Modeling principles:

- **History is immutable**: orders, allocations, team membership, and insider lists use new rows with validity periods (effective_from/to) instead of UPDATEs.

- **Document integrity via hashes**: record the SHA-256 of executed versions to detect after-the-fact tampering.

- **Every amount carries its currency**: cross-border deals are common, so amount plus currency pairs are the default.

Workflow Engine Design

The deal lifecycle, wall crossing, credit approval, and signature tracking are all workflows. Whether you build your own or use an engine (Camunda, Temporal, and so on), the IB domain demands these characteristics.

Enforcing deal stage transitions with an explicit state machine

from enum import Enum

class Stage(Enum):

PITCH = "PITCH"

CONFLICT_CHECK = "CONFLICT_CHECK"

MANDATED = "MANDATED"

DUE_DILIGENCE = "DUE_DILIGENCE"

MARKETING = "MARKETING"

PRICING = "PRICING"

CLOSED = "CLOSED"

DEAD = "DEAD"

TRANSITIONS = {

Stage.PITCH: {Stage.CONFLICT_CHECK, Stage.DEAD},

Stage.CONFLICT_CHECK: {Stage.MANDATED, Stage.DEAD},

Stage.MANDATED: {Stage.DUE_DILIGENCE, Stage.DEAD},

Stage.DUE_DILIGENCE: {Stage.MARKETING, Stage.DEAD},

Stage.MARKETING: {Stage.PRICING, Stage.DEAD},

Stage.PRICING: {Stage.CLOSED, Stage.DEAD},

}

REQUIRED_APPROVALS = {

(Stage.PITCH, Stage.CONFLICT_CHECK): ["team_head"],

(Stage.CONFLICT_CHECK, Stage.MANDATED): ["compliance", "business_head"],

(Stage.MARKETING, Stage.PRICING): ["syndicate_head", "compliance"],

}

def transition(deal, target: Stage, approvals: set, actor: str):

if target not in TRANSITIONS[deal.stage]:

raise ValueError(f"illegal transition {deal.stage} -> {target}")

needed = set(REQUIRED_APPROVALS.get((deal.stage, target), []))

if not needed.issubset(approvals):

raise PermissionError(f"missing approvals: {needed - approvals}")

audit_log(deal.deal_id, deal.stage, target, actor, approvals)

deal.stage = target

Additional needs:

- **Timers and escalation**: alerts to seniors when notice deadlines or approval SLAs are exceeded.

- **Compensating actions**: when a deal goes DEAD, insider list cleanup, entitlement revocation, and VDR closure must cascade automatically. If this teardown is manual, it will be missed.

- **The workflow history itself is audit material**: who approved, with which supporting documents attached, must be bound to the transition events.

Pitfalls and Anti-Patterns

- **Spreadsheet pipelines**: the most common and most dangerous. Conflict checks and entitlement controls get bypassed. During transition, provide spreadsheet import features if you must — but pull everything into the system.

- **Conflict checks based on company name string matching**: starting without a legal entity master makes the results untrustworthy.

- **Missed entitlement revocation**: accounts that keep access after deal closure or team departure are a perennial examination finding. Make grants expire by default (grant with expiry).

- **Black-box allocation logic**: unexplainable allocations are a regulatory risk. Record all inputs and manual adjustments.

- **Neglected rounding residue in syndicated loans**: one-cent differences accumulate over years into reconciliation breaks.

- **Indiscriminate two-way sync between the deal system and CRM**: it punches holes in the Chinese wall. Define the sync scope explicitly.

- **Logging without queryability**: audit logs that cannot answer point-in-time questions are useless in an examination.

Build Checklist

- [ ] Is there a legal entity master (including group/affiliate relations) with LEI-based identification

- [ ] Is the conflict check enforced as a workflow gate before deal creation

- [ ] Is the default policy for deal information deny-all, opened only by team membership

- [ ] Do code names replace real names on screens for unauthorized users

- [ ] Is wall crossing a single workflow of approval, registration, time-boxed access, and auto-revocation

- [ ] Does the insider list support immutable history plus point-in-time queries

- [ ] Do document views and downloads carry per-user watermarks and access logs

- [ ] Is the full amendment history of bookbuilding orders preserved and are post-cutoff orders blocked

- [ ] Are allocation inputs, weights, and manual adjustments fully recorded

- [ ] Is there a point-in-time share ledger and a rounding residue rule for syndicated loans

- [ ] Is exposure aggregated at the corporate group level, including undrawn commitments

- [ ] Do entitlement revocation, VDR closure, and list cleanup cascade automatically at deal closure

- [ ] Are audit logs append-only with retention policies matching regulation

Closing Thoughts

The essence of IB systems is not transaction processing but **controlled collaboration**. The reason these systems exist is to precisely control information access, approvals, and records around a small number of high-value deals. The functional requirements (pipeline, bookbuilding, loan administration) are relatively plain; it is the non-functional requirements — immutable history, point-in-time queries, deny-by-default entitlements, automatic revocation — that decide success. If you are building a new system, design the data model and entitlement model before the screens.

Once more: this article is a technical resource, not investment or legal advice.

References

- Financial Investment Services and Capital Markets Act (Korean Law Information Center): https://www.law.go.kr

- Financial Supervisory Service of Korea: https://www.fss.or.kr

- Korea Financial Investment Association (demand forecast rules): https://www.kofia.or.kr

- Korea Exchange listing rules: https://www.krx.co.kr

- DART electronic disclosure system: https://dart.fss.or.kr

- ICMA (International Capital Market Association): https://www.icmagroup.org

- LSTA (Loan Syndications and Trading Association): https://www.lsta.org

- LMA (Loan Market Association): https://www.lma.eu.com

- ESMA — Market Abuse Regulation resources: https://www.esma.europa.eu

- BIS (Bank for International Settlements): https://www.bis.org

- IOSCO (International Organization of Securities Commissions): https://www.iosco.org

- GLEIF (Global Legal Entity Identifier Foundation): https://www.gleif.org