LabHub

블로그

트레이딩 백오피스와 결제 시스템 — Front/Middle/Back의 데이터 여정

2026-06-13 · 31 분 읽기 · #back-office#settlement#trading#capital-markets#reconciliation#finance#swift

한국어English日本語

들어가며

트레이딩 시스템이라고 하면 보통 화려한 프론트오피스 — 주문 집행, 알고 트레이딩, 호가창 — 를 떠올립니다. 하지만 체결 한 건이 돈과 증권의 실제 이동으로 끝나기까지는 그 뒤에 훨씬 긴 여정이 있습니다. 포지션 반영, 손익 계산, 확인(컨펌), 청산, 결제 지시, 원장 기장, 대사까지. 이 여정을 책임지는 것이 미들오피스와 백오피스 시스템입니다.

백오피스는 화려하지 않지만, 장애가 곧 금융사고가 되는 영역입니다. 결제가 하루 늦으면 거래상대방 리스크와 페널티가 발생하고, 대사 브레이크를 방치하면 회계 감사와 규제 검사에서 문제가 됩니다. 이 글은 주식/채권/파생 트레이드 한 건이 체결 후 어떤 시스템들을 거쳐 최종 결제와 회계 기장까지 도달하는지, 그 과정에서 어떤 통제와 배치가 작동하는지를 시스템 설계 관점에서 따라갑니다. 한국 시장 인프라(한국거래소, 한국예탁결제원, 한국은행 BOK-Wire+)의 맥락도 함께 다룹니다.

본 글은 기술 자료이며 투자 자문이 아닙니다.

FO/MO/BO 구분과 시스템 맵

증권사·은행 트레이딩 부문의 시스템은 전통적으로 세 구역으로 나눕니다.

+--------------------------------------------------------------------+
| FRONT OFFICE (FO)            "거래를 만든다"                         |
|  - OMS(주문관리) / EMS(집행관리) / 알고 엔진                          |
|  - 프라이싱, 호가, 마켓데이터                                         |
|  - 트레이더 블로터(당일 거래 현황)                                     |
+---------------------------+----------------------------------------+
                            | 체결(execution) 이벤트
                            v
+--------------------------------------------------------------------+
| MIDDLE OFFICE (MO)           "거래를 통제한다"                       |
|  - 트레이드 캡처/보강(enrichment) - 계좌, 수수료, 결제정보 부여        |
|  - 한도 모니터링(포지션/신용/VaR), 리스크 리포팅                       |
|  - 실시간 PnL, 일중 포지션 관리                                       |
|  - 컨펌(거래 확인), 어펌(기관고객 확인)                                |
+---------------------------+----------------------------------------+
                            | 확정된 트레이드(confirmed trade)
                            v
+--------------------------------------------------------------------+
| BACK OFFICE (BO)             "거래를 끝낸다"                         |
|  - 청산/결제 지시 생성, 결제기관 연계(KSD/KRX청산/글로벌 커스터디안)    |
|  - 원장 기장, 회계 연동, 수수료/세금 정산                              |
|  - 대사(포지션/현금/거래), 브레이크 관리                               |
|  - 코퍼레이트 액션, 보고서, 규제 보고                                  |
+--------------------------------------------------------------------+

핵심 원칙은 직무 분리(segregation of duties)입니다. 거래를 일으키는 사람(FO)과 거래를 검증·정산하는 사람(MO/BO)은 조직도, 시스템 권한도 분리되어야 합니다. FO 트레이더가 백오피스 시스템의 결제 데이터를 수정할 수 있는 구조는 그 자체로 감사 지적 사항입니다.

주문 → 체결 → 청산 → 결제: 상품별 흐름

전체 흐름을 시퀀스로 보면 다음과 같습니다.

 트레이더      OMS/EMS      거래소/장외     MO(캡처/컨펌)    청산기관       BO(결제)      예탁/계좌
   |             |             |              |              |             |             |
   |--주문------>|--집행------->|              |              |             |             |
   |             |<--체결 통보--|              |              |             |             |
   |             |--체결 전달--------------->|               |             |             |
   |             |             |              |--보강/검증--->|             |             |
   |             |             |              |--컨펌 발송--> (상대방)      |             |
   |             |             |              |              |<--청산내역--|             |
   |             |             |              |              |--차감결제-->|             |
   |             |             |              |              |             |--결제지시-->|
   |             |             |              |              |             |<--결제완료--|
   |             |             |              |              |             |--기장/대사--|

상품별로 청산·결제 구조가 다릅니다.

구분주식(장내)채권장내파생장외파생(OTC)
체결 장소거래소(KRX)장외 위주 + 국채전문유통시장파생상품시장(KRX)양자간 계약
청산KRX 청산(CCP)대부분 양자간, 일부 CCPKRX 청산(CCP)일부 CCP 의무청산(IRS 등)
결제 주기T+2 (KRX 주식시장 기준)통상 T+1, 거래 조건에 따름일일정산(증거금)계약 조건(CSA 담보)
결제 방식DVP, 예탁결제DVP현금 차감결제현금/담보 이전
핵심 리스크결제 실패결제 실패, 상대방증거금 부족상대방 신용, 담보 분쟁

설계 시사점: 트레이드 모델은 상품 공통 코어(거래 식별자, 당사자, 수량, 금액, 일자들)와 상품별 확장(파생의 기초자산·만기·증거금, 채권의 경과이자 등)으로 분리하는 것이 유지보수에 유리합니다. 특히 일자(date)의 구분 — 체결일(trade date), 결제예정일(settlement date), 실제결제일 — 을 처음부터 분리해 두지 않으면 나중에 수습이 어렵습니다.

포지션과 손익 관리 — 실시간 PnL과 EOD 평가

포지션 관리의 기본은 단순합니다. 체결 이벤트를 계좌·종목 단위로 누적하면 포지션이 됩니다. 어려운 것은 손익(PnL)입니다. 손익은 두 가지로 나뉩니다.

실현손익(realized PnL)
  = 매도 시점에 확정되는 손익
  = (매도단가 - 보유원가단가) x 매도수량   [원가 산정: 이동평균법 등]

평가손익(unrealized PnL)
  = 보유 중인 포지션의 장부상 손익
  = (현재 평가단가 - 보유원가단가) x 보유수량

일중 PnL(intraday)
  = 전일 평가 기준 대비 당일 변동
  = 당일 실현손익 + (당일 평가단가 - 전일 평가단가) x 보유수량 + 당일 신규분 손익

실시간 PnL은 MO의 영역입니다. 체결 스트림과 시세 스트림을 결합해 트레이더·데스크·북 단위로 집계합니다. 반면 EOD(일마감) 평가는 BO/리스크의 공식 숫자입니다. 마감 시세(공정가액 평가 기준)로 전 포지션을 재평가하고, 이 숫자가 회계 원장과 규제 보고의 원천이 됩니다.

# EOD 평가 배치의 골격 (개념 예시)
from decimal import Decimal

def eod_valuation(positions, closing_prices, fx_rates, base_ccy="KRW"):
    results = []
    for pos in positions:
        price = closing_prices.get(pos.instrument_id)
        if price is None:
            # 평가 불능 종목은 반드시 예외 큐로 — 0으로 채우면 안 된다
            results.append(valuation_exception(pos, reason="NO_PRICE"))
            continue
        mv_local = Decimal(pos.quantity) * price.clean_price
        if pos.instrument_type == "BOND":
            mv_local += Decimal(pos.quantity) * price.accrued_interest
        fx = fx_rates.get((pos.currency, base_ccy), Decimal("1"))
        mv_base = mv_local * fx
        unrealized = mv_base - pos.cost_basis_base
        results.append(make_valuation(pos, mv_local, mv_base, unrealized,
                                      price_source=price.source))
    return results

운영 포인트:

리스크 미들오피스 — 한도와 VaR

미들오피스의 또 다른 축은 리스크 통제입니다.

확인과 대사 — 컨펌, 어펌, 브레이크 관리

체결 직후 가장 중요한 통제는 거래 확인(confirmation)입니다. 우리 시스템의 거래 기록과 상대방의 기록이 일치하는지 확인하는 절차입니다.

확인·대사에서 불일치가 발견되면 브레이크(break)로 등록되고, 해소될 때까지 추적됩니다.

브레이크 라이프사이클:
  탐지(detected) --> 배정(assigned: 담당자 지정)
     --> 조사(investigating: 원인 코드 분류)
     --> 해소(resolved: 정정 분개/상대방 수정/시세 정정 ...)
     --> 종결(closed: 승인자 확인)

  핵심 메트릭: 미해소 브레이크 건수 x 경과일수(aging) x 금액
  3일 이상 경과한 고액 브레이크는 자동 에스컬레이션

결제 시스템 — DVP, 한국예탁결제원, BOK-Wire+

결제(settlement)는 증권과 대금이 실제로 이동하는 순간입니다. 핵심 개념은 DVP(Delivery versus Payment, 동시결제): 증권 인도와 대금 지급이 상호 조건부로 묶여, 한쪽만 이행되는 원금 리스크를 제거하는 방식입니다. BIS CPMI 기준으로 DVP는 세 가지 모델로 분류됩니다.

모델증권대금특징
DVP 모델 1건별 총량 결제건별 총량 결제원금 리스크 최소, 유동성 소요 큼
DVP 모델 2건별 총량 결제차감(net) 결제증권은 즉시, 대금은 마감 차감
DVP 모델 3차감 결제차감 결제유동성 효율 최대, 시스템 의존 큼

한국 시장 인프라:

백오피스 시스템 관점에서 결제 처리는 다음 단계로 구성됩니다.

확정 트레이드
   --> 결제지시 생성(settlement instruction)
       - 상대방 결제 정보(SSI: Standing Settlement Instructions) 적용
   --> 지시 전송 (KSD 연계 / 글로벌은 커스터디안 경유 SWIFT)
   --> 매칭 상태 추적 (상대방 지시와 매칭 여부)
   --> 결제일 모니터링 (예정 vs 실제)
   --> 결제 완료 확인 --> 원장 기장 확정
   --> 실패 시: 결제 실패 처리 플로(후술)

SSI 마스터 데이터의 품질이 결제 STP(straight-through processing)율을 결정합니다. 상대방·통화·상품별 결제 계좌 정보가 틀려 있으면 그 거래는 반드시 수작업이 됩니다.

SWIFT 메시지 흐름 — MT와 MX

크로스보더 결제와 글로벌 커스터디 연계에는 SWIFT 메시지가 표준입니다. 증권 결제에서 자주 쓰는 메시지:

용도MT (기존)MX (ISO 20022)
증권 수령 지시 (대금 지급)MT541sese.023 (RvP)
증권 인도 지시 (대금 수령)MT543sese.023 (DvP)
결제 확인MT545 / MT547sese.025
상태/처리 통보MT548sese.024
잔고 보고MT535semt.002
거래 내역 보고MT536semt.017
고객 송금MT103pacs.008
은행간 자금 이체MT202pacs.009

흐름 예시 — 외화 채권을 글로벌 커스터디안을 통해 수령(RvP)하는 경우:

 자산운용/증권사 BO        글로벌 커스터디안           현지 CSD/서브커스터디안
       |                        |                          |
       |--- MT541 (수령지시) --->|                          |
       |                        |--- 현지 지시 변환 -------->|
       |                        |<-- 매칭/결제 상태 ---------|
       |<-- MT548 (상태통보) ----|                          |
       |<-- MT545 (결제확인) ----|     (결제 완료 시)         |
       |                        |                          |
       |<-- MT535 (잔고보고, EOD)|                          |

운영 포인트: MT 메시지는 필드가 느슨해서 기관마다 관행이 다릅니다. 같은 MT548이라도 상태 코드 사용 방식이 커스터디안마다 달라, 상대 기관별 파싱 규칙(온보딩 시 합의)이 필요합니다. ISO 20022 전환(증권 분야는 진행 중)은 이 문제를 구조화된 코드로 완화합니다.

원장 기장과 회계 연동

모든 트레이드는 최종적으로 회계 분개가 됩니다. 백오피스 시스템은 거래 이벤트를 회계 이벤트로 변환하는 포스팅 룰 엔진을 가집니다.

이벤트별 분개 예시 (주식 매수, 단순화):
  체결일(T):    (차) 미수증권     xxx   (대) 미지급금       xxx
  결제일(T+2):  (차) 보유증권     xxx   (대) 미수증권       xxx
               (차) 미지급금     xxx   (대) 현금(예탁금)    xxx
  EOD 평가:    (차/대) 평가손익  xxx   (대/차) 증권평가조정 xxx

설계 원칙:

코퍼레이트 액션 처리

배당, 무상증자, 액면분할, 합병, 콜/풋 행사 — 코퍼레이트 액션(CA)은 백오피스에서 가장 오류가 잦은 영역입니다.

장애가 곧 사고 — 결제 실패 대응 runbook

결제 실패(settlement fail)는 예정일에 증권 또는 대금이 이동하지 못한 상태입니다. 원인은 증권 부족(매도 측), 자금 부족, 지시 불일치, SSI 오류 등 다양합니다.

결제 실패 대응 runbook (요약):

1. 탐지 (결제일 당일, 가능한 한 이른 시각)
   - 결제 예정 vs 매칭/완료 상태 모니터링 대시보드
   - 미매칭 지시는 결제일 전부터 경보 (T+1 시점 미매칭 = 위험 신호)

2. 분류 (원인 코드)
   - 지시 불일치(UNMATCHED) / 증권 부족(LACK) / 자금 부족(MONY)
   - 상대방 사유 / 자사 사유 구분 — 책임 소재가 페널티와 직결

3. 즉시 조치
   - 지시 불일치: 상대방과 조건 재확인, 정정 지시 전송
   - 증권 부족: 대차(차입) 가능성 타진, 부분 결제(partial) 협의
   - 자금 부족: 자금부서 에스컬레이션, 일중 유동성 조달

4. 이해관계자 통보
   - 고객(기관) / 트레이딩 데스크 / 준법·리스크
   - 페일이 연쇄(체인)를 만드는 경우 후속 결제 영향 분석

5. 사후 처리
   - 페일 비용/페널티 정산 기록
   - 원인 분석 → SSI 정비, 프로세스 개선 항목 등록
   - 반복 상대방/반복 원인 리포트 (월간)

유럽 CSDR의 결제규율(페널티) 제도처럼 결제 실패에 금전 페널티를 부과하는 규제가 확산되어 왔기 때문에, 페일 모니터링은 비용 절감과 직결됩니다.

정합성 대사 배치 설계

백오피스의 심장은 대사(reconciliation)입니다. 최소 세 종류가 일배치로 돌아야 합니다.

  1. 포지션 대사: 내부 장부 vs 예탁기관/커스터디안 잔고(MT535)
  2. 현금 대사: 내부 현금 원장 vs 은행/커스터디안 계좌 명세(MT940/camt.053)
  3. 거래 대사: FO 시스템 vs BO 시스템의 당일 거래 (내부 시스템 간)
# 포지션 대사 배치의 골격 (개념 예시)
from collections import defaultdict
from decimal import Decimal

KEY = ("account_id", "instrument_id")  # 대사 키
TOLERANCE = Decimal("0")               # 포지션은 0 허용오차가 원칙

def reconcile(internal_rows, external_rows, as_of_date):
    internal = aggregate(internal_rows)   # key -> quantity
    external = aggregate(external_rows)
    breaks = []
    for key in internal.keys() | external.keys():
        iq = internal.get(key, Decimal("0"))
        eq = external.get(key, Decimal("0"))
        if abs(iq - eq) > TOLERANCE:
            breaks.append({
                "as_of": as_of_date,
                "key": key,
                "internal_qty": iq,
                "external_qty": eq,
                "diff": iq - eq,
                "classification": classify(key, iq, eq),  # 자동 원인 추정
            })
    return breaks

def classify(key, iq, eq):
    # 자동 분류 휴리스틱: 미결제 거래분, CA 처리 시차, 대차 미반영 등
    # 분류 불가는 UNKNOWN으로 남겨 사람이 조사
    ...

설계 원칙:

데이터 모델 스케치

+----------------+      +------------------+      +-------------------+
|    TRADE       |      | SETTLEMENT_      |      |   POSITION        |
+----------------+      | INSTRUCTION      |      +-------------------+
| trade_id PK    |--+   +------------------+      | account_id        |
| order_id FK    |  +-<-| trade_id FK      |      | instrument_id     |
| account_id     |      | si_id PK         |      | as_of_date        |
| instrument_id  |      | direction (R/D)  |      | quantity          |
| qty / price    |      | ssi_id FK        |      | cost_basis        |
| trade_date     |      | expected_date    |      | (일자별 스냅숏)     |
| settle_date    |      | matched_status   |      +-------------------+
| status         |      | settled_at       |
| version        |      +------------------+      +-------------------+
+----------------+                                |  RECON_BREAK      |
       |                +------------------+      +-------------------+
       +------------->  | POSTING (분개)    |      | break_id PK       |
                        +------------------+      | recon_type        |
                        | posting_id PK    |      | as_of_date        |
                        | trade_id FK      |      | key (acct/instr)  |
                        | event_type       |      | diff_amount       |
                        | debit_account    |      | status / aging    |
                        | credit_account   |      | assigned_to       |
                        | amount / ccy     |      | resolution_code   |
                        | posted_at        |      +-------------------+
                        +------------------+

트레이드 테이블에서 중요한 것은 버전 관리입니다. 정정(amend)·취소(cancel)는 기존 행 수정이 아니라 새 버전 행으로 쌓고, 항상 최신 유효 버전을 가리키는 뷰를 둡니다. 결제 지시·분개가 어느 트레이드 버전에서 생성됐는지 추적 가능해야 정정 처리의 정합성이 보장됩니다.

함정과 안티패턴

구축 체크리스트

마치며

백오피스 시스템의 가치는 평소에는 보이지 않습니다. 모든 것이 STP로 흘러가는 날에는 아무도 백오피스를 이야기하지 않습니다. 그러나 결제가 실패한 날, 대사가 깨진 날, 감사가 들어온 날 — 그날 조직을 지키는 것은 잘 설계된 데이터 모델, 불변 이력, 자동화된 대사, 그리고 준비된 runbook입니다. 트레이딩 시스템을 만든다면 화려한 프론트만큼, 아니 그보다 더, 데이터의 마지막 구간을 단단하게 만드시기 바랍니다.

참고 자료

원문 보기: https://www.youngju.dev/blog/finance/2026-06-13-trading-back-office-settlement-systems

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다