들어가며
국경을 넘는 송금 한 건의 뒤에는 은행 간에 오가는 메시지가 있습니다. 이 메시지의 형식이 수십 년 만에 교체되고 있습니다. 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)의 분리**입니다.
- **비즈니스 모델**: 지급, 증권, 외환 등 금융 업무의 개념(차주, 채권자, 금액, 계좌...)을 표준화된 사전(Data Dictionary)으로 정의합니다.
- **메시지 정의**: 비즈니스 모델에서 도출된 메시지 스키마. 현재 주력 문법은 XML(XSD 스키마)이며, 같은 모델에서 JSON 등 다른 문법도 파생될 수 있습니다.
- **버전 관리**: 메시지 식별자는 `pacs.008.001.08`처럼 비즈니스 영역, 메시지 번호, 변형, 버전으로 구성됩니다.
주요 메시지 패밀리:
| 패밀리 | 영역 | 대표 메시지 |
| --- | --- | --- |
| 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"?>
주목할 점: 송금인(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 (헤더) | UETR | PmtId/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, 구조화 요소로 분산 |
차이의 핵심:
- **MT 50a/59a는 4줄 x 35자 자유 텍스트**였습니다. pacs.008에서는 이름, 거리, 도시, 국가 코드가 분리됩니다. 제재 스크리닝 엔진이 "국가" 필드를 정확히 읽을 수 있다는 의미입니다.
- **송금 사유(remittance information)**가 구조화될 수 있습니다(Strd 요소에 인보이스 번호, 금액 분해). 기업 매출채권 자동 소거(reconciliation)와 직결됩니다.
- **메시지와 별개로 상태 흐름이 표준화**됩니다. pacs.002(상태 보고), camt.056(취소 요청), pacs.004(자금 반환)가 명시적 메시지로 정의되어 예외 처리가 데이터화됩니다.
camt.053 — 계좌 보고의 구조화
지급 지시(pacs)만큼 중요한 것이 현금 보고(camt)입니다. 기존 MT940 계좌 명세는 86번 필드의 자유 텍스트에 거래 정보를 욱여넣는 구조라, 기업·기관의 자동 대사가 늘 파싱 휴리스틱에 의존했습니다. camt.053은 명세의 각 엔트리가 구조화되고, 무엇보다 **UETR로 원 지급 메시지와 연결**됩니다.
실무 효과를 정리하면:
- **현금 대사 자동화**: 명세 엔트리의 UETR/EndToEndId를 지급 시스템의 키와 직접 조인할 수 있어, 백오피스 현금 대사의 매칭률이 올라갑니다.
- **잔고 유형의 표준 코드**: 기초 잔고, 마감 잔고, 가용 잔고가 코드(OPBD, CLBD, CLAV 등)로 구분되어 유동성 모니터링이 정확해집니다.
- **인트라데이 보고와의 일관성**: camt.052(일중)와 camt.053(일마감)이 같은 구조를 공유하므로 처리 파이프라인을 재사용할 수 있습니다.
CBPR+ 마이그레이션 — 무엇이 언제 바뀌었나
CBPR+(Cross-Border Payments and Reporting Plus)는 SWIFT 네트워크 상 국경 간 지급·보고 메시지의 ISO 20022 사용 규격입니다. ISO 20022 표준 그 자체는 자유도가 높아, 실제 상호운용을 위해 시장 관행 그룹이 필드 사용 규칙을 좁혀 정의한 것이 CBPR+ 사용 지침입니다.
타임라인(주요 사실 위주):
- **2022년 3월**: SWIFT 네트워크에서 MT와 MX(CBPR+)의 공존 기간 시작. 수신 은행은 MX를 받을 수 있어야 했습니다.
- **2023년 3월**: 유로존 T2(ECB의 RTGS)가 ISO 20022로 빅뱅 전환. 영국 CHAPS도 같은 해 ISO 20022 전환.
- **2025년 3월**: 미국 Fedwire가 ISO 20022로 전환.
- **2025년 11월**: SWIFT 국경 간 지급에서 대상 MT 전문(지급 지시 관련 카테고리 1·2 및 일부 카테고리 9)의 공존 기간 종료. 이후 국경 간 지급 지시는 ISO 20022(MX)가 표준입니다. 현금 보고(camt 계열로의 전환)도 일정에 따라 진행되었습니다.
마이그레이션 전략은 기관마다 달랐습니다.
| 전략 | 내용 | 장단점 |
| --- | --- | --- |
| 네이티브 전환 | 코어 지급 시스템이 직접 MX 처리 | 데이터 손실 없음 / 비용·기간 큼 |
| 변환 계층 | 경계에서 MX-MT 상호 변환, 내부는 MT 유지 | 빠른 대응 / 절단·데이터 손실 위험 |
| 하이브리드 | 신규 플로는 네이티브, 레거시는 변환 | 현실적 / 이중 운영 부담 |
공존 기간에 많은 기관이 변환 계층으로 버텼지만, 구조화 주소처럼 **MT에 담을 수 없는 데이터가 MX에 실려 오기 시작하면 변환은 본질적으로 손실 변환**이 됩니다. 그래서 전환의 끝그림은 결국 네이티브 처리입니다.
구조화 데이터의 가치 — AML과 STP
ISO 20022 전환의 효익은 운영 데이터에서 나옵니다.
- **제재·AML 스크리닝 개선**: 자유 텍스트 주소에서는 "JORDAN"이 사람 이름인지 국가인지 구분할 수 없어 오탐(false positive)이 양산됩니다. 구조화 필드에서는 국가 코드는 국가 코드로만 비교합니다. 오탐 감소는 곧 수작업 심사 비용 감소입니다.
- **STP율 상승**: 수취 은행이 계좌번호·은행 식별자를 정확한 필드에서 읽으므로 수작업 보정(repair)이 줄어듭니다.
- **정확한 송금인·수취인 정보**: FATF 권고 16(전신송금 정보 요건, travel rule)이 요구하는 송금인/수취인 정보가 구조화되어 전달·검증됩니다.
- **데이터 분석**: 지급 목적 코드, 카테고리 코드가 표준화되면 유동성 예측, 수수료 분석, 고객 행동 분석의 품질이 올라갑니다.
다만 효익은 공짜가 아닙니다. 보내는 쪽이 구조화 데이터를 채워야 받는 쪽이 활용할 수 있습니다. 고객 채널(인터넷뱅킹, 펌뱅킹)에서부터 주소를 구조화해 받는 업스트림 개선이 함께 가야 합니다.
국내 적용 맥락
한국 관점에서 ISO 20022는 다음 접점이 있습니다(아는 범위에서 서술하며, 최신 일정은 각 기관 공지를 확인하세요).
- **국경 간 송금**: 국내 은행의 외환 송금 업무는 SWIFT를 사용하므로 CBPR+ 전환의 직접 영향권입니다. 외화자금 부서와 수발신 시스템(스위프트 게이트웨이, 외환 코어)의 MX 대응이 핵심 과제였습니다.
- **한은금융망(BOK-Wire+)**: 한국은행은 차세대 한은금융망 구축을 추진하면서 ISO 20022 도입을 계획에 포함해 왔습니다. 거액결제 시스템이 ISO 20022로 전환되면 국내 은행의 원화 거액이체 인터페이스도 MX 기반으로 바뀌게 됩니다.
- **금융결제원(KFTC)**: 소액결제망 등 국내 지급결제 인프라에서도 국제 표준과의 정합성 논의가 이어지고 있습니다.
국내 메시지 체계(전문 규격)와 국제 표준이 다른 상태가 당분간 지속되므로, 국내 은행의 통합 레이어는 "국내 전문 - 내부 표준 모델 - 국제 MX"의 삼중 변환을 다루게 됩니다. 이때 내부 표준 모델을 ISO 20022 비즈니스 모델에 가깝게 설계해 두면 변환 손실과 매핑 수가 줄어듭니다.
메시지 변환 아키텍처
변환 계층의 표준적인 구성은 다음과 같습니다.
[채널/코어 시스템]
| (내부 포맷)
v
+-----------------------+
| Canonical Model 계층 | 내부 표준 모델 (ISO 20022 비즈니스 모델 기반)
+-----------------------+
|
v
+-----------------------+ +--------------------+
| Transformer 계층 | <--> | Mapping 정의 저장소 | (버전 관리되는 매핑 룰)
| (MT <-> 표준 <-> MX) | +--------------------+
+-----------------------+
|
v
+-----------------------+ +--------------------+
| Validation 계층 | <--> | Schema Registry | (XSD + CBPR+ 사용 규칙)
| - XSD 스키마 검증 | | 버전별 보관/배포 |
| - 사용 지침(usage) 검증| +--------------------+
| - 비즈니스 룰 검증 |
+-----------------------+
|
v
[SWIFT 게이트웨이 / RTGS 어댑터]
설계 포인트:
- **정규(canonical) 모델을 중심에**: 포맷 간 N:N 직접 변환은 매핑 수가 폭발합니다. 중심 모델을 두면 포맷당 매핑 하나로 줄어듭니다.
- **스키마 레지스트리**: ISO 20022 메시지는 버전이 올라갑니다(예: pacs.008.001.08에서 그 이후 버전으로). 어떤 상대·망과 어떤 버전을 쓰는지 레지스트리에서 관리하고, 검증기는 메시지 네임스페이스로 버전을 식별해 해당 XSD를 적용해야 합니다.
- **3단 검증**: 문법(XSD) → 사용 규칙(CBPR+ 지침: 필수/금지 요소, 코드 제한) → 비즈니스 룰(금액 한도, 통화-국가 정합성 등). 단계별로 오류 코드를 분리해야 장애 분석이 빨라집니다.
변환기 구현의 골격(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 사용 예 (개념 골격)
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;
}
}
- Java: Prowide Core(MT)와 Prowide ISO 20022(MX)는 오픈소스이고, JAXB 기반 모델 클래스를 제공합니다.
- Python: 표준 라이브러리 수준의 결정판은 없고, lxml + XSD 검증 또는 xsdata로 스키마에서 데이터클래스를 생성하는 접근이 일반적입니다.
- 어느 쪽이든 **스키마에서 코드 생성**을 기본으로 하고, 손으로 파서를 짜는 것은 피하세요. 버전 업그레이드 시 회귀가 통제되지 않습니다.
테스트 전략
메시징 시스템 테스트는 레이어별로 나눠야 합니다.
1. **스키마 검증 테스트**: 모든 송신 메시지가 대상 XSD와 사용 지침을 통과하는지. 메시지 빌더의 단위 테스트에 XSD 검증을 포함합니다.
2. **골든 파일 테스트**: 대표 시나리오(통화별, 수수료 부담별, 중개은행 유무, 반환·취소)의 입력과 기대 출력 메시지를 골든 파일로 고정하고, 변환기 변경 시 디프를 검토합니다.
3. **왕복(round-trip) 테스트**: 내부 모델 → MX → 내부 모델로 되돌렸을 때 정보가 보존되는지. MT가 끼는 경로는 손실 필드 목록이 명세와 일치하는지를 검증합니다.
4. **부정 테스트**: 필수 요소 누락, 잘못된 통화 코드, 초과 길이, 허용되지 않는 문자 등 거절 케이스가 의도한 오류 코드로 떨어지는지.
5. **시나리오(엔드투엔드) 테스트**: 상대 기관 시뮬레이터를 두고 지급 → 상태 보고(pacs.002) → 취소 요청(camt.056) → 반환(pacs.004)의 전체 대화를 검증합니다. SWIFT가 제공하는 테스트 환경과 검증 도구(MyStandards 기반 명세 공유 등)를 활용합니다.
6. **성능 테스트**: XSD 검증은 CPU를 씁니다. 마감 시간대 피크 TPS에서 검증 포함 처리 지연이 SLA 안에 드는지 측정합니다. 스키마 컴파일 캐싱이 기본기입니다.
운영 함정
실전에서 자주 만나는 문제들입니다.
- **문자셋**: MT는 제한된 문자셋(X 문자셋)을 썼습니다. CBPR+ MX도 상호운용을 위해 문자 제한(기본 라틴 위주)이 있어, 한글 이름·주소는 로마자 변환이 필요합니다. 변환 규칙(성명 로마자 표기)의 일관성이 없으면 스크리닝과 대사가 흔들립니다.
- **절단(truncation)**: MX의 긴 구조화 데이터가 MT 경유 구간에서 잘립니다. 절단이 발생하면 "데이터가 잘렸다"는 표시(+로 끝내는 관행 등 지침상 규칙)를 적용하고, 절단 발생을 로그로 남겨 후속 심사에 알려야 합니다. 반대로 MT에서 MX로 갈 때는 자유 텍스트를 구조화 필드로 찢는 휴리스틱이 필요한데, 이 로직의 오류율을 모니터링해야 합니다.
- **잔여 MT 의존**: 공존 종료 후에도 내부 시스템, 일부 시장 인프라, 문서화된 업무 절차에 MT 가정이 남아 있을 수 있습니다. "MT103 사본 보관" 같은 내규, MT 필드 번호로 쓰인 운영 매뉴얼, 화면의 4x35 입력 칸이 대표적입니다. 메시지 포맷 전환은 코드만이 아니라 절차·교육 전환입니다.
- **버전 드리프트**: 상대 기관·망마다 쓰는 메시지 버전이 다를 수 있습니다. 네임스페이스 기반 동적 검증과 버전별 매핑이 없으면 특정 상대와의 거래만 깨지는 장애가 납니다.
- **타임존과 일자**: MX는 시각에 오프셋이 붙습니다(예: +09:00). 결제일(IntrBkSttlmDt)과 생성 시각(CreDtTm)의 기준을 혼동하면 휴일 처리와 컷오프 계산이 틀어집니다.
- **빈 요소와 기본값**: 스키마상 선택 요소를 빈 값으로 보내면 검증은 통과해도 상대 시스템이 거절할 수 있습니다. "없으면 요소 자체를 생략"이 원칙입니다.
도입 체크리스트
- [ ] 송수신하는 모든 메시지 유형의 인벤토리(MT/MX, 버전, 상대망)가 있는가
- [ ] 스키마 레지스트리와 버전별 XSD 관리·배포 체계가 있는가
- [ ] XSD-사용지침-비즈니스룰의 3단 검증이 분리된 오류 코드로 구현되어 있는가
- [ ] 정규 모델 중심의 변환 구조인가, 포맷 간 직접 변환이 난립하는가
- [ ] MT 경유 구간의 절단 규칙과 절단 발생 로깅이 있는가
- [ ] 한글 성명·주소의 로마자 변환 규칙이 단일 소스로 관리되는가
- [ ] UETR가 전 구간에서 보존되고 추적 조회와 연결되는가
- [ ] 골든 파일·왕복·부정 테스트가 CI에 들어 있는가
- [ ] 상태·예외 메시지(pacs.002, camt.056, pacs.004)의 처리 플로가 자동화되어 있는가
- [ ] 피크 TPS에서 스키마 검증 포함 성능이 측정되어 있는가
- [ ] 운영 매뉴얼·내규·화면이 MT 가정을 벗어났는지 점검했는가
- [ ] 업스트림 채널에서 구조화 주소를 수집하도록 개선 계획이 있는가
마치며
ISO 20022 전환은 "포맷 교체 프로젝트"로 시작해서 "데이터 품질 프로젝트"로 끝납니다. XML 파싱과 스키마 검증은 어렵지 않습니다. 어려운 것은 수십 년간 자유 텍스트에 적응해 온 시스템, 절차, 데이터의 구조화입니다. 그리고 그 구조화가 끝나는 지점에서 비로소 — 더 정확한 스크리닝, 더 높은 STP, 더 풍부한 분석이라는 — 전환의 배당이 지급됩니다. 변환 계층으로 버티는 단계에 있다면, 정규 모델과 스키마 거버넌스에 먼저 투자하시기를 권합니다. 그것이 네이티브 전환으로 가는 가장 짧은 길입니다.
참고 자료
- ISO 20022 공식 사이트 (메시지 카탈로그, 데이터 사전): https://www.iso20022.org
- SWIFT — ISO 20022 전환 안내: https://www.swift.com/standards/iso-20022
- SWIFT — Standards (MT): https://www.swift.com/standards
- ECB — T2 (RTGS) ISO 20022: https://www.ecb.europa.eu
- Bank of England — CHAPS / RTGS 갱신 프로그램: https://www.bankofengland.co.uk
- Federal Reserve — Fedwire ISO 20022 전환: https://www.frbservices.org
- BIS CPMI — 지급결제 인프라 보고서: https://www.bis.org/cpmi
- FATF — 권고 16 (전신송금): https://www.fatf-gafi.org
- 한국은행 (한은금융망): https://www.bok.or.kr
- 금융결제원: https://www.kftc.or.kr
- Prowide 오픈소스 라이브러리: https://www.prowidesoftware.com
- W3C XML Schema (XSD): https://www.w3.org/XML/Schema
현재 단락 (1/221)
국경을 넘는 송금 한 건의 뒤에는 은행 간에 오가는 메시지가 있습니다. 이 메시지의 형식이 수십 년 만에 교체되고 있습니다. 1970년대에 설계된 SWIFT MT 포맷이 ISO 2...