SWIFT

SWIFT送金およびMT・MXメッセージによる通信

SWIFT(Society for Worldwide Interbank Financial Telecommunication)は、銀行などの金融機関が、支払指図や確認といった金融取引に関する標準化されたメッセージを送受信するための、安全なメッセージング・ネットワークです。SWIFT は口座を保有せず、資金の移動も行いません。情報を交換するための安全で信頼性の高い基盤を提供するのみです。

通常のSWIFT送金では、MT(メッセージタイプ)メッセージと呼ばれる一連の標準化されたメッセージ種別が用いられます。これらのメッセージは書式および項目があらかじめ定められており、金融機関が記載情報を容易に理解し処理できるようになっています。

MX(ISO 20022)メッセージは、XML(拡張可能なマークアップ言語)に基づく新しい金融メッセージング規格です。より豊富で構造化された形式により、データ交換の高度化とストレート・スルー・プロセッシング(STP)の改善を可能にします。MXメッセージは、SWIFTネットワークにおいて順次MTメッセージに置き換えられつつあり、相互運用性とデータ処理能力の向上を目的としております。

従来のSWIFT送金は数十年にわたり国際決済の基盤となってきましたが、透明性の限界、処理時間の長さ、非構造化データなど、いくつかの制約があります。

Swift 103+ STP(ストレート・スルー・プロセッシング)

Swift 103+ STPは、ストレート・スルー・プロセッシング(STP)向けに最適化された従来のMT形式でしたが、併存期間の終了に伴い、その役割はpacs.008のSTP利用ガイドラインに引き継がれています。STPにより、支払処理の全工程(開始から最終決済まで)を、手作業を介さずに電子的に完結させることができます。

その他の特長:

1. 標準化された形式:標準化された形式の厳格な遵守が求められるため、誤りや遅延が減少します。
2. 自動処理:取引は自動的に処理され、より迅速かつ効率的な処理が確保されます。
3. 手作業の削減:手入力や確認作業の必要性が最小限に抑えられ、誤りや遅延のリスクが低減されます。
4. 決済の迅速化:従来の方法と比べ、取引がより迅速に決済されます。

STPに関する留意事項:

1. 正確なデータ入力:遅延や拒絶を避けるため、データは正確に入力する必要があります。
2. フォーマット要件の遵守:銀行は、103+ STPのフォーマット要件が厳格に遵守されるよう確保しなければなりません。
3. ソフトウェアおよびシステム:銀行がSTP(ストレート・スルー・プロセッシング)を効果的に運用するには、適切なソフトウェアおよびシステムを整備している必要があります。

メッセージの送受信と決済とを区別することが重要です。SWIFTは金融機関間で構造化された金融メッセージを伝送しますが、それ自体が資金を移動させたり残高を保有したりするものではありません。pacs.008メッセージを含むSWIFTの確認通知は、参加金融機関の銀行システム内で実際に処理され照合された取引に対応している場合にのみ有効です。

金融機関による検証を経ずに提示された単独のSWIFT文書、スクリーンショットまたはメッセージは、決済完了の証拠として取り扱うべきではありません。

SWIFT gpiによる送金。

SWIFT gpi(グローバル・ペイメンツ・イノベーション):

2017年に開始されたSWIFT gpiは、従来のSWIFT送金の限界に対処するため、国際送金の迅速性、透明性および追跡可能性を高めることを目的とした取り組みです。SWIFT gpiは、既存のMTおよびMXメッセージ形式を活用して決済サービスを改善しています。SWIFT gpiの主な特長は次のとおりです。

• 決済の迅速化:gpiは手続きを簡素化し、銀行間のサービスレベル契約(SLA)をより厳格に定めることで、取引時間を短縮します。多くの場合、数分または数秒で完了します。
• 送金追跡:gpiトラッカーにより、取引をリアルタイムで追跡でき、透明性が向上するとともに、手作業による照会が減少します。
• 手数料の透明性:銀行は、取引手数料に関する情報を事前にお客様に提供することができ、これによりお客様はより適切な判断を行うことができます。
• より豊富なデータ:gpiは、より詳細かつ構造化された情報交換に対応しており、照合作業の改善および規制遵守に資します。

SWIFT gpiは、エンドツーエンドの追跡、処理の迅速化、より豊富なデータにより国際決済を強化することで、従来のSWIFT送金が抱える制約に対応するものです。

SWIFT gpi非参加機関向けの主要パラメーター

SWIFT gpiに参加していない機関(たとえば、gpiに直接加入していない銀行その他の金融機関)がgpi参加銀行に支払指図を送信する場合、gpi参加銀行はこれを所定のSWIFTメッセージ形式(顧客送金にはpacs.008、カバー送金にはpacs.009 COV、金融機関間送金にはpacs.009)に変換することができます。この変換により、gpiネットワーク内での処理および追跡が可能となります。ただし、指図に必須項目を入力するために十分なデータが含まれていること、およびエンドツーエンドでの追跡可能性などのgpiの規則に適合していることが条件となります。

gpi非参加の銀行は通常、これらのパラメータを国内決済スキーム、API、または従来形式を通じて提供し、gpi参加銀行がgpi固有の項目を付加します(たとえばUETRが提供されていない場合の生成。ただし、gpi非参加の機関にとってUETRの引継ぎは任意です)。具体的な要件は、法域、通貨および二者間の取決めによって異なる場合がありますが、中核となるパラメータはCBPR+(Cross-Border Payments and Reporting Plus)ガイドラインおよびISO 20022標準に基づいています。2025年11月22日に共存期間が終了したことにより、国際送金の指図はISO 20022形式で交換されています。以下に示す従来のMTフィールドへの言及は、参考情報にすぎません。
1. 当事者の特定(支払人および受取人の情報)
これらは仕向人および受取人を特定するもので、トラベルルールに関するFATF勧告16の遵守を確保するものです。

• 債務者/依頼人:氏名(名称)の正式表記、構造化住所(街路、市区町村、郵便番号、国)および口座識別情報(IBANまたは口座番号など)。従来のMT103/MT202 COVではフィールド50aに、pacs.008/pacs.009では<Dbtr>および<DbtrAcct>に対応します。
• 債権者/受益者顧客:氏名(名称)の完全表記、構造化された住所および口座識別情報。従来のMT 103/MT 202 COVにおけるフィールド59aに対応し、pacs.008/pacs.009では<Cdtr>および<CdtrAcct>に対応します。
• 最終債務者・最終債権者(該当する場合):主たる当事者と異なる場合には、透明性を高めるため、その詳細を記載します(任意ですが、gpiによる追跡のため推奨されます)。pacs.008およびpacs.009の<UltmtDbtr>/<UltmtCdtr>に対応します。

必要とされる理由:正確な送金経路の特定および規制上の確認を可能にするためです。データが不完全な場合、取引の差戻しや遅延が生じることがあります。

2. 代理機関およびルーティング情報
取引経路に関与する金融機関を特定します。

• 債務者側銀行(Debtor Agent):送金銀行のBIC(銀行識別コード)またはその他の識別子。従来のMT103ではフィールド52aに、pacs.008/pacs.009では<DbtrAgt>に対応します。
• 債権者側銀行:受取銀行のBIC。従来のMT 103/MT 202 COVではフィールド57a、pacs.008/pacs.009では<CdtrAgt>に対応します。
• 仲介エージェント(判明している場合):コルレス銀行のBIC(最大3段階まで)。従来のMTにおけるフィールド56aに対応し、pacs.008/pacs.009では<IntrmyAgt1-3>に対応します。
• 指図/被指図エージェント:送金経路上の直近の送信者・受信者のBIC。任意記載ですが、シリアル方式またはカバー方式において有用です。
• 先行する指図エージェント(該当する場合):複数の中継を経る経路の場合、先行するエージェント最大3社。

必須である理由:仲介機関への適切な経路指定を確保するためです。pacs.009 COVでは、正確性の観点から、名称よりもBICFIを用いてください。

3. 取引明細
決済のための中核的な金融要素です。

• 金額および通貨:銀行間決済金額およびISO 4217通貨コード(例:USD、EUR)。従来のMT103/MT202 COVではフィールド32Aに、pacs.008/pacs.009では<IntrBkSttlmAmt>に対応します。
• 指図金額(異なる場合):控除前の元の金額。
• 銀行間決済日:決済のバリュー日。MTでは Field 32A の一部に対応し、pacs.008/pacs.009 では <IntrBkSttlmDt> に対応します。
• 決済方法:RTGS(CLRG)、カバー方式(COVE)、またはエージェント経由(INDA/INGA)のいずれによるかを明示します。MTには直接対応する項目はありませんが、黙示的に含まれます。

必須となる理由:価値の移転を定義するものであり、すべてのフォーマットで必須です。

4. 参照番号および追跡用識別子
特にgpiにおける追跡可能性を確保するためのものです。

• エンドツーエンド識別子:取引の連鎖全体を関連付ける参照情報(例:請求書番号または取引ID)。pacs.008およびpacs.009における<EndToEndId>。
• 指図識別子:送信者の参照番号(MTでは16文字以内)。従来のMTではフィールド20に、pacs.008/pacs.009では<InstrId>に対応します。
• 固有のエンドツーエンド取引参照番号(UETR):エンドツーエンドでの追跡のためのUUIDです。pacs.008/pacs.009において、また従来のMT103/MT202においてはフィールド121において必須です。発信チャネルがこれを付与しない場合は、チェーン上で最初のSWIFT加盟銀行が生成します。
• 取引識別情報:追加の内部参照番号。

必要とされる理由:gpiによる追跡および関連付け(例:pacs.008とpacs.009 COV)を可能にします。UETRは、統一的な確認通知を実現するうえで鍵となります。

5. 目的およびサービスに関する情報
支払の種類を分類します。

• 目的コードおよびカテゴリー目的コード:取引の性質を示すISOコード(例:給与を示すSALA)。一部の送金ルートでは必須であり、pacs.008では<Purp>および<CtgyPurp>が該当します。
• サービスレベルコード:gpiサービス(例:gpi顧客送金を示すG001)を識別します。gpi非参加銀行は、別途合意がない限り、gpi固有のコードを記載しないでください。MT形式ではフィールド23E、pacs.008/pacs.009では<SvcLvl>に対応します。
• ローカル・インストルメント・コード:特定のスキーム(例:グループ内送金)向けのコードです。

必要とされる理由:規制遵守および処理上の優先順位を確保するためです。ISO移行後は、義務化される場面が増えております。

6. 送金および追加の指示事項

• 送金情報:非構造化(最大140文字)または構造化(請求書の詳細など)。従来のMT 103のField 70に対応し、pacs.008/pacs.009では<RmtInf>に対応します。
• エージェントへの指図:たとえば、受信銀行宛てを示す/REC/、口座を示す/ACC/、または電話による指図(PHOB)などです。従来のMTにおけるField 72に対応し、pacs.008/pacs.009では<InstrForNxtAgt>/<InstrForCdtrAgt>に対応します。
• 決済時刻指標:要求される時刻(例:CLS時刻を示すCLSTm)。

必要な理由:背景情報および取扱い指示を提供するものであり、pacs.009 COVにおけるカバー方式に不可欠です。

7. 規制・コンプライアンス関連データ

• 規制報告:コードまたは詳細情報(例:納税者番号、CRED/DEBなどの報告区分)。MTではフィールド77B、pacs.008/pacs.009では<RgltryRptg>に対応します。
• 返金理由コード(返金の場合に適用):例えば、口座解約を示すAC04があり、pacs.004において元のメッセージと関連付けられます。

必要とされる理由:AML/KYCおよび報告義務を満たすため。規制の対象となる送金経路では必須です。

ベストプラクティスとして、gpi非参加行は、MTからMXへの変換時にデータが切り捨てられないようデータを構成し、個別の要件についてはgpi参加銀行にご相談ください。カバー方式を用いる支払の場合、基礎となるお客様情報は各メッセージ間で一致させる必要があります(例:pacs.008とpacs.009 COV)。

SWIFT gpiにおける支払メッセージ

SWIFT gpi(グローバル・ペイメンツ・イノベーション)の枠組みでは、元の支払メッセージ(例:顧客送金のpacs.008、カバー送金のpacs.009 COV)は、いったん送信されると変更不能なものとして扱われます。受取銀行がこれらのメッセージの内容を直接変更することはできません。SWIFTメッセージは、支払チェーン全体を通じて完全性と監査可能性を維持するよう設計されているためです。訂正、修正または取消はいずれも、別個のフォローアップメッセージ、gpiトラッカーによるステータス更新、またはgSRP(gpi Stop and Recall Payment)などの専用サービスを通じて処理されます。これにより、Unique End-to-End Transaction Reference(UETR)を用いたエンドツーエンドの追跡可能性が確保されます。

受取銀行(通常は債権者側エージェントまたは仲介機関として行動する銀行)は、一方で、送信者からの変更依頼に応じることができ、また、支払結果を実質的に変更することとなる措置(例:返却や保留)を開始することもできます。また、特定の条件の下で、送信者に対して説明の提供や訂正を求めることもできます。これらの手続は、SWIFTのルールブック、市場慣行ガイドライン(例:Payments Market Practice Group(PMPG)によるもの)および規制上の要件に従っており、自動化、透明性および不正防止を重視しています。

受取銀行が変更を要求または促進するための条件
受取銀行は、当初の支払が指図どおりに処理できない場合、変更(例:詳細情報の訂正)を要求し、または変更の必要性を示唆する措置を講じることがあります。これは通常、照会メッセージ(例:MT 195/199)または送信側が開始した要求への回答を通じて行われます。主な条件は次のとおりです。

• 支払内容の誤り:受取人口座の誤り(閉鎖済み口座の場合はコードAC04)、通貨の誤り(コードCURR)、仲介金融機関の経路の誤り(コードAGNT)、あるいは技術的問題(コードTECH)など、不備がある場合、受取銀行は当該支払を保留とし、送金人に対して訂正情報の提供または新たな支払の実行を求めることがあります。これにより、支払を直ちに拒否することなく、解決を図ることができます。
• 支払の充当不能:コードCUTA(Cancel Upon Unable to Apply:充当不能時の取消し)の下では、不一致(例:名義・口座の相違や詳細情報の不足)により入金処理ができない場合、受取銀行は、是正のために、送金銀行に対して取消しまたは訂正の詳細を求めることができます。
• 不正の疑いまたは無権限取引:不正(コードFRAD)の場合、受取銀行は、問題を独自に検知し、送金人からの依頼を待たずに資金の返却手続を開始することができます。また、送金人からのリコール要請に対しては、資金を保全したうえで、すでに入金済みの場合は補償(コードINDM)を求め、返却前にリスクを軽減することができます。
• 重複または不当な支払:DUPL(重複支払)やUPAY(不当支払)などのコードにより、取引が誤りまたは不当である場合、受取銀行はこれを指摘し、取消しを依頼することができます。
• 規制またはコンプライアンス上の問題:支払が現地の法令、制裁措置またはAML要件に違反する場合(コードLEGL)、受取銀行は当該支払を拒否または保留し、送金人に追加書類の提出または訂正を求めることができます。
• 顧客または受取人による判断:受取人が支払いを拒否した場合(コードCUSTまたはNOAS(受取人からの応答なし))、受取銀行は当該支払いを返戻して送金人に通知することができ、場合によっては変更内容の確認を求めることがあります。
• 保留中の案件:借方記帳権限の待機(RQDA)や次の代理銀行からの回答待ち(PTNA)など、保留中の案件(コードPDCR)については、受取銀行は支払を保留し、処理を進めるための追加指示または変更を求めることができます。

いずれの場合も、ストレート・スルー処理(STP)を可能にするため、依頼は自動処理に適した形式で構成されなければなりません(例:UETR、フィールド20/32A/50/59などの元の参照情報、およびメッセージのフィールド79における所定のコードを含めること)。資金が入金された場合には、当事者間で補償契約が求められることがあり、受取銀行は依頼を受諾する義務を負いませんが、緊急性の高い依頼(例:不正関連)については優先して取り扱う必要があります。

関連する手続

• 送金人起点の取消依頼への対応:送金人(債務者側銀行)は通常、gSRPサービスを通じてMT 192/292(またはcamt.056などのISO 20022相当メッセージ)により取消依頼を開始し、これは受取銀行に順次または直接送信されます。受取銀行は直ちに受領を確認し、CNCL(取消済)、RJCR(理由付き拒否)、PDCR(保留中)などのコードを用いて、MT 196/296(構造化されている場合はMT 199/299)で回答しなければなりません。受諾された場合、資金はpacs.004(支払返戻)により返還されます。
• 受取銀行による独自の対応:内部で不正が検知された場合、受取銀行は構造化された詳細情報を付してpacs.004により資金を返還でき、Trackerを通じてリアルタイムのステータス更新を通知できます。
• 訂正・照会の依頼:受取銀行は、照会メッセージ(MT 195/295など)を用いて、追加の詳細情報など内容の変更を依頼します。これは、保留中の支払に関してよくみられます。
• トラッカー連携:すべての処理はgpi Trackerにリアルタイムで反映され、APIまたはGUIを通じて、関係者全員が確認できます。gpiメンバーは、gCCT(顧客クレジット送金)、gCOV(カバー)およびgSRPに関する必須のルールブックを遵守しなければなりません。
• 制約事項と成功要因:変更が認められる保証はなく、成否は支払段階(入金前の方が容易)、受取人の協力、および法域によって左右されます。入金済みの場合、返金には受取人の同意または補償が必要となります。規制は常にガイドラインに優先いたします。

これらの実務は主にgpi参加銀行に適用されますが、gpi非参加銀行もゲートウェイを通じて参加することができます。最新の詳細につきましては、プロセスが(たとえばISO 20022への移行に伴い)変化しておりますので、SWIFTの公式ルールブックをご参照ください。

SWIFT gpiにおけるメッセージングと決済の分離

SWIFT gpiは、主にメッセージ(たとえば、顧客送金に用いるpacs.008や金融機関間送金に用いるpacs.009などのISO 20022形式、または従来のMT103/MT202)を通じて支払指図とその追跡を取り扱いますが、資金の実際の移動は、決済レベルで別途行われます。決済は通常、コルレス銀行関係(ノストロ口座/ボストロ口座)、二者間ネッティング、またはリアルタイム・グロス決済(RTGS)システム(たとえば、欧州のT2(旧TARGET2)、米国のFedwire、英国のCHAPS)といった清算・決済メカニズム(CSM)を通じて行われます。gpiトラッカーはメッセージの状況をリアルタイムで可視化しますが、資金の移動はこれらの基盤となるシステムに依拠しています。

国際送金指図の併存期間は2025年11月22日に終了しました。MT 103やMT 202などの送金指図は、pacs.008やpacs.009などのISO 20022(MX)メッセージに置き換えられており、その他のMTカテゴリーも後日順次廃止されます。以下では、返戻および保留解除が口座・クリアリング・決済の各レベルでどのように行われるかを説明します。

口座・クリアリング・決済の各段階における資金の返還方法
返還は、組戻し依頼(gSRP(gpi Stop and Recall Payment)サービス経由)が受理された場合、または不正や誤りなどが独自に検知された場合に開始されます。gSRPでは、送金人側がcamt.056(Payment Cancellation Request:支払取消依頼)を送信し、これに対してcamt.029(Resolution of Investigation:調査結果通知)が返信されます。受理後、資金の返還は、資金の流れを逆方向にたどる新たな支払指図によって実行され、受取銀行の口座から引き落とされ、連鎖を遡って返金されます。これは元のメッセージを変更するものではなく、別個の取引として処理されます。

主な決済方法と返還手続
決済方法によって、返還の方法が決まります。

• CLRG(マーケットインフラ経由の決済):RTGSまたはCSM(例:中央銀行経由)を通じた決済です。返金にはpacs.004を用い、マーケットインフラに対し、受取代理銀行の口座を借方記帳し、前段の代理銀行の口座を貸方記帳するよう指図します。多くの場合、リアルタイムまたは同日中に処理されます。
• INGA(Instructing Agent Settles First:指図銀行が先に決済):送信者は、メッセージ送信に先立って資金を決済します。pacs.004による返金は、決済後に被指図銀行の口座から引き落とされます。
• INDA(指図を受けた代理人が受領時に決済):受取側はメッセージ受領時に決済します。未決済の場合はpacs.002により拒否し(資金は移動しません)、決済済みの場合はpacs.004により返金します。
• COVE(カバー方式):カバー送金(pacs.009 COV)を伴う高額支払に用いられます。返戻は逆の経路をたどり、受取人側の代理銀行から仲介銀行へpacs.004が送られ、これに応じてコルレス口座の借記・貸記が行われます。

決済段階における返還手続の手順

1. 開始と受諾:送信側が(例えばUETRを付したcamt.056により)取消しを依頼します。受信側は(camt.029により)応答し、資金が利用可能であり、かつ受益者にまだ入金されていない場合には、これを受諾します(入金前のほうが容易です)。既に入金されている場合には、受益者の同意または補償が必要となることがあります。

2. 資金返還指図:受取側がpacs.004(支払返戻)または従来のMT 103/MT 202を、返戻コード(例:RETN)とともに発行します。このメッセージには次の事項が含まれます。

• 元の参照情報(UETR、エンドツーエンドID、指図ID)。
• 役割の逆転:元の債権者が債務者となり、元の債務者の代理銀行が債権者となります。
• 決済の詳細:当初の銀行間決済金額・決済日、為替レート(外国為替が関与する場合)、手数料(控除される場合)。
• 返却理由コード(例:口座閉鎖の場合はAC04、不正の場合はFRAD)。
• 入金先口座を指定するための決済口座フィールド(原電文に含まれる場合)。

3. 決済の実行:

• pacs.004により、受取銀行のノストロ口座またはボストロ口座(前の代理銀行または市場インフラに開設されたもの)から引落しが行われます。
• 資金は、同じ決済方法(たとえばCLRGにおけるRTGS送金)を用い、チェーンを構成する各当事者を順にたどって返金されます。
• 一部返還の場合は、追加情報欄に「PART」と記載し、按分した金額を明記してください。
• トラッカーはステータス(例:「返戻済み」)をリアルタイムで更新し、APIまたはGUIから確認できます。

4. 最終的な入金:元の送金人の口座に入金されます。多くの場合、手数料が差し引かれます。CSM(クリアリング・決済メカニズム)を経由する場合、決済はアトミック(不可分)に行われます。二者間の取決めでは、日末のネッティングを伴うことがあります。

5. 返却後の通知:camt.053/054(口座明細/借方・貸方通知)を使用して、元帳の更新を確認します。「返却の返却」に対するpacs.004は使用せず、代わりに照会を用います。
返却は可能な限り自動化されておりますが、コンプライアンス上の理由や資金が凍結されている場合には、手作業による対応が必要となることがあります。資金の回収は保証されるものではなく、何よりも組戻しの依頼がどれだけ迅速に送信されたか、また資金がすでに入金処理されているかどうかによって左右されます。未決済の場合(例:決済前に拒否された場合)には資金は移動しないため、代わりにpacs.002を使用します。

保留された支払いが口座・クリアリング・決済の各段階で解除(承認)される仕組み

保留は、支払を直ちに処理できない場合(例:エラー、コンプライアンス上の確認、照会事項への回答待ちなど)に発生し、決済が行われないまま「保留中」の状態となります。解消されるまで、資金の引落しも入金も行われません。gpi Trackerでは「On Hold」や「Pending」(例:PDCRコード)といったステータスが表示され、解消にはMT 195/199またはcamt.029による照会メッセージが用いられます。

保留(ホールド)に至る条件

• 不一致(例:口座番号と名義の相違 – CUTAコード)。
• 規制上の確認(例:制裁関連確認 - LEGLコード)。
• 受取人の回答(NOASコード)または引落権限(RQDA)の待機中。
• 受取銀行側のオフライン時間帯またはバッチ処理。

決済段階での解除手続
1. 保留通知:受信側は、pacs.002(ステータス更新)または保留コード付きのMT 199を送信し、(カバー方式などで)一部のみ決済された場合には、資金を仮勘定/エスクロー口座に留め置きます。
2. 解消:送信側は、(MT 195による回答またはcamt.029などを通じて)訂正・明確化を提供します。解消された場合、受信側は元の指図を処理して「承認」します。
3. 決済の実行:

• 元のpacs.008/pacs.009の保留が解除されます。
• 資金は所定の方法で決済されます。すなわち、送金人の口座を借方記帳し、受取人側の口座を貸方記帳したうえで(例:CLRGにおけるRTGSを通じて)、最終的に受益者の口座へ貸方記帳されます。
• 受益者側の区間(受取銀行から最終顧客まで)は、特に資本規制がある市場やインフラが限られている市場において、遅延が生じやすい部分です。
• トラッカーが「入金済」または「完了」に更新され、pacs.002(支払ステータス報告)により確認されます。

4. 解放されない場合:未解決のままの場合(例:タイムアウト後)は、上記のとおりpacs.004により返金するか、pacs.002により拒否します(決済は行われません)。

gpiのルールでは、可能な限り当日中の入金が求められています。Swiftは2018年に、gpi決済のほぼ50%が30分以内に、ほぼ100%が24時間以内に入金されたと報告しました。資本規制や銀行の営業時間外といった要因により保留が長引く場合もありますが、gpiは自動化によってこれを最小限に抑えることを重視しています。

SwiftNet Instant

SwiftNet Instant。24時間365日利用可能な、低遅延のリアルタイム・メッセージング・プラットフォームであり、クリアリング・決済機構(CSM)とその参加者との間におけるインスタント決済フローの安全な交換を支えています。

お客様は、VPNボックス、専用回線、ハードウェア・セキュリティ・モジュールなど、既存のSwift接続環境およびセキュリティ基盤を通じて、SwiftNet Instantに接続できます。銀行のIT環境との統合は、Alliance Gateway Instant(AGI)を通じて実現されます。

即時決済チェーンに関与するすべての当事者が、AGIおよびSwiftNet Instantメッセージングを利用できます。用途としては、オーバーレイサービスからの支払指図、間接参加者とスポンサー参加行との間の通信、事業法人による支払確認の受領などがあります。

SWIFT Instantは、各国の国内即時決済システムと接続し、ISO 20022規格を用いて、国内外を問わずリアルタイムでの取引処理を可能にします。これらのシステムは、金融業界における決済プロセスの近代化と簡素化に向けた継続的な取り組みを表すものです。

SWIFTダイレクトデビット

SWIFTシステムにおける口座振替(ダイレクトデビット)は、企業および個人が、複数の通貨にまたがり、また複数の国にまたがって、債務者の銀行口座から資金を回収することを可能にする決済手段です。SEPA圏向けに設計され、ユーロ建て取引に限定されるSEPA口座振替とは異なり、SWIFTにおける口座振替は世界的な適用範囲を持ち、幅広い通貨に対応しています。

SWIFTシステム内で口座振替取引を開始する手続は、通常、次のステップで行われます。

1. 債権者と債務者の間の合意:債権者と債務者の間には、口座振替取引に関する約款・利用条件を含む既存の合意が存在していなければなりません。この合意には、債権者が債務者の銀行口座から支払いを回収することを可能にする委任または承認の設定が含まれる場合もあります。
2. メッセージ交換:債権者側の銀行は、債務者側の銀行にSWIFTメッセージを送信して口座振替を開始します。ISO 20022ではpacs.003(顧客口座振替)またはpacs.010(金融機関口座振替)、従来のメッセージ形式ではMT 104またはMT 204に相当します。このメッセージには、金額、通貨、債務者の口座情報、その他必要な情報など、取引の詳細が含まれます。
3. 検証および承認:債務者の取引銀行は、取引の詳細を検証し、債務者の口座における資金の有無を確認したうえで、当該取引の承認を確認します。すべてに問題がなければ、債務者の取引銀行は債務者の口座から資金を引き落とします。
4. 資金移動:資金は、コルレス口座または清算・決済システムを通じて、債務者の取引銀行と債権者の取引銀行との間で決済されます。
5. 確認:資金を受領すると、債権者の取引銀行は債権者に確認通知を送信し、口座振替が正常に完了したことをお知らせします。

SWIFTシステムにおいて口座振替取引を開始するための前提条件は、以下のとおりです。

1. 銀行口座:債権者および債務者の双方が、SWIFTネットワークに参加している金融機関に銀行口座を保有している必要があります。
2. 合意および授権:口座振替取引を可能にするため、債権者と債務者の間で事前の合意および授権(委任)が成立している必要があります。
3. SWIFTメッセージ形式:債権者およびその取引銀行は、適切なメッセージ形式を使用しなければなりません。口座振替(ダイレクトデビット)の開始にはpain.008、銀行間ではpacs.003またはpacs.010を使用します。
4. 銀行手数料:債権者および債務者は、SWIFTシステム内での口座引落取引に伴う手数料にご留意ください。当該手数料は、関与する銀行および国によって異なる場合があります。

銀行間SWIFTメッセージングにおけるRMA

銀行業務および金融の分野では、銀行間の安全かつ効率的な通信が不可欠です。ここで重要な役割を果たすのがSWIFT(国際銀行間通信協会)であり、国際的な銀行間メッセージの大半を取り扱っています。これらの通信の安全性と選択性を確保する上で重要な要素となるのが、リレーションシップ・マネジメント・アプリケーション(RMA)です。

RMAとは何か

Relationship Management Application(RMA)は、金融機関がどの取引相手からSWIFTメッセージを受信できるかを定めることを可能にし、SWIFTネットワーク上の通信を認証済みのユーザーのみに限定するSWIFTのソフトウェアアプリケーションです。RMAは、権限のないメッセージを排除し不正のリスクを低減することから、銀行間通信の管理における基本的なセキュリティ層となっています。

RMAの重要性

IFBのように国際金融業務に携わる銀行にとって、RMAツールは不可欠です。このツールは、セキュリティ手順を強化するだけでなく、国際的な銀行規制への遵守も確保します。メッセージを送信できる金融機関を管理することで、銀行は権限のない情報照会や金融指図を防止し、自行および顧客双方の利益を保護することができます。

RMAの仕組み

RMAの手続には、次の主な段階があります。

1. RMA関係の確立:2つの銀行がSWIFTを通じて情報交換を開始する前に、相互にRMAを確立することに合意する必要があります。この合意は、いわばデジタル上の握手にあたり、信頼と通信への同意を意味します。
2. 鍵の交換:各銀行はRMAアプリケーションを通じてRMA承認を送信し、相手方がこれを承諾します。RMAは従来の二者間鍵交換(BKE)に代わるものであり、メッセージ自体はSWIFTNet PKI(公開鍵基盤)により認証されます。
3. RMA設定の構成:各銀行はRMAツールを用いて権限を設定し、相手方銀行から受け入れるメッセージの種類を指定します。これは大まかに分類することも、特定のメッセージタイプやサブクラスを含めるよう細かく調整することも可能です。
4. 有効化とモニタリング:RMAの設定が完了し有効化された後は、各銀行は受信メッセージが確立された許可に適合しているかを監視することができます。RMAには、業務上の必要性やセキュリティ上の懸念に応じて、許可を変更または取り消すための機能も備わっています。

実務への応用

高額資産家の個人および法人顧客を対象とする投資・資産運用を専門とするIFBにとって、RMAには次のような利点があります。

• セキュリティの強化:メッセージのトラフィックを管理することにより、IFBは、お客様の取引および機微な情報を不正アクセスから保護することができます。
• 業務効率:信頼できる相手先との通信を円滑化することで、正当なメッセージの処理が迅速になり、対応時間の短縮とお客様満足度の向上につながります。
• 規制遵守:RMAは、マネーロンダリングや詐欺などの金融犯罪を防止するために情報交換の厳格な管理を義務付ける国際的な銀行規制への対応を支援します。

RMAとMT799。銀行は、チャネルが許容する場合に限り、MT799を用いてRMA関係の要請または調整を行うことができます。RMA認可そのものはRMAシステム上で付与されるものであり、MT799のみでは何らの権限も有効化されません。MT799に必要なRMA認可が存在しない場合、MT799を直接送信することでこれを迂回することはできません。その場合の設定は、認可の交換に先立つ取引相手との調整を目的としたSwiftのRelationship Management PortalのRMAコミュニケーション機能、または他の許容されたチャネルを通じて合意されます。したがって、「MT799によるRMA」は付随する銀行間の連絡を指す場合がありますが、技術的なRMA認可は別個の手順です。

要約

IFBにとって、RMAの効果的な導入は単なる技術的要件ではなく、グローバルな事業運営における戦略的資産です。これは、セキュリティと規制遵守に対する当行の姿勢を裏付けるとともに、通信ネットワークの効率性を高めます。国際金融の環境が進化し続ける中、RMAのようなツールは、最高水準の業務の健全性とお客様へのサービスの維持に努める銀行にとって、引き続き不可欠な手段です。

RMA(リレーションシップ・マネジメント・アプリケーション)は、金融機関間の安全かつ選択的な通信の基盤を成すものであり、SWIFTネットワークを通じて交換されるすべてのメッセージが最高水準のセキュリティ基準に適合し、完全に認証されることを確保します。IFBのような銀行にとって、RMAを理解し適切に管理することは、業務を保護し、世界各地の取引先との信頼関係を築くうえで不可欠です。

Swiftデジタル・ブロックチェーン金融指図

2025年9月、Swiftは、30を超える金融機関とともに、共有デジタル台帳の設計・開発に着手したことを発表しました。2026年7月9日、Swiftは同台帳が初期利用の準備を整えたと表明し、17行がトークン化預金による実取引のパイロット運用に向けた準備を進めています。参加行は、ANZ、BNP Paribas、BNY、Citi、DBS、First Abu Dhabi Bank、FirstRand、HSBC、Itaú Unibanco、Lloyds、Mashreq、MUFG、OCBC、Standard Chartered、UBS、UOB、Wells Fargoです。最初の適用分野は、銀行間のリアルタイムかつ24時間365日の国際指図の実現であり、国際取引処理の基盤を支える重要な機能強化となります。

最初の概念実証プロトタイプは、Consensysと共同で構築されました。この台帳は、金融機関間の金融指図を記録する、安全かつ改ざん不可能なリアルタイムの登録簿として設計されています。取引メッセージを記録・順序付け・検証するとともに、スマートコントラクトにより運用上およびコンプライアンス上のルールを執行します。相互運用性は中心的な原則であり、本台帳は既存および新興のインフラの双方と接続しつつ、Swiftの特長である強靭性、信頼性、規制遵守を維持します。

Swiftの最高経営責任者(CEO)であるハビエル・ペレス=タソ氏は、次のように述べています。
「共有台帳とSwiftの既存のメッセージング、API、ISO 20022を組み合わせることで、さらに強力な仕組みが生まれます。取引フローの当初からリスク、統制、コンプライアンス要件を組み込むことができ、同時に、Swiftが培ってきた信頼性、安全性、強靭性、拡張性、卓越した業務運営を維持したまま、24時間365日のリアルタイムの銀行間クロスボーダー指図を可能にします。これはすべて、私たちが一貫して取ってきた責任あるイノベーションの方針に沿ったものです。」

インフラの拡張

共有台帳は、Swiftの既存のネットワークを補完するものであり、これに代わるものではありません。オーケストレーションと相互運用性を拡張し、金融機関が指図をより迅速に、より高い予見可能性をもって、真にグローバルな規模でやり取りできるようにすることを目的としています。

Sibosにおいて、ペレス=タッソ氏は、この二本立てのアプローチを強調しました。
「金融インフラは、オペレーショナル・エクセレンス、規制遵守、ガバナンスという基本を、絶えず重視し続けなければなりません。同時に、将来への備えも整える必要があります。Swiftでは、二つの並行する軌道でイノベーションを進めるというアプローチを取っています。」

業界全体にわたる協働

16か国の金融機関が、共有台帳の設計、ガバナンス、および開発の方向性の策定に当初から関与してきました。この共同の取り組みは、銀行間指図のためのグローバルなインフラを発展させるには規模と協働が必要であるという共通の認識を示しています。

今後の展望

共有台帳は、Swiftによるこれまでのデジタル資産の実証実験を自然に発展させたものであり、パブリック・ネットワークとプライベート・ネットワークの双方にまたがる相互運用性への、より広範な取組みの一環です。これにより、規制対象のトークン化された価値と従来型の金融商品のいずれも、システム間を円滑に移動できるようになります。

ペレス=タッソ氏は構想を次のように要約しました。
「これは将来に向けた強力なプラットフォームです。そして、将来的にはさらに大きな変革をもたらす可能性があります。」

よくあるご質問

Swiftのブロックチェーン基盤の共有台帳とは何ですか。
金融機関間の資金決済指示について、リアルタイムの共有記録を提供するブロックチェーン基盤であり、コンプライアンスに適合した継続的な国際決済処理を可能にします。

対象となるお客様
より迅速かつ透明性の高い取引指図を提供するとともに、デジタル化の将来に備える必要のある銀行および金融機関。

どのような利点がありますか。

• 指図のリアルタイムでの可視化および実行順序の管理
• スマートコントラクトによる自動化されたコンプライアンス
• 従来型ネットワークとデジタルネットワーク間の相互運用性
• 規制対象のトークン化価値フローの安全な取扱い

SWIFTのプラットフォームとの関係はどのようになっておりますか。
SWIFTの信頼性の高いインフラを拡張し、レジリエンス、セキュリティおよびコンプライアンスを維持しつつ、デジタルによる指図機能を組み込むものです。

最初のユースケースは何ですか。
リアルタイムで24時間365日対応の、国際銀行間取引指図です。

関与している機関は?
16か国、30を超える金融機関が設計に携わり、17行が最初の実取引の試行運用を行っています。

いつ利用可能になりますか?
Swiftは、2026年7月9日に当該台帳の初期利用の準備が整ったと発表しました。パイロット参加銀行は、管理されたゴーライブ段階において初期の実取引を実施します。最終的な決済は引き続き既存のシステムを通じて行われます。機能および利用可能範囲は、その後拡張される予定です。

コルレス銀行網を通じた資金の送金方法についてさらに詳しくお知りになりたい場合は、コルレス銀行業務責任者のAmri Elarisse氏までお問い合わせください。