🏦

ブロックチェーンでのISO20022の取り組み

かるでね

2025/10/24に公開

 はじめに初めまして。

『DApps開発入門』という本や色々記事を書いているAva Labsのかるでねです。
https://amzn.asia/d/gxvJ0Pw
以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！
https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4
https://twitter.com/cardene777
https://qiita.com/cardene
https://cardene.substack.com/
https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58
今回は『ISO20022』をブロックチェーンで表現する取り組みについてまとめていきます。

 概要ISO 20022は、国際標準化機構（ISO）が金融分野向けに定めた電子メッセージ交換の標準規格です。

金融機関や決済ネットワーク間で取引データを効率的かつ統一的にやり取りするための「共通言語」を提供します。
以下のような金融業務を対象にメッセージ定義を整備しています。
決済（支払い）
証券取引・決済
貿易金融
為替（外国為替）
カード取引
また、これまで各国・各システムごとに異なっていたフォーマットを統一することで、相互運用性（interoperability）を高めようという狙いがあります。

 構造と設計ISO20022は単なるメッセージフォーマットの標準化ではなく、金融情報交換全体の構造と設計思想を統一するための枠組みです。

そのため、以下のような要素で構成されています。


要素
説明


メタモデル（Metamodel）
金融業務メッセージの設計に共通する構造（モデル）を定義する概念モデル。これにより、異なる業務領域間でも整合性のあるモデル化が可能になります。

UMLプロファイル
UML（統一モデリング言語）を用いてメッセージ構造を表現するための拡張・制約ルール。これにより、開発者が一貫した設計手法でモデリングできます。

モデリング規則
各業務ドメイン（決済、証券、貿易金融など）をどのようにモデル化するかを定めたガイドライン。

メッセージ仕様（XML／ASN.1）
UMLモデルを具体的なメッセージ定義（XMLスキーマやASN.1定義など）に変換するための技術的ルール。

登録および管理プロセス
新しいメッセージ定義や変更を承認・登録・管理する仕組み。ISOの中央レジストリで統一的に運用されます。

この構成により、メッセージ仕様は「モデル＋変換ルール」として設計され、柔軟性と拡張性を両立しています。

 メッセージフォーマットの仕組みISO20022では、従来のメッセージ形式を抜本的に見直し、情報をより「意味的に」伝達できるよう設計されています。

 従来のメッセージフォーマット（MT形式）従来、国際送金や銀行間決済で使われていたのは SWIFT MT形式（Message Type） です。

この形式はISO15022に基づくテキストメッセージ仕様で、1970年代から世界中で使用されてきました。
固定長のテキスト形式で、各項目が「フィールド番号」で区分される構造になっていました。
例：
:20:1234567890
:23B:CRED
:32A:230309JPY1000000
:50K:/123456789
Taro Yamada
Tokyo Japan
:59:/987654321
Hanako Suzuki
Osaka Japan
上記の場合、情報量が限られ、送金理由や住所などの詳細を構造的に表現できません。

また、非構造的な文字列情報が多く、機械処理や自動照合が困難です。
この形式はシンプルで軽量ですが、近年の金融取引が求める詳細な情報表現には対応できませんでした。

 新しいメッセージフォーマット（MX形式／ISO 20022）ISO20022では、XMLを用いた構造化データフォーマット（MX形式） が採用されています。

これはメッセージを「意味を持つ要素」として定義し、機械的な理解・処理を可能にします。
例（pacs.008：銀行間クレジット送金）:
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>ABC123456789</MsgId>
      <CreDtTm>2025-03-09T12:34:56Z</CreDtTm>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId>
        <InstrId>INSTR-001</InstrId>
        <EndToEndId>E2E-001</EndToEndId>
      </PmtId>
      <Amt>
        <InstdAmt Ccy="JPY">1000000</InstdAmt>
      </Amt>
      <Cdtr>
        <Nm>Hanako Suzuki</Nm>
        <PstlAdr>
          <Ctry>JP</Ctry>
          <AdrLine>Osaka Japan</AdrLine>
        </PstlAdr>
      </Cdtr>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>
このように、XMLタグでデータの意味（誰が・誰に・どの通貨で・いくら送金するかなど）を明確に表現できます。

また、XML構造のため項目追加や属性拡張が容易で、将来的な拡張性にも優れています。
メッセージは「ドメイン.メッセージ.バージョン」で識別され、以下のような命名規則が用いられます。

pacs.008.001.08

銀行間クレジット送金（MT103に相当）

pacs.009.001.08

銀行間資金移動（MT202に相当）

camt.053.001.08

口座明細報告（MT940に相当）

pain.001.001.09

顧客→銀行の送金依頼
この命名により、どの業務ドメインに属するメッセージかを一目で識別できます。

 MT形式とMX形式の比較

項目
従来：MT形式
新：MX形式（ISO 20022）


フォーマット
固定長テキスト
XMLベースの構造化データ

データ構造
単層（フィールド番号）
階層構造（要素と属性）

表現力
限定的（文字数制限あり）
豊富（属性や複数言語対応）

機械可読性
低い
高い（タグで意味が明確）

拡張性
低い
高い（新要素追加が容易）

識別方法
MT＋数字
ドメイン.メッセージ.バージョン


 Stellar
 概要Stellarは、国際的な金融取引メッセージの標準規格である「ISO20022」の項目を扱えるようにするエコシステム整備を進めるブロックチェーンプロジェクトです。

この取り組みは、ブロックチェーン技術が持つ「高速・低コスト・透明性」といった利点を、既存の国際金融システムが求める厳格なデータ標準と融合させることを目的としています。

特に、ブロックチェーンソフトウェアサービス企業のBPV社が開発を主導し、Stellarの技術仕様を活用することで、ISO20022が要求する豊富な取引情報を処理できる仕組みを実現しました。

 仕組みStellarのISO20022対応は、**Stellarエコシステム提案（SEP）**と呼ばれる一連の標準化された技術仕様を組み合わせることで実現されています。

開発を主導したBPV社は、特に以下のSEPを活用しました。

送金情報の標準化 (SEP-31)

これは国境を越える決済のためのプロトコルで、送金人、受取人、送金目的といったISO20022が必要とする基本的な取引情報を定義します。

金融機関はこのSEP-31のデータ形式に沿って情報を入力することで、コンプライアンス要件を満たした送金が可能になります。

本人確認情報 (KYC) の標準化 (SEP-9, SEP-12)

金融機関が規制上遵守すべき本人確認（KYC）/顧客確認（KYB）手続きのために、どのような情報をやり取りするかを定めたプロトコルです。

SEP-9でデータ項目（氏名、住所など）を標準化し、SEP-12でその情報を安全に送受信するためのAPI（プログラム間の連携方法）を定義します。
これらのSEPを組み合わせることで、金融機関は「誰が、誰に、いくら、何の目的で」送金したのかというISO20022準拠の詳細なデータを、Stellarの高速なネットワークに乗せて、安全かつ確実に伝達することができるのです。

 仕組みの詳細StellarエコシステムにおけるISO20022準拠の決済は、「アンカー」と呼ばれる金融機関やフィンテック企業が、標準化されたプロトコル（SEP）群を通じて連携することで実現します。

ここでの鍵は、価値の移転（決済）はStellarネットワーク上で行い、それに付随する詳細な情報（ISO20022データ）はAPIを通じてアンカー間で直接交換される点にあります。
以下に、国外の受取人に送金する際の典型的な流れを示します。
情報入力（SEP-31 /info）

送金者（ユーザー）が送金元アンカー（例: A国の銀行）のアプリで送金を開始します。

アプリは受取側アンカーの/infoで必須項目・対応資産を取得し、SEP-31の仕様に基づいて受取人情報、送金目的、金額など（ISO20022のpacs.008の項目に対応づけた情報）を入力します。
本人確認（SEP-12）

規制要件を満たすため、受取側が要求するKYC項目に従い、送金元アンカーが受取側のSEP-12エンドポイントへ送金者のKYC情報を提出します（更新が必要な場合を含みます）。
取引作成と決済の実行（SEP-31 → Stellar Network）

送金元アンカーはSEP-31のPOST /transactionsで取引を作成し、受取側アンカーから入金先アカウントとmemo/memo_type（取引ID）を受領します。

続いてStellarネットワーク上で、価値が担保されたトークン（例: USDCなどのステーブルコイン）を受取側アンカーへ送金します。オンチェーンのトランザクションには受取側が指定したmemoを含めます。
詳細情報の通知／ステータス更新（API）

受取側アンカーは入金検知・KYC審査の進捗に応じて、送金元アンカーのコールバックURLへステータスを通知するか、送金元アンカーがSEP-31のGET /transactionsで照会します。
情報の照会と取得（SEP-31）

受取側アンカーは、オンチェーン決済に紐づく取引ID（memo） をキーとして、SEP-31のエンドポイントで送金詳細を取得・照合します。

これにより、ステップ1で入力されたISO20022の項目に対応づけた送金人・受取人情報を安全に参照できます。
法定通貨での払出

受取側アンカーは、Stellar上で受け取ったトークンとAPIで得た詳細情報を照合し、コンプライアンス上の問題がないことを確認した上で、受取人の銀行口座に現地の法定通貨で資金を払い出します。

 シーケンス図
 ユースケースStellarとISO20022の融合は、主に以下の分野での活用が期待されています。

国際送金の革新

従来の数日かかっていた国際送金が、数秒で完了するようになります。

特に、個人間の少額送金や、これまで多くの仲介銀行を必要としていた新興国への送金などが、劇的に効率化されます。

資産のトークン化

不動産や株式、美術品などの実物資産をデジタル化（トークン化）してStellar上で取引する時に、その資産の属性情報や所有者情報をISO20022の標準形式で記録できます。

これにより、トークン化された資産が既存の金融システムと相互運用性を持ち、グローバルで透明性の高い取引が可能になります。

金融機関のインフラ刷新

国際送金分野でISO20022への移行が進む中、Stellarの導入は規制要件に配慮したメッセージ連携と次世代の決済インフラ整備を同時に進める機会になります。

 Cardano
 概要Cardanoは、その開発組織であるIOG（Input Output Global）が国際的な標準化活動に参画し、金融領域におけるブロックチェーンの標準化と相互運用性の向上に取り組んでいます。

ISO20022は金融メッセージの標準であり、Cardano上で構築されるアプリケーションやゲートウェイがISO20022形式のデータを扱えるようにすることを重視しています。

Cardanoの取り組みは、ネットワーク自体が直接的に準拠するというよりは、Cardano上で構築されるアプリケーションやサービスが、将来的にISO20022の標準に準拠したメタデータ（取引付随情報）を扱えるようにするための、学術的かつ基盤的なアプローチが特徴です。

 仕組みCardanoのISO20022への対応は、主に以下の2つの層で進められています。

標準化団体への参加

開発組織IOGが金融領域タスクフォースに参加し、ISO20022を含む金融標準とブロックチェーン技術をどう連携させるかという「ルール作り」の段階から関与しています。

これにより、Cardanoの思想や技術的優位性を将来の国際標準に反映させることを目指しています。

トランザクションメタデータの活用

Cardanoのトランザクションには概ね約16KBを目安とするメタデータを添付できますが、実際の上限はトランザクション全体のサイズ制約に依存します。

dApps（分散型アプリケーション）開発者はこの機能を活用し、ISO20022のメッセージフォーマット（例: pacs.008など）に準拠した送金情報をJSON形式などでトランザクションに埋め込むことが可能です。これにより、Cardanoの高速な決済ネットワークを使いながら、金融機関が必要とする監査証跡やコンプライアンス情報を保持することができます。
簡単に言えば、Cardanoは「ISO20022という世界標準の荷札（メタデータ）を付けて、商品を運べる高性能な輸送網（ブロックチェーン）」を開発者が構築できる環境を提供している、と考えることができます。

 仕組みの詳細CardanoのISO20022対応は、特定のサービスやネットワークを提供するのではなく、開発者がISO20022準拠のアプリケーションを構築するための、柔軟な「ツールキット」をブロックチェーン自体に組み込むという思想に基づいています。

その中核をなすのが、トランザクションメタデータ機能です。
Cardano上のすべての取引（トランザクション）には、支払い情報（誰から誰へ、いくら）に加えて、構造化されたカスタムデータ（メタデータ）を直接添付できます。

Cardanoのメタデータは、ISO20022の項目にマッピングした構造化データとして設計できます。

機微なコンプライアンス情報はオフチェーンに保持し、オンチェーンにはその参照（DIDやハッシュ等） を紐づける形で記録します。
以下に、Cardano上でISO20022準拠の送金を行うアプリケーションの典型的な流れを示します。
メタデータの生成

送金者（ユーザー）がdApp（分散型アプリケーション）やウォレットで送金を開始します。

アプリケーションは、ISO20022のメッセージ（例: pacs.008）で要求される送金人情報、受取人情報、送金目的などをJSON形式のデータとして生成します。
本人確認情報の連携 (Atala PRISM)

必要に応じて、アプリケーションはCardanoの分散型IDソリューション「Atala PRISM」と連携します。

KYC/AML情報はAtala PRISMのDID/VC（検証可能な資格情報）としてオフチェーンで管理し、トランザクションにはその参照（DIDや証明のハッシュ）を紐づけてプライバシーを保ちます。
トランザクションの構築

ウォレットは、①送金内容、②ISO20022の項目にマッピングしたメタデータ、③本人確認情報の参照（DID/ハッシュ等）を含むトランザクションを構築します。
ブロックチェーンへの記録

ユーザーがトランザクションに署名すると、それはCardanoブロックチェーンに送信され、不変の記録として台帳に刻まれます。

支払い情報に参照子（DID/ハッシュ等）を併記して記録します。

詳細な本人確認情報自体はオフチェーンに留め、オンチェーンと連携させます。
情報の検証と処理

着金側（金融機関や取引所など）のアプリケーションは、ブロックチェーンを監視しています。

着金トランザクションを検知すると、その取引に添付されているメタデータを読み取ります。
コンプライアンスと記帳

着金側は、メタデータの内容がISO20022の標準に準拠しており、規制上の要件を満たしていることを検証します。

問題がなければ、受取人の勘定に資金を記帳し、内部の記録を更新します。

 シーケンス図この一連の流れは、送金と参照情報をオンチェーンで扱い、詳細なコンプライアンスデータはオフチェーンで管理する構成が特徴です。

 ユースケースCardanoとISO20022の融合により、以下のような活用が期待されています。

DeFi（分散型金融）と伝統金融の融合

Cardano上で展開されるDeFiプロトコルが、ISO20022準拠のデータを扱うことで規制下にある金融機関がDeFiサービスをより利用しやすくなります。

例えば、KYC/AML（本人確認/マネーロンダリング対策）情報をメタデータに含めることで、コンプライアンスを遵守した形でのステーブルコイン決済やデジタル資産取引が可能になります。

サプライチェーン・ファイナンス

商品の生産から流通までの各段階の情報をCardano上に記録し、支払いトランザクションにISO20022準拠の請求書データを添付することで、貿易金融の透明性と効率性を大幅に向上させることができます。

リアルワールドアセット（RWA）のトークン化

不動産や証券などの現実世界の資産をトークン化する際に、その資産の属性や所有者情報をISO20022標準で記録します。

これにより、規制に準拠した形でのグローバルな資産取引と決済がシームレスに行えるようになります。

 IOTA
 概要IOTAは、その開発を主導するIOTA財団が国際的な標準化団体Object Management Group (OMG)に貢献メンバーとして参加し、ISO 20022を含む金融メッセージ標準との連携を視野に入れた取り組みに参画しています。

IOTAの取り組みは、Cardanoと同様に、金融サービスにおける分散型台帳技術（DLT）の標準化を目指すOMGのFinance Domain Task Force（金融領域タスクフォース）での活動が中心です。

IOTAの最大の特徴である、IoT（モノのインターネット）デバイス間のデータと価値の交換に特化した独自技術「Tangle」を、将来的に金融メッセージ標準（ISO 20022を含む）と結びつける方向で検討を進めています。

 仕組みIOTAのISO20022への対応は、直接的なプロトコル実装というよりは、その基盤技術を標準に適合させるための活動が中心です。

標準化プロセスへの貢献

IOTA財団は、OMGのタスクフォースにおいて、DLTを既存の金融標準（ISO20022を含む）と統合するための仕様策定に積極的に関与しています。

これにより、将来の金融標準がIOTAの持つ手数料無料やスケーラビリティといった利点を活用できるようなルール作りを目指しています。

データストリームの活用 (IOTA Streams)

IOTAには「IOTA Streams」という、暗号化されたデータストリームをTangle上で安全に送受信する機能があります。

IOTA Streamsは暗号化されたデータストリームを安全に共有できる仕組みであり、必要に応じてISO 20022のメッセージをオフチェーンで運搬・連携する用途にも活用できます。

デジタルアイデンティティの統合

IOTAが開発する自己主権型アイデンティティ（SSI）の仕組みは、ISO20022が要求する「取引当事者の明確化」に貢献します。

人だけでなく、IoTデバイスや組織にもユニークなデジタルIDを付与することで、誰が（どの機械が）取引を行ったのかを確実に証明できます。

 仕組みの詳細IOTAのISO20022対応は、その独自技術であるTangleが持つ「データと価値を同一基盤で連携して扱える能力」を最大限に活用する形で構想されています。

特に、プライバシーとセキュリティを重視したデータ通信レイヤーであるIOTA Streamsが中核的な役割を担います。
Cardanoが取引自体にメタデータを添付するのに対し、IOTAはより柔軟なアプローチを取ります。

機密性の高いISO20022メッセージは当事者間でのみ閲覧可能な暗号化されたチャネルで交換し、実際の決済はTangle上の別のトランザクションとして実行し、両者を紐づけます。
以下に、IOTA Streamsを活用したISO20022準拠の決済フローの典型例を示します。
暗号化チャネルの確立

送金者と受取人は、事前にIOTA Streamsを用いて、両者だけがアクセスできる暗号化されたデータチャネルをTangle上に確立します。
ISO20022メッセージの送信

送金者は、ISO 20022の項目に沿って（マッピングして）構造化した金融メッセージを生成し、このStreamsチャネルに書き込みます（Publish）。

これはTangle上ではデータメッセージ（ゼロバリュー）として記録されます。
メッセージの受信と合意

受取人は、Streamsチャネルを購読（Subscribe）しており、暗号化されたメッセージを安全に受信・復号します。内容を確認し、取引に合意します。
決済の実行

合意に基づき、送金者は実際の資金（IOTAトークンなど）を「価値トランザクション」としてTangle上で受取人に送金します。

このトランザクションには、ステップ2で送信したデータメッセージを特定するための参照情報（メッセージID／ハッシュ等） を含めることができます。

これにより、決済とその目的（詳細情報）が改ざん不可能な形で紐づけられます。
取引の完了

受取人は、Tangle上で資金の着金を確認します。

同時に、トランザクションに紐づけられた参照情報を元に、Streamsで受信したメッセージが正しいものであることを最終確認し、取引を完了させます。

 シーケンス図このプロセスは、機密情報の交換と実際の価値移転を分離しつつ、両者を安全に連携させる点が特徴です。

 ユースケースIOTAの技術とISO20022の標準が結びつくことで、従来の金融の枠を超えた新しい応用が期待されています。

IoT（モノのインターネット）経済

IOTAの最も象徴的なユースケースです。

例えば、電気自動車が充電スタンドで自ら充電量を認識し、その場でISO 20022の項目に沿ったデータとともに自動で支払いを行う、といった実装が想定できます。

工場内の機械が、必要な部品を自律的に発注・決済することも考えられます。

スマートシティ

都市のインフラ（交通、電力網、公共サービスなど）に組み込まれた無数のセンサーやデバイスが、リアルタイムでデータを交換しながら、サービス利用料などを手数料無料で自動決済する基盤として活用できます。

サプライチェーンと貿易金融

商品のコンテナに付けられたセンサーが、位置情報や温度データをTangle上に記録し、特定の地点（港など）を通過したことをトリガーに、ISO20022形式の支払いメッセージが自動で実行される、といった高度な自動化が実現します。

 Ripple
 概要Ripple社は、自社が提供する国際送金ネットワーク「RippleNet」において、ISO 20022に整合したメッセージング（標準スキーマと運用）を採用しています。

Ripple社は、DLTにフォーカスした企業としては初めて、ISO 20022の標準化団体Registration Management Group（RMG）のメンバーとなりました

他のプロジェクトが標準化団体への参加や将来的な対応を目指す中で、Rippleはすでに自社の商用サービスにISO20022を深く統合し、世界中の金融機関に提供している点が最大の特徴です。

 仕組みRippleのISO20022対応は、RippleNetというネットワークサービスを通じて実現されています。
標準化されたメッセージング層

RippleNetに参加する金融機関は、APIを通じて自社のシステムを接続します。

送金を行う時、RippleNetが提供するメッセージング層では、ISO 20022のpacs.008に整合したJSONスキーマ（Standard RippleNet Payment Object, SRPO）に基づきデータが生成・交換されます。

これにより、送金に関わる詳細な情報（送金人、受取人、目的、コンプライアンス情報など）が、参加機関の間で標準化された形で正確に伝達されます。
決済層との分離と連携

ISO20022はあくまで「メッセージ（情報）」の標準です。

RippleNetは、この情報伝達層と、実際の「価値（お金）」を動かす決済層を連携させています。
ODL (On-Demand Liquidity) とXRPの活用

決済層では、ODL（オンデマンド流動性）というサービスが提供されます。

これは、暗号資産であるXRPを「ブリッジ通貨」として用いる選択可能な決済手段です。

例えば、米ドルから日本円へ送金する場合、RippleNetは瞬時に米ドルをXRPに変換し、XRP Ledger上で日本へ送り、着金側で日本円に変換します。

この一連のプロセスが数秒で完了し、その時の取引情報としてISO20022準拠のデータが紐づけられます。

これにより、金融機関は送金のために海外の銀行に多額の資金（ノストロ口座）を置いておく必要がなくなります。

一方で、RippleNetは法定通貨同士の送金にも対応します。

 仕組みの詳細RippleのISO20022対応は、**メッセージング層（情報伝達）と決済層（価値移転）**を明確に分離しつつ、両者を自社のネットワーク「RippleNet」上でシームレスに統合している点に最大の特徴があります。これにより、金融機関は既存のシステムと連携しながら、次世代の国際決済インフラを利用できます。
その中核をなすのが、暗号資産XRPをブリッジ通貨として利用する「Ripple Payments」（旧称: ODL - On-Demand Liquidity）で、現在はこのフラッグシップ決済ソリューションとして提供されています。
以下に、Ripple Paymentsを利用した国際送金の典型的な流れを示します。
支払い指示 (ISO 20022)

送金元金融機関は、RippleNetのAPIを通じてISO 20022（pacs.008）に整合したSRPOで支払い指示データを送信します。

このメッセージには、送金人・受取人情報、コンプライアンス情報などが全て含まれています。
最適な決済経路の決定

RippleNetは、この指示を受け取り、最も効率的な決済経路を自動的に決定します。

Ripple Paymentsを利用する場合、以下のプロセスが開始されます。
法定通貨からXRPへの変換

RippleNetは、送金元国（A国）の提携流動性プロバイダー（取引所など）に対し、送金元の法定通貨（例: 米ドル）をXRPに変換するよう指示します。
XRPの移転 (XRP Ledger)

変換されたXRPは、数秒でXRP Ledgerを通じて、送金先国（B国）の提携流動性プロバイダーのウォレットへ送られます。

このXRP Ledger上での取引は、極めて高速かつ低コストで完了します。
XRPから法定通貨への変換

XRPを受け取ったB国の流動性プロバイダーは、即座にそれを現地の法定通貨（例: 日本円）に変換します。
着金処理

変換された法定通貨が、受取人金融機関（B国の銀行）の口座に入金され、最終的な受取人に支払われます。
取引完了通知

この一連の決済プロセスが完了すると、その結果がRippleNetのメッセージング層でISO 20022整合スキーマ（SRPO等） に沿って関係機関へ通知されます。
この仕組みにより、金融機関は国際送金のために海外の銀行に資金（ノストロ口座）を事前に預けておく必要がなくなり、数秒で、かつ低いコストで国境を越える決済を完了できます。

 シーケンス図
 ユースケースRippleNetの導入により、具体的で実践的なメリットが生まれています。

国際送金の劇的な高速化と低コスト化

これまで数日かかり手数料も不透明だった国際送金が、数秒で完了してコストも大幅に削減されます。

これは、個人間の送金だけでなく、企業間の貿易決済などあらゆる国際金融取引に適用されます。

流動性管理の効率化

金融機関は、世界中の通貨に対応するために維持していたノストロ口座の資金を解放し、その資本を他の事業に有効活用できます。

これは銀行の収益性に直接的なインパクトを与えます。

新興国市場へのアクセス向上

銀行インフラが未発達で、これまで送金が困難だった「エキゾチックな通貨回廊」においても、低コストで迅速な送金サービスを提供できるようになります。

これにより、金融包摂の促進にも貢献します。

 Algorand
 概要Algorandは、その高速性、即時ファイナリティ、そしてカーボンネガティブという特徴を活かし、次世代の金融インフラとしてISO20022標準との連携を目指すブロックチェーンプロジェクトです。

Algorandの取り組みは、特定のサービスを提供するというよりは、金融機関やフィンテック企業がAlgorandのブロックチェーン上でISO20022に準拠した金融アプリケーションを効率的に構築できる、高性能で環境に配慮した基盤を提供することに重点を置いています。

特に、中央銀行デジタル通貨（CBDC）や資産のトークン化といった分野で、その技術的優位性をアピールしています。

 仕組みAlgorandのISO20022対応は、ブロックチェーンのコア機能に組み込まれたツール群を活用することで実現されます。

トランザクションノート (Transaction Note)

Algorandの全てのトランザクションには、「ノート」と呼ばれる最大1KBの任意のデータを添付できるフィールドがあります。

開発者はこのノートフィールドを利用して、ISO 20022の項目にマッピングしたJSONデータを格納できます。

ノートは最大約1KBのため、必要に応じて主要項目のみを記録し、詳細はオフチェーンの安全なストアへの参照（URL/ハッシュ/DID等）で連携します。

Algorand標準資産 (ASA - Algorand Standard Assets)

ステーブルコイン、証券、不動産といった様々な資産を、ブロックチェーンの第一層（レイヤー1）で簡単かつ安全にトークン化できる標準機能です。

ASAで表現した資産とISO 20022メッセージの項目を対応付けて運用しやすく、オンチェーンの資産移転とオフチェーン/メッセージ層のデータ連携を設計できます。

スマートコントラクト (ASC1)

Algorandのスマートコントラクトを利用して、KYC/AMLやその他規制要件を自動で実行するロジックを組むことができます。

例えば、「特定の認可を受けた参加者しか取引できない」といったルールを強制することが可能です。

 仕組みの詳細AlgorandにおけるISO20022準拠の決済フローは、Cardanoと同様に、トランザクションとそれに付随する情報がブロックチェーン上で一体として扱われるモデルです。
ノートの生成

送金者がウォレットやdApp（分散型アプリケーション）を通じて送金操作を行うとき、アプリケーションはISO20022のpacs.008などに相当する詳細な取引情報を生成し、これを「ノート」フィールドに書き込む準備をします。
アセットの指定

送金する資産（ネイティブ通貨のALGO、またはASAとして発行されたステーブルコインなど）を指定します。
トランザクションの構築と送信

送金情報（誰から誰へ、何を）、ノートフィールドに埋め込まれたISO 20022項目にマッピングしたメタデータ、そして手数料を含むトランザクションが構築され、ユーザーの署名を経てAlgorandネットワークに送信されます。
ブロックチェーンへの記録とファイナリティ

トランザクションは約3.3秒でブロックに取り込まれ、その瞬間にファイナリティに達します。

これにより、送金データとその参照（ノート中の要約/ハッシュ/URL等）が改ざん困難な形で同時に確定します。

詳細なコンプライアンス情報はオフチェーンで管理します。
受信側での処理

受信側（金融機関など）のシステムは、Algorandネットワークを監視しており、自社に関連するトランザクションを検知します。

トランザクションに添付された「ノート」を読み取り、内容をISO 20022の項目にマッピングして解釈し、コンプライアンスや内部記帳に反映します。

 シーケンス図
 ユースケースAlgorandの技術特性は、特に信頼性と環境配慮が求められる分野での活用を可能にします。

中央銀行デジタル通貨 (CBDC)

Algorandは既にマーシャル諸島などでCBDCの実証実験に関わっています。

国家レベルの決済インフラとして、ISO20022に準拠したデータ連携は不可欠であり、Algorandの即時ファイナリティと高いセキュリティがその基盤となります。

グリーンファイナンスとサステナブル金融

カーボンネガティブという特徴を活かし、グリーンボンド（環境債）の発行・流通や、炭素クレジットの取引など、ESG投資に関連する金融商品のプラットフォームとしての活用が期待されます。

規制に準拠した資産のトークン化

金融機関がコンプライアンスを遵守しながら、不動産、プライベートエクイティ、証券といったリアルワールドアセット（RWA）をトークン化し、グローバルな投資家に提供するためのインフラとして利用されます。

 XDC Network
 概要XDC Networkは、国際貿易と金融（Trade Finance）の分野に特化した、企業利用を想定したハイブリッド・ブロックチェーンです。

ISO20022への取り組みにおいては、自らがメッセージングシステムになるのではなく、ISO20022に整合した金融メッセージを受け取り、その指示に基づいて価値の移転（決済）を実行する、高速かつ効率的な「決済レイヤー」としての役割を目指しています。

この戦略を実現するため、XDCエコシステム内のImpel社などが、既存の金融メッセージングシステム（SWIFTなど）とXDC Networkを繋ぐブリッジとなるサービスを開発・提供しています。

 仕組みXDC Networkは、ISO20022を「実行すべき指示書」として扱います。

金融機関が作成したISO20022メッセージを、XDC Network上で実行可能なトランザクションに変換する「ブリッジ」を介して連携します。

メッセージングレイヤーと決済レイヤーの分離

金融機関は、既存のシステムやSWIFTを通じてISO20022フォーマットのメッセージを送信します。

ブリッジの役割 (Impel)

XDCエコシステム企業であるImpel社などが提供するプラットフォームが、このメッセージを受信します。

プラットフォームはメッセージを解析し、その内容（誰から誰へ、どの資産を、いくら）を理解します。

決済の実行

ブリッジは、解析した指示に基づき、XDC Network上でトランザクションを生成・実行します。

これは、XDCトークンや、ネットワーク上で発行されたステーブルコイン、トークン化された貿易資産などの価値移転を伴います。

結果の通知

決済が完了すると、その結果（成功、失敗など）が、再びISO20022フォーマットのメッセージ（例: pacs.002）として生成され、関係する金融機関に通知されます。

 仕組みの詳細この仕組みは、既存の金融インフラと次世代の決済インフラを、APIを介して安全に繋ぐことで実現されます。
メッセージの生成と送信

送金元金融機関が、自社のシステムでISO20022 pacs.008（支払い指示）メッセージを生成し、ImpelのようなプラットフォームにAPI経由で送信します。
メッセージの解析と決済準備

Impelプラットフォームはメッセージを受信し、その正当性を検証します。

その後、メッセージの内容を解析し、XDC Network上で実行すべきトランザクションの内容（送金元アドレス、送金先アドレス、アセットの種類、数量など）を特定します。
アトミックスワップまたは価値移転の実行

特定された内容に基づき、ImpelはXDC Network上でトランザクションを実行します。

現状は主に単一資産（XDCまたはトークン化資産）の移転が中心ですが、将来的にはアトミックスワップなどの複合取引にも対応が予定されています。

トランザクションのメモ欄には、元のISO20022メッセージを識別できるハッシュ参照が記録されます。
決済の確定とファイナリティ

トランザクションは約2秒でXDC Network上で確定し、ファイナリティに達します。
完了通知の生成と送信

Impelは、XDC Network上での決済完了を確認すると、**ISO 20022構造に整合した pacs.002 互換メッセージ（XMLまたはJSON形式）を生成して送金元金融機関に送信します。

これにより、送金元は内部台帳を更新し、決済完了を正式に確認できます。

 シーケンス図
 ユースケースXDC Networkの特性は、特にB2B（企業間）の金融取引において大きな価値を発揮します。

貿易金融の革新

船荷証券や請求書などの貿易書類をNFTとしてトークン化し、その所有権移転と支払い（決済）を同時に、かつプログラム可能に行うことができます。

これにより、従来数週間かかっていた決済サイクルを数秒に短縮し、企業のキャッシュフローを大幅に改善します。

クロスボーダー決済

既存のコルレス銀行網を介さず、XDC Networkを決済レールとして利用することで、国際送金を高速かつ低コストで実現します。

特に、企業間の高額な決済に適しています。

サプライチェーン・ファイナンス

商品の物理的な流れと、それに伴う金融の流れを一つの台帳上で連携させ、透明性の高いサプライチェーン・ファイナンスを実現します。

例えば、商品が特定の地点に到着したことをトリガーに、自動で支払いが行われるといった仕組みを構築できます。

 Chainlink
 概要Chainlinkは、ブロックチェーンではなく、現実世界（オフチェーン）のデータやシステムと、ブロックチェーン（オンチェーン）のスマートコントラクトを安全に繋ぐ「分散型オラクルネットワーク」です。

ChainlinkのISO20022への取り組みは、決済を自ら実行するのではなく、既存の金融メッセージング標準（ISO20022など）に整合した形式でSWIFTネットワークと複数のブロックチェーンを接続する「通訳」および「ブリッジ」としての役割を担うものです。

この取り組みはすでにSWIFTとの技術実証（PoC）として進行しており、将来的に金融機関が既存インフラを維持したまま、ブロックチェーン上のトークン化資産にアクセスできる環境を目指しています。

 仕組みChainlinkは、SWIFTネットワークとブロックチェーンの間に立ち、両者が互いの言語を理解できるように翻訳する役割を果たします。

メッセージの受信

金融機関がSWIFTネットワークを通じて、ブロックチェーン上での操作を指示するメッセージを送信します。

メッセージの翻訳と転送 (CCIP)

ChainlinkのCCIPがこのメッセージを受け取ります。

メッセージを解析し、ターゲットとなるブロックチェーン（例: Ethereum）上のスマートコントラクトが理解できる形式のトランザクション命令に変換します。

ブロックチェーン上での実行

変換された命令がターゲットのブロックチェーンに送られ、スマートコントラクトが起動されます。これにより、トークンの移転やスワップなどの金融取引が実行されます。

実行結果の監視と報告

Chainlinkのオラクルネットワークは、ブロックチェーン上での取引が確実に実行され、完了（ファイナリティ）したことを監視します。

結果の逆翻訳と通知

取引が完了すると、Chainlinkは結果（成功、失敗、取引IDなど）をSWIFTが理解できるISO 20022整合フォーマットのメッセージに変換し、SWIFTネットワークを通じて金融機関に報告します。

 仕組みの詳細このプロセスは、金融機関が既存のインフラを一切変更することなく、パブリックおよびプライベートブロックチェーンの双方にアクセスできる点が画期的です。
支払い指示の送信

金融機関Aが、自社のSWIFT端末から「金融機関Bに対し、イーサリアムネットワーク上のステーブルコイン100万USDCを送金せよ」という内容のISO20022準拠メッセージを送信します。
CCIPによるメッセージの受信とルーティング

このメッセージはSWIFTネットワークを介して、Chainlink CCIPに接続されたエンドポイントに到達します。

CCIPの「ルーター」がメッセージを解析し、送信元（SWIFT）、送信先チェーン（イーサリアム）、実行すべきアクション（トークン転送）を特定します。
オンチェーンでのアクション実行

CCIPは、分散型オラクルネットワーク（DON）を利用して、Ethereum上の適切なスマートコントラクト（例: トークン転送コントラクト）を呼び出すトランザクションを安全に生成・実行します。
実行の監視とファイナリティ確認

Chainlink DONは、このトランザクションがEthereum上で承認され、覆ることがない状態（ファイナリティ）になるまで監視を続けます。
完了報告

ファイナリティが確認されると、CCIPは「取引成功、トランザクションハッシュは0x...」といった内容を含むISO20022準拠の完了報告メッセージを生成し、SWIFTネットワークを通じて金融機関Aに送り返します。

 シーケンス図
 ユースケースChainlinkとSWIFTの連携は、伝統的金融（TradFi）とブロックチェーン経済圏の間に巨大な橋を架けることを意味します。

トークン化資産のグローバル決済

金融機関が、SWIFTという単一のネットワークを通じて、世界中の異なるブロックチェーン上で発行された証券トークン、不動産トークン、プライベートエクイティなどを売買・決済できるようになります。

TradFiからDeFiへのアクセス

銀行が、既存のインフラから直接、AaveやCompoundといったDeFiプロトコルに資金を供給して金利を得たり、MakerDAOでステーブルコインを発行したりすることが可能になります。

金融機関のDX（デジタルトランスフォーメーション）促進

金融機関は、ブロックチェーンごとに個別のインフラを構築するという莫大なコストと複雑性を回避できます。SWIFTへの接続を維持するだけで、Web3の世界が提供するイノベーションの恩恵を受けることができます。

 実装案前章までで、ブロックチェーン上でのISO20022の取り組みについてまとめてきました。

この章では、EVM互換ブロックチェーン上でSolidityで書かれたSmartContractを使用したISO20022の実装案についてまとめていきます。
pacs.008とpacs.002
 pacs.008pacs.008 は、銀行（または決済事業者）が別の銀行に対して「顧客送金を実行してください」と依頼する送金指示メッセージです。

旧SWIFT MT103に相当し、顧客の送金データを銀行間で転送する目的で使われます。
https://www.smbctb.co.jp/service/pdf/iso20022_ja.pdf
特徴
送金元銀行 (送信者) → 送金先銀行 (受信者) に送られる。
実際の送金（Credit Transfer）を行うための必須情報を持つ。
顧客・受取人・金額・通貨・目的などの詳細を XML 構造で表す。
主な構成


セクション
内容


<GrpHdr>
メッセージ全体の識別情報。MsgId（一意のメッセージID）、作成日時など。

<CdtTrfTxInf>
送金取引の詳細。複数含まれる場合もある。

<PmtId>
取引識別子群。InstrId（銀行内部ID）、EndToEndId（顧客側トレーサID）。

<Amt>
金額と通貨（例：<InstdAmt Ccy="JPY">1000000</InstdAmt>）。


<Dbtr> / <Cdtr>

送金人（Debtor）と受取人（Creditor）の情報。

<RmtInf>
支払理由や請求番号などの自由記述情報。


 pacs.002pacs.002 は、受信した pacs.008 などの支払メッセージに対する処理結果の報告を行うメッセージです。

旧SWIFT MT199／MT900 系の役割に相当し、取引が受理されたか・拒否されたかを返します。
特徴
受取銀行 (または処理システム) → 送信銀行 に返される。
「支払指示を受け取った」、「決済が完了した」、「拒否された」などのステータスを伝える。
取引単位・メッセージ単位の両方で結果を記述できる。
主な構成


セクション
内容


<GrpHdr>
レポート全体の識別情報（MsgId、作成日時など）。

<OrgnlGrpInfAndSts>
元のメッセージ（例：pacs.008）の MsgId を参照。

<TxInfAndSts>
各取引のステータス詳細。OrgnlInstrId、OrgnlEndToEndId、TxSts、StsRsnInf (理由) など。

<TxSts>
ステータスコード。代表例：ACTC (受理済)、RJCT (拒否)、ACSP (処理中)。


 pacs.008 と pacs.002 の関係

観点
pacs.008
pacs.002


メッセージ種別
支払指示（リクエスト）
支払結果報告（レスポンス）

主な方向
送金元銀行 → 送金先銀行
送金先銀行 → 送金元銀行

主な用途
送金命令、顧客決済の実行
指示の受理／拒否、決済結果の報告

ISO20022の位置づけ
Payment Initiation
Payment Status

ブロックチェーン対応箇所

registerPayment() に入力される

PaymentSettled イベントをもとに生成される


 オンチェーンオンチェーンでは、Solidityで書かれたスマートコントラクトを実装します。

以下は、ISO20022の pacs.008（銀行間クレジット送金）に対応した最小限の実装です。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IERC20 {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
}

contract ISO20022Settlement {
    struct Payment {
        string msgId;           // ISO20022: GrpHdr.MsgId
        string instrId;         // PmtId.InstrId
        string endToEndId;      // PmtId.EndToEndId
        address debtor;         // 送金者
        address creditor;       // 受取人
        address asset;          // ERC20アドレス
        uint256 amount;         // InstdAmt
        bytes32 messageHash;    // ISO20022 XMLのハッシュ
        uint256 timestamp;
        bool settled;
    }

    mapping(string => Payment) public payments;

    event PaymentRegistered(string msgId, address debtor, address creditor, uint256 amount, address asset);
    event PaymentSettled(string msgId, bool success);

    // pacs.008登録
    function registerPayment(
        string memory msgId,
        string memory instrId,
        string memory endToEndId,
        address debtor,
        address creditor,
        address asset,
        uint256 amount,
        bytes32 messageHash
    ) external {
        require(payments[msgId].timestamp == 0, "Duplicate MsgId");

        payments[msgId] = Payment({
            msgId: msgId,
            instrId: instrId,
            endToEndId: endToEndId,
            debtor: debtor,
            creditor: creditor,
            asset: asset,
            amount: amount,
            messageHash: messageHash,
            timestamp: block.timestamp,
            settled: false
        });

        emit PaymentRegistered(msgId, debtor, creditor, amount, asset);
    }

    // pacs.002相当：決済実行
    function settlePayment(string calldata msgId) external {
        Payment storage p = payments[msgId];
        require(!p.settled, "Already settled");
        require(p.amount > 0, "Invalid payment");

        IERC20 token = IERC20(p.asset);
        bool success = token.transferFrom(p.debtor, p.creditor, p.amount);
        require(success, "Transfer failed");

        p.settled = true;
        emit PaymentSettled(msgId, true);
    }
}
この Solidity コントラクトは、ISO 20022の pacs.008（支払指示） をブロックチェーン上に登録し、settlePayment で実際の送金（ERC20トークン送付）を行うシンプルな実装です。
このコントラクトでは、外部のオフチェーンシステム（例：ISO 20022 ゲートウェイ）がこのコントラクトを呼び出して、支払指示データを登録して決済を実行します。

決済通貨は ERC20トークン（ステーブルコインなど）を想定しています。

 Payment
struct Payment {
    string instrId;      // 支払指示ID
    string endToEndId;   // トレーサID
    address debtor;      // 送金者
    address creditor;    // 受取人
    address asset;       // ERC20トークンのコントラクトアドレス
    uint256 amount;      // 送金額
    bytes32 messageHash; // 元XMLのSHA-256などのハッシュ
    uint256 timestamp;   // 登録時刻
    bool settled;        // 決済完了フラグ
}

// ISO20022: GrpHdr.MsgId => Payment
mapping(string => Payment) public payments;
msgId （ISO 20022のメッセージ識別子）をキーに Payment 構造体を保存します。
instrId と endToEndId は、以下のISO 20022 の pacs.008（FIToFICustomerCreditTransfer） メッセージの「支払指示ID（Instruction ID）」と「トレーサID（End-to-End ID）」に対応しています。
https://www.smbctb.co.jp/service/pdf/iso20022_ja.pdf
pacs.008 の主要部分にある支払識別子 (PmtId) は、以下の3つの要素から構成されます。


要素名
日本語名称
説明



InstrId (Instruction Identification)
支払指示ID
送金を実行する金融機関（送信者）がその取引を一意に識別するためのID。
銀行や決済システム内での管理に使われる「内部的な処理ID」。


EndToEndId (End-to-End Identification)
トレーサID
取引の発端（顧客・企業など）から最終受取まで、エンドツーエンドで取引を識別するID。
複数の金融機関を経由しても同じIDが引き継がれるため、「顧客が指定するトランザクション番号」のようなもの。


TxId (Transaction Identification)
トランザクションID
中継銀行など、個々の金融機関が独自に付与するID。pacs.008 では省略可能な場合があります。

<PmtId>
  <InstrId>INSTR-001</InstrId>      <!-- 支払指示ID -->
  <EndToEndId>E2E-001</EndToEndId>  <!-- トレーサID -->
  <TxId>TX-001</TxId>               <!-- トランザクションID（任意） -->
</PmtId>
Payment 構造体ではこの情報を管理しています。


Solidity構造体の項目
ISO20022項目
説明


instrId
<InstrId>
銀行（ゲートウェイ）がブロックチェーン上で支払いを登録するときに生成する内部的な識別子。オンチェーンでの「支払処理1件」を一意に特定します。

endToEndId
<EndToEndId>
顧客または送金依頼者が発行するトレーサID。この値は銀行・ブリッジ・ブロックチェーン間で引き継がれ、最終的な pacs.002（決済結果通知）にも含まれます。

msgId
<GrpHdr><MsgId>

pacs.008 メッセージ全体の識別子。複数トランザクションを含む場合の「メッセージ単位のID」。

つまりこの3つは階層的に以下のようになります。
GrpHdr.MsgId     → メッセージ全体（ファイル単位）のID
  └─ CdtTrfTxInf.PmtId.InstrId     → 銀行の支払指示ごとのID
  └─ CdtTrfTxInf.PmtId.EndToEndId  → 顧客トレーサID（送金全体の追跡）
実運用では以下のような使い分けになります。


区分
付与主体
使われる範囲
Solidity構造体内


MsgId
金融機関（送信側）
pacs.008 メッセージ全体
msgId

InstrId
金融機関（送信側）
送信銀行内部、または各支払ごと
instrId

EndToEndId
企業または顧客
顧客から受取まで一貫して引き継がれる
endToEndId

!
InstrId は 金融機関が管理する取引単位（銀行内の技術的識別子）。

EndToEndId は 顧客が管理する取引単位（請求書番号や発注番号など）。
これを分離しておくことで、金融機関内部では同じ顧客取引でも複数の指示を別管理でき、顧客側では「自分の注文番号でトレース」できるようになります。
この構造をブロックチェーン上に持ち込むと、オンチェーンでは InstrId を内部キーとして処理し、EndToEndId を監査や pacs.002 返却のために外部照合用キーとして扱うのが一般的です。

 PaymentRegistered
event PaymentRegistered(
    string msgId,
    address debtor,
    address creditor,
    uint256 amount,
    address asset
);
新しい支払指示（pacs.008）がオンチェーンに登録されたことをイベントに記録します。

オフチェーンシステム（ゲートウェイや金融機関側システム）はこのイベントを監視して、「新しい支払要求がブロックチェーンに記録された」ことを検知し、msgId をキーに「支払受付」をトリガにできる。


引数
内容


msgId

pacs.008 メッセージ全体の識別子。どの支払取引に対応するかを特定するキー。

debtor
送金者（トークンを送る側のアドレス）。

creditor
受取人（トークンを受け取る側のアドレス）。

amount
送金額。ERC20トークンの単位で指定される。

asset
送金に使うトークンのコントラクトアドレス（例：USDC, JPYCなど）。


 PaymentSettled
event PaymentSettled(string msgId, bool success);
支払処理（pacs.008 に基づく送金）が完了したこと、または失敗したことを通知します。

これは ISO 20022の pacs.002（支払ステータス報告）に対応します。


引数
内容


msgId
対応する支払メッセージの識別子。

success
決済が成功したかどうかを示す。trueなら送金成功、falseなら失敗。

オフチェーンの決済ゲートウェイはこのイベントを監視して、成功時に pacs.002（ACTC: 承認済み）を生成し、失敗時に pacs.002（RJCT: 拒否）を生成して送信元へ返します。

 registerPayment
function registerPayment(
    string memory msgId,
    string memory instrId,
    string memory endToEndId,
    address debtor,
    address creditor,
    address asset,
    uint256 amount,
    bytes32 messageHash
) external {
    require(payments[msgId].timestamp == 0, "Duplicate MsgId");

    payments[msgId] = Payment({
        msgId: msgId,
        instrId: instrId,
        endToEndId: endToEndId,
        debtor: debtor,
        creditor: creditor,
        asset: asset,
        amount: amount,
        messageHash: messageHash,
        timestamp: block.timestamp,
        settled: false
    });

    emit PaymentRegistered(msgId, debtor, creditor, amount, asset);
}


引数名
意味


msgId
ISO20022の <GrpHdr><MsgId> に対応。メッセージ全体の一意識別子。payments のキーとしても利用。

instrId

<PmtId><InstrId> に対応。銀行やシステム内部の支払指示ID。

endToEndId

<PmtId><EndToEndId> に対応。顧客・企業が取引を追跡するためのトレーサID。

debtor
支払元のウォレットアドレス（送金者）。ERC20トークンを支払う側。

creditor
支払先のウォレットアドレス（受取人）。トークンを受け取る側。

asset
使用するトークンのコントラクトアドレス（例：USDC、JPYCなど）。

amount
送金額。asset トークンの単位に基づく整数値。

messageHash
オフチェーンで保持しているISO20022 XML（pacs.008）のSHA-256等ハッシュ値。改ざん検知用。


msgId をキーに既存登録がないかチェック。

すでに同じ msgId が登録されていれば二重登録として revert。

Payment 構造体を新規作成し、現在の block.timestamp を登録時刻として記録。

payments[msgId] に保存。

PaymentRegistered イベントを発行。

イベントには主な支払情報（msgId、送金元、受取人、金額、資産）を含め、オフチェーン監視システムがこれを契機に「支払受付済み」として扱う。

 settlePayment
function settlePayment(string calldata msgId) external {
    Payment storage p = payments[msgId];
    require(!p.settled, "Already settled");
    require(p.amount > 0, "Invalid payment");

    IERC20 token = IERC20(p.asset);
    bool success = token.transferFrom(p.debtor, p.creditor, p.amount);
    require(success, "Transfer failed");

    p.settled = true;
    emit PaymentSettled(msgId, true);
}


引数名
意味


msgId

registerPayment() で登録された取引を一意に特定するID。payments のキー。


payments[msgId] から支払情報を取得。登録済みかつ未決済であることを確認。

!p.settled

すでに決済済みなら拒否。

p.amount > 0

金額が無効（0や未登録）なら拒否。


IERC20(p.asset) でトークンコントラクトを指定。

transferFrom(p.debtor, p.creditor, p.amount) により、debtor から creditor へ送金を実行。

この前に debtor は approve(contract, amount) を済ませておく必要があります（Allowance 方式）。
送金に成功したら、p.settled = true で状態を更新。

PaymentSettled イベントを発行。

オフチェーンシステムはこのイベントを検知して pacs.002（支払ステータス報告）を生成。

成功時は TxSts=ACTC（Accepted Technical Validation）、失敗時は RJCT（Rejected）に対応。

 オフチェーン側オフチェーン側では、ブロックチェーンと既存の金融システムを接続するためにゲートウェイサーバーが稼働します。

このサーバーは金融システムから受け取った ISO20022メッセージ（XML形式）を解析・検証し、スマートコントラクトを呼び出して決済を実行します。

また、ブロックチェーン上の結果を監視し、処理結果を再び ISO20022 形式の応答メッセージに変換して返します。

 サーバー構成と機能ゲートウェイサーバーは、複数の機能モジュールで構成されるアプリケーションです。

主な構成要素は以下です。
APIサーバー
金融システムから送られる pacs.008（支払指示）XML を受信するモジュールです。

HTTPS（相互TLS推奨）を使用し、認証済みの送信元からのみ通信を受け付けます。

受信したメッセージは内部処理キューに渡され、後続の検証工程に進みます。
バリデーションモジュール
受信したXMLがISO20022のXSDスキーマに準拠しているかを検証します。

さらに、署名検証や送信者証明書の確認を行い、送信元の真正性とメッセージの完全性を保証します。

この段階でエラーが検出された場合は、ブロックチェーンを呼び出さず、即時に pacs.002（RJCT）を返します。
マッピングモジュール
検証を通過した pacs.008 メッセージを解析し、スマートコントラクト呼び出し用のパラメータに変換します。

XML内の要素（MsgId、InstrId、EndToEndId、InstdAmt、Ccy、Dbtr、Cdtr など）を抽出し、通貨コードは対応するERC20トークンのアドレスに変換、金額はトークンの小数点に合わせて整数化します。

また、XML本文のハッシュ値を計算し、オンチェーン登録時の messageHash として使用します。
トランザクションモジュール
変換されたデータをもとにスマートコントラクトを呼び出します。

registerPayment() により支払情報を登録し、条件が整えば settlePayment() を実行して送金を行います。

実行時にはウォレット鍵を使ってトランザクションに署名し、ブロックチェーンのRPCノードへ送信します。

送信後、トランザクションハッシュやブロック番号をデータベースに保存します。
イベント監視モジュール
ブロックチェーン上のスマートコントラクトから発行されるイベント（PaymentRegistered、PaymentSettledなど）を監視します。

これにより、オンチェーンの決済が確定したタイミングを検知し、オフチェーン側の状態管理に反映します。
応答生成モジュール
決済結果をもとに pacs.002（支払ステータス報告）XMLを生成します。

成功時には TxSts=ACTC（Accepted）、失敗時には TxSts=RJCT（Rejected）を設定し、元の MsgId、InstrId、EndToEndId を対応づけて整合性を保ちます。

必要に応じてステータス理由コード（StsRsnInf）を追加します。

生成したXMLは署名され、金融システムへ返信されます。
ログ・監査モジュール
受信したメッセージ、ハッシュ値、スマートコントラクトへの呼び出し、トランザクション結果、イベント情報、生成した pacs.002 をすべて記録します。

これにより、処理履歴や監査証跡を完全に保持できます。

 処理フローpacs.008受信

銀行・ERPなどの既存システムが pacs.008（支払指示）XML をゲートウェイに送信します。

サーバーはメッセージを受け取り、内部でトランザクション処理を開始します。
検証

XMLのスキーマおよび署名検証を実施し、送信者の認証を確認します。

構文エラーや認証エラーが発生した場合は pacs.002（RJCT）を生成し返信します。
重複確認

MsgId をキーとして既存レコードを照会し、二重送信ではないかを確認します。

既存レコードがある場合は再登録を行わず、既存結果を返します。
データ変換

メッセージをスマートコントラクトが受け入れられる形式に変換します。

金額を整数化し、通貨をトークンアドレスに置き換え、XMLのハッシュを作成します。
オンチェーン登録

スマートコントラクトの registerPayment() を呼び出し、支払情報を登録します。

登録成功後、トランザクションハッシュとブロック番号を記録します。
決済実行準備

debtor のウォレットでコントラクトに対して必要な許可（approve もしくは permit）が設定されていることを確認します。

許可がない場合は取得手続きを行い、それでも失敗すれば RJCT として処理を終了します。
決済実行

settlePayment(msgId) を呼び出して送金を行います。

スマートコントラクト内でERC20トークンの transferFrom が実行されます。
結果確認

ブロックチェーン上のイベントもしくはトランザクション結果を監視し、送金の成功／失敗を確定します。

成功時はステータスを「SETTLED」、失敗時は「REJECTED」として内部記録を更新します。
pacs.002生成

決済結果に応じて pacs.002 XML を生成します。

成功時は TxSts=ACTC、失敗時は TxSts=RJCT を設定し、必要に応じて理由コードを付与します。
返信と保存

生成した pacs.002 を送信元に返信します。

また、受信XML、ハッシュ値、オンチェーン記録、イベント情報、返信XMLをデータベースおよびストレージに保存し、

監査対応が可能な状態で保持します。

 処理フローpacs.008 （支払指示）の送信
銀行や企業のERPシステムが、ISO20022形式の支払指示メッセージ pacs.008 をオフチェーンのゲートウェイに送信します。

このメッセージには、送金依頼人（Debtor）、受取人（Creditor）、金額（InstdAmt）、通貨コード、取引識別子（MsgId、InstrId、EndToEndId）などが含まれています。

ここで送られているのは「この金額をこの相手に送金してください」という命令そのものです。
メッセージ検証と整形
ゲートウェイは受け取ったXMLをまず検証します。

構文（XSD準拠）、署名（送信者の証明書）、および重複（MsgIdの照合）をチェックし、正しい送金依頼であることを確認します。

検証を通過したら、XMLをブロックチェーンで扱えるデータに変換します。
金額を整数に変換（ERC20トークンのdecimalsに合わせる）
通貨コードをトークンアドレスに変換
XML全文をハッシュ化（SHA-256）してmessageHashを生成
これで、ISO20022の情報をSolidityの関数引数に置き換えられる形になります。
スマートコントラクトへの登録（registerPayment）
ゲートウェイはAvalancheブロックチェーンのスマートコントラクトを呼び出し、registerPayment() 関数に先ほど変換したデータを送信します。

ブロックチェーン側では、支払情報が Payment 構造体として保存され、登録が成功すると PaymentRegistered イベントが発行されます。
この段階で、「支払指示がブロックチェーンに正式に記録された」状態になります。

つまり、pacs.008 の内容が不可改ざんの形でブロックチェーンに載りました。
決済の実行（settlePayment）
登録後、ゲートウェイは送金者（Debtor）のウォレットがコントラクトに対して十分な送金許可（Allowance）があるかを確認します。

承認済みであれば、settlePayment(msgId) を呼び出して実際の送金処理を行います。
スマートコントラクト内では以下の処理が行われます。

IERC20.transferFrom(debtor, creditor, amount) により、送金者のトークンが受取人に移転される。
成功すると PaymentSettled イベントが発行される。
このイベントが、ブロックチェーン上で「決済が完了した」ことを示す通知になります。
決済完了の確認
ゲートウェイはブロックチェーン上のイベントログを監視しており、PaymentSettled イベントを検知すると、その支払が成功したことを確認します。（この監視はWebSocketやRPCのイベント購読で行います。）
もしエラーで失敗していれば、スマートコントラクトの呼び出し結果からその原因を取得して後続処理に反映します。
pacs.002（結果報告）の生成
決済が成功または失敗すると、ゲートウェイは結果をISO20022形式で再構築します。

これが pacs.002（FIToFIPaymentStatusReport） です。
成功した場合：TxSts=ACTC（Accepted）
失敗した場合：TxSts=RJCT（Rejected）
pacs.002 には、元の pacs.008 の MsgId, InstrId, EndToEndId がそのまま引き継がれます。

これにより、銀行側が「どの支払指示に対する結果なのか」を一意に照合できます。
結果の返信と記録
生成された pacs.002 XML は署名され、銀行やERPに返送されます。

同時に、ゲートウェイの内部データベースには以下が保存されます。
元の pacs.008 XML
ハッシュ値（messageHash）
ブロックチェーン上のトランザクションハッシュ
決済イベントの内容
返信した pacs.002
これにより、すべての取引履歴が監査可能な形で保存されます。

これで「送金指示 → 登録 → 決済 → 結果報告」という1サイクルが完結します。

 全体の流れの要約

フェーズ
主な動作
対応するISO20022メッセージ


①
銀行が支払指示を送信
pacs.008

②
ゲートウェイが検証・整形
（内部処理）

③
ブロックチェーンに登録

pacs.008 内容を registerPayment で記録

④
実際の送金処理
コントラクト内でトークン送付

⑤
イベント検知と確認
PaymentSettled

⑥
結果メッセージ作成

pacs.002（ACTCまたはRJCT）

⑦
結果返信・記録

pacs.002 送信・監査保存

この流れで、既存の銀行システムの通信プロトコル（ISO20022）を維持したまま、ブロックチェーン上で安全かつ透明な決済を実行し、その結果を金融システムへ返すことが可能になります。

 pacs.008 → JSON スキーマ定義（送金指示）pacs.008 は、銀行などの金融機関が「この顧客の送金を、他行を経由して実行してください」と依頼する支払指示メッセージです。

ここで定義しているJSONスキーマは、そのXML形式をブロックチェーン連携用に機械的に扱えるようにしたものです。

スマートコントラクト呼び出しで利用される各引数は、この pacs.008 の要素を直接マッピングしています。
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ISO20022_pacs008",
  "type": "object",
  "properties": {
    "Document": {
      "type": "object",
      "properties": {
        "FIToFICstmrCdtTrf": {
          "type": "object",
          "properties": {
            "GrpHdr": {
              "type": "object",
              "properties": {
                "MsgId": { "type": "string", "description": "一意のメッセージ識別子" },
                "CreDtTm": { "type": "string", "format": "date-time" }
              },
              "required": ["MsgId", "CreDtTm"]
            },
            "CdtTrfTxInf": {
              "type": "object",
              "properties": {
                "PmtId": {
                  "type": "object",
                  "properties": {
                    "InstrId": { "type": "string" },
                    "EndToEndId": { "type": "string" }
                  },
                  "required": ["InstrId", "EndToEndId"]
                },
                "Amt": {
                  "type": "object",
                  "properties": {
                    "InstdAmt": {
                      "type": "object",
                      "properties": {
                        "_": { "type": "string", "description": "金額" },
                        "Ccy": { "type": "string", "description": "通貨コード" }
                      },
                      "required": ["_", "Ccy"]
                    }
                  },
                  "required": ["InstdAmt"]
                },
                "Dbtr": {
                  "type": "object",
                  "properties": {
                    "Nm": { "type": "string" },
                    "Acct": { "type": "string" },
                    "WalletAddr": { "type": "string", "description": "ブロックチェーンウォレットアドレス" }
                  }
                },
                "Cdtr": {
                  "type": "object",
                  "properties": {
                    "Nm": { "type": "string" },
                    "Acct": { "type": "string" },
                    "WalletAddr": { "type": "string" }
                  }
                },
                "RmtInf": {
                  "type": "object",
                  "properties": {
                    "Ustrd": { "type": "string", "description": "送金目的などの自由記述" }
                  }
                }
              },
              "required": ["PmtId", "Amt", "Dbtr", "Cdtr"]
            }
          },
          "required": ["GrpHdr", "CdtTrfTxInf"]
        }
      },
      "required": ["FIToFICstmrCdtTrf"]
    }
  },
  "required": ["Document"]
}

 スキーマ構造Document
ISO 20022 メッセージ全体のルートとなる要素です。

XMLでは <Document> が最上位にあり、ここでは FIToFICstmrCdtTrf（銀行間顧客送金）を含みます。
FIToFICstmrCdtTrf
「Financial Institution to Financial Institution Customer Credit Transfer」の略。

銀行間の顧客送金情報そのものを格納するメインブロックです。
GrpHdr（Group Header）
メッセージ全体の識別情報です。

MsgId

このメッセージの一意の識別子。ブロックチェーン上では msgId として使用されます。

CreDtTm

作成日時。

ISO8601フォーマット（例: 2025-10-22T12:34:56Z）。
CdtTrfTxInf（Credit Transfer Transaction Information）
送金取引の中身。pacs.008 の心臓部です。

1メッセージに複数含めることもできますが、ブロックチェーンで扱う場合は1件単位で処理します。

PmtId（Payment Identification）

送金取引を識別する3つのIDのうち、主要な2つをここで定義します。

InstrId

金融機関内部の指示ID（Solidity構造体 instrId）。

EndToEndId

顧客が指定するトレーサID（構造体 endToEndId）。

pacs.002 の報告時にもこのIDで対応付けます。

Amt（Amount）

支払金額および通貨を定義します。

InstdAmt._

実際の金額。

ブロックチェーンでは整数化して amount に変換。

InstdAmt.Ccy

通貨コード（例: JPY, USD）。

通貨ごとにERC20トークンのアドレスへ変換。

Dbtr（Debtor）

送金者（支払元）の情報です。

名前・口座番号・ウォレットアドレスを含み、WalletAddr がブロックチェーン上の debtor に対応します。

Cdtr（Creditor）

受取人（支払先）の情報です。

WalletAddr がブロックチェーン上の creditor に対応します。

RmtInf（Remittance Information）

送金目的や請求番号など、自由記述の追加情報。

ブロックチェーンには記録しませんが、監査ログや報告には利用できます。
このスキーマを基に、オフチェーンゲートウェイがXMLをJSON化し、Solidity コントラクトの registerPayment() に次の形で渡します。


コントラクト引数
JSON対応項目


msgId
GrpHdr.MsgId

instrId
PmtId.InstrId

endToEndId
PmtId.EndToEndId

debtor
Dbtr.WalletAddr

creditor
Cdtr.WalletAddr

asset
InstdAmt.Ccy → ERC20アドレス

amount
InstdAmt._（整数化後）

messageHash
XML全文のSHA-256ハッシュ


 pacs.002 → JSON スキーマ定義（支払ステータス報告）pacs.002 は、pacs.008 で送られた支払指示の処理結果を報告するメッセージです。

ブロックチェーンのスマートコントラクトで決済が完了した時点で、オフチェーンゲートウェイがこのJSONスキーマをもとに XML を生成して送信元に返します。
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ISO20022_pacs002",
  "type": "object",
  "properties": {
    "Document": {
      "type": "object",
      "properties": {
        "FIToFIPmtStsRpt": {
          "type": "object",
          "properties": {
            "GrpHdr": {
              "type": "object",
              "properties": {
                "MsgId": { "type": "string" },
                "CreDtTm": { "type": "string", "format": "date-time" }
              },
              "required": ["MsgId"]
            },
            "OrgnlGrpInfAndSts": {
              "type": "object",
              "properties": {
                "OrgnlMsgId": { "type": "string" },
                "OrgnlMsgNmId": { "type": "string", "enum": ["pacs.008.001.08"] }
              },
              "required": ["OrgnlMsgId", "OrgnlMsgNmId"]
            },
            "TxInfAndSts": {
              "type": "object",
              "properties": {
                "OrgnlInstrId": { "type": "string" },
                "OrgnlEndToEndId": { "type": "string" },
                "TxSts": {
                  "type": "string",
                  "enum": ["ACTC", "RJCT"],
                  "description": "ACTC=承認, RJCT=拒否"
                },
                "StsRsnInf": {
                  "type": "object",
                  "properties": {
                    "Rsn": { "type": "string" },
                    "AddtlInf": { "type": "string" }
                  }
                }
              },
              "required": ["OrgnlInstrId", "TxSts"]
            }
          },
          "required": ["GrpHdr", "OrgnlGrpInfAndSts", "TxInfAndSts"]
        }
      },
      "required": ["FIToFIPmtStsRpt"]
    }
  },
  "required": ["Document"]
}

 スキーマ構造
Document

pacs.008 と同様に、ISO20022メッセージ全体を包むルート要素。

FIToFIPmtStsRpt（Financial Institution To Financial Institution Payment Status Report）

pacs.002 の本体部分です。1件の報告情報を格納します。

GrpHdr

この報告メッセージ自体の識別情報。

MsgId は pacs.002 側で新たに発行する一意のIDです。

OrgnlGrpInfAndSts（Original Group Information and Status）

元の pacs.008 の識別情報を参照します。

OrgnlMsgId

元メッセージの GrpHdr.MsgId。

OrgnlMsgNmId

常に "pacs.008.001.08"（このpacs.002がどのメッセージに対応しているかを明示）。


TxInfAndSts（Transaction Information and Status）

取引単位のステータスを格納します。

OrgnlInstrId

元の取引の InstrId。

OrgnlEndToEndId

元の EndToEndId。

TxSts

取引結果。

成功時は ACTC、失敗時は RJCT。

StsRsnInf

拒否時の理由（エラーコードや補足情報）。

pacs.002 はブロックチェーンのイベント出力によって生成されます。
コントラクトが PaymentSettled(msgId, success) イベントを出す。
オフチェーンがこのイベントを購読して pacs.002 JSON を生成。
成功時 → TxSts=ACTC

失敗時 → TxSts=RJCT + StsRsnInf（例：残高不足、トークン承認なし 等）

 pacs.008 ↔ pacs.002 の対応関係


pacs.008 項目

pacs.002 項目
意味・対応内容


GrpHdr.MsgId
OrgnlGrpInfAndSts.OrgnlMsgId
元のメッセージ全体を特定するためのリンク

PmtId.InstrId
TxInfAndSts.OrgnlInstrId
各取引（支払指示）を特定するためのID

PmtId.EndToEndId
TxInfAndSts.OrgnlEndToEndId
顧客が取引を追跡するためのトレーサID

AvalancheコントラクトのPaymentSettled

TxInfAndSts.TxSts
決済の結果（ACTC＝成功、RJCT＝拒否）

失敗理由
TxInfAndSts.StsRsnInf
拒否の詳細（エラー原因など）


 最後に今回は『ISO20022』をブロックチェーンで表現する取り組みについてまとめてきました。
他でも色々記事を書いているのでぜひよろしければ読んでいってください！
https://amzn.asia/d/gxvJ0Pw
https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9?source=copy_link
https://qiita.com/cardene
https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58
https://twitter.com/cardene777
https://cardene.substack.com/

 参考List of ISO 20022 Compliant Crypto
外国送金の国際標準フォーマット化（ISO20022準拠対応）について
Cross-Border Payments (SEP-31) — Anchor Platform Admin Guide
SEP-12: KYC API — Specification
bp-ventures/stellar-payment-api (ISO 20022 マッピング例)
ISO 20022: Implementation — SWIFT (CBPR+)
ISO 20022 Message Definitions — Catalogue
Cardano Developers — Docs (Transaction metadata overview & retrieval)
CIP-10: Transaction Metadata Label Registry
CIP-20: Transaction message/comment metadata
What is the size limit of transaction’s metadata? — Cardano StackExchange
Catalogue of messages — ISO 20022
OMG Financial Sector Domain Task Force (Finance DTF)
IOTA — What is IOTA?（公式解説）
IOTA Streams（暗号化データストリーム／リポジトリ）
IOTA Identity（自己主権型ID／W3C DID & VC）
IOTA Identity Docs — Verifiable Credentials
ISO 20022 — Overview（公式）
ISO 20022: Shaping the Future of Cross-Border Payments — Ripple（RMG参加とDLT初のメンバー）
Ripple Docs — Ripple Payments / SRPO / ODL API 一覧
On-Demand Liquidity Spans Worldwide — Ripple（ODLの展開状況）
About ISO 20022 — ISO20022.org（標準の公式概要）
ISO 20022 Message Definitions — ISO20022.org（メッセージ定義カタログ）
Algorand — OKX: “Algorand’s Surge: ISO 20022 Compliance, Sustainability & Tokenization”
Algorand — Binance Research: “Algorand is ISO 20022 ready”
ISO 20022 — ISO20022.org（標準の公式概要）
ISO 20022 Message Definitions — ISO20022.org
CoinCodex: “ISO 20022 Crypto: List of Compliant Coins & Tokens in 2025”
99Bitcoins: “ISO 20022 isn’t a Certification: Algorand is compatible…”
XDC Payments — ISO 20022 メッセージング（公式）
XDPoS — XDCのコンセンサスとファイナリティ（Docs）
XDC 2.0 — 2秒ブロックと三ブロック最終性（Network概要）
Impel — ISO 20022 Financial Messaging / ブリッジ（XDC上）
Impel、XDC上でISO 20022対応を発表（GlobeNewswire）
ImpelのISO 20022金融メッセージ提供（Finextra）
XDC × R3 Corda ブリッジに関する発表（SBIグループ資料）
ISO 20022 Message Definitions（公式カタログ：pacs.008 / pacs.002 など）
Swift, UBS Asset Management, and Chainlink successfully complete pilot
Swift: Successful blockchain experiments unlock tokenisation (Chainlink/CCIP活用)
Swift: Live trials of digital asset transactions to start in 2025
The Swift and Chainlink Partnership — Chainlink Blog
Chainlink Docs — CCIP overview / architecture / directory
Sibos 2025 Recap — ISO 20022メッセージでトークン化ファンドを操作

要素	説明
メタモデル（Metamodel）	金融業務メッセージの設計に共通する構造（モデル）を定義する概念モデル。これにより、異なる業務領域間でも整合性のあるモデル化が可能になります。
UMLプロファイル	UML（統一モデリング言語）を用いてメッセージ構造を表現するための拡張・制約ルール。これにより、開発者が一貫した設計手法でモデリングできます。
モデリング規則	各業務ドメイン（決済、証券、貿易金融など）をどのようにモデル化するかを定めたガイドライン。
メッセージ仕様（XML／ASN.1）	UMLモデルを具体的なメッセージ定義（XMLスキーマやASN.1定義など）に変換するための技術的ルール。
登録および管理プロセス	新しいメッセージ定義や変更を承認・登録・管理する仕組み。ISOの中央レジストリで統一的に運用されます。

項目	従来：MT形式	新：MX形式（ISO 20022）
フォーマット	固定長テキスト	XMLベースの構造化データ
データ構造	単層（フィールド番号）	階層構造（要素と属性）
表現力	限定的（文字数制限あり）	豊富（属性や複数言語対応）
機械可読性	低い	高い（タグで意味が明確）
拡張性	低い	高い（新要素追加が容易）
識別方法	MT＋数字	ドメイン.メッセージ.バージョン

セクション	内容
`<GrpHdr>`	メッセージ全体の識別情報。`MsgId`（一意のメッセージID）、作成日時など。
`<CdtTrfTxInf>`	送金取引の詳細。複数含まれる場合もある。
`<PmtId>`	取引識別子群。`InstrId`（銀行内部ID）、`EndToEndId`（顧客側トレーサID）。
`<Amt>`	金額と通貨（例：`<InstdAmt Ccy="JPY">1000000</InstdAmt>`）。
`<Dbtr>` / `<Cdtr>`	送金人（Debtor）と受取人（Creditor）の情報。
`<RmtInf>`	支払理由や請求番号などの自由記述情報。

セクション	内容
`<GrpHdr>`	レポート全体の識別情報（`MsgId`、作成日時など）。
`<OrgnlGrpInfAndSts>`	元のメッセージ（例：`pacs.008`）の `MsgId` を参照。
`<TxInfAndSts>`	各取引のステータス詳細。`OrgnlInstrId`、`OrgnlEndToEndId`、`TxSts`、`StsRsnInf` (理由) など。
`<TxSts>`	ステータスコード。代表例：`ACTC` (受理済)、`RJCT` (拒否)、`ACSP` (処理中)。

観点	`pacs.008`	`pacs.002`
メッセージ種別	支払指示（リクエスト）	支払結果報告（レスポンス）
主な方向	送金元銀行 → 送金先銀行	送金先銀行 → 送金元銀行
主な用途	送金命令、顧客決済の実行	指示の受理／拒否、決済結果の報告
ISO20022の位置づけ	Payment Initiation	Payment Status
ブロックチェーン対応箇所	`registerPayment()` に入力される	`PaymentSettled` イベントをもとに生成される

要素名	日本語名称	説明
InstrId (`Instruction Identification`)	支払指示ID	送金を実行する金融機関（送信者）がその取引を一意に識別するためのID。銀行や決済システム内での管理に使われる「内部的な処理ID」。
EndToEndId (`End-to-End Identification`)	トレーサID	取引の発端（顧客・企業など）から最終受取まで、エンドツーエンドで取引を識別するID。複数の金融機関を経由しても同じIDが引き継がれるため、「顧客が指定するトランザクション番号」のようなもの。
TxId (`Transaction Identification`)	トランザクションID	中継銀行など、個々の金融機関が独自に付与するID。`pacs.008` では省略可能な場合があります。

Solidity構造体の項目	ISO20022項目	説明
`instrId`	`<InstrId>`	銀行（ゲートウェイ）がブロックチェーン上で支払いを登録するときに生成する内部的な識別子。オンチェーンでの「支払処理1件」を一意に特定します。
`endToEndId`	`<EndToEndId>`	顧客または送金依頼者が発行するトレーサID。この値は銀行・ブリッジ・ブロックチェーン間で引き継がれ、最終的な `pacs.002`（決済結果通知）にも含まれます。
`msgId`	`<GrpHdr><MsgId>`	`pacs.008` メッセージ全体の識別子。複数トランザクションを含む場合の「メッセージ単位のID」。

区分	付与主体	使われる範囲	Solidity構造体内
MsgId	金融機関（送信側）	pacs.008 メッセージ全体	`msgId`
InstrId	金融機関（送信側）	送信銀行内部、または各支払ごと	`instrId`
EndToEndId	企業または顧客	顧客から受取まで一貫して引き継がれる	`endToEndId`

引数	内容
`msgId`	`pacs.008` メッセージ全体の識別子。どの支払取引に対応するかを特定するキー。
`debtor`	送金者（トークンを送る側のアドレス）。
`creditor`	受取人（トークンを受け取る側のアドレス）。
`amount`	送金額。ERC20トークンの単位で指定される。
`asset`	送金に使うトークンのコントラクトアドレス（例：USDC, JPYCなど）。

引数	内容
`msgId`	対応する支払メッセージの識別子。
`success`	決済が成功したかどうかを示す。`true`なら送金成功、`false`なら失敗。

引数名	意味
`msgId`	ISO20022の `<GrpHdr><MsgId>` に対応。メッセージ全体の一意識別子。`payments` のキーとしても利用。
`instrId`	`<PmtId><InstrId>` に対応。銀行やシステム内部の支払指示ID。
`endToEndId`	`<PmtId><EndToEndId>` に対応。顧客・企業が取引を追跡するためのトレーサID。
`debtor`	支払元のウォレットアドレス（送金者）。ERC20トークンを支払う側。
`creditor`	支払先のウォレットアドレス（受取人）。トークンを受け取る側。
`asset`	使用するトークンのコントラクトアドレス（例：USDC、JPYCなど）。
`amount`	送金額。`asset` トークンの単位に基づく整数値。
`messageHash`	オフチェーンで保持しているISO20022 XML（`pacs.008`）のSHA-256等ハッシュ値。改ざん検知用。

引数名	意味
`msgId`	`registerPayment()` で登録された取引を一意に特定するID。`payments` のキー。

フェーズ	主な動作	対応するISO20022メッセージ
①	銀行が支払指示を送信	`pacs.008`
②	ゲートウェイが検証・整形	（内部処理）
③	ブロックチェーンに登録	`pacs.008` 内容を `registerPayment` で記録
④	実際の送金処理	コントラクト内でトークン送付
⑤	イベント検知と確認	`PaymentSettled`
⑥	結果メッセージ作成	`pacs.002`（ACTCまたはRJCT）
⑦	結果返信・記録	`pacs.002` 送信・監査保存

コントラクト引数	JSON対応項目
msgId	GrpHdr.MsgId
instrId	PmtId.InstrId
endToEndId	PmtId.EndToEndId
debtor	Dbtr.WalletAddr
creditor	Cdtr.WalletAddr
asset	InstdAmt.Ccy → ERC20アドレス
amount	InstdAmt._（整数化後）
messageHash	XML全文のSHA-256ハッシュ

`pacs.008` 項目	`pacs.002` 項目	意味・対応内容
`GrpHdr.MsgId`	`OrgnlGrpInfAndSts.OrgnlMsgId`	元のメッセージ全体を特定するためのリンク
`PmtId.InstrId`	`TxInfAndSts.OrgnlInstrId`	各取引（支払指示）を特定するためのID
`PmtId.EndToEndId`	`TxInfAndSts.OrgnlEndToEndId`	顧客が取引を追跡するためのトレーサID
Avalancheコントラクトの`PaymentSettled`	`TxInfAndSts.TxSts`	決済の結果（ACTC＝成功、RJCT＝拒否）
失敗理由	`TxInfAndSts.StsRsnInf`	拒否の詳細（エラー原因など）

Ava Labs JPテックブログPublication

はじめに

概要

構造と設計

メッセージフォーマットの仕組み

従来のメッセージフォーマット（MT形式）

新しいメッセージフォーマット（MX形式／ISO 20022）

MT形式とMX形式の比較

Stellar

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

Cardano

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

IOTA

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

Ripple

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

Algorand

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

XDC Network

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

Chainlink

概要

仕組み

仕組みの詳細

シーケンス図

ユースケース

実装案

pacs.008

pacs.002

pacs.008 と pacs.002 の関係

オンチェーン

Payment

PaymentRegistered

PaymentSettled

registerPayment

settlePayment

オフチェーン側

サーバー構成と機能

処理フロー

処理フロー

全体の流れの要約

pacs.008 → JSON スキーマ定義（送金指示）

スキーマ構造

pacs.002 → JSON スキーマ定義（支払ステータス報告）

スキーマ構造

pacs.008 ↔ pacs.002 の対応関係

最後に

参考

Discussion

`pacs.008` と `pacs.002` の関係

`Payment`

`PaymentRegistered`

`PaymentSettled`

`registerPayment`

`settlePayment`

`pacs.008` → JSON スキーマ定義（送金指示）

`pacs.002` → JSON スキーマ定義（支払ステータス報告）

`pacs.008` ↔ `pacs.002` の対応関係