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

> ISO 20022は、国際標準化機構（ISO）が金融分野向けに定めた電子メッセージ交換の標準規格です。金融機関や決済ネットワーク間で取引データを効率的かつ統一的にやり取りするための「共通言語」を提供します。

- URL: https://cardene.dev/articles/65833002cff470
- 公開日: 2025-10-24
- 更新日: 2025-10-24
- トピック: Blockchain
- タグ: solidity, ethereum, smartcontract, avalanche

## はじめに

初めまして。
『DApps開発入門』という本や色々記事を書いているAva Labsのかるでねです。

https://amzn.asia/d/gxvJ0Pw

以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！

https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9

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：銀行間クレジット送金）:

```xml
<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を通じてアンカー間で直接交換される点にあります。

以下に、国外の受取人に送金する際の典型的な流れを示します。

1. **情報入力（SEP-31 /info）**
   送金者（ユーザー）が送金元アンカー（例: A国の銀行）のアプリで送金を開始します。
   アプリは受取側アンカーの`/info`で必須項目・対応資産を取得し、`SEP-31`の仕様に基づいて受取人情報、送金目的、金額など（ISO20022の`pacs.008`の項目に**対応づけた**情報）を入力します。

2. **本人確認（SEP-12）**
   規制要件を満たすため、受取側が要求するKYC項目に従い、送金元アンカーが**受取側の`SEP-12`エンドポイントへ**送金者のKYC情報を提出します（更新が必要な場合を含みます）。

3. **取引作成と決済の実行（SEP-31 → Stellar Network）**
   送金元アンカーは`SEP-31`の`POST /transactions`で取引を作成し、受取側アンカーから入金先アカウントと`memo`/`memo_type`（取引ID）を受領します。
   続いてStellarネットワーク上で、価値が担保されたトークン（例: USDCなどのステーブルコイン）を受取側アンカーへ送金します。オンチェーンのトランザクションには受取側が指定した`memo`を含めます。

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

5. **情報の照会と取得（SEP-31）**
   受取側アンカーは、オンチェーン決済に紐づく**取引ID（memo）** をキーとして、`SEP-31`のエンドポイントで送金詳細を取得・照合します。
   これにより、ステップ1で入力されたISO20022の項目に対応づけた送金人・受取人情報を安全に参照できます。

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

#### シーケンス図

```mermaid
sequenceDiagram
    participant User as 送金者
    participant SendingAnchor as 送金元アンカー<br>(A国の銀行)
    participant ReceivingAnchor as 送金先アンカー<br>(B国の銀行)
    participant Stellar as Stellar Network
    participant Recipient as 受取人

    User->>+SendingAnchor: 1. 送金リクエスト（SEP-31 /infoで要件取得）<br>必要情報の入力
    SendingAnchor->>+ReceivingAnchor: 2. KYC提出（SEP-12）
    ReceivingAnchor-->>-SendingAnchor: KYC受領・要件応答

    SendingAnchor->>+ReceivingAnchor: 3a. 取引作成（SEP-31 POST /transactions）
    ReceivingAnchor-->>-SendingAnchor: 3b. 入金先アカウント＋memo/memo_type（取引ID）

    SendingAnchor->>+Stellar: 3c. オンチェーン送金（指定資産・memo付き）
    Stellar-->>-ReceivingAnchor: 入金反映

    ReceivingAnchor-->>SendingAnchor: 4. ステータス更新（コールバック）<br>※またはSendingAnchorがGETで照会
    ReceivingAnchor->>+Recipient: 6. 法定通貨で払出（照合完了後）
```

### ユースケース

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準拠の送金を行うアプリケーションの典型的な流れを示します。

1. **メタデータの生成**
    送金者（ユーザー）がdApp（分散型アプリケーション）やウォレットで送金を開始します。
    アプリケーションは、ISO20022のメッセージ（例: `pacs.008`）で要求される送金人情報、受取人情報、送金目的などをJSON形式のデータとして生成します。

2. **本人確認情報の連携 (Atala PRISM)**
    必要に応じて、アプリケーションはCardanoの分散型IDソリューション「**Atala PRISM**」と連携します。
    KYC/AML情報はAtala PRISMのDID/VC（検証可能な資格情報）としてオフチェーンで管理し、トランザクションにはその参照（DIDや証明のハッシュ）を紐づけてプライバシーを保ちます。

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

4. **ブロックチェーンへの記録**
    ユーザーがトランザクションに署名すると、それはCardanoブロックチェーンに送信され、不変の記録として台帳に刻まれます。
    支払い情報に参照子（DID/ハッシュ等）を併記して記録します。
    詳細な本人確認情報自体はオフチェーンに留め、オンチェーンと連携させます。

5. **情報の検証と処理**
    着金側（金融機関や取引所など）のアプリケーションは、ブロックチェーンを監視しています。
    着金トランザクションを検知すると、その取引に添付されているメタデータを読み取ります。

6. **コンプライアンスと記帳**
    着金側は、メタデータの内容がISO20022の標準に準拠しており、規制上の要件を満たしていることを検証します。
    問題がなければ、受取人の勘定に資金を記帳し、内部の記録を更新します。

#### シーケンス図

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

```mermaid
sequenceDiagram
    participant User as 送金者
    participant dApp as dApp/ウォレット
    participant Cardano as Cardanoブロックチェーン
    participant ReceivingApp as 受信側アプリ/機関
    participant Recipient as 受取人

    User->>+dApp: 1. 送金指示
    Note over dApp: 2. ISO20022準拠の<br>メタデータ(JSON)を生成
    dApp->>+User: 3. トランザクション内容の確認を要求<br>(送金＋メタデータ)
    User->>+dApp: 署名
    dApp->>+Cardano: 4. トランザクションを送信
    Cardano-->>-dApp: 承認

    ReceivingApp->>+Cardano: 5. 新規トランザクションを監視・検知
    Cardano-->>-ReceivingApp: トランザクションデータ<br>(送金＋メタデータ)を渡す

    Note over ReceivingApp: 6. メタデータを解析し、<br>コンプライアンスを検証
    ReceivingApp->>+Recipient: 受取人の口座へ記帳
```

### ユースケース

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準拠の決済フローの典型例を示します。

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

2. **ISO20022メッセージの送信**
    送金者は、ISO 20022の項目に沿って（マッピングして）構造化した金融メッセージを生成し、このStreamsチャネルに書き込みます（Publish）。
    これはTangle上ではデータメッセージ（ゼロバリュー）として記録されます。

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

4. **決済の実行**
    合意に基づき、送金者は実際の資金（IOTAトークンなど）を「**価値トランザクション**」としてTangle上で受取人に送金します。
    このトランザクションには、ステップ2で送信したデータメッセージを特定するための**参照情報（メッセージID／ハッシュ等）** を含めることができます。
    これにより、決済とその目的（詳細情報）が改ざん不可能な形で紐づけられます。

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

#### シーケンス図

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

```mermaid
sequenceDiagram
    participant Sender as 送金者/デバイス
    participant Streams as IOTA Streams Channel
    participant Tangle as IOTA Tangle
    participant Receiver as 受取人/デバイス

    Sender->>+Streams: 1. 暗号化チャネルを確立
    Receiver->>+Streams: 

    Sender->>+Streams: 2. ISO20022準拠メッセージを書き込む (Publish)
    Note right of Sender: これはデータのみのゼロ価値トランザクション

    Receiver->>+Streams: 3. メッセージを購読・受信 (Subscribe)
    Note left of Receiver: 内容を確認し、取引に合意

    Sender->>+Tangle: 4. 価値(IOTAトークン)を送金
    Note over Sender, Receiver: このトランザクションには<br>Streamsメッセージへの参照を含む

    Receiver->>+Tangle: 5. 着金を確認
    Note left of Receiver: 参照情報とメッセージを照合し、取引を完了
```

### ユースケース

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というネットワークサービスを通じて実現されています。

1. **標準化されたメッセージング層**
    RippleNetに参加する金融機関は、APIを通じて自社のシステムを接続します。
    送金を行う時、RippleNetが提供するメッセージング層では、ISO 20022のpacs.008に整合したJSONスキーマ（Standard RippleNet Payment Object, SRPO）に基づきデータが生成・交換されます。
    これにより、送金に関わる詳細な情報（送金人、受取人、目的、コンプライアンス情報など）が、参加機関の間で標準化された形で正確に伝達されます。

2. **決済層との分離と連携**
    ISO20022はあくまで「**メッセージ（情報）**」の標準です。
    RippleNetは、この情報伝達層と、実際の「価値（お金）」を動かす決済層を連携させています。

3.  **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を利用した国際送金の典型的な流れを示します。

1. **支払い指示 (ISO 20022)**
    送金元金融機関は、RippleNetのAPIを通じてISO 20022（pacs.008）に整合したSRPOで支払い指示データを送信します。
    このメッセージには、送金人・受取人情報、コンプライアンス情報などが全て含まれています。

2. **最適な決済経路の決定**
    RippleNetは、この指示を受け取り、最も効率的な決済経路を自動的に決定します。
    Ripple Paymentsを利用する場合、以下のプロセスが開始されます。

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

4. **XRPの移転 (XRP Ledger)**
    変換されたXRPは、数秒で**XRP Ledger**を通じて、送金先国（B国）の提携流動性プロバイダーのウォレットへ送られます。
    このXRP Ledger上での取引は、極めて高速かつ低コストで完了します。

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

6. **着金処理**
    変換された法定通貨が、受取人金融機関（B国の銀行）の口座に入金され、最終的な受取人に支払われます。

7. **取引完了通知**
    この一連の決済プロセスが完了すると、その結果がRippleNetのメッセージング層で**ISO 20022整合スキーマ（SRPO等）** に沿って関係機関へ通知されます。

この仕組みにより、金融機関は国際送金のために海外の銀行に資金（ノストロ口座）を事前に預けておく必要がなくなり、数秒で、かつ低いコストで国境を越える決済を完了できます。

#### シーケンス図

```mermaid
sequenceDiagram
    participant SendingFI as 送金元金融機関<br>(A国)
    participant RippleNet as RippleNet<br>(メッセージング層)
    participant SourceLP as 送金元LP<br>(取引所A)
    participant XRPL as XRP Ledger<br>(決済層)
    participant DestLP as 送金先LP<br>(取引所B)
    participant ReceivingFI as 受取人金融機関<br>(B国)

    SendingFI->>+RippleNet: 1. 支払い指示 (ISO 20022)
    RippleNet->>+SourceLP: 2. 法定通貨A → XRP 変換指示
    SourceLP->>+XRPL: 3. XRPを送金
    XRPL-->>-DestLP: XRP着金
    RippleNet->>+DestLP: 4. XRP → 法定通貨B 変換指示
    DestLP->>+ReceivingFI: 5. 法定通貨Bを送金
    RippleNet-->>-SendingFI: 6. 決済完了通知
```

### ユースケース

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と同様に、トランザクションとそれに付随する情報がブロックチェーン上で一体として扱われるモデルです。

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

2. **アセットの指定**
    送金する資産（ネイティブ通貨のALGO、またはASAとして発行されたステーブルコインなど）を指定します。

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

4. **ブロックチェーンへの記録とファイナリティ**
    トランザクションは約3.3秒でブロックに取り込まれ、その瞬間にファイナリティに達します。
    これにより、送金データとその参照（ノート中の要約/ハッシュ/URL等）が改ざん困難な形で同時に確定します。
    詳細なコンプライアンス情報はオフチェーンで管理します。

5. **受信側での処理**
    受信側（金融機関など）のシステムは、Algorandネットワークを監視しており、自社に関連するトランザクションを検知します。
    トランザクションに添付された「ノート」を読み取り、内容をISO 20022の項目にマッピングして解釈し、コンプライアンスや内部記帳に反映します。

#### シーケンス図

```mermaid
sequenceDiagram
    participant User as 送金者
    participant dApp as dApp/ウォレット
    participant Algorand as Algorandブロックチェーン
    participant ReceivingApp as 受信側アプリ/機関
    participant Recipient as 受取人

    User->>+dApp: 1. 送金指示
    Note over dApp: 2. ISO20022準拠のデータを<br>「ノート」フィールド用に生成
    dApp->>+User: 3. トランザクション内容の確認を要求<br>(送金＋ノート)
    User->>+dApp: 署名
    dApp->>+Algorand: 4. トランザクションを送信
    Algorand-->>-dApp: 承認 (約3.3秒でファイナリティ)

    ReceivingApp->>+Algorand: 5. 新規トランザクションを監視・検知
    Algorand-->>-ReceivingApp: トランザクションデータ<br>(送金＋ノート)を渡す

    Note over ReceivingApp: 6. 「ノート」を解析し、<br>コンプライアンスを検証
    ReceivingApp->>+Recipient: 受取人の口座へ記帳
```

### ユースケース

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を介して安全に繋ぐことで実現されます。

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

2. **メッセージの解析と決済準備**
    Impelプラットフォームはメッセージを受信し、その正当性を検証します。
    その後、メッセージの内容を解析し、XDC Network上で実行すべきトランザクションの内容（送金元アドレス、送金先アドレス、アセットの種類、数量など）を特定します。

3. **アトミックスワップまたは価値移転の実行**
    特定された内容に基づき、ImpelはXDC Network上でトランザクションを実行します。
    現状は主に単一資産（XDCまたはトークン化資産）の移転が中心ですが、将来的にはアトミックスワップなどの複合取引にも対応が予定されています。
    トランザクションのメモ欄には、元のISO20022メッセージを識別できるハッシュ参照が記録されます。

4. **決済の確定とファイナリティ**
    トランザクションは約2秒でXDC Network上で確定し、ファイナリティに達します。

5.  **完了通知の生成と送信**
    Impelは、XDC Network上での決済完了を確認すると、**ISO 20022構造に整合した `pacs.002` 互換メッセージ（XMLまたはJSON形式）を生成して送金元金融機関に送信します。
    これにより、送金元は内部台帳を更新し、決済完了を正式に確認できます。

#### シーケンス図

```mermaid
sequenceDiagram
    participant SendingFI as 送金元金融機関
    participant Impel as ブリッジ<br>(Impel Platform)
    participant XDC as XDC Network<br>(決済レイヤー)
    participant ReceivingFI as 受取人金融機関

    SendingFI->>+Impel: 1. ISO 20022 (pacs.008) メッセージを送信
    Note over Impel: 2. メッセージを解析し、<br>トランザクション内容を特定
    Impel->>+XDC: 3. トークン移転トランザクションを実行<br>(メモ欄に参照情報を含む)
    XDC-->>-Impel: 4. 決済完了 (約2秒でファイナリティ)
    Note over Impel: 完了ステータスを確認
    Impel->>+SendingFI: 5. ISO 20022 (pacs.002) 完了通知を返信
    Impel->>+ReceivingFI: (オプション) 着金通知
```

### ユースケース

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

* **貿易金融の革新**
    船荷証券や請求書などの貿易書類をNFTとしてトークン化し、その所有権移転と支払い（決済）を同時に、かつプログラム可能に行うことができます。
    これにより、従来数週間かかっていた決済サイクルを数秒に短縮し、企業のキャッシュフローを大幅に改善します。
* **クロスボーダー決済**
    既存のコルレス銀行網を介さず、XDC Networkを決済レールとして利用することで、国際送金を高速かつ低コストで実現します。
    特に、企業間の高額な決済に適しています。
* **サプライチェーン・ファイナンス**
    商品の物理的な流れと、それに伴う金融の流れを一つの台帳上で連携させ、透明性の高いサプライチェーン・ファイナンスを実現します。
    例えば、商品が特定の地点に到着したことをトリガーに、自動で支払いが行われるといった仕組みを構築できます。

## Chainlink

### 概要

Chainlinkは、ブロックチェーンではなく、現実世界（オフチェーン）のデータやシステムと、ブロックチェーン（オンチェーン）のスマートコントラクトを安全に繋ぐ「**分散型オラクルネットワーク**」です。
ChainlinkのISO20022への取り組みは、決済を自ら実行するのではなく、既存の金融メッセージング標準（ISO20022など）に整合した形式でSWIFTネットワークと複数のブロックチェーンを接続する「**通訳**」および「**ブリッジ**」としての役割を担うものです。
この取り組みはすでにSWIFTとの技術実証（PoC）として進行しており、将来的に金融機関が既存インフラを維持したまま、ブロックチェーン上のトークン化資産にアクセスできる環境を目指しています。

### 仕組み

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

1. **メッセージの受信**
    金融機関がSWIFTネットワークを通じて、ブロックチェーン上での操作を指示するメッセージを送信します。
2. **メッセージの翻訳と転送 (CCIP)**
    ChainlinkのCCIPがこのメッセージを受け取ります。
    メッセージを解析し、ターゲットとなるブロックチェーン（例: Ethereum）上のスマートコントラクトが理解できる形式のトランザクション命令に変換します。
3. **ブロックチェーン上での実行**
    変換された命令がターゲットのブロックチェーンに送られ、スマートコントラクトが起動されます。これにより、トークンの移転やスワップなどの金融取引が実行されます。
4.  **実行結果の監視と報告**
    Chainlinkのオラクルネットワークは、ブロックチェーン上での取引が確実に実行され、完了（ファイナリティ）したことを監視します。
5. **結果の逆翻訳と通知**
    取引が完了すると、Chainlinkは結果（成功、失敗、取引IDなど）をSWIFTが理解できるISO 20022整合フォーマットのメッセージに変換し、SWIFTネットワークを通じて金融機関に報告します。

### 仕組みの詳細

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

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

2. **CCIPによるメッセージの受信とルーティング**
    このメッセージはSWIFTネットワークを介して、Chainlink CCIPに接続されたエンドポイントに到達します。
    CCIPの「**ルーター**」がメッセージを解析し、送信元（SWIFT）、送信先チェーン（イーサリアム）、実行すべきアクション（トークン転送）を特定します。

3. **オンチェーンでのアクション実行**
    CCIPは、分散型オラクルネットワーク（DON）を利用して、Ethereum上の適切なスマートコントラクト（例: トークン転送コントラクト）を呼び出すトランザクションを安全に生成・実行します。

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

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

#### シーケンス図

```mermaid
sequenceDiagram
    participant FI as 金融機関
    participant SWIFT as SWIFTネットワーク
    participant CCIP as Chainlink CCIP
    participant DON as Chainlink DON
    participant Blockchain as ターゲット・ブロックチェーン

    FI->>+SWIFT: 1. ISO 20022 支払い指示
    SWIFT->>+CCIP: 2. メッセージを転送
    Note over CCIP: メッセージを解析し、<br>オンチェーン命令に翻訳
    CCIP->>+DON: 3. トランザクション実行を指示
    DON->>+Blockchain: 4. スマートコントラクトを実行
    Blockchain-->>-DON: 実行結果
    Note over DON: 5. ファイナリティを監視・確認
    DON->>+CCIP: 6. 実行完了を報告
    CCIP->>+SWIFT: 7. ISO 20022 完了報告メッセージを生成
    SWIFT-->>-FI: 8. 完了報告を金融機関に通知
```

### ユースケース

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

* **トークン化資産のグローバル決済**
    金融機関が、SWIFTという単一のネットワークを通じて、世界中の異なるブロックチェーン上で発行された証券トークン、不動産トークン、プライベートエクイティなどを売買・決済できるようになります。
* **TradFiからDeFiへのアクセス**
    銀行が、既存のインフラから直接、AaveやCompoundといったDeFiプロトコルに資金を供給して金利を得たり、MakerDAOでステーブルコインを発行したりすることが可能になります。
* **金融機関のDX（デジタルトランスフォーメーション）促進**
    金融機関は、ブロックチェーンごとに個別のインフラを構築するという莫大なコストと複雑性を回避できます。SWIFTへの接続を維持するだけで、Web3の世界が提供するイノベーションの恩恵を受けることができます。

## 実装案

前章までで、ブロックチェーン上でのISO20022の取り組みについてまとめてきました。
この章では、EVM互換ブロックチェーン上でSolidityで書かれたSmartContractを使用したISO20022の実装案についてまとめていきます。


:::details pacs.008とpacs.002

### pacs.008

`pacs.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.002

`pacs.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`（銀行間クレジット送金）に対応した最小限の実装です。

```solidity
// 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`

```solidity
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。<br>銀行や決済システム内での管理に使われる「内部的な処理ID」。   |
| **EndToEndId** (`End-to-End Identification`) | トレーサID     | 取引の発端（顧客・企業など）から最終受取まで、エンドツーエンドで取引を識別するID。<br>複数の金融機関を経由しても同じIDが引き継がれるため、「顧客が指定するトランザクション番号」のようなもの。 |
| **TxId** (`Transaction Identification`)      | トランザクションID | 中継銀行など、個々の金融機関が独自に付与するID。`pacs.008` では省略可能な場合があります。     |

```xml
<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` |

:::message

* `InstrId` は **金融機関が管理する取引単位**（銀行内の技術的識別子）。
* `EndToEndId` は **顧客が管理する取引単位**（請求書番号や発注番号など）。

これを分離しておくことで、金融機関内部では同じ顧客取引でも複数の指示を別管理でき、顧客側では「**自分の注文番号でトレース**」できるようになります。

この構造をブロックチェーン上に持ち込むと、オンチェーンでは `InstrId` を内部キーとして処理し、`EndToEndId` を監査や `pacs.002` 返却のために外部照合用キーとして扱うのが一般的です。
:::


#### `PaymentRegistered`

```solidity
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`

```solidity
event PaymentSettled(string msgId, bool success);
```

支払処理（`pacs.008` に基づく送金）が完了したこと、または失敗したことを通知します。
これは ISO 20022の `pacs.002`（支払ステータス報告）に対応します。

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

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

#### `registerPayment`

```solidity
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等ハッシュ値。改ざん検知用。  |

1. `msgId` をキーに既存登録がないかチェック。
    すでに同じ `msgId` が登録されていれば二重登録として `revert`。
2. `Payment` 構造体を新規作成し、現在の `block.timestamp` を登録時刻として記録。
3. `payments[msgId]` に保存。
4. `PaymentRegistered` イベントを発行。
   イベントには主な支払情報（msgId、送金元、受取人、金額、資産）を含め、オフチェーン監視システムがこれを契機に「**支払受付済み**」として扱う。

#### `settlePayment`

```solidity
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` のキー。 |

1. `payments[msgId]` から支払情報を取得。登録済みかつ未決済であることを確認。
    * `!p.settled`
        すでに決済済みなら拒否。
    * `p.amount > 0`
        金額が無効（0や未登録）なら拒否。
2. `IERC20(p.asset)` でトークンコントラクトを指定。
   `transferFrom(p.debtor, p.creditor, p.amount)` により、`debtor` から `creditor` へ送金を実行。
    この前に `debtor` は `approve(contract, amount)` を済ませておく必要があります（Allowance 方式）。
3. 送金に成功したら、`p.settled = true` で状態を更新。
4. `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` をすべて記録します。
これにより、処理履歴や監査証跡を完全に保持できます。

#### 処理フロー

1. **pacs.008受信**
    銀行・ERPなどの既存システムが pacs.008（支払指示）XML をゲートウェイに送信します。
    サーバーはメッセージを受け取り、内部でトランザクション処理を開始します。

2. **検証**
    XMLのスキーマおよび署名検証を実施し、送信者の認証を確認します。
    構文エラーや認証エラーが発生した場合は `pacs.002`（RJCT）を生成し返信します。

3. **重複確認**
    `MsgId` をキーとして既存レコードを照会し、二重送信ではないかを確認します。
    既存レコードがある場合は再登録を行わず、既存結果を返します。

4. **データ変換**
    メッセージをスマートコントラクトが受け入れられる形式に変換します。
    金額を整数化し、通貨をトークンアドレスに置き換え、XMLのハッシュを作成します。

5. **オンチェーン登録**
    スマートコントラクトの `registerPayment()` を呼び出し、支払情報を登録します。
    登録成功後、トランザクションハッシュとブロック番号を記録します。

6. **決済実行準備**
    `debtor` のウォレットでコントラクトに対して必要な許可（`approve` もしくは `permit`）が設定されていることを確認します。
    許可がない場合は取得手続きを行い、それでも失敗すれば RJCT として処理を終了します。

7. **決済実行**
    `settlePayment(msgId)` を呼び出して送金を行います。
    スマートコントラクト内で**ERC20**トークンの `transferFrom` が実行されます。

8. **結果確認**
    ブロックチェーン上のイベントもしくはトランザクション結果を監視し、送金の成功／失敗を確定します。
    成功時はステータスを「`SETTLED`」、失敗時は「`REJECTED`」として内部記録を更新します。

9. **`pacs.002`生成**
    決済結果に応じて `pacs.002` XML を生成します。
    成功時は `TxSts=ACTC`、失敗時は `TxSts=RJCT` を設定し、必要に応じて理由コードを付与します。

10. **返信と保存**
    生成した `pacs.002` を送信元に返信します。
    また、受信XML、ハッシュ値、オンチェーン記録、イベント情報、返信XMLをデータベースおよびストレージに保存し、
    監査対応が可能な状態で保持します。


### 処理フロー

```mermaid
sequenceDiagram
    participant Bank as 銀行／ERPシステム
    participant Gateway as オフチェーンゲートウェイ<br>(API・検証・変換・連携)
    participant Avalanche as ブロックチェーン<br>(ISO20022Settlementコントラクト)
    participant Contract as スマートコントラクト内ロジック
    participant DB as ゲートウェイ内部DB／監査ログ

    %% pacs.008 受信
    Bank->>+Gateway: pacs.008 XML送信（支払指示）
    Gateway->>Gateway: XML検証（XSD・署名・送信者確認）
    Gateway->>Gateway: 重複チェック（MsgId照合）
    Gateway->>Gateway: XML解析・データ変換<br>金額整数化／トークンアドレス解決／SHA-256ハッシュ生成

    %% オンチェーン登録
    Gateway->>+Avalanche: registerPayment(msgId, instrId, endToEndId, debtor, creditor, asset, amount, messageHash)
    Avalanche->>+Contract: 新規Payment構造体を登録
    Contract-->>Avalanche: emit PaymentRegistered(msgId, debtor, creditor, amount, asset)
    Avalanche-->>-Gateway: 登録完了イベント通知
    Gateway->>DB: TxHash・BlockNumber・登録結果を保存

    %% 承認確認と決済実行
    Gateway->>Gateway: debtorのAllowance／permit状態確認
    Gateway->>+Avalanche: settlePayment(msgId)
    Avalanche->>+Contract: ERC20.transferFrom(debtor → creditor)
    Contract-->>Avalanche: emit PaymentSettled(msgId, success=true)
    Avalanche-->>-Gateway: 決済完了イベント通知

    %% 結果生成と返信
    Gateway->>DB: 決済ステータス更新（SETTLED）
    Gateway->>Gateway: pacs.002 XML生成（TxSts=ACTC）
    Gateway->>Bank: pacs.002送信（決済結果報告）
    Gateway->>DB: XML・イベント・監査情報を保存

    Note over Bank,Avalanche: pacs.008（支払指示）→ 登録／決済 → pacs.002（結果報告）の一連処理を完結

```

1. **`pacs.008` （支払指示）の送信**

    銀行や企業のERPシステムが、ISO20022形式の支払指示メッセージ `pacs.008` をオフチェーンのゲートウェイに送信します。
    このメッセージには、送金依頼人（Debtor）、受取人（Creditor）、金額（InstdAmt）、通貨コード、取引識別子（MsgId、InstrId、EndToEndId）などが含まれています。
    ここで送られているのは「**この金額をこの相手に送金してください**」という命令そのものです。

2. **メッセージ検証と整形**

    ゲートウェイは受け取ったXMLをまず検証します。
    構文（XSD準拠）、署名（送信者の証明書）、および重複（MsgIdの照合）をチェックし、正しい送金依頼であることを確認します。
    検証を通過したら、XMLをブロックチェーンで扱えるデータに変換します。

    * 金額を整数に変換（ERC20トークンの`decimals`に合わせる）
    * 通貨コードをトークンアドレスに変換
    * XML全文をハッシュ化（SHA-256）して`messageHash`を生成

    これで、ISO20022の情報をSolidityの関数引数に置き換えられる形になります。

3. **スマートコントラクトへの登録（`registerPayment`）**

    ゲートウェイはAvalancheブロックチェーンのスマートコントラクトを呼び出し、`registerPayment()` 関数に先ほど変換したデータを送信します。
    ブロックチェーン側では、支払情報が `Payment` 構造体として保存され、登録が成功すると `PaymentRegistered` イベントが発行されます。

    この段階で、「**支払指示がブロックチェーンに正式に記録された**」状態になります。
    つまり、`pacs.008` の内容が不可改ざんの形でブロックチェーンに載りました。

4. **決済の実行（settlePayment）**

    登録後、ゲートウェイは送金者（Debtor）のウォレットがコントラクトに対して十分な送金許可（Allowance）があるかを確認します。
    承認済みであれば、`settlePayment(msgId)` を呼び出して実際の送金処理を行います。

    スマートコントラクト内では以下の処理が行われます。

    * `IERC20.transferFrom(debtor, creditor, amount)` により、送金者のトークンが受取人に移転される。
    * 成功すると `PaymentSettled` イベントが発行される。

    このイベントが、ブロックチェーン上で「**決済が完了した**」ことを示す通知になります。

5. **決済完了の確認**

    ゲートウェイはブロックチェーン上のイベントログを監視しており、`PaymentSettled` イベントを検知すると、その支払が成功したことを確認します。（この監視はWebSocketやRPCのイベント購読で行います。）

    もしエラーで失敗していれば、スマートコントラクトの呼び出し結果からその原因を取得して後続処理に反映します。

6. **`pacs.002`（結果報告）の生成**

    決済が成功または失敗すると、ゲートウェイは結果をISO20022形式で再構築します。
    これが **pacs.002（FIToFIPaymentStatusReport）** です。

    * 成功した場合：`TxSts=ACTC`（Accepted）
    * 失敗した場合：`TxSts=RJCT`（Rejected）

    `pacs.002` には、元の `pacs.008` の `MsgId`, `InstrId`, `EndToEndId` がそのまま引き継がれます。
    これにより、銀行側が「**どの支払指示に対する結果なのか**」を一意に照合できます。

7. **結果の返信と記録**

    生成された `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` の要素を直接マッピングしています。


```json
{
  "$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 を生成して送信元に返します。

```json
{
  "$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-2a03fa3ea33d43baa9ed82288f98d4a9EIP-2a03fa3ea33d43baa9ed82288f98d4a9

https://qiita.com/cardene

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://twitter.com/cardene777

https://cardene.substack.com/

## 参考

* [List of ISO 20022 Compliant Crypto](https://101blockchains.com/iso-20022-compliant-crypto-list/)
* [外国送金の国際標準フォーマット化（ISO20022準拠対応）について](https://www.smbc.co.jp/hojin/iso20022/index.html)
* [Cross-Border Payments (SEP-31) — Anchor Platform Admin Guide](https://developers.stellar.org/platforms/anchor-platform/admin-guide/sep31)
* [SEP-12: KYC API — Specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md)
* [bp-ventures/stellar-payment-api (ISO 20022 マッピング例)](https://github.com/bp-ventures/stellar-payment-api)
* [ISO 20022: Implementation — SWIFT (CBPR+)](https://www.swift.com/standards/iso-20022/iso-20022-faqs/implementation)
* [ISO 20022 Message Definitions — Catalogue](https://www.iso20022.org/iso-20022-message-definitions)
* [Cardano Developers — Docs (Transaction metadata overview & retrieval)](https://developers.cardano.org/docs/get-started/)
* [CIP-10: Transaction Metadata Label Registry](https://cips.cardano.org/cip/CIP-10)
* [CIP-20: Transaction message/comment metadata](https://cips.cardano.org/cip/CIP-20)
* [What is the size limit of transaction’s metadata? — Cardano StackExchange](https://cardano.stackexchange.com/questions/4124/what-is-the-size-limit-of-transactions-metadata)
* [Catalogue of messages — ISO 20022](https://www.iso20022.org/catalogue-messages)
* [OMG Financial Sector Domain Task Force (Finance DTF)](https://www.omg.org/fdtf/)
* [IOTA — What is IOTA?（公式解説）](https://www.iota.org/learn/intro)
* [IOTA Streams（暗号化データストリーム／リポジトリ）](https://github.com/iotaledger-archive/streams)
* [IOTA Identity（自己主権型ID／W3C DID & VC）](https://www.iota.org/products/identity)
* [IOTA Identity Docs — Verifiable Credentials](https://docs.iota.org/developer/iota-identity/explanations/verifiable-credentials)
* [ISO 20022 — Overview（公式）](https://www.iso20022.org/iso-20022)
* [ISO 20022: Shaping the Future of Cross-Border Payments — Ripple（RMG参加とDLT初のメンバー）](https://ripple.com/insights/iso-20022-shaping-the-future-of-cross-border-payments/)
* [Ripple Docs — Ripple Payments / SRPO / ODL API 一覧](https://docs.ripple.com/payments-odl/)
* [On-Demand Liquidity Spans Worldwide — Ripple（ODLの展開状況）](https://ripple.com/insights/on-demand-liquidity-spans-worldwide/)
* [About ISO 20022 — ISO20022.org（標準の公式概要）](https://www.iso20022.org/about-iso-20022)
* [ISO 20022 Message Definitions — ISO20022.org（メッセージ定義カタログ）](https://www.iso20022.org/iso-20022-message-definitions)
* [Algorand — OKX: “Algorand’s Surge: ISO 20022 Compliance, Sustainability & Tokenization”](https://www.okx.com/en-us/learn/algorand-iso-20022-sustainability-tokenization)
* [Algorand — Binance Research: “Algorand is ISO 20022 ready”](https://www.binance.com/en/square/post/27336101694121)
* [ISO 20022 — ISO20022.org（標準の公式概要）](https://www.iso20022.org/iso-20022)
* [ISO 20022 Message Definitions — ISO20022.org](https://www.iso20022.org/iso-20022-message-definitions)
* [CoinCodex: “ISO 20022 Crypto: List of Compliant Coins & Tokens in 2025”](https://coincodex.com/article/27964/iso-20022-crypto/)
* [99Bitcoins: “ISO 20022 isn’t a Certification: Algorand is compatible…”](https://99bitcoins.com/cryptocurrency/best-iso-20022-cryptos/)
* [XDC Payments — ISO 20022 メッセージング（公式）](https://xinfin.org/xdc-payments/index.html)
* [XDPoS — XDCのコンセンサスとファイナリティ（Docs）](https://docs.xdc.network/xdcchain/xdpos/)
* [XDC 2.0 — 2秒ブロックと三ブロック最終性（Network概要）](https://xdc.org/network)
* [Impel — ISO 20022 Financial Messaging / ブリッジ（XDC上）](https://impel.xinfin.network/index.html)
* [Impel、XDC上でISO 20022対応を発表（GlobeNewswire）](https://www.globenewswire.com/news-release/2022/06/22/2467195/0/en/Impel-Launches-Next-Gen-Alternative-to-SWIFT-SEPA-on-the-XDC-Network.html)
* [ImpelのISO 20022金融メッセージ提供（Finextra）](https://www.finextra.com/pressarticle/93145/iso-20022-player-impel-launches-to-challenge-swift-and-sepa)
* [XDC × R3 Corda ブリッジに関する発表（SBIグループ資料）](https://www.sbigroup.co.jp/english/news/pdf/2024/0531_a_en.pdf)
* [ISO 20022 Message Definitions（公式カタログ：pacs.008 / pacs.002 など）](https://www.iso20022.org/iso-20022-message-definitions)
* [Swift, UBS Asset Management, and Chainlink successfully complete pilot](https://www.swift.com/news-events/press-releases/swift-ubs-asset-management-and-chainlink-successfully-complete-innovative-pilot-bridge-tokenized-assets-existing-payment-systems)
* [Swift: Successful blockchain experiments unlock tokenisation (Chainlink/CCIP活用)](https://www.swift.com/news-events/news/successful-blockchain-experiments-unlock-potential-tokenisation)
* [Swift: Live trials of digital asset transactions to start in 2025](https://www.swift.com/news-events/news/live-trials-digital-asset-transactions-swift-start-2025)
* [The Swift and Chainlink Partnership — Chainlink Blog](https://blog.chain.link/the-swift-and-chainlink-partnership/)
* [Chainlink Docs — CCIP overview / architecture / directory](https://docs.chain.link/ccip)
* [Sibos 2025 Recap — ISO 20022メッセージでトークン化ファンドを操作](https://blog.chain.link/sibos-2025-recap/)