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

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

들어가며

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

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

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

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

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

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

| FRONT OFFICE (FO) "거래를 만든다" |

| - OMS(주문관리) / EMS(집행관리) / 알고 엔진 |

| - 프라이싱, 호가, 마켓데이터 |

| - 트레이더 블로터(당일 거래 현황) |

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

| 체결(execution) 이벤트

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

| MIDDLE OFFICE (MO) "거래를 통제한다" |

| - 트레이드 캡처/보강(enrichment) - 계좌, 수수료, 결제정보 부여 |

| - 한도 모니터링(포지션/신용/VaR), 리스크 리포팅 |

| - 실시간 PnL, 일중 포지션 관리 |

| - 컨펌(거래 확인), 어펌(기관고객 확인) |

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

| 확정된 트레이드(confirmed trade)

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

| BACK OFFICE (BO) "거래를 끝낸다" |

| - 청산/결제 지시 생성, 결제기관 연계(KSD/KRX청산/글로벌 커스터디안) |

| - 원장 기장, 회계 연동, 수수료/세금 정산 |

| - 대사(포지션/현금/거래), 브레이크 관리 |

| - 코퍼레이트 액션, 보고서, 규제 보고 |

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

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

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

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

트레이더 OMS/EMS 거래소/장외 MO(캡처/컨펌) 청산기관 BO(결제) 예탁/계좌

| | | | | | |

|--주문------>|--집행------->| | | | |

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

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

설계 시사점: 트레이드 모델은 상품 공통 코어(거래 식별자, 당사자, 수량, 금액, 일자들)와 상품별 확장(파생의 기초자산·만기·증거금, 채권의 경과이자 등)으로 분리하는 것이 유지보수에 유리합니다. 특히 **일자(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

운영 포인트:

- **시세 소스의 우선순위와 폴백**: 마감 시세가 없는 종목(비유동 채권, 비상장)은 평가 모델이나 전일 가격 폴백 규칙이 필요하고, 어떤 소스로 평가했는지가 기록되어야 합니다.

- **FO 추정 PnL과 BO 공식 PnL의 차이 설명**: 두 숫자는 다를 수 있습니다(시세 시점, 수수료 반영 차이). 차이가 임계치를 넘으면 마감 전에 설명되어야 합니다. 이를 PnL explain 프로세스라 부릅니다.

- **마감 후 정정(late adjustment)**: 마감 후 발견된 오류는 전일 데이터를 고치는 것이 아니라 당일 정정 분개로 반영합니다. 마감된 일자의 데이터는 불변이어야 합니다.

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

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

- **한도 모니터링**: 포지션 한도(종목·섹터·북 단위), 손실 한도(일중/누적 손실 제한), 신용 한도(거래상대방별 익스포저)를 실시간 또는 준실시간으로 감시합니다. 한도 위반 시의 절차(경보 → 소명 → 강제 청산 여부)가 시스템 워크플로로 정의되어야 합니다.

- **VaR(Value at Risk)**: 일정 신뢰수준(예: 99%)에서 일정 보유기간(예: 1일) 동안 발생할 수 있는 최대 손실 추정치입니다. 역사적 시뮬레이션, 분산-공분산, 몬테카를로 방식이 있으며, 어느 방식이든 포지션 데이터와 시장데이터의 품질이 결과를 좌우합니다. VaR 계산 자체는 리스크 엔진의 일이지만, **입력이 되는 포지션 스냅숏의 정확성과 적시성**은 백오피스 데이터 품질의 문제입니다.

- **백테스팅**: VaR 추정치와 실제 손익을 비교해 모델을 검증합니다. 바젤 시장리스크 규제(FRTB 포함)에서 요구되는 절차입니다.

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

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

- 장내 거래는 거래소 체결 데이터가 기준이 되므로 비교적 단순합니다.

- 장외 거래(채권, OTC 파생)는 양 당사자가 각자 기록한 조건을 맞춰야 합니다. 전자 컨펌 플랫폼을 쓰거나, SWIFT 메시지로 교환하거나, 최악의 경우 팩스·이메일 수작업이 됩니다.

- 기관 고객 거래는 운용사 측 확인(affirmation)과 결제 지시 배분(allocation: 블록 체결을 복수 펀드 계좌로 쪼개는 것)이 추가됩니다.

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

브레이크 라이프사이클:

탐지(detected) --> 배정(assigned: 담당자 지정)

--> 조사(investigating: 원인 코드 분류)

--> 해소(resolved: 정정 분개/상대방 수정/시세 정정 ...)

--> 종결(closed: 승인자 확인)

핵심 메트릭: 미해소 브레이크 건수 x 경과일수(aging) x 금액

3일 이상 경과한 고액 브레이크는 자동 에스컬레이션

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

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

| 모델 | 증권 | 대금 | 특징 |

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

한국 시장 인프라:

- **한국거래소(KRX)**: 장내 매매 체결과 청산(CCP). 장내 주식·파생의 중앙거래당사자로서 결제 이행을 보증합니다.

- **한국예탁결제원(KSD)**: 증권의 중앙예탁기관(CSD). 증권 계좌대체(전자등록)로 증권 인도가 이뤄집니다. 주식은 전자증권제도에 따라 전자등록 방식으로 관리됩니다.

- **한국은행 BOK-Wire+(한은금융망)**: 원화 거액결제시스템(RTGS). 결제 대금의 최종 이체가 한국은행 당좌계좌 간에 이뤄지며, 증권대금동시결제(DVP)가 KSD와 연계되어 처리됩니다.

- **결제 주기**: KRX 주식시장은 T+2 결제입니다(체결일로부터 2영업일 후).

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

확정 트레이드

--> 결제지시 생성(settlement instruction)

- 상대방 결제 정보(SSI: Standing Settlement Instructions) 적용

--> 지시 전송 (KSD 연계 / 글로벌은 커스터디안 경유 SWIFT)

--> 매칭 상태 추적 (상대방 지시와 매칭 여부)

--> 결제일 모니터링 (예정 vs 실제)

--> 결제 완료 확인 --> 원장 기장 확정

--> 실패 시: 결제 실패 처리 플로(후술)

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

SWIFT 메시지 흐름 — MT와 MX

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

| 용도 | MT (기존) | MX (ISO 20022) |

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

| 증권 수령 지시 (대금 지급) | MT541 | sese.023 (RvP) |

| 증권 인도 지시 (대금 수령) | MT543 | sese.023 (DvP) |

| 결제 확인 | MT545 / MT547 | sese.025 |

| 상태/처리 통보 | MT548 | sese.024 |

| 잔고 보고 | MT535 | semt.002 |

| 거래 내역 보고 | MT536 | semt.017 |

| 고객 송금 | MT103 | pacs.008 |

| 은행간 자금 이체 | MT202 | pacs.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

설계 원칙:

- **거래 시스템의 트레이드와 회계 분개는 1:N 매핑**이고, 모든 분개에는 원천 거래 식별자가 남아야 합니다(drill-down 가능).

- **포스팅 룰은 데이터로 관리**: 상품·이벤트·계정 매핑을 코드에 하드코딩하면 신상품 출시마다 배포가 필요해집니다. 룰 테이블 + 버전 관리가 표준 접근입니다.

- **일마감과 총계정원장(GL) 인터페이스**: 백오피스 보조원장(sub-ledger)의 일계표가 GL로 넘어가고, 보조원장-GL 잔액 대사가 일배치로 돌아야 합니다.

코퍼레이트 액션 처리

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

- **이벤트 수신**: KSD/커스터디안/데이터 벤더로부터 CA 통지를 받습니다(SWIFT MT564 계열). 같은 이벤트가 여러 소스에서 다른 형태로 오기 때문에 **골든 레코드 생성(소스 간 대사)**이 첫 관문입니다.

- **권리 계산**: 기준일(record date) 시점 보유 수량에 비율을 적용합니다. 기준일 포지션 스냅숏의 정확성이 전부입니다. 대차(빌려준/빌린 주식) 포지션의 권리 귀속도 처리해야 합니다.

- **선택형 이벤트(voluntary 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으로 남겨 사람이 조사

...

설계 원칙:

- **대사는 스냅숏 기준**: 양쪽 데이터의 기준 시점(as-of)이 일치해야 합니다. 내부는 마감 후, 외부는 전일 잔고 보고라면 그 시차에서 가짜 브레이크가 양산됩니다.

- **자동 분류와 자동 해소**: 알려진 패턴(미결제분 시차 등)은 자동 분류·자동 매칭하고, 사람은 미지의 브레이크에 집중하게 합니다. 단, 자동 해소 규칙 자체가 감사 대상이므로 규칙 변경 이력을 남깁니다.

- **브레이크는 데이터로 관리**: 위 브레이크 라이프사이클(탐지→배정→조사→해소→종결)을 테이블로 두고 에이징 리포트를 자동화합니다.

데이터 모델 스케치

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

+----------------+ | INSTRUCTION | +-------------------+

| trade_id PK |--+ +------------------+ | account_id |

| 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)는 기존 행 수정이 아니라 새 버전 행으로 쌓고, 항상 최신 유효 버전을 가리키는 뷰를 둡니다. 결제 지시·분개가 어느 트레이드 버전에서 생성됐는지 추적 가능해야 정정 처리의 정합성이 보장됩니다.

함정과 안티패턴

- **체결일/결제일 혼동**: 포지션을 "어느 기준으로" 보는지(trade-date position vs settle-date position)가 화면마다 다르면 모든 대사가 혼란에 빠집니다. 기준을 명시하고 양쪽 뷰를 의도적으로 제공하세요.

- **마감 데이터 수정**: 마감된 일자의 데이터를 직접 UPDATE하는 운영 관행은 회계 감사에서 치명적입니다. 정정은 항상 당일 반대 분개 + 재기장으로.

- **수작업 SSI 관리**: 결제 실패의 단골 원인. SSI 변경에 4-eyes 승인과 유효 기간을 두세요.

- **대사 허용오차의 남용**: 브레이크를 줄이려고 허용오차를 키우면 대사의 의미가 사라집니다. 포지션은 0 오차가 원칙입니다.

- **상태 코드의 자유 입력**: 브레이크 원인, 결제 실패 사유를 자유 텍스트로 받으면 통계와 자동화가 불가능해집니다. 코드 체계를 먼저 설계하세요.

- **CA 마감 시한의 수동 관리**: 선택형 CA 마감을 달력과 사람 기억에 의존하는 구조는 언젠가 반드시 사고가 납니다.

- **배치 의존 체인의 암묵화**: 시세 수신 → 평가 → 분개 → GL 전송 → 대사의 순서 의존성이 문서에만 있고 스케줄러에 없으면, 지연 시 부분 실행으로 오염된 데이터가 만들어집니다.

구축 체크리스트

- [ ] FO/MO/BO의 시스템 권한이 직무 분리 원칙에 따라 분리되어 있는가

- [ ] 트레이드 모델이 정정·취소를 버전으로 관리하는가

- [ ] 체결일 기준/결제일 기준 포지션이 명확히 구분되는가

- [ ] EOD 평가의 시세 소스 우선순위와 평가 불능 예외 큐가 있는가

- [ ] FO 추정 PnL과 BO 공식 PnL의 차이 설명 프로세스가 있는가

- [ ] 컨펌/어펌이 전자화되어 있고 미확인 거래 에이징이 모니터링되는가

- [ ] SSI가 마스터 데이터로 관리되고 변경에 승인 절차가 있는가

- [ ] 결제 지시의 매칭 상태가 결제일 전부터 추적되는가

- [ ] 결제 실패 runbook과 원인 코드 체계, 에스컬레이션 경로가 있는가

- [ ] 포지션/현금/거래 대사가 일배치로 돌고 브레이크가 라이프사이클로 관리되는가

- [ ] 분개가 원천 거래로 drill-down 가능하고 포스팅 룰이 데이터로 관리되는가

- [ ] 보조원장-GL 잔액 대사가 자동화되어 있는가

- [ ] CA 이벤트의 소스 간 대사와 선택형 마감 시한 알림이 있는가

- [ ] 배치 의존성이 스케줄러(DAG)에 명시되어 있는가

마치며

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

참고 자료

- BIS CPMI — Principles for Financial Market Infrastructures (PFMI): https://www.bis.org/cpmi/publ/d101.htm

- BIS CPMI — Delivery versus Payment in Securities Settlement Systems: https://www.bis.org/cpmi/publ/d06.htm

- 한국예탁결제원: https://www.ksd.or.kr

- 한국은행 (한은금융망 BOK-Wire+): https://www.bok.or.kr

- 한국거래소 (청산결제): https://www.krx.co.kr

- 금융감독원: https://www.fss.or.kr

- SWIFT — Standards (MT/MX): https://www.swift.com/standards

- ISO 20022: https://www.iso20022.org

- DTCC (미국 청산결제 인프라 참고): https://www.dtcc.com

- ESMA — CSDR (결제규율 제도): https://www.esma.europa.eu

- Basel Committee — Minimum capital requirements for market risk (FRTB): https://www.bis.org/bcbs/publ/d457.htm