LabHub

블로그

ISO 20022와 SWIFT — 금융 메시징 표준의 대전환

2026-06-13 · 27 분 읽기 · #iso20022#swift#payments#financial-messaging#xml#finance#integration

한국어English日本語

들어가며

국경을 넘는 송금 한 건의 뒤에는 은행 간에 오가는 메시지가 있습니다. 이 메시지의 형식이 수십 년 만에 교체되고 있습니다. 1970년대에 설계된 SWIFT MT 포맷이 ISO 20022 기반의 구조화된 XML 메시지(MX)로 전환되는 것입니다. 2025년 11월, 국경 간 지급 메시지의 MT-MX 공존 기간이 종료되면서 이 전환은 더 이상 미래형이 아니라 완료형에 가까워졌습니다.

이 전환은 단순한 포맷 변경이 아닙니다. 수취인 이름이 자유 텍스트 한 줄에서 구조화된 주소 필드로 바뀌면 AML(자금세탁방지) 스크리닝의 정확도가 달라지고, 정형 데이터가 늘어나면 지급 시스템의 자동화율이 달라집니다. 동시에, 기존 MT에 묶여 있는 레거시 시스템을 운영하는 입장에서는 변환 계층, 스키마 관리, 절단(truncation) 문제라는 현실적인 과제가 쏟아집니다.

이 글은 금융 메시징의 역사부터 ISO 20022의 구조, MT103과 pacs.008의 비교, CBPR+ 마이그레이션, 변환 아키텍처와 구현, 테스트 전략, 운영 함정까지를 엔지니어 관점에서 정리합니다. 본 글은 기술 자료이며 투자 자문이 아닙니다.

금융 메시징의 역사 — 텔렉스에서 ISO 20022까지

1950~70년대   텔렉스(Telex)
              - 자유 텍스트 전문, 표준 없음, 수작업 검증
              - 위변조·오타 리스크, 처리 자동화 불가
        |
        v
1977~        SWIFT MT (Message Type)
              - SWIFT 네트워크 가동, 블록 구조의 정형 전문
              - MT103(고객송금), MT202(은행간), MT5xx(증권), MT9xx(현금관리)
              - 필드는 구조화됐지만 상당수가 자유 텍스트(이름/주소 4x35자 등)
        |
        v
2004~        ISO 20022 표준 제정
              - 비즈니스 모델 기반의 메시지 표준 (XML 문법)
              - SEPA(유럽), 일본 젠긴(Zengin) EDI, 각국 RTGS가 단계적 채택
        |
        v
2022~2025    CBPR+ — 국경 간 지급의 ISO 20022 전환
              - 2022년 3월 MT/MX 공존 시작
              - 2025년 11월 지급 관련 MT(카테고리 1, 2, 9 중 대상 전문)의
                국경 간 사용 공존 종료 — MX(pacs/camt)로 일원화
              - 주요국 RTGS(유로 T2, 영국 CHAPS, 미국 Fedwire 등)도
                ISO 20022 전환 완료 또는 진행

요약하면, 금융 메시징은 "사람이 읽는 전문"에서 "기계가 검증하고 처리하는 데이터"로 진화해 왔습니다. ISO 20022는 그 진화의 현재 종착점입니다.

ISO 20022의 구조 — 비즈니스 모델과 메시지 정의

ISO 20022의 가장 큰 특징은 문법(syntax)과 의미(semantics)의 분리입니다.

주요 메시지 패밀리:

패밀리영역대표 메시지
pain고객-은행 지급 개시pain.001 (지급 지시), pain.002 (상태 보고)
pacs은행 간 지급 청산·결제pacs.008 (고객송금), pacs.009 (은행간), pacs.004 (반환), pacs.002 (상태)
camt현금 관리·계좌 보고camt.053 (계좌명세), camt.052 (잔고보고), camt.056 (취소요청)
sese / semt증권 결제·관리sese.023 (결제지시), semt.002 (잔고)
setr펀드 주문setr.004 등

pacs.008(은행 간 고객송금)의 단순화된 예시:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>ABCDKRSE-20260613-000123</MsgId>
      <CreDtTm>2026-06-13T09:30:47+09:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf>
        <SttlmMtd>INDA</SttlmMtd>
      </SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>INSTR-000123</InstrId>
        <EndToEndId>E2E-INV-2026-0456</EndToEndId>
        <UETR>97ed4827-7b6f-4491-a06f-b548d5a7512d</UETR>
      </PmtId>
      <IntrBkSttlmAmt Ccy="USD">25000.00</IntrBkSttlmAmt>
      <IntrBkSttlmDt>2026-06-13</IntrBkSttlmDt>
      <ChrgBr>SHAR</ChrgBr>
      <Dbtr>
        <Nm>HANKOOK TRADING CO LTD</Nm>
        <PstlAdr>
          <StrtNm>TEHERAN-RO 123</StrtNm>
          <TwnNm>SEOUL</TwnNm>
          <Ctry>KR</Ctry>
        </PstlAdr>
      </Dbtr>
      <DbtrAcct>
        <Id><Othr><Id>110123456789</Id></Othr></Id>
      </DbtrAcct>
      <DbtrAgt>
        <FinInstnId><BICFI>ABCDKRSE</BICFI></FinInstnId>
      </DbtrAgt>
      <CdtrAgt>
        <FinInstnId><BICFI>WXYZUS33</BICFI></FinInstnId>
      </CdtrAgt>
      <Cdtr>
        <Nm>GLOBAL PARTS INC</Nm>
        <PstlAdr>
          <TwnNm>NEW YORK</TwnNm>
          <Ctry>US</Ctry>
        </PstlAdr>
      </Cdtr>
      <CdtrAcct>
        <Id><Othr><Id>987654321</Id></Othr></Id>
      </CdtrAcct>
      <RmtInf>
        <Ustrd>INVOICE 2026-0456 MACHINE PARTS</Ustrd>
      </RmtInf>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

주목할 점: 송금인(Dbtr)과 수취인(Cdtr)의 이름·주소가 구조화된 필드로 나뉘어 있고, UETR(고유 거래 식별자)이 메시지에 내장되어 SWIFT gpi 추적과 연결됩니다.

MT103 vs pacs.008 — 필드 매핑

비교를 위해, 위와 같은 송금을 기존 MT103 원문 형태로 보면 다음과 같습니다.

{1:F01ABCDKRSEAXXX0000000000}{2:I103WXYZUS33XXXXN}
{3:{121:97ed4827-7b6f-4491-a06f-b548d5a7512d}}{4:
:20:INSTR-000123
:23B:CRED
:32A:260613USD25000,00
:33B:USD25000,00
:50K:/110123456789
HANKOOK TRADING CO LTD
TEHERAN-RO 123
SEOUL KOREA
:57A:WXYZUS33
:59:/987654321
GLOBAL PARTS INC
NEW YORK US
:70:INVOICE 2026-0456 MACHINE PARTS
:71A:SHA
-}

콜론으로 시작하는 필드 태그와 줄바꿈으로 구분되는 자유 텍스트 — 사람이 읽기에는 간결하지만, 50K의 네 줄 중 어디까지가 이름이고 어디부터가 주소인지 기계가 확신할 방법이 없습니다. 두 형식의 대응 관계를 보면 전환의 본질이 보입니다.

MT103 필드의미pacs.008 대응 요소(경로)
20송금 참조번호GrpHdr/MsgId, PmtId/InstrId
121 (헤더)UETRPmtId/UETR
23B은행 운영 코드별도 코드 체계로 분해 (PmtTpInf 등)
32A결제일·통화·금액IntrBkSttlmDt + IntrBkSttlmAmt
33B지시 통화·금액InstdAmt
50a송금 의뢰인Dbtr (Nm, PstlAdr 구조화) + DbtrAcct
52a의뢰인 은행DbtrAgt/FinInstnId/BICFI
56a중개 은행IntrmyAgt1
57a수취인 은행CdtrAgt/FinInstnId/BICFI
59a수취인Cdtr (구조화) + CdtrAcct
70송금 사유RmtInf/Ustrd 또는 RmtInf/Strd (구조화 가능)
71A수수료 부담ChrgBr (DEBT/CRED/SHAR)
72은행 간 추가 정보InstrForNxtAgt, 구조화 요소로 분산

차이의 핵심:

camt.053 — 계좌 보고의 구조화

지급 지시(pacs)만큼 중요한 것이 현금 보고(camt)입니다. 기존 MT940 계좌 명세는 86번 필드의 자유 텍스트에 거래 정보를 욱여넣는 구조라, 기업·기관의 자동 대사가 늘 파싱 휴리스틱에 의존했습니다. camt.053은 명세의 각 엔트리가 구조화되고, 무엇보다 UETR로 원 지급 메시지와 연결됩니다.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
  <BkToCstmrStmt>
    <Stmt>
      <Id>STMT-20260613-001</Id>
      <Acct>
        <Id><Othr><Id>110123456789</Id></Othr></Id>
        <Ccy>USD</Ccy>
      </Acct>
      <Bal>
        <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="USD">1250000.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-06-13</Dt></Dt>
      </Bal>
      <Ntry>
        <Amt Ccy="USD">25000.00</Amt>
        <CdtDbtInd>DBIT</CdtDbtInd>
        <Sts><Cd>BOOK</Cd></Sts>
        <NtryDtls>
          <TxDtls>
            <Refs>
              <UETR>97ed4827-7b6f-4491-a06f-b548d5a7512d</UETR>
              <EndToEndId>E2E-INV-2026-0456</EndToEndId>
            </Refs>
          </TxDtls>
        </NtryDtls>
      </Ntry>
    </Stmt>
  </BkToCstmrStmt>
</Document>

실무 효과를 정리하면:

CBPR+ 마이그레이션 — 무엇이 언제 바뀌었나

CBPR+(Cross-Border Payments and Reporting Plus)는 SWIFT 네트워크 상 국경 간 지급·보고 메시지의 ISO 20022 사용 규격입니다. ISO 20022 표준 그 자체는 자유도가 높아, 실제 상호운용을 위해 시장 관행 그룹이 필드 사용 규칙을 좁혀 정의한 것이 CBPR+ 사용 지침입니다.

타임라인(주요 사실 위주):

마이그레이션 전략은 기관마다 달랐습니다.

전략내용장단점
네이티브 전환코어 지급 시스템이 직접 MX 처리데이터 손실 없음 / 비용·기간 큼
변환 계층경계에서 MX-MT 상호 변환, 내부는 MT 유지빠른 대응 / 절단·데이터 손실 위험
하이브리드신규 플로는 네이티브, 레거시는 변환현실적 / 이중 운영 부담

공존 기간에 많은 기관이 변환 계층으로 버텼지만, 구조화 주소처럼 MT에 담을 수 없는 데이터가 MX에 실려 오기 시작하면 변환은 본질적으로 손실 변환이 됩니다. 그래서 전환의 끝그림은 결국 네이티브 처리입니다.

구조화 데이터의 가치 — AML과 STP

ISO 20022 전환의 효익은 운영 데이터에서 나옵니다.

다만 효익은 공짜가 아닙니다. 보내는 쪽이 구조화 데이터를 채워야 받는 쪽이 활용할 수 있습니다. 고객 채널(인터넷뱅킹, 펌뱅킹)에서부터 주소를 구조화해 받는 업스트림 개선이 함께 가야 합니다.

국내 적용 맥락

한국 관점에서 ISO 20022는 다음 접점이 있습니다(아는 범위에서 서술하며, 최신 일정은 각 기관 공지를 확인하세요).

국내 메시지 체계(전문 규격)와 국제 표준이 다른 상태가 당분간 지속되므로, 국내 은행의 통합 레이어는 "국내 전문 - 내부 표준 모델 - 국제 MX"의 삼중 변환을 다루게 됩니다. 이때 내부 표준 모델을 ISO 20022 비즈니스 모델에 가깝게 설계해 두면 변환 손실과 매핑 수가 줄어듭니다.

메시지 변환 아키텍처

변환 계층의 표준적인 구성은 다음과 같습니다.

   [채널/코어 시스템]
        |  (내부 포맷)
        v
+-----------------------+
|  Canonical Model 계층  |   내부 표준 모델 (ISO 20022 비즈니스 모델 기반)
+-----------------------+
        |
        v
+-----------------------+      +--------------------+
|  Transformer 계층      | <--> |  Mapping 정의 저장소 |  (버전 관리되는 매핑 룰)
|  (MT <-> 표준 <-> MX)  |      +--------------------+
+-----------------------+
        |
        v
+-----------------------+      +--------------------+
|  Validation 계층       | <--> |  Schema Registry   |  (XSD + CBPR+ 사용 규칙)
|  - XSD 스키마 검증      |      |  버전별 보관/배포     |
|  - 사용 지침(usage) 검증|      +--------------------+
|  - 비즈니스 룰 검증     |
+-----------------------+
        |
        v
   [SWIFT 게이트웨이 / RTGS 어댑터]

설계 포인트:

변환기 구현의 골격(Python):

# pacs.008 -> 내부 표준 모델 파싱 골격 (lxml 사용)
from lxml import etree

NS = {"p8": "urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08"}

def parse_pacs008(xml_bytes: bytes, xsd: etree.XMLSchema) -> dict:
    doc = etree.fromstring(xml_bytes)
    if not xsd.validate(doc):
        raise SchemaError([str(e) for e in xsd.error_log])

    tx = doc.find(".//p8:CdtTrfTxInf", NS)
    amt_el = tx.find("p8:IntrBkSttlmAmt", NS)
    payment = {
        "msg_id":   doc.findtext(".//p8:GrpHdr/p8:MsgId", namespaces=NS),
        "uetr":     tx.findtext("p8:PmtId/p8:UETR", namespaces=NS),
        "e2e_id":   tx.findtext("p8:PmtId/p8:EndToEndId", namespaces=NS),
        "amount":   amt_el.text,
        "currency": amt_el.get("Ccy"),
        "settle_date": tx.findtext("p8:IntrBkSttlmDt", namespaces=NS),
        "debtor": {
            "name":    tx.findtext("p8:Dbtr/p8:Nm", namespaces=NS),
            "country": tx.findtext("p8:Dbtr/p8:PstlAdr/p8:Ctry", namespaces=NS),
        },
        "creditor": {
            "name":    tx.findtext("p8:Cdtr/p8:Nm", namespaces=NS),
            "country": tx.findtext("p8:Cdtr/p8:PstlAdr/p8:Ctry", namespaces=NS),
        },
        "charge_bearer": tx.findtext("p8:ChrgBr", namespaces=NS),
    }
    # 사용 지침 검증 예: UETR 필수 (CBPR+)
    if not payment["uetr"]:
        raise UsageRuleError("UETR is mandatory under CBPR+")
    return payment

Java 진영에서는 Prowide 라이브러리가 사실상 표준에 가깝습니다.

// Prowide ISO 20022 사용 예 (개념 골격)
import com.prowidesoftware.swift.model.mx.MxPacs00800108;

public class Pacs008Reader {
    public PaymentDto read(String xml) {
        MxPacs00800108 mx = MxPacs00800108.parse(xml);
        var tx = mx.getFIToFICstmrCdtTrf().getCdtTrfTxInf().get(0);
        PaymentDto dto = new PaymentDto();
        dto.setUetr(tx.getPmtId().getUETR());
        dto.setAmount(tx.getIntrBkSttlmAmt().getValue());
        dto.setCurrency(tx.getIntrBkSttlmAmt().getCcy());
        dto.setCreditorName(tx.getCdtr().getNm());
        return dto;
    }
}

테스트 전략

메시징 시스템 테스트는 레이어별로 나눠야 합니다.

  1. 스키마 검증 테스트: 모든 송신 메시지가 대상 XSD와 사용 지침을 통과하는지. 메시지 빌더의 단위 테스트에 XSD 검증을 포함합니다.
  2. 골든 파일 테스트: 대표 시나리오(통화별, 수수료 부담별, 중개은행 유무, 반환·취소)의 입력과 기대 출력 메시지를 골든 파일로 고정하고, 변환기 변경 시 디프를 검토합니다.
  3. 왕복(round-trip) 테스트: 내부 모델 → MX → 내부 모델로 되돌렸을 때 정보가 보존되는지. MT가 끼는 경로는 손실 필드 목록이 명세와 일치하는지를 검증합니다.
  4. 부정 테스트: 필수 요소 누락, 잘못된 통화 코드, 초과 길이, 허용되지 않는 문자 등 거절 케이스가 의도한 오류 코드로 떨어지는지.
  5. 시나리오(엔드투엔드) 테스트: 상대 기관 시뮬레이터를 두고 지급 → 상태 보고(pacs.002) → 취소 요청(camt.056) → 반환(pacs.004)의 전체 대화를 검증합니다. SWIFT가 제공하는 테스트 환경과 검증 도구(MyStandards 기반 명세 공유 등)를 활용합니다.
  6. 성능 테스트: XSD 검증은 CPU를 씁니다. 마감 시간대 피크 TPS에서 검증 포함 처리 지연이 SLA 안에 드는지 측정합니다. 스키마 컴파일 캐싱이 기본기입니다.

운영 함정

실전에서 자주 만나는 문제들입니다.

도입 체크리스트

마치며

ISO 20022 전환은 "포맷 교체 프로젝트"로 시작해서 "데이터 품질 프로젝트"로 끝납니다. XML 파싱과 스키마 검증은 어렵지 않습니다. 어려운 것은 수십 년간 자유 텍스트에 적응해 온 시스템, 절차, 데이터의 구조화입니다. 그리고 그 구조화가 끝나는 지점에서 비로소 — 더 정확한 스크리닝, 더 높은 STP, 더 풍부한 분석이라는 — 전환의 배당이 지급됩니다. 변환 계층으로 버티는 단계에 있다면, 정규 모델과 스키마 거버넌스에 먼저 투자하시기를 권합니다. 그것이 네이티브 전환으로 가는 가장 짧은 길입니다.

참고 자료

원문 보기: https://www.youngju.dev/blog/finance/2026-06-13-iso20022-financial-messaging-swift

댓글

아직 댓글이 없습니다.

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