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

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

はじめに

国境を越える送金1件の裏側には、銀行間でやり取りされるメッセージがあります。このメッセージの形式が、数十年ぶりに入れ替わりつつあります。1970年代に設計されたSWIFT MTフォーマットが、ISO 20022ベースの構造化されたXMLメッセージ(MX)へ移行するのです。2025年11月、国際送金メッセージのMT-MX共存期間が終了し、この移行はもはや未来形ではなく、ほぼ完了形に近づきました。

この移行は単なるフォーマット変更ではありません。受取人名義が自由テキスト1行から構造化された住所フィールドに変わればAML(マネーロンダリング防止)スクリーニングの精度が変わり、定型データが増えれば決済システムの自動化率が変わります。同時に、既存のMTに縛られたレガシーシステムを運用する立場には、変換レイヤー、スキーマ管理、切り捨て(truncation)問題という現実的な課題が押し寄せます。

本記事では、金融メッセージングの歴史からISO 20022の構造、MT103とpacs.008の比較、CBPR+移行、変換アーキテクチャと実装、テスト戦略、運用上の落とし穴までを、エンジニアの視点で整理します。本記事は技術資料であり、投資助言ではありません。

金融メッセージングの歴史 — テレックスからISO 20022まで

1950〜70年代テレックス(Telex)

- 自由テキスト電文、標準なし、手作業の検証

- 偽造・誤記リスク、処理の自動化は不可能

1977〜 SWIFT MT (Message Type)

- SWIFTネットワーク稼働、ブロック構造の定型電文

- MT103(顧客送金)、MT202(銀行間)、MT5xx(証券)、MT9xx(資金管理)

- フィールドは構造化されたが、多くは自由テキスト

(名義/住所は4行x35文字など)

2004〜 ISO 20022標準の制定

- ビジネスモデルに基づくメッセージ標準(XML文法)

- SEPA(欧州)、日本の全銀EDI、各国RTGSが段階的に採用

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の4行のうちどこまでが名義でどこからが住所なのか、機械が確信を持って判断する方法はありません。2つの形式の対応関係を見ると、移行の本質が見えてきます。

| 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行x35文字の自由テキスト**でした。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(電信送金の情報要件、トラベルルール)が要求する送金人/受取人情報が構造化されて伝達・検証されます。

- **データ分析**: 支払目的コード、カテゴリコードが標準化されれば、流動性予測、手数料分析、顧客行動分析の品質が上がります。

ただし便益は無料ではありません。送る側が構造化データを埋めてこそ、受け取る側が活用できます。顧客チャネル(インターネットバンキング、ファームバンキング)の段階から住所を構造化して受け取る、アップストリームの改善が並走すべきです。

韓国国内での適用の文脈

韓国の観点では、ISO 20022には次の接点があります(知っている範囲で記述します。最新のスケジュールは各機関の公表をご確認ください)。

- **国際送金**: 韓国国内銀行の外為送金業務はSWIFTを使用するため、CBPR+移行の直接の影響圏にあります。外貨資金部門と送受信システム(SWIFTゲートウェイ、外為コア)のMX対応が中核課題でした。

- **韓銀金融網(BOK-Wire+)**: 韓国銀行は次世代の韓銀金融網構築を推進する中で、ISO 20022の導入を計画に含めてきました。大口決済システムがISO 20022へ移行すれば、国内銀行のウォン大口振替インターフェースもMXベースに変わることになります。

- **金融決済院(KFTC)**: 小口決済網など国内の支払決済インフラでも、国際標準との整合性の議論が続いています。

国内のメッセージ体系(電文規格)と国際標準が異なる状態は当面続くため、国内銀行の統合レイヤーは「国内電文 - 内部標準モデル - 国際MX」の三重変換を扱うことになります。このとき内部標準モデルをISO 20022のビジネスモデルに近づけて設計しておくと、変換損失とマッピング数が減ります。

メッセージ変換アーキテクチャ

変換レイヤーの標準的な構成は次のとおりです。

[チャネル/コアシステム]

| (内部フォーマット)

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

| Canonicalモデル層 | 内部標準モデル(ISO 20022ビジネスモデルに基づく)

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

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

| Transformer層 | <--> | マッピング定義リポジトリ| (バージョン管理されたルール)

| (MT <-> 標準 <-> MX) | +--------------------+

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

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

| Validation層 | <--> | Schema Registry | (XSD + CBPR+使用ルール、

| - XSDスキーマ検証 | | バージョン別に保管/配布| バージョン別)

| - 使用ガイドライン検証 | +--------------------+

| - ビジネスルール検証 |

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

[SWIFTゲートウェイ / RTGSアダプタ]

設計ポイント:

- **正規(canonical)モデルを中心に**: フォーマット間のN対N直接変換はマッピング数が爆発します。中心モデルを置けばフォーマットごとにマッピング1つで済みます。

- **スキーマレジストリ**: 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. **ラウンドトリップテスト**: 内部モデル → 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

- 韓国銀行(BOK-Wire+): https://www.bok.or.kr

- 金融決済院(KFTC): https://www.kftc.or.kr

- Prowideオープンソースライブラリ: https://www.prowidesoftware.com

- W3C XML Schema (XSD): https://www.w3.org/XML/Schema