🌍 世界の銀行をつなぐ秘密のネットワーク！SWIFTって何？

みなさんは、海外送金や国際的な取引で「SWIFTコード」という言葉を聞いたことはありませんか？

私たちの普段の生活ではあまり意識しませんが、世界の銀行や金融機関が毎日何千、何万という取引をスムーズに行うために、欠かせない仕組みがあります。それが今回ご紹介する「SWIFT（スイフト）」です！

この巨大な金融ネットワークの役割と仕組みを、ひとつずつ見ていきましょう！😊

💡 SWIFT誕生秘話：なぜ「SWIFT」が必要だったのか？

アイコン	内容
🏦	【昔の通信手段】銀行間の通信は、テレックス、FAX、電話でした。
🐢	【問題点】「遅い」し、「安全じゃない」！とても非効率でした。

国際的な取引が増えるにつれて、この昔ながらの通信方法では限界がありました。そこで、もっと速く、もっと安全に、世界の銀行同士がコミュニケーションできる方法が必要になりました。

📅 1973年、革命が起きる！

参加者: 15カ国から約239の銀行
目的: 共通のメッセージングシステムを構築すること
設立: ベルギーに本部を置く協同組合
名前: Society for Worldwide Interbank Financial Telecommunication
略称: 🌐 SWIFT（スイフト）

こうして、銀行間の通信を劇的に改善する、安全なプライベートネットワークが誕生したのです！

🚀 現在のSWIFTは？

項目	現在の規模
参加機関数	11,000以上！
ネットワーク名	SWIFTNet (スイフトネット)
特徴	メンバーだけがアクセスできる、安全なIPネットワークです。

SWIFTNetは、銀行だけでなく、大企業（コーポレート）も参加できるのがポイントです。企業が直接、金融機関と取引の指示をやり取りするために使われることもあります。

🔑 メンバーの「住所」と「名前」：SWIFTコードの読み方

SWIFTNetの中で、ある銀行が別の銀行を識別するために使われるのが「SWIFTコード」です。正式には「BIC（Business Identifier Code）」と言います。（「B」は「Bank」ではなく「Business」のBですよ！）

このコードは、ただのIDではなく、その組織の場所や支店の情報も含んでいます。長さは8文字または11文字です。

🔢 SWIFTコードの構成（例：ドイツ銀行・シュトゥットガルト支店の場合）

構成要素	文字数	種別	例 (DEUT DE SS 648)	意味
1	4文字	アルファベット	DEUT	事業体コード（誰？）： Deutsche Bank（ドイツ銀行）
2	2文字	アルファベット	DE	国コード（どこ？）： Deutschland（ドイツ）
3	2文字	アルファベット/数字	SS	所在地コード（都市/地域）： Stuttgart（シュトゥットガルト）
4	3文字	アルファベット/数字	648	支店コード（詳細な場所）：特定の支店（※8文字の場合は省略され、本店を指します）

📝 他の例を見てみよう！

SWIFTコード	銀行名	国	所在地	意味
SBIN IN BB	State Bank of India	India (IN)	Bombay (BB)	インドの本店（ムンバイ）
SBIN US 33	State Bank of India	USA (US)	New York (33)	ニューヨーク支店

このように、SWIFTコードを見るだけで、「どこの国の、どの都市にある、どの銀行」なのかが一瞬でわかるようになっています。

🗣️ 銀行が話す共通言語：MTメッセージとは？

SWIFTのメンバーが実際に取引の指示をやり取りするときは、みんなが理解できる「共通のフォーマット」に従ってメッセージを送ります。これを「メッセージング標準」と呼びます。

SWIFTがサポートしている主なメッセージ標準には、古い「MTメッセージ」と新しい「MXメッセージ」の2種類があります。

📝 MTメッセージ（ISO 15022準拠）

MTメッセージは、「FIN (Financial Messaging Application)」というサービスで交換されます。

FINサービスは、次の2つのアプリケーションで成り立っています。

FINメッセージングアプリケーション: 📧 実際の金融メッセージの交換、メッセージのチェック（検証）、保存、配信の監視を行います。
GPA (General Purpose Application): ⚙️ FINサービスの管理、アクセス制御、関連サービスメッセージの提供など、ユーザー間の通信以外の管理業務を行います。

🧱 MTメッセージの「5つのブロック構造」

MTメッセージは、送る情報が漏れなく伝わるように、以下の5つのブロックに分かれています。

ブロック名	必須/任意	役割	備考
1. 基本ヘッダー	必須	メッセージの基本的な情報や制御情報。	システムが自動で作成します。
2. アプリケーションヘッダー	任意	アプリケーション固有の情報。
3. ユーザーヘッダー	任意	送信者（ユーザー）が追加できる情報。
4. テキストブロック	必須	メッセージのメインとなる内容（取引情報など）
5. トレーラー	任意	メッセージの特別な処理（セキュリティ情報など）に関する情報。

🔍 MTメッセージの種類（カテゴリー）

MTメッセージは、取引の種類によって全部で9つのカテゴリーに分類されています。

カテゴリー（最初の数字）	領域	例（メッセージの種類）
1	顧客支払い・小切手	MT 103: 単一顧客信用送金（一番よく使われる送金メッセージ）
2	金融機関間の送金
3	外国為替・金利デリバティブ
4	回収・割引
5	証券市場
6	資金移動
7	貿易金融（トレードファイナンス）
8	旅行者小切手
9	現金管理・顧客ステートメント

メッセージの番号は、以下のように決まります。

【MT 103 の場合】

1 → カテゴリー（顧客支払い）
0 → グループ（電子ベース）
3 → 特定の機能（信用送金）

⚠️ メッセージを正しく送るための「ルール」

SWIFTのメッセージは、世界中の銀行で正しく処理されるよう、様々なルールとガイドラインが決められています。このルールに従わないと、取引が失敗してしまう可能性があります。

ルールの種類	ネットワーク検証	必須性	概要
1. NVR (Network Validated Rules)	YES (エラーコードあり)	必須	複数のフィールド間の条件など。ルール違反はエラーになり、メッセージを送れません。
2. 使用ルール (Usage Rules)	NO (エラーコードなし)	必須	2つのメッセージ間で情報を正しくコピーするなど、ネットワークでは自動チェックできないが、正しい利用に必須なルール。
3. ガイドライン (Guidelines)	NO	任意	慣行に関する推奨事項など。メッセージの構造化に役立ちます。
4. 市場慣行ルール (Market Practice Rules)	NO	任意	市場の専門家グループ（PMPGなど）が推奨する「業界のベストプラクティス」。

このように、SWIFTは単なる通信手段ではなく、IDの提供、共通のメッセージフォーマット、厳格なルールのすべてを提供することで、世界中の金融取引の土台を支えているのです。

この仕組みのおかげで、私たちは海外へ安全かつ迅速にお金を送ることができるのです！✨

💸 お金はこうして世界を巡る！決済システムの３つの秘密

前回、世界の銀行をつなぐ「SWIFT」というメッセージ網があることを知りました。

でも、SWIFTはあくまで「手紙を運ぶ郵便屋さん」の役割しかありません。実際に、ある銀行の口座から別の銀行の口座へお金を移動させるには、別の重要な仕組みが必要です。

それが「決済システム」です。決済システムには、次の3つの要素が欠かせません。

📧 メッセージング (情報伝達) $\to$ SWIFTが担当
⚖️ 清算 (Clearing) (計算と相殺)
💰 決済 (Settlement) (実際の送金)

これから、この「清算」と「決済」の仕組みを、簡単な例で見ていきましょう！

⚖️ 第1の秘密：清算（Clearing）と決済（Settlement）の違い

この2つの言葉は似ていますが、役割は全く違います。

1. 清算 (Clearing) $\to$ 計算と相殺（ネッティング）

清算とは、お金を実際に動かす前に、「誰が誰にいくら払うべきか」を計算し、差し引きする作業のことです。

銀行A	銀行B
AはBに $500$ 万円を払う義務がある	BはAに $700$ 万円を払う義務がある

この場合、実際に2回送金する代わりに、「差し引きして、BがAに 200 万円だけ払えばいい」とします。

この「差し引き（相殺）」の行為を ネッティング (Netting) と言います。
この「200 万円」のように差し引きで決まった最終的な金額を 最終ポジション と言います。

2. 決済 (Settlement) $\to$ 実際の送金

決済とは、清算で決まった「最終ポジション」の金額を、実際に口座間で移動させる行為です。つまり、お金が動くのが決済です。

🏢 清算機関 (Clearing House) の役割

銀行がたった2行なら簡単ですが、これが何百という銀行になると、直接やり取りするのは大変です。

そこで登場するのが 清算機関 (CSM: Clearing and Settlement Mechanism) です。銀行は、他の銀行と直接計算する代わりに、清算機関に接続します。

清算機関が全参加銀行の取引を集計・計算し、最終的な送金額を中央銀行の口座を通じて移動させるよう指示します。

💰 第2の秘密：決済システムの種類

決済のやり方には、大きく分けて2種類あります。

1. ネット決済システム (Net Settlement)

「清算」の仕組みで説明したように、取引をまとめて相殺（ネッティング）してから、最終的な差額だけを決済する方法です。

✅ メリット: 実際に動かすお金の総額が少なくなり、効率的。
❌ デメリット: 決済の完了までに時間がかかる（1日1回など）。

2. グロス決済システム (Gross Settlement)

こちらは相殺をせず、すべての取引を一つひとつ、全額（グロス）決済する方法です。

🏦 RTGS (Real Time Gross Settlement) とは？
- ネッティングせず、リアルタイム（すぐさま）に決済を完了させます。
- 主に高額な取引や緊急の送金に使われます。

🚀 究極のスピード決済：RTFS（リアルタイム最終決済）

通常のグロス決済は、銀行同士の口座（中央銀行にある口座）が決済されてから、顧客の口座に入金されます。

RTFS (Real Time Final Settlement) は、それとは異なり、「まず顧客の口座にすぐ入金し、後から銀行間の決済を行う」という方法です。利用者にとっては、取引がすぐに完了したように見えます。（例：インドのIMPS、米国のCHIPSなど）

🌍 第3の秘密：国際送金をつなぐ「コルレス口座」

決済システムは、通常、その国のその国の通貨での取引を扱っています。では、ある国（ユーロ圏）の銀行Aが、別の国（ドル圏）の銀行Bに「ドル」で送金したいとき、どうするのでしょうか？

ここで「コルレス（コルレスポンダント）口座」という仕組みが重要になります。

🤝 コルレス口座 (Correspondent Account) の仕組み

簡単に言えば、銀行が、海外の銀行に自分専用の口座を開かせてもらう、ということです。

登場人物	口座を開設した銀行（送金元A）	口座を持つ銀行（送金先B）
口座の呼び方	ノストロ口座 (Nostro Account)	ボストロ口座 (Vostro Account)
例	「当行（A）が貴行（B）に開いた我々のドル口座」	「貴行（A）が当行（B）に開いた貴方のドル口座」

つまり、同じ一つの口座を指していますが、「誰から見た口座か」によって呼び名が変わります。

銀行Aは、銀行Bにドル建てのノストロ口座を開設します。
銀行Aは、そのノストロ口座の**鏡（ミラー）**となる「影の口座」を自分の帳簿にも作ります。（お金は入っていないが、取引を記録・照合するため）
これで、銀行Aは銀行Bを通じて、ドルでの支払いができるようになります。

🔒 誰とメッセージをやり取りするか？：RMA

世界には何千もの銀行があります。どの銀行とも自由にSWIFTメッセージをやり取りできるようにすると、メッセージ量が爆発し、詐欺のリスクも高まります。

そこで、SWIFTは「RMA (Relationship Management Application)」という機能を提供しています。

サービス名	役割
RMA	「この銀行からのメッセージは受け取る」という許可を出す機能（包括的認証）。
RMA+	「この銀行からなら、この種類のメッセージだけを受け取る」と、さらに細かく制限できる機能。

RMAを使うことで、銀行は「信頼できる相手」とだけ、安全にメッセージを交換し、トラフィックを制御しています。これは、不正対策の最初の防衛線としても機能しています。

💡 まとめ：決済システムの種類

決済サービスを提供する事業者は、この3つの要素（メッセージング・清算・決済）のどれを提供しているかによって異なります。

サービス名	国	メッセージング	清算 (Clearing)	決済 (Settlement)
SWIFT	グローバル	$✓$	❌	❌
CHIPS (米)	USA	$✓$	$✓$	❌
CHAPS (英) / Fedwire (米)	UK / USA	$✓$	$✓$	$✓$

SWIFTは「情報伝達」に特化したグローバルなプロバイダーであり、実際の「お金の移動」は、各国の決済システム（CSM）の仕事なんですね！

これらの仕組みがあるからこそ、私たちは世界中どこでも、安全にお金を動かすことができるのです。仕組みがわかると、国際送金を見る目も変わりますね！✨

💌 SWIFTメッセージ解読術！MT103、MT202って何？

SWIFTネットワークでは、取引の種類に応じて「MT (Message Type) メッセージ」という共通フォーマットのメッセージが使われています。

このメッセージは大きく9つのカテゴリーに分かれていますが、今回は特に送金でよく使われる以下の3つのカテゴリーに注目します。

カテゴリー	役割	誰の取引か？
1	🧑‍💻 顧客支払い・小切手	企業の顧客、個人の顧客が関わる支払い
2	🏦 金融機関間の送金	銀行が自分の口座を決済するために行う資金移動
9	📝 現金管理・ステートメント	口座の入出金明細や確認

🧑‍💻 第1章：顧客の送金（Category 1）と関連メッセージ

カテゴリー1は、送金の「始まり」や「終わり」に顧客（企業や個人）が関わるときに使われます。

1. MT101：振込依頼の「まとめ役」

MT101は、「お金を振り込んでほしい」という依頼メッセージです。

誰が使う？
- 銀行が、別の銀行に送金を依頼するとき。
- SWIFTのメンバーである大企業（コーポレート）が、取引銀行に直接送金を依頼するとき。
特徴
- 1通のMT101で、複数の送金指示（複数口座からの引き落としや、複数の受取人への支払い）をまとめて送ることができます。
例
- 企業（ABC社）の資金管理を請け負う銀行（Yellow Bank）が、ABC社の口座を持つ銀行（Green Bank）に「ABC社のこの口座から、これとこれに振り込んで！」とまとめて指示するときに使われます。

2. MT102：銀行自身の口座を使う「複数」送金

MT102も複数の送金指示をまとめられますが、MT101との決定的な違いは、「引き落とし元」の口座です。

MT101: 顧客（ABC社など）の口座が引き落とし元。
MT102: 送金依頼をする銀行自身（Yellow Bank）が、相手銀行（Green Bank）に持っている自分自身の口座（ノストロ口座など）が引き落とし元。

3. MT103：国際送金の「花形」メッセージ

MT103は、単一の顧客信用送金（個人や企業1件の送金）に使われる、国際送金で最も有名かつ重要なメッセージです。

役割: 振込依頼元の銀行から、受取人の銀行へ、資金移動の指示を伝達します。
使われ方: MT103には、資金を移動させるための「カバー方式」と「シリアル方式」の2つの方法があります。

⛓️ 第2章：MT103の2つの国際送金方法

海外送金では、送金元・受取人双方の銀行が、米ドルなどの基軸通貨のコルレス銀行（ニューヨークなど）を経由させる必要があります。

1. 📢 カバー方式 (Cover Method)

この方式では、2種類のメッセージを組み合わせて使います。

メッセージ	送り先	役割
MT103 (Cover)	受取人銀行へ直接	「今からお金が届くよ！」という到着予告（アナウンス）の役割。資金は運びません。
MT202 (Cover)	送金側のコルレス銀行へ	「ノストロ口座から金を動かせ！」という実際の資金移動指示。MT103の参照番号を含みます。

この方法では、MT202 Coverによってコルレス銀行間で実際にお金が決済され、その後、MT103の予告とMT910の入金確認が揃って、受取人銀行が顧客へ入金します。

2. 🔁 シリアル方式 (Serial Method)

この方式では、MT103だけを使います。

役割: MT103メッセージが、資金を運びながら、コルレス銀行を経由して次々に転送されていきます。
資金の動き: 送金銀行 $\to$ コルレス銀行A $\to$ コルレス銀行B $\to$ 受取人銀行
メリット: メッセージ数が少ない。
デメリット: 各中継銀行がMT103を受け取るたびに処理する必要があるため、経路が複雑だと時間がかかることがあります。

💡 知っておきたい豆知識 受取人銀行は、MT103（カバー方式の予告）を受け取った時点で、MT910（入金確認）を待たずに、すぐに顧客へ入金することがあります。これは、送金銀行への信頼度、送金額、顧客の重要性など、各銀行の方針によって決められます。

🏦 第3章：銀行間の取引（Category 2）メッセージ

カテゴリー2は、銀行が自分たちの決済（ノストロ/ボストロ口座） のために、銀行間で資金を移動させるときに使われます。（MT202 CoverとMT205 Coverを除く）

MT番号	種類	目的	特徴
MT200	🏦 自口座振替（単一）	銀行が自分の2つの口座間でお金を移動させる	同じ通貨の口座間で利用
MT201	🏦 自口座振替（複数）	MT200の複数取引版
MT202	💰 一般振替（単一）	他行の口座へ資金を振り替える	国際送金で利用
MT203	💰 一般振替（複数）	MT202の複数取引版
MT205	🏠 国内一般振替（単一）	MT202の国内送金版	国内送金で利用
MT202 Cover	📢 顧客送金用	MT103のカバー方式で実際の資金を運ぶ	唯一、顧客取引に関わる
MT210	🔔 受領通知	「資金が届く予定です」と相手銀行に通知する	情報伝達のみ

📝 第4章：確認と明細（Category 9）メッセージ

カテゴリー9のメッセージは、口座の入出金を確認したり、明細を送ったりするために使われます。

MT番号	役割	誰の口座の確認か？
MT900	➖ デビット（引き落とし）確認	口座を持っている銀行が、口座の持ち主へ「引き落としました」と通知
MT910	➕ クレジット（入金）確認	口座を持っている銀行が、口座の持ち主へ「入金しました」と通知
MT940	📜 顧客ステートメント	銀行が、顧客の口座の明細を、顧客の資金管理を代行する別の銀行へ送る
MT950	📄 銀行ステートメント	銀行が、自分自身が持っている口座（ノストロ口座など）の明細を、その口座の持ち主である銀行へ送る

⚙️ 第5章：SWIFTの裏方メッセージ（GPAとその他）

今まで見てきたのは「FINメッセージ」ですが、SWIFTのネットワークの管理やエラー対応に使われる、見えないメッセージもあります。

1. ✅ GPAメッセージ (General Purpose Application)

FINサービスの管理や制御に使われるメッセージです。

サービス番号	役割	詳細
Service Message 21	ACK/NAK (承認/拒否)	送信されたメッセージがSWIFTシステムに受け付けられたか（ACK）拒否されたか（NAK）を通知します。
MT 0xx	システムメッセージ	メッセージの不達通知や重複警告など、配信の監視に関する通知です。

2. 🚨 メッセージの重複警告 (PDE/PDM)

PDE (Possible Duplicate Emission): 送信者が、メッセージが届かなかった場合に再送するとき、ブロック5（トレーラー）に追加する警告。
PDM (Possible Duplicate Message): SWIFTシステムが、無効な以前の配信のためにメッセージを再送するときに、ブロック5に追加する警告。

SWIFTは、単に送金指示を運ぶだけでなく、資金の確認、明細、そしてシステムの安全な管理まで、あらゆる金融取引を支えるために、細かくメッセージの種類を使い分けているのですね！これで、SWIFTのメッセージがどのように機能しているか、全体像が掴めたのではないでしょうか。😊

🚀 国際送金が劇的進化！SWIFT GPI（ジーピーアイ）のすごい力

前回の話で、SWIFTが銀行間のメッセージを運んでいることがわかりました。しかし、これまでの伝統的なSWIFT送金（MTメッセージ）には、実はたくさんの弱点がありました。

アイコン	従来のSWIFT送金が抱えていた「4つの課題」
🕵️‍♀️	追跡できない: メッセージを送ったら、今どこにあるのか、どの銀行で止まっているのかがわからない。
💸	手数料が不透明: 中継する銀行が勝手に手数料を引いていくため、最終的にいくら引かれたかが受取人に届くまでわからない。
⏰	時間がかかる: 処理にかかる時間がバラバラで、いつ届くかわからない。
🗑️	情報が途切れる: 送金目的などの重要な情報が、中継のたびに消えてしまうことがある。

これらの問題を一気に解決するために、SWIFTが導入したのが「SWIFT GPI (Global Payments Innovation)」です。これは、国際送金を「速く、透明に、追跡可能に」するための大改革です！

🎯 第1章：GPIの心臓部！追跡の仕組み

GPIの最も重要な機能は、送金の追跡可能性 (Traceability) です。これを可能にするのが「UETR」という魔法の番号です。

🔑 UETR（ユニークな取引参照番号）の役割

略称	UETR (Unique End-to-End Transaction Reference)
役割	送金の最初から最後まで、絶対に変わらない、世界に一つだけの参照番号。
従来との違い	従来のMTメッセージでは、中継のたびに参照番号（Field 20）が変わっていました。UETRは常に同じ番号を使い続けます。
義務化	2018年以降、GPIメンバーかどうかにかかわらず、MT103など主要な送金メッセージにはUETRの付与が義務付けられています。

🛰️ GPIトラッカー：送金のリアルタイム地図

送金がどの銀行に届き、いつ次の銀行へ送られたか、という情報が、UETRを使ってすべて「GPIトラッカー」というシステムにリアルタイムで記録されます。

見える化: 銀行や企業は、このトラッカーのインターフェースを見て、今、自分の送金がどこにあるか、そしていつ届くかを正確に把握できます。
手数料の透明性: 各銀行がいつ、いくら手数料を引いたか（チャージ額）もすべて記録・表示されるため、不透明さがなくなります。

🔒 第2章：サービスの品質保証と管理（SLA）

GPIは、ただ追跡できるだけでなく、「サービス品質」を保証するためのルール（SLA：Service Level Agreement）を定めています。

アイコン	GPI SLAの主なルール（約束事）
⚡	同日処理 (Same Day Processing): 締切時間までに受け取った送金は、その日のうちに次の銀行へ送ること。
💰	全額送金 (Full Amount Transfer): 送金人が手数料を負担する場合、中継銀行は送金額から手数料を引いてはいけない（全額送金先に届ける）。
🔍	手数料の透明性: 手数料を分担（Shared）したり、受取人負担（Beneficiary）にする場合の手数料を明確にすること。
🤝	情報保持: 送金目的などのメッセージ情報を途中で失わないこと。

👁️ GPIオブザーバーとディレクトリ

GPI Observer: 銀行がこのSLA（約束事）をちゃんと守っているかを監視し、評価するための管理ツールです。
GPI Directory: GPIメンバーのBIC（SWIFTコード）、対応通貨、締切時間などの運用情報を提供する名簿。最適な送金ルートを決めるのに役立ちます。

💡 第3章：最新のイノベーションとメリット

GPIは常に進化しています。特に注目すべき最新のサービスが「即時決済」や「間違い防止」の機能です。

1. 🚀 GPI Instant（GPI インスタント）

概要: GPIの追跡機能を、各国の国内即時決済システムと連携させることで、国際送金を一瞬で完了させるサービスです。
例: 英国の銀行から送られたGPIメッセージが、インドの国内即時決済システム（IMPS）と連携し、インド国内の受取人口座に瞬時に入金される、といったことが可能になりました。

2. 🛡️ 事故を未然に防ぐサービス

サービス名	役割	メリット
Payment Pre-Validation	事前検証	送金前に、受取人の口座情報が正しいかをAPIを通じて確認し、間違いをその場で修正できるようにする。これにより、送金遅延やリジェクトを大幅に減らせます。
Stop and Recall	送金停止・資金回収	詐欺や誤送金が疑われる場合、GPIトラッカーの力を使って処理中の送金をネットワーク上で即座に停止し、資金の回収を試みます。
Case Resolution	問合せ解決	支払いエラーや不足情報に関する銀行間の問合せを、GPIトラッカー上で管理・追跡し、解決までの時間を大幅に短縮します。

✨ GPIのメリットまとめ

対象	メリット
企業・顧客	高速・透明性の高いサービス。追跡可能で、入金確認もすぐわかる。誤送金のリスクが減り、資金の動きが見えるため資金管理（流動性）が最適化される。
銀行	顧客からの問い合わせや苦情が減るため、調査にかかる時間やコストを削減できる。顧客により大きな信頼と新しいサービスを提供できる。

SWIFT GPIは、もはや単なる「郵便屋さん」ではなく、国際送金を安心・安全・スピーディにするための「高性能な管制塔」へと進化していると言えます！

🚀 SWIFTの次の時代！ISO 20022（MXメッセージ）のすごい進化

今まで見てきたMTメッセージは、世界の金融取引を支えてきましたが、時代とともに様々な限界が見えてきました。そこで登場するのが、世界共通の新しいメッセージング規格「ISO 20022」に基づいた MXメッセージ です。

🛑 第1章：MTメッセージが抱えていた「4つの限界」

新しい規格が必要になった主な理由を、MTメッセージの欠点から見てみましょう。

アイコン	MTメッセージの限界	具体的な問題
🌍	乱立する規格	各国で異なるメッセージ規格（米国のFedwireなど）が使われているため、国際送金では規格間の変換が必要で、データが失われたり、遅延が発生したりしていました。
📝	データ不足	メッセージの文字数制限が厳しいため、例えば「請求書番号」や「返品理由」といった重要な詳細情報が途中で切り捨てられてしまうことがありました。
🧑‍💻	使い道の制限	カード決済や、銀行口座から自動で引き落とす「口座振替（ダイレクトデビット）」の指示（マンデート）を作成する機能がありませんでした。
🧱	構造の硬直性	メッセージの構造が固定されているため、特定の市場やビジネスの要求に合わせて内容を柔軟に変更することができませんでした。

ISO 20022 (MXメッセージ) は、これらの欠点をすべて克服し、さらに多くの機能を提供するために設計されました。

💡 第2章：MXメッセージの設計思想：3層構造の秘密

MXメッセージが柔軟で高機能である最大の理由は、メッセージの設計方法にあります。MTメッセージのように「取引＝特定のフォーマット」とするのではなく、情報を3つの層に分けています。

🧩 1. トップ層：ビジネスモデル（概念）

「この取引とは何か？」を定義する層です。

役割: 取引に必要な役割（誰が払うか、誰が受け取るか）や情報（金額、日付など）を、まず言葉の概念として定義します。
例: 資金移動の場合、「支払人（Debtor）」「受取人（Creditor）」「支払人の銀行（Debtor Agent）」といった核となる概念を定義します。

🗂️ 2. 中間層：ロジカルメッセージ（構造）

トップ層で定義された概念を使い、「このビジネス活動に必要な情報の全体像」を構文に依存せずに記述する層です。

役割: ビジネス要素を再利用できることが最大の特徴。例えば、「住所」というコンポーネントは、送金でも証券取引でも、必要に応じてどのメッセージでも使い回されます。
メリット: 柔軟性が生まれ、新しい取引が生まれても、既存の部品を組み合わせて対応できます。

💻 3. ボトム層：シンタックス（物理形式）

中間層で定義された情報の構造を、実際にコンピューターでやり取りできる形に表現する層です。

MXの形式: 現在は、国際標準のオープン形式である XML（Extensible Markup Language） が使われています。
最大の強み: 3層構造のおかげで、将来、XMLよりも優れた別の形式（シンタックス）が登場しても、ビジネス概念や論理構造を変えることなく対応できます。

🌟 まとめ: MXメッセージは、「内容（ビジネス）」と「伝え方（XML）」が切り離されているため、非常に柔軟で、将来の変化にも対応できるのです。

🌐 第3章：何が変わる？新しい言葉とコード

ISO 20022への移行は2022年11月から始まり、MTメッセージとの共存期間を経て、2025年11月頃に完了する予定です。（特に送金関連）

変更点	従来のMTメッセージ	新しいMXメッセージ
送金人	オーダリング・カスタマー (Ordering Customer)	デター (Debtor)
受取人	ベネフィシャリー・カスタマー (Beneficiary Customer)	クレディター (Creditor)
銀行	銀行 (Bank)	エージェント (Agent)
参照項目	フィールド (Field)	エレメント (Element)

🏷️ MXメッセージの命名規則

MTメッセージが3桁の数字（例: MT 103）だったのに対し、MXメッセージはより詳細な情報を含む命名規則になります。

例：PACS.008.001.01

PACS (4文字アルファベット): ビジネス領域 (Payment Clearing and Settlement $\to$ 送金清算)
008 (3桁数字): メッセージ機能 (FI to FI Customer Credit Transfer $\to$ 銀行間顧客信用送金)
001 (3桁数字): バリアント (市場やビジネス固有の要件への対応バージョン)
01 (2桁数字): バージョン (メッセージの更新履歴)

📈 ストレート・スルー・プロセシング（STP）の実現

MXメッセージは、XML形式で情報一つ一つが明確なタグ付け（要素化）されているため、コンピューターが人間を介さずに（STP: Straight Through Processing）データを処理しやすくなります。

MT: 情報が連続したテキストとして入っているため、一部を読み取るのに手間がかかる。
MX: 「ストリート名」「パスポート番号」など、必要な情報だけを瞬時に取り出せる。

これにより、制裁リストとの照合などで誤検知（例：XYZ通りなのにXYZ社と誤認）が発生しても、システムが正確に判断しやすくなり、送金遅延が大幅に減少します。

📨 第4章：MXの主要メッセージと機能

MXメッセージは、複数のMTメッセージの機能をたった一つのメッセージでカバーできます。

MXメッセージ	MTメッセージの等価物	役割と新しい機能
PAIN.001	MT 101	送金開始。企業から銀行への振込依頼。複数の取引をまとめられる。
PAIN.009	該当なし	口座振替のマンデート（同意）作成。MTにはなかった重要な新機能。
PAIN.002 / PACS.002	該当なし	支払い状況レポート。GPIほど詳細ではないが、取引ステータス（処理中、拒否など）を相手に通知する。（新機能）
PACS.008	MT 102 / MT 103	顧客信用送金。MT103の役割を担う主要なメッセージ。
PACS.009	MT 202 / MT 202 Cover	銀行間資金移動。Core（銀行自身の資金）とCover（顧客の資金移動）を区別して利用。
CAMT.053	MT 940 / MT 950	口座明細。MT940（顧客）とMT950（銀行）の機能を統合。複数の口座を報告可能。
CAMT.054	MT 900 / MT 910	入出金通知。デビット（900）とクレジット（910）の機能を統合。

🔄 MTとMXの共存方法

移行期間中、システムはMTとMXの両方を扱わなければなりません。

MT $\to$ MX: 比較的簡単。データ容量の小さいMTから、リッチなMXへのマッピングは容易です。
MX $\to$ MT: 難しい。リッチなMXから、容量の小さいMTへ変換するときは、データの一部が切り捨てられる（トランケーション） ことがあり、その場合は「+」マークなどで通知されます。

ISO 20022（MX）は、世界の金融システムの標準語となり、「より速く、より正確に、より詳細な情報を持った」 決済を実現するための、金融業界の巨大なインフラ革命です！

🧑‍🤝‍🧑 SWIFTの使い方は誰が決める？４つの重要グループと移行の波

前回の話で、MXメッセージは柔軟であることが最大の強みだとお話ししました。しかし、この「柔軟さ」ゆえに、「誰が、どの取引で、どう使うか？」を細かく決める必要があります。

このルール作りを担当しているのが、SWIFT内の専門チーム、つまり「ペイメント・グループ」です。

🤝 第1章：SWIFT内の４つのペイメント・グループ

取引の目的や参加者によって、使用するメッセージのルール（利用ガイドライン）が異なります。これらのルールを決めているのが以下の4つのグループです。

グループ名	略称	担当する取引	使用ガイドライン
クロスボーダー決済・報告	CBPR+	国境を越える国際送金と報告。	CBPR+ 利用ガイドライン
高額決済システム	HVPS+	国内や地域内の高額決済。	HVPS+ 利用ガイドライン
共通グローバル実装	CGI-MP	企業と銀行の間（Corporate to Bank）の通信。 (例: PAINメッセージ)	CGI-MP 利用ガイドライン
リアルタイム決済	RTPG	小口の即時決済（インスタントペイメント）。	RTPG 利用ガイドライン

💡 なぜグループが必要なの？

ISO 20022メッセージ（MX）は非常に柔軟です。例えば、PAIN.008という一つのメッセージでも…

CBPR+（国際送金） で使う場合
HVPS+（国内決済） で使う場合

…とでは、「この項目は必須」「文字数はXX文字まで」といった細かいルールが異なります。これらのグループは、その分野に特化して、ベースとなるMXメッセージを市場のニーズに合わせてカスタマイズしているのです。

📅 第2章：MTからMXへの世界的な移行スケジュール

MTメッセージからMXメッセージへの移行は、世界中で段階的に進められています。

1. 🌍 国際送金（CBPR+）の移行スケジュール

国際送金（クロスボーダー）に関しては、SWIFT自身が中心となって移行を主導しています。

項目	詳細
開始時期	2023年3月20日から移行開始
対象	カテゴリー1（MT 102/103）とカテゴリー2（MT 200/202/205など）の国際送金に利用されるメッセージ。
期限	2025年11月のSWIFTが定める期限までに、対応するMXメッセージへの移行を完了する必要があります。
注意点	このスケジュールは、国内決済（HVPS+）や企業-銀行間（CGI-MP）の通信には適用されません。

2. 🏦 国内・地域決済（HVPS+）の移行スケジュール

国内の高額決済システム（HVPS+）については、各国・各地域の市場インフラが、独自のスケジュールと方法で移行を進めています。

市場インフラ	国/地域	移行方法	移行完了日
Target2	欧州	ビッグバン（一夜での完全移行）	2023年3月20日
CHAPS	イギリス	段階的移行	2023年6月19日
Fedwire	アメリカ	段階的移行	2025年7月14日

用語解説:
ビッグバン方式: ある日を境に、古いシステム（MT）から新しいシステム（MX）へ一斉に切り替える方法。
段階的（フェーズ）方式: MTとMXを共存させながら、少しずつ新しいシステムへの移行を進める方法。

このように、SWIFTは国際送金の「郵便局」であるだけでなく、新しいグローバルスタンダード（ISO 20022）を世界中の金融機関に普及させるための「標準化推進機関」としての役割も担っているのです。

承知いたしました！ISO 20022（MXメッセージ）の最も重要な部分の一つである「送金に関わる人や銀行の役割」について、シンプルな具体例を使って、ブログ形式でわかりやすく整理しますね。😊

🧑‍🤝‍🧑 誰が誰に払うの？決済チェーンの登場人物と新しい役割（MXメッセージ編）

ISO 20022（MXメッセージ）では、従来のSWIFT（MTメッセージ）よりもずっと細かく、送金に関わるすべてのプレイヤーに役割（ロール）が割り当てられています。

ここでは、「会社Aが会社Bに支払う」という送金の流れを例に、メッセージが銀行をリレーしていく様子を見ていきましょう。

⛓️ 第1章：送金チェーンのリレー走者たち

まず、送金メッセージが次々とリレーされていく「決済チェーン」における銀行の役割を見てみましょう。

役割名	役割（誰のことか？）	例: Bank 3 $\to$ Bank 4 のメッセージ
📨 Instructing Agent (指示銀行)	メッセージを送る銀行（送信者）。	Bank 3
📥 Instructed Agent (被指示銀行)	メッセージを受け取る銀行（受信者）。	Bank 4
🔙 Previous Instructing Agent (前指示銀行)	指示銀行（Bank 3）の直前にメッセージを送った銀行。	Bank 2
➡️ Intermediary Agent (中継銀行)	被指示銀行（Bank 4）の後に送金を中継していく銀行。	Bank 5

💰 第2章：お金の「出所」と「行き先」（基本の役割）

これは、誰のお金が動き、最終的にどこに届くか、という基本的な役割です。

役割名	役割（誰のことか？）	例
➖ Debtor (デター/支払人)	実際に口座からお金が引き落とされる（支払う）当事者。	会社A
➕ Creditor (クレディター/受取人)	実際に口座にお金が入金される（受け取る）当事者。	会社B
🏦 Debtor Agent (支払人銀行)	支払人（会社A）が口座を持つ銀行。	Bank 1
🏦 Creditor Agent (受取人銀行)	受取人（会社B）が口座を持つ銀行。	Bank 6

👑 第3章：MXで追加された新しい役割（親会社など）

MXメッセージの最大の特徴は、**「誰が指示したか」「誰のために払うか/受け取るか」**といった、より詳細な背景情報まで記録できるようになったことです。

役割名	役割（誰のことか？）	具体的な例
🤴 Ultimate Debtor (究極の支払人)	真にそのお金を支払う義務がある（最終的に負担する）当事者。	会社Aの親会社Pが、会計処理のために子会社Aに「P社の代わりに払って」と指示した場合の「会社P」。
👸 Ultimate Creditor (究極の受取人)	真にそのお金を受け取る権利がある（最終的な恩恵を受ける）当事者。	会社Bの親会社Qが、子会社Bに「Q社の代わりに受け取って」と指示した場合の「会社Q」。
⚙️ Initiating Party (イニシエーティング・パーティ)	デター（支払人）に代わって、実際に支払い処理の最初の依頼を行う当事者。	グループ会社の支払いを一括で管理する経理専門の子会社Mが、デター（会社A）のために銀行に送金依頼を送った場合の「会社M」。

この新しい役割のおかげで、銀行は「この送金が誰の最終的な指示で、誰の最終的な利益になるのか」まで正確に把握できるようになり、会計処理やコンプライアンス（法規制遵守）対応がずっと楽になるのです！

📝 PACS.008徹底解剖！MXメッセージの「設計図」を読む

PACS.008（銀行間顧客信用送金）は、従来のMT103に相当する、MXメッセージの国際送金の中心となるメッセージです。

MXメッセージは、MTメッセージよりも多くの情報を、非常に構造化された形で送ることができます。ここでは、その構造と、主要な要素（エレメント）を見ていきましょう。

🧱 第1章：PACS.008の基本構造（2つのブロック）

PACS.008メッセージは、大きく2つのセクションに分かれています。

1. 📋 Group Header（グループヘッダー）

役割: そのメッセージ全体に共通する情報（「いつ、誰が、誰に送ったか」など）を記録します。
注意点: 本来は複数の取引を格納可能ですが、現在のCBPR+（国際送金）のルールでは、1メッセージにつき1取引のみと決められています。

2. 💸 Credit Transfer Transaction Information（信用送金取引情報）

役割: 実際の個別の支払いに関する詳細情報（金額、受取人、目的など）を記録します。
注意点: CBPR+のルールにより、ここにも1取引の情報のみが含まれます。

🔑 第2章：グループヘッダーの必須要素

メッセージ全体を識別するための、重要な情報です。

要素名 (XMLタグ)	必須/任意	MTの等価フィールド	役割
Message Identification (`MsgId`)	必須	Field 20	メッセージを一意に識別するID。各銀行が新しいメッセージごとに独自のIDを付けます。（ポイント・ツー・ポイント参照）
Creation Date Time	必須	-	メッセージが作成された日時。
Number of Transactions	必須	-	メッセージ内の取引数。CBPR+では常に「1」となります。
Settlement Information	必須	-	指示銀行と被指示銀行の間で、どう決済するか（資金移動の方法）を定めます。

Settlement Method: 決済情報の中にある要素で、「決済は指示銀行が担う（INGA）」といった決済方法のコードが入ります。

📌 第3章：取引識別情報（Payment Identification）

取引情報のブロックに入り、その取引自体を識別する重要な情報です。

要素名	必須/任意	MTの等価フィールド	役割
Instruction ID	必須	Field 20	決済チェーンのリレーごとに変わるID。通常はメッセージIDと同じ値。
End To End ID	必須	-	最初から最後まで変わらない、送金依頼全体を一意に識別するID。主に照合（リコンサイル）に使用されます。
UETR	必須	-	SWIFT GPIで利用される、取引全体の追跡を可能にするユニークなID。

💰 金額と手数料に関する要素

要素名	必須/任意	MTの等価フィールド	役割
Interbank Settlement Amount / Date	必須	Field 32A	実際に銀行間で決済される（動く）金額とその日付。
Instructed Amount	任意	Field 33B	送金人が最初に指示した金額（手数料控除前の金額）。
Charge Bearer	必須	Field 71A	手数料を誰が負担するかを示すコード（例: SHAR=共有、BEN=受取人、OUR=送金人）。
Charges Information	任意	-	どのエージェントが、いくら手数料を控除したかを明確に記録します。透明性の向上に不可欠です。

🧑‍🤝‍🧑 第4章：関係者（パーティ）とエージェントの情報

送金に関わるすべてのプレイヤーと、その口座情報を記録します。

役割名	必須/任意	MTの等価フィールド	役割
Previous Instructing Agent	任意	Field 72 INS	このメッセージの指示銀行の直前に送った銀行。最大3つまで記録可能。
Instructing Agent	必須	-	メッセージの送信者（Bank 3）の情報。
Instructed Agent	必須	-	メッセージの受信者（Bank 4）の情報。
Intermediary Agent	任意	Field 56A	このメッセージの被指示銀行の後で中継する銀行。最大3つまで記録可能。
Ultimate Debtor	任意	-	真に資金を負担する当事者（例：支払人Aの親会社P）。
Initiating Party	任意	-	デターに代わって支払い処理を開始した当事者（例：経理代行会社M）。
Debtor	必須	Field 50A	実際に口座が引き落とされる当事者（会社A）。
Debtor Agent	必須	Field 52A	支払人（デター）の口座を持つ銀行（Bank 1）。
Creditor Agent	必須	Field 57A	受取人（クレディター）の口座を持つ銀行（Bank 6）。
Creditor	必須	Field 59	実際に口座に入金される当事者（会社B）。
Ultimate Creditor	任意	-	真に資金を受け取る権利がある当事者（例：受取人Bの親会社Q）。

📃 最後の重要な情報

要素名	必須/任意	MTの等価フィールド	役割
Purpose	任意	-	送金の目的（例：INTC=企業内取引、SALA=給与など）をコードで示します。
Remittance Information	任意	-	請求書番号、契約番号など、支払いの詳細を構造化された形式で提供します。MTに比べ、より多くの詳細情報を正確に伝えられるようになりました。

PACS.008は、このように誰が、いつ、どこから、なぜ、いくら動かしたかという情報を、MTメッセージ時代には不可能だったレベルで正確かつ透明に記録できるように設計されているのです。

これで、SWIFTの基礎から最新のMXメッセージの構造まで、主要な概念を理解いただけたかと思います。

【SWIFTのすべて】MTからMXへ：次世代国際決済メッセージ徹底解読