# トレーダム ペイメント — UX設計 統合リファレンス

**バージョン：** 2.2（作業中）
**最終更新：** 2026-05-14
**ステータス：** 社内作業文書 — 法律事務所（森・濱田松本）確認前
**対象範囲：** 初回ローンチスコープ（パイロット取引対応）

> ⚠️ **重要：** Buyer向けUI上の文言はすべて法務確認（MHM）が必要。このドキュメントはUX設計の骨格を整理するものであり、法的文書ではない。

---

## 目次

### Part A — カスタマージャーニー（メイン）
1. [用語集・前提知識](#1-用語集前提知識)
2. [アクター定義](#2-アクター定義)
3. [取引スキーム定義](#3-取引スキーム定義)
4. [Journey 1 — トレーダム管理者（内部）](#journey-1--トレーダム管理者内部)
5. [Journey 2A — 加盟店：支払先履行型](#journey-2a--加盟店支払先履行型-sc-1--sc-2)
6. [Journey 2B — 加盟店：インボイス後払い型](#journey-2b--加盟店インボイス後払い型-sc-3)
7. [Journey 2C — 加盟店：インボイス前払い型](#journey-2c--加盟店インボイス前払い型-sc-4)
8. [Journey 3 — Buyer：支払先履行型](#journey-3--buyer支払先履行型-sc-1--sc-2)
9. [Journey 4A — Buyer：インボイス後払い型](#journey-4a--buyerインボイス後払い型-sc-3)
10. [Journey 4B — Buyer：インボイス前払い型](#journey-4b--buyerインボイス前払い型-sc-4)
11. [Journey 5 — 例外・返金](#journey-5--例外返金全アクター視点)

### Part B — 機能別フロー詳細（参照用）
9. [FL-01〜FL-18 詳細](#part-b--機能別フロー詳細)

---

# Part A — カスタマージャーニー

---

## ジャーニー構成 概要

- **Journey 1** — TRADOM管理者（内部）：アカウント設定 → 加盟店登録 → KYC審査 → 日次オペレーション → Fiat送金 → レポート
- **Journey 1** — TRADOM管理者：加盟店審査・契約・初期設定・ウォレット発行・精算管理
- **Journey 2A** — 加盟店 / 支払先履行型（SC-1 / SC-2）：API連携設定 → 購買者のSC受領確認 → 精算・売上管理
- **Journey 2B** — 加盟店 / インボイス後払い型（SC-3）：**商品発送** → インボイス情報提出 → 与信審査 → 債権譲渡成立 → 支払案内送付 → 支払完了通知受信 → Fiat受取
- **Journey 2C** — 加盟店 / インボイス前払い型（SC-4）：インボイス確定 → 与信審査 → 債権譲渡成立 → 支払案内送付 → 支払完了通知受信 → **商品発送** → Fiat受取
- **Journey 3** — Buyer / 支払先履行型（SC-1 / SC-2）：EC購入 → 同意・SC送金 → 購入完了
- **Journey 4A** — Buyer / インボイス後払い型（SC-3）：**商品受取済み** → 支払案内メール受信 → 同意・SC送金 → 完了
- **Journey 4B** — Buyer / インボイス前払い型（SC-4）：支払案内メール受信 → 同意・SC送金 → **商品発送待ち** → 商品受取
- **Journey 5** — 例外・返金（全アクター視点）：不足送金・過払い・キャンセル・返金の各ケースを横断整理

> **共通フェーズについて：** Journey 2A / 2B / 2Cはログイン・クライアント登録・KYC・入金確認・ダッシュボードが共通。取引登録フェーズ（2A-3 / 2B-3 / 2C-3）のみ異なる。

---

## 1. 用語集・前提知識

### 1.1 用語対応表（ユーザーストーリー ↔ Ver1.4正式用語）

| ユーザーストーリー上の用語 | Ver1.4正式用語 | 備考 |
|---|---|---|
| Partner | Seller / 加盟店（Client A） | 日本国内の販売事業者 |
| Partner's Client / Client | Buyer（Client B） | 海外・国内の購入者 |
| TRADOM System | 当社（トレーダム） | — |
| Partner Operator | 加盟店担当者 | — |
| Partner Admin | 加盟店管理者 | — |
| Invoice | インボイス／売買代金債権 | — |
| Payment Link | 支払案内・決済リンク | 代物弁済同意取得を含む |
| Stablecoin / SC | ステーブルコイン（USDT/USDC/JPYC） | 電子決済手段 |
| Customer-specific Liquidation Wallet | TRADOM管理のPartner専用精算ウォレット | Sellerが所有・管理するものではない |

### 1.2 主要法的用語

| 用語 | 意味 |
|---|---|
| **債権譲渡** | Sellerがトレーダムに対して売買代金債権を譲渡する契約。譲渡後、BuyerはトレーダムにのみSCで支払義務を負う。 |
| **代物弁済** | Buyerが法定通貨建ての債務をステーブルコインで弁済すること。全額着金をもって債務消滅。 |
| **代物弁済同意** | 「法定通貨債務をSCで代物弁済することに同意する」旨のBuyerによる明示的合意。法的スキームの要。 |
| **個別債権譲渡** | インボイス型において、1取引ごとに行われる債権譲渡。審査・承認後に発生。 |
| **債権譲渡通知** | トレーダムがSellerからの債権譲渡を受けた旨をBuyerへ通知すること。インボイス型では支払案内と同時に送付。 |
| **本旨弁済** | 契約条件通りの完全な弁済。インボイス型では一部入金は本旨弁済にならない。 |
| **SC決済契約** | Buyerとトレーダムの間で成立する、代物弁済による決済を内容とする契約。 |

### 1.3 システム用語

| 用語 | 意味 |
|---|---|
| **精算ウォレット（Liquidation Wallet）** | 各Client A専用の固定ウォレット。TRADOMが管理。Sellerはアクセス不可。 |
| **マスターウォレット（Master Wallet）** | トレーダムの内部統合ウォレット。照合完了後、精算ウォレットからSCがここに移動（Sweep）される。 |
| **スイープ（Sweep）** | 精算ウォレット → マスターウォレットへのSC自動送金。照合成功後に自動実行。 |
| **オフランプ（Off-ramp）** | SC → 法定通貨への変換プロセス。 |
| **Fireblocks** | 機関向けデジタル資産管理プラットフォーム。TRADOMのウォレット基盤。 |
| **MHM** | 森・濱田松本法律事務所。法的スキーム・規約・同意文言の策定担当。 |

### 1.4 法的構造（UX設計者必読）

このサービスは日本民法上の2つの概念の組み合わせで成立している。

**債権譲渡：** SellerがBuyerへの代金請求権をトレーダムに譲渡。譲渡後、トレーダムが唯一の債権者になる。

**代物弁済：** BuyerがFiat建て債務をSCの移転によって弁済することに合意。債務消滅は全額着金時。

> **同意画面はこのサービスの法的根拠そのもの。** MHMが文言を確定するまで設計確定不可。

#### 同意画面の法的必須要素（Buyer向け）

Buyerは以下の**全項目**にSC送金前に明示同意が必要：

1. 元の売買契約はFiat建てであること
2. Sellerがトレーダムに債権を譲渡した旨（または同意した旨）
3. BuyerはSellerではなくトレーダムに支払うこと
4. 支払う正確なFiat金額
5. 支払期限
6. 使用するSC種類とブロックチェーンネットワーク
7. ユーザー利用規約（毎回）

---

## 2. アクター定義

| アクターID | 名称 | 役割 | アクセス先 |
|---|---|---|---|
| **T-SA** | TRADOMスーパー管理者 | システム全体管理。FX管理・監査・システム設定。 | `/administration/` |
| **T-A** | TRADOM管理者 | 日次オペレーション。クライアント管理・KYC審査・取引モニタリング・返金承認。 | `/admin/` |
| **T-CO** | TRADOMコンプライアンス担当者 | KYC提出書類の審査専任。加盟店からの申請内容をレビューし承認/却下/差し戻し。 | `/admin/`（専用キュー） |
| **P-A** | 加盟店管理者（Partner Admin） | 自社クライアント管理・ペイメントリンク作成・取引確認・返金申請。 | `/partner/` |
| **P-O** | 加盟店担当者（Partner Operator） | 日次取引登録・照合差異対応。 | `/partner/` |
| **B** | Buyer（Client B） | SCを送金してECの代金を支払うエンドユーザー。 | 公開ペイメントURL |
| **SYS** | システム（Kilimanjaro） | ウォレット監視・照合・スイープ・オフランプ・通知を自動実行。 | バックエンド |

### パイロット取引ペルソナ（2026年5月想定）

| ID | 名前 | 役割 | 所在 | 取引内容 |
|---|---|---|---|---|
| B1 | ひろみ（母） | Buyer | 海外 | DENIMIO デニム（支払先履行型）、Edute おもちゃ（インボイス後払い型） |
| B2 | ひなた | Buyer | 国内（日本） | DENIMIO デニム（支払先履行型）、Edute おもちゃ（支払先履行型） |
| — | DENIMIO | Seller / Client A | 日本 | Lingbleプラットフォーム経由クロスボーダーEC |
| — | Lingble | プラットフォーム（非MoR） | — | 業務支援のみ。SC受取・保有・移転は一切行わない。 |
| — | Edute | Seller / Client A | 日本 | 直販EC（支払先履行型 + インボイス後払い型の2種対応） |

---

## 3. 取引スキーム定義

| スキームID | 名称 | 概要 | 初回ローンチ |
|---|---|---|---|
| **SC-1** | 支払先履行型（自社EC前払い型） | Buyer先払い → Seller出荷 | ✅ |
| **SC-2** | 支払先履行型（プラットフォーマー/PSP経由型） | SC-1と同構造。Lingble等経由。 | ✅ |
| **SC-3** | 商品引渡し先履行型（インボイス後払い型） | Seller出荷後 → インボイス → Buyer後払い | ✅ |
| **SC-4** | 商品引渡し後履行型（インボイス前払い型） | インボイス確定後 → 与信審査 → 全額着金確認後にSeller出荷。 | ✅ |

### スキーム別 主要な違い

| 比較項目 | SC-1 / SC-2 | SC-3 / SC-4 |
|---|---|---|
| 与信審査 | なし（取引モニタリングのみ） | あり（TRADOM審査・承認必須） |
| 債権譲渡タイミング | 購入確定時（同時成立） | インボイス確定・審査承認後 |
| Buyer同意取得方法 | ペイメントリンク画面上 | メール経由（支払案内リンク） |
| 不足入金発生時 | 自動解消（猶予期間→返金） | 自動解消不可。T-COへエスカレーション。 |
| Seller出荷タイミング | 全額着金確認後（TRADOM通知後） | SC-3：インボイス発行前に出荷済み / SC-4：全額着金確認後 |

---

## Journey 1 — トレーダム管理者

**ペルソナ：** T-SA / T-A / T-CO
**ゴール：** プラットフォームを安全に稼働させ、加盟店・取引・コンプライアンスを管理する
**参照フロー：** FL-01, FL-03, FL-04, FL-05, FL-09, FL-10, FL-13, FL-17

---

### フェーズ 1-1：アカウント設定・ログイン

| ステップ | アクション（T-SA） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | T-SAが管理者アカウントを作成（名前・メール・役割を入力） | 招待メール送信 | 管理者登録フォーム | FL-01 |
| 2 | T-AまたはT-COが招待メールから初回ログイン・パスワード設定 | 認証完了 → 役割別ダッシュボードへ遷移 | ログイン画面 | FL-01 |

**UX考慮点**
- 役割（T-SA / T-A / T-CO）によってログイン後のナビゲーションが変わる
- T-COはKYC審査キューが最初に表示される想定

---

### フェーズ 1-2：加盟店の登録

| ステップ | アクション（T-A） | システム反応 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | T-Aが加盟店登録フォームに入力（法人名・住所・代表者・銀行口座等） | 銀行口座名義と法人名の自動照合 | 加盟店登録フォーム | 銀行口座名義一致確認（AML対策） | FL-03 |
| 2 | 照合OK → ステータス「Active」で登録完了 | 加盟店にログイン招待メール送信 | 管理画面 | — | FL-03 |
| 3 | T-Aが加盟店の精算ウォレットを払い出し（SC種類・チェーン指定） | ウォレットアドレスをクライアントに紐づけ | ウォレット管理画面 | ウォレットはTRADOMが管理・所有 | FL-05 |

**UX考慮点**
- 初回ローンチでは加盟店の自己登録はなし。T-Aが直接登録する。
- 取扱商品・事業内容のリスク評価もこの時点で実施（画面上に審査フォームが必要）

---

### フェーズ 1-3：クライアント（Buyer/取引先）のKYC審査

| ステップ | アクション（T-CO） | システム反応 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | 加盟店がKYC情報を提出後、T-COの審査キューに追加 | 「審査中（Pending Review）」ステータスで表示 | KYC審査キュー | — | FL-04 |
| 2 | T-COがクライアント情報・書類・送金元ウォレットを確認 | — | 審査詳細画面 | — | FL-04 |
| 3a | 承認（Approve） | ステータス「Active」/ 加盟店に通知 | 審査アクションボタン | KYC承認証跡を記録 | FL-04 |
| 3b | 却下（Reject） | 理由入力必須 / 加盟店に通知 | 審査アクションボタン | — | FL-04 |
| 3c | 追加情報要求 | 加盟店に差し戻し通知 | 審査アクションボタン | — | FL-04 |

**UX考慮点**
- 初回ローンチではBridge/Nium外部連携なし。手動審査のみ。
- T-COの画面はT-Aダッシュボード内の専用キュービューとして設計（独立画面ではない）

---

### フェーズ 1-4：日次オペレーション・取引監視

| ステップ | アクション（T-A） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | T-Aがダッシュボードにログイン → 優先アラートを確認 | 「Failed」/「X時間以上Pending」の取引を上部にハイライト | ダッシュボード | FL-17 |
| 2 | 照合差異のある取引を確認 → 対応（修正 or オーバーライド） | 承認後スイープ実行 | 取引詳細画面 | FL-10 |
| 3 | インボイス型の与信審査申請を確認・審査 | 承認/却下通知を加盟店に送信 | 審査キュー | FL-08 |
| 4 | 返金申請を確認・承認 | 返金処理を実行 / 加盟店・Buyerに通知 | 返金管理画面 | FL-14 |

---

### フェーズ 1-5：Fiat送金・決済（T-SA）

| ステップ | アクション（T-SA） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | T-SAがオフランプ完了済みの取引を確認 | 変換レート・手数料控除後の純額を表示 | Fiat取引管理画面 | FL-13 |
| 2 | 締切日（当月末）に加盟店への送金を実行 | 送金記録保存（SC受取額・レート・手数料・純額・送金番号） | 送金実行画面 | FL-13 |
| 3 | 加盟店に支払完了通知 | ダッシュボード通知 + メール | — | FL-13 |

**UX考慮点**
- 初回ローンチはJPY送金のみ。外為口座開設後にUSD対応。
- 締切日・支払日のカレンダー表示をT-SAダッシュボードに設計する必要あり

---

### フェーズ 1-6：レポーティング・分析

| 表示項目 | フィルター | 参照FL |
|---|---|---|
| 取引件数・ボリューム・手数料の合計 | 本日 / 直近7日 / 月次 / カスタム | FL-17 |
| 資産種類別内訳（USDC / USDT / JPYC） | 同上 | FL-17 |
| チェーン別内訳（ETH / Polygon） | 同上 | FL-17 |
| 直近50件の取引テーブル | クライアント / ステータス / 種別 | FL-17 |
| オペレーションアラート（Failed / 長時間Pending） | — | FL-17 |

---

## Journey 2A — 加盟店：支払先履行型（SC-1 / SC-2）

**ペルソナ：** P-A / P-O
**ゴール：** 取引を登録してペイメントリンクを発行し、着金確認後に商品を発送してFiatを受け取る
**参照フロー：** FL-02, FL-04, FL-06, FL-07, FL-09, FL-13, FL-18

> フェーズ 2A-1（ログイン）・2A-2（クライアント登録）・2A-4（入金確認）・2A-5（ダッシュボード）はJourney 2Bと共通。

---

### フェーズ 2A-1：ログイン・チームセットアップ　※ 2Bと共通

| ステップ | アクション（P-A） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | TRADOMから招待メールを受信 → 初回ログイン・パスワード設定 | 認証完了 → Partner Dashboardへ遷移 | ログイン画面 | FL-02 |
| 2 | P-Aがチームメンバー（P-O）のアカウントを作成・権限設定 | 招待メール送信 | ユーザー管理画面 | FL-02 |
| 3 | P-Aがアカウントの有効化/無効化を管理 | ステータス変更 | ユーザー管理画面 | FL-02 |

---

### フェーズ 2A-2：クライアント登録 ＋ KYC提出　※ 2Bと共通

| ステップ | アクション（P-A / P-O） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | クライアント情報を入力（法人名・住所・代表者・UBO・送金元ウォレットアドレス） | 入力バリデーション | クライアント登録フォーム | FL-04 |
| 2 | KYC書類をアップロード（法人登記・本人確認書類） | ステータス「審査中（Pending Review）」 | ファイルアップロード | FL-04 |
| 3 | TRADOM（T-CO）の審査結果を待つ | 承認 / 却下 / 追加情報要求の通知を受信 | ダッシュボード通知 + メール | FL-04 |
| 4a | 承認 → クライアントステータス「Active」 | 精算ウォレットアドレスが紐づく | クライアント詳細画面 | FL-04, FL-05 |
| 4b | 差し戻し → 情報を修正して再提出 | 差し戻し理由を表示 | クライアント登録フォーム | FL-04 |

**UX考慮点**
- 審査中は取引の作成が不可。「審査中」ステータスを明示するバナーが必要。
- 送金元ウォレットアドレスはホワイトリスト登録のため正確な入力が必要。バリデーション設計が重要。

---

### フェーズ 2A-3：取引登録 ＋ ペイメントリンク作成

*Journey 3（Buyer）のフェーズ 3-1〜3-2 と並行して進む。*

| ステップ | アクション（P-A / P-O） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | 取引登録：クライアント選択・金額・通貨・商品名・支払期限を入力 | 精算ウォレットアドレスを自動取得 | 取引登録フォーム | FL-06 |
| 2 | インボイスPDFを任意で添付 | ファイル保存 | ファイルアップロード | FL-06 |
| 3 | ペイメントリンク（QRコード付き）を生成 | ステータス「Pending（支払待ち）」 | ペイメントリンク生成画面 | FL-06 |
| 4 | リンクをBuyerに共有（メール / ECサイト誘導） | — | — | FL-06 |
| 5 | 取引ステータスをリアルタイムで確認 | Pending → Matched → Completed の遷移を表示 | 取引一覧画面 | FL-09 |
| 6 | 全額着金確認後 → TRADOMから「発送可能通知」を受信 | ダッシュボード通知 + メール + Webhook（オプション） | ダッシュボード通知 | FL-06 |
| 7 | 商品を発送 → 発送情報（追跡番号・発送日）をシステムに登録（任意） | 取引記録に発送情報を追記 | 取引詳細画面 | FL-06 |

**UX考慮点**
- SC-2（Lingble経由）の場合、取引登録はLingble APIから自動送信される場合がある。手動登録との併用を設計する必要あり。
- 「発送可能通知を受け取るまで絶対に発送しないこと」を画面上で周知するUXが必要（法的要件）。

---

### フェーズ 2A-4：入金確認 ＋ Fiat受取　※ 2Bと共通

| ステップ | アクション（P-A / P-O） | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | 取引ステータス「Completed」を確認 | — | 取引詳細画面 | FL-13 |
| 2 | 照合差異が発生した場合 → 差異内容を確認・対応（修正 or オーバーライド） | 承認後スイープ実行 | 照合差異対応画面 | FL-10 |
| 3 | 月末締め → 翌月末にTRADOMから加盟店銀行口座へFiat送金 | 送金完了通知（ダッシュボード + メール） | — | FL-13 |

---

### フェーズ 2A-5：ダッシュボード ＋ レポート確認　※ 2Bと共通

| 表示項目 | フィルター | 参照FL |
|---|---|---|
| 完了済み取引の総ボリューム・手数料 | 期間 | FL-18 |
| 取引テーブル（クライアント名 / インボイス番号 / 金額 / ステータス / 手数料） | クライアント / ステータス | FL-18 |
| 未確定入金予定額（決済スケジュール） | ⚠️ 未定義 → 要設計 | FL-18 |

---

## Journey 2B — 加盟店：インボイス後払い型（SC-3）

**ペルソナ：** P-A / P-O
**ゴール：** 商品発送後にインボイスで与信審査を通過し、債権譲渡を成立させ、BuyerのSC入金確認後にFiatを受け取る
**参照フロー：** FL-02, FL-04, FL-08, FL-09, FL-10, FL-13, FL-18

> フェーズ 2B-1（ログイン）・2B-2（クライアント登録）・2B-4（入金確認）・2B-5（ダッシュボード）はJourney 2A / 2Cと共通。

---

### フェーズ 2B-1：ログイン・チームセットアップ　※ 2A / 2Cと共通
→ Journey 2A フェーズ 2A-1 参照

### フェーズ 2B-2：クライアント登録 ＋ KYC提出　※ 2A / 2Cと共通
→ Journey 2A フェーズ 2A-2 参照

---

### フェーズ 2B-3：商品発送 ＋ 与信審査申請 ＋ 債権譲渡 ＋ 支払案内送付

*Journey 4A（Buyer）のフェーズ 4A-1〜4A-3 と並行して進む。*

| ステップ | アクション（P-A / P-O） | システム反応 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | 商品を発送・役務を提供（インボイス発行前） | — | — | — | FL-08 |
| 2 | インボイス情報を入力：Buyer情報・金額・支払期日・商品内容・輸送先国 | バリデーション | 取引登録フォーム | — | FL-08 |
| 3 | インボイスPDF・契約書抜粋を添付（任意） | ファイル保存 | ファイルアップロード | — | FL-08 |
| 4 | TRADOMによる与信審査結果を待つ | 「審査中」ステータスをダッシュボードに表示 | ダッシュボード通知 | — | FL-08 |
| 5a | ✅ 承認 → 個別債権譲渡が成立 | 承認通知受信。「債権譲渡通知」ボタンが有効化される。 | ダッシュボード通知 | 承認後は未払いのみを理由に譲渡取消し不可 | FL-08 |
| 5b | ❌ 却下 → 理由コードとともに通知 | NG通知受信。この取引はTRADOM経由では処理不可。 | ダッシュボード通知 | — | FL-08 |
| 6 | 「債権譲渡通知」ボタンを押す | TRADOMがBuyerへ自動でメール送信（支払案内リンク付き） | 取引詳細画面のボタン | 債権譲渡通知のトリガー | FL-08 |
| 7 | Buyerの支払いを待つ（取引ステータスをダッシュボードで確認） | Pending → Matched → Completed の遷移を表示 | 取引一覧画面 | — | FL-09 |
| 8 | 全額着金確認後 → TRADOMから「支払完了通知」を受信 | ダッシュボード通知 + メール | ダッシュボード通知 | — | FL-08 |

**UX考慮点**
- 「審査中」「承認」「却下」の各ステータスが取引一覧で明確に区別できるデザインが必要
- 「債権譲渡通知」ボタンは承認後にのみ有効化。押す前に確認モーダルを設ける。
- SC-3は商品発送済みのため不足入金の自動解消が不可。エスカレーション時の対応設計が重要。

---

### フェーズ 2B-4：入金確認 ＋ Fiat受取　※ 2A / 2Cと共通
→ Journey 2A フェーズ 2A-4 参照

### フェーズ 2B-5：ダッシュボード ＋ レポート確認　※ 2A / 2Cと共通
→ Journey 2A フェーズ 2A-5 参照

---

## Journey 2C — 加盟店：インボイス前払い型（SC-4）

**ペルソナ：** P-A / P-O
**ゴール：** インボイス確定後に与信審査を通過し、BuyerのSC全額着金確認後に商品を発送してFiatを受け取る
**参照フロー：** FL-02, FL-04, FL-08, FL-09, FL-10, FL-13, FL-18

> フェーズ 2C-1（ログイン）・2C-2（クライアント登録）・2C-4（入金確認）・2C-5（ダッシュボード）はJourney 2A / 2Bと共通。

---

### フェーズ 2C-1：ログイン・チームセットアップ　※ 2A / 2Bと共通
→ Journey 2A フェーズ 2A-1 参照

### フェーズ 2C-2：クライアント登録 ＋ KYC提出　※ 2A / 2Bと共通
→ Journey 2A フェーズ 2A-2 参照

---

### フェーズ 2C-3：インボイス確定 ＋ 与信審査申請 ＋ 債権譲渡 ＋ 支払案内送付 ＋ 商品発送

*Journey 4B（Buyer）のフェーズ 4B-1〜4B-3 と並行して進む。*

| ステップ | アクション（P-A / P-O） | システム反応 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | インボイスを確定（**商品はまだ発送しない**） | — | — | — | FL-08 |
| 2 | インボイス情報を入力：Buyer情報・金額・支払期日・商品内容・輸送先国 | バリデーション | 取引登録フォーム | — | FL-08 |
| 3 | インボイスPDF・契約書抜粋を添付（任意） | ファイル保存 | ファイルアップロード | — | FL-08 |
| 4 | TRADOMによる与信審査結果を待つ | 「審査中」ステータスをダッシュボードに表示 | ダッシュボード通知 | — | FL-08 |
| 5a | ✅ 承認 → 個別債権譲渡が成立 | 承認通知受信。「債権譲渡通知」ボタンが有効化される。 | ダッシュボード通知 | 承認後は未払いのみを理由に譲渡取消し不可 | FL-08 |
| 5b | ❌ 却下 → 理由コードとともに通知 | NG通知受信。この取引はTRADOM経由では処理不可。 | ダッシュボード通知 | — | FL-08 |
| 6 | 「債権譲渡通知」ボタンを押す | TRADOMがBuyerへ自動でメール送信（支払案内リンク付き） | 取引詳細画面のボタン | 債権譲渡通知のトリガー | FL-08 |
| 7 | Buyerの支払いを待つ（取引ステータスをダッシュボードで確認） | Pending → Matched → Completed の遷移を表示 | 取引一覧画面 | — | FL-09 |
| 8 | 全額着金確認後 → TRADOMから「支払完了通知」を受信 | ダッシュボード通知 + メール | ダッシュボード通知 | — | FL-08 |
| **9** | **支払完了通知を受けて商品を発送** | 発送情報（追跡番号・発送日）をシステムに登録（任意） | 取引詳細画面 | **通知前の発送は禁止（法的要件）** | FL-08 |

**UX考慮点**
- Step 9の発送禁止ルールは画面上で強く周知する必要あり（法的要件）
- 「支払完了通知」を受信するまで発送アクションを画面上でロックする設計を検討
- 「審査中」「承認」「却下」のステータス区別はJourney 2Bと同様

---

### フェーズ 2C-4：入金確認 ＋ Fiat受取　※ 2A / 2Bと共通
→ Journey 2A フェーズ 2A-4 参照

### フェーズ 2C-5：ダッシュボード ＋ レポート確認　※ 2A / 2Bと共通
→ Journey 2A フェーズ 2A-5 参照

---

## Journey 3 — Buyer：支払先履行型（SC-1 / SC-2）

**ペルソナ：** B1（海外）/ B2（国内）
**ゴール：** 商品を購入してSCで支払いを完了する（Seller出荷前に入金）
**参照フロー：** FL-06, FL-07, FL-09, FL-11, FL-12

> **SC-2（Lingble経由）との違い：**
> BuyerのUXはSC-1と同一。支払い画面上に「お支払い先はトレーダム株式会社のウォレットです（Lingble・DENIMIOのウォレットではありません）」と明示することが法的に必要。

---

### フェーズ 3-1：商品選択 ＋ 支払方法の選択

| ステップ | Buyerのアクション | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | ECサイトで商品を選択・カートに追加 | — | Sellerのサイト | — |
| 2 | 決済画面で「トレーダム ペイメント」を選択 | トレーダム ペイメントの画面へ遷移 | 決済方法選択画面 | FL-06 |

---

### フェーズ 3-2：取引モニタリング（スクリーニング）

| ステップ | SYSのアクション | 結果 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | AML/CFT・制裁スクリーニングを自動実行 | — | — | スクリーニング通過が同意画面表示の前提条件 | FL-06 |
| 2a | ❌ NG → Buyerをリダイレクト | Sellerサイトへ戻す。エラー理由は表示しない。 | エラー画面 | 同意画面は絶対に表示しない | FL-06 |
| 2b | ✅ OK → フェーズ 3-3へ | 同意画面を表示 | — | — | FL-06 |

**UX考慮点**
- NG時のBuyerへの表示内容（文言・リダイレクト先）は未定義 → 要決定 🔴

---

### フェーズ 3-3：同意画面（法的ゲート）

| ステップ | Buyerのアクション | 表示内容 | タッチポイント | 法的ゲート | 参照FL |
|---|---|---|---|---|---|
| 1 | 同意画面を確認 | ① Fiat建て売買代金の金額 / ② 債権譲渡通知（トレーダムが債権者） / ③ 代物弁済の合意内容 / ④ 支払期限 / ⑤ SC種類・チェーンの選択 / ⑥ ユーザー利用規約（毎回） | 同意画面 | **全項目への明示同意が法的要件。欠如すると法的スキーム全体が無効。** | FL-06 |
| 2 | 「確認して支払う」をタップ | 三者同時成立：①売買契約 ②債権譲渡 ③代物弁済契約 | 同意確認ボタン | 同意ログ保存（タイムスタンプ・IP・ウォレット等） | FL-06 |

**UX考慮点**
- 同意画面の法的文言はMHM確定待ち。確定まで設計は確定不可 🔴
- 「I agree」チェックボックス1つで済ませることはできない
- 利用規約は毎回表示・同意が必要。

---

### フェーズ 3-4：SC送金

| ステップ | Buyerのアクション | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | 支払い画面を確認 | SC金額（ライブレート）・QRコード・送金先ウォレットアドレス・カウントダウンタイマー・チェーン確認・ガス代注意書きを表示 | 支払い画面 | FL-06 |
| 2 | 外部ウォレットアプリを開いてQRコードをスキャンまたはアドレスをコピー | TRADOM画面は「送金待ち」表示 | 外部ウォレットアプリ | FL-06 |
| 3 | ウォレットアプリ上でSC送金を実行 | — | 外部ウォレットアプリ | FL-06 |
| 4 | トレーダム画面に戻る → 着金確認を待つ | 「確認中」ローディング表示 | 支払い完了待ち画面 | FL-06 |

**UX考慮点**
- レートロックのタイミング（同意時 vs 着金時）は未決定 → 表示設計に直接影響 🔴
- チェーン選択を間違えると資金が失われる可能性がある。警告文の強度を設計する必要あり 🟡
- ウォレットアプリへの切り替え中に画面を閉じてしまうリスクへの対策（Deep Link等）を検討

---

### フェーズ 3-5：着金確認 ＋ 完了

| ステップ | SYS / Buyerのアクション | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | SYSが精算ウォレットへの着金を検知 | — | — | FL-09 |
| 2a | ✅ 全額着金確認 | 債務消滅。「支払完了」画面を表示。Buyerにメール通知。 | 支払完了画面 | FL-09 |
| 2b | ⚠️ 不足入金を検知 | 「入金が不足しています。残り必要金額：○○USDC」を表示。1時間のカウントダウン開始。 | 不足入金通知画面 | FL-11 |
| 2c | ⚠️ 超過入金を検知 | 契約額分で債務消滅。余剰分を返金処理開始。「超過分を返金します」を表示。 | 超過入金通知画面 | FL-12 |
| 3 | Sellerが商品を発送 | TRADOMがSellerに発送可能通知を送信（Buyerに画面通知も送信） | 支払完了画面 | FL-06 |

---

### フェーズ 3-6：不足入金 — 猶予期間中の追加送金（SC-1 / SC-2のみ）

| ステップ | Buyerのアクション | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1 | カウントダウン（例：1時間）内に残額を送金 | 着金検知 → 合計が全額に達した場合 → 正常処理 | 追加送金案内画面 | FL-11 |
| 2 | タイマー切れ後も未解消の場合 | 代物弁済契約を解消。受取済みSCをBuyerの送金元ウォレットに自動返金（ガス代Buyer負担）。Sellerにキャンセル通知。 | キャンセル通知画面 | FL-11 |

---

## Journey 4A — Buyer：インボイス後払い型（SC-3）

**ペルソナ：** B1（海外、後払い）
**ゴール：** 受取済みの商品に対するインボイスを受け取り、期限内にSCで支払いを完了する
**参照フロー：** FL-08, FL-09, FL-10, FL-13

---

### フェーズ 4A-1：商品受取済み ＋ 支払案内メールの受信

| ステップ | Buyerの状態 / アクション | メール内容 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 前提 | 商品またはサービスを受取済み | — | — | — |
| 1 | TRADOMからの支払案内メールを受信 | ① 元のSellerの名称 / ② トレーダムが新債権者になった旨の通知 / ③ インボイス金額 / ④ 支払期限 / ⑤ 支払案内リンク | メール受信箱 | FL-08 |
| 2 | 支払案内リンクをクリック | トレーダム ペイメント画面へ遷移 | 支払案内リンク | FL-08 |

**UX考慮点**
- メールの到達確認・リマインダー機能の設計が必要（支払期限前に自動リマインダー）
- リンクの有効期限（支払期限）を明確に表示する

---

### フェーズ 4A-2：取引モニタリング（スクリーニング）

Journey 3 フェーズ 3-2 と同様。

---

### フェーズ 4A-3：同意画面（法的ゲート）

Journey 3 フェーズ 3-3 と同様の必須要素。以下の点のみ異なる：

| 項目 | SC-3 の特徴 |
|---|---|
| 文脈の違い | 商品はすでに手元にある。支払いのみが残っている状態での同意。 |
| 債権譲渡の説明 | より詳細な「債権譲渡通知書」の内容を表示（商品受取後の文脈に合わせた文言） |
| 同意ログ保存 | タイムスタンプ・IPアドレス・Buyer識別子・ウォレットアドレス・インボイス参照・同意文言バージョンを記録 |
| 契約成立タイミング | この同意をもってSC決済契約が成立（債務消滅は全額着金時） |

**法的ゲート：** 同意画面の法的文言はMHM確定待ち 🔴

---

### フェーズ 4A-4：SC送金 ＋ 着金確認

Journey 3 フェーズ 3-4 / 3-5 と同様。

**SC-3特有の差異：**

| 差異点 | 内容 |
|---|---|
| 不足入金の処理 | **自動解消不可**。T-COへエスカレーション。Buyerへの自動返金は行わない。 |
| 不払いの場合 | 個別債権譲渡は維持される。TRADOMはSellerへの支払義務を引き続き負う。 |
| 完了後の通知 | TRADOMがSellerへ「支払完了通知」を送信。Sellerは既に発送済みのため追加アクションなし。 |

---

## Journey 4B — Buyer：インボイス前払い型（SC-4）

**ペルソナ：** B1（海外、前払い）
**ゴール：** 支払案内メールを受け取り、SCで支払いを完了してから商品の発送を待つ
**参照フロー：** FL-08, FL-09, FL-10, FL-13

---

### フェーズ 4B-1：支払案内メールの受信（商品未受取）

| ステップ | Buyerの状態 / アクション | メール内容 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 前提 | 商品はまだ受取っていない | — | — | — |
| 1 | TRADOMからの支払案内メールを受信 | ① 元のSellerの名称 / ② トレーダムが新債権者になった旨の通知 / ③ インボイス金額 / ④ 支払期限 / ⑤ 支払案内リンク | メール受信箱 | FL-08 |
| 2 | 支払案内リンクをクリック | トレーダム ペイメント画面へ遷移 | 支払案内リンク | FL-08 |

**UX考慮点**
- SC-4はBuyerが先払いするため、「支払後に商品が発送される」旨を画面上で明確に伝える必要あり
- メール文言もSC-3と異なり「支払後発送」の文脈で設計が必要

---

### フェーズ 4B-2：取引モニタリング（スクリーニング）

Journey 3 フェーズ 3-2 と同様。

---

### フェーズ 4B-3：同意画面（法的ゲート）

Journey 3 フェーズ 3-3 と同様の必須要素。以下の点のみ異なる：

| 項目 | SC-4 の特徴 |
|---|---|
| 文脈の違い | 商品はまだ手元にない。先払いしてから発送される流れ。 |
| 発送条件の明示 | 「全額着金確認後にSellerが発送する」旨を明示する必要あり |
| 同意ログ保存 | タイムスタンプ・IPアドレス・Buyer識別子・ウォレットアドレス・インボイス参照・同意文言バージョンを記録 |
| 契約成立タイミング | この同意をもってSC決済契約が成立（債務消滅は全額着金時） |

**法的ゲート：** 同意画面の法的文言はMHM確定待ち 🔴

---

### フェーズ 4B-4：SC送金 ＋ 着金確認 ＋ 商品発送待ち

| ステップ | SYS / Buyerのアクション | システム反応 | タッチポイント | 参照FL |
|---|---|---|---|---|
| 1〜4 | Journey 3 フェーズ 3-4 と同様（SC送金〜着金確認待ち） | — | 支払い画面 | FL-08 |
| 5a | ✅ 全額着金確認 | 債務消滅。「支払完了」画面を表示。TRADOMがSellerに「支払完了通知」を送信。 | 支払完了画面 | FL-09 |
| 5b | ⚠️ 不足入金を検知 | **自動解消不可**。T-COへエスカレーション。Buyerへの自動返金は行わない。 | 不足入金通知画面 | FL-08 |
| 6 | 支払完了後 → Sellerからの発送を待つ | 「商品発送手配中」の状態をBuyerに表示（Webhook / メール通知） | 完了待ち画面 | FL-08 |

**UX考慮点**
- SC-4では支払完了後に「商品発送待ち」状態が続く。BuyerへのステータスフィードバックUXが重要。
- 発送通知（追跡番号など）の受け渡し方法を設計する必要あり
- 不足入金エスカレーション時は、Buyerに「支払が未完了のため商品は発送されない」旨を伝えるUXが必要

---

## Journey 5 — 例外・返金（全アクター視点）

**ゴール：** 取引キャンセルや例外発生時に、全当事者が適切に対応できること
**参照フロー：** FL-11, FL-12, FL-14, FL-15, FL-16

---

### ケース A：決済完了後のキャンセル（返金フロー①）

*商品返品・売買契約解除などで発生。全スキーム対象。*

```
【Sellerのアクション】
P-AがTRADOMペイメントのダッシュボードでキャンセルフラグを設定
  ※ BuyerへのFiat直接返金は規約上禁止。必ずトレーダム経由。

【法的イベント】
売買契約の取消し・解除に伴い、債権譲渡契約も解除
→ トレーダムの受取SC = 不当利益となるため返金義務発生

【Sellerのアクション】
既に受取った債権譲渡代金（Fiat）をトレーダム指定銀行口座に返金

【トレーダムのアクション（T-A）】
入金確認 → 返金処理を承認

【SYSのアクション】
Buyerの送金元ウォレットへSCを返金

返金金額の算定（"Original Fiat Value"原則）：
「返金はFiat建て金額を基準とし、返金実行時のレートでSCに再換算して支払う」
→ 初回決済時のレートとの乖離あり（弁護士確認済み）

控除項目：
  - 初回決済手数料
  - 返金時のネットワーク手数料（ガス代）

返金リンク有効期限：24時間

【完了】
Sellerに「返金完了通知」（ダッシュボード + メール）
Buyerにも「返金完了通知」
```

| アクター | 体験するタッチポイント |
|---|---|
| P-A | キャンセルフラグ設定画面 → Fiat返金通知 → 返金完了通知 |
| T-A | 返金申請確認画面 → 入金確認 → 返金承認 |
| Buyer | 返金通知メール → SC受取確認 |

---

### ケース B：不足入金 — 自動解消（SC-1 / SC-2のみ）

Journey 3 フェーズ 3-6 参照。

```
SYS が不足を検知 → Buyerに通知 → 1時間の猶予
  ✅ 猶予内に残額入金 → 正常処理
  ❌ 猶予切れ → 代物弁済契約解消 → SC自動返金（ガス代Buyer負担）
             → Sellerにキャンセル通知
```

---

### ケース C：不足入金 — インボイス型（SC-3 / SC-4）エスカレーション

```
SYS が不足を検知 → T-COへエスカレーション通知
T-COが法的・オペレーション上の対応を判断
  ※ 自動解消・自動返金は行わない
  ※ 個別債権譲渡は維持される
  ※ TRADOMはSellerへの支払義務を引き続き負う
```

---

### ケース D：超過入金

```
SYS が超過を検知 → 契約額分で債務消滅（✅ 全額充足）
余剰SCをBuyerの送金元ウォレットへ返金
  ※ ガス代Buyer負担
  ※ 余剰額がガス代を下回る場合は返金しない
Buyerに完了通知
```

> ⚠️ **未決定事項：** 余剰分の取り扱い（返金 / クレジット保留 / 保有）を確定する必要あり。

---

### ケース E：ペイメントリンク期限切れ（SC着金済みの場合）

> ⚠️ **仕様未確定 — 要定義**

```
ペイメントリンク有効期限切れ後にSCが着金
→ 「Pending Identification」フラグ（紐づく有効な取引記録なし）
→ T-Aへアラート通知
→ T-Aが手動で確認 → Buyerへ連絡 → SC返金手続き
```

---

### ケース F：照合差異 — オペレーター手動対応

```
「Discrepancy Detected」ステータス → オペレーターキューに積まれる
P-O / T-Aが差異内容を確認

対応アクション：
  ① 修正（Correct） → 登録情報を修正 → 再照合
  ② 承認オーバーライド → 理由入力必須（証跡記録）
     ※ SC-1のみ適用可
     ※ SC-3の一部入金オーバーライドは不可 → T-COへエスカレーション

承認後 → ステータス「Verified」→ スイープ実行
```

---

### 例外フロー ステータス遷移まとめ

```
通常フロー:
PENDING → MATCHED → VERIFIED → FUNDS COLLECTED → COMPLETED

例外分岐:
PENDING ──────────────────────────────────────── EXPIRED
MATCHED ──── 差異あり ──── DISCREPANCY DETECTED
                                    │
                               P-O対応 / T-CO対応
                                    │
                               VERIFIED → スイープ
PENDING ──── 不足入金（SC-1）──── 猶予期間 ──── 返金（REFUNDED）
PENDING ──── 不足入金（SC-3）──── T-COエスカレーション
```

---

# Part B — 機能別フロー詳細

*Part Aの各ジャーニーから参照される。開発・システム設計の詳細仕様として使用する。*

| フローID | フロー名 | 対象スキーム | 主なアクター | 優先度 | Part A参照先 |
|---|---|---|---|---|---|
| **FL-01** | TRADOMユーザー ログイン・登録 | 全スキーム | T-SA, T-A, T-CO | 🔴 必須 | Journey 1 フェーズ 1-1 |
| **FL-02** | 加盟店 ログイン・ユーザー管理 | 全スキーム | P-A, P-O | 🔴 必須 | Journey 2 フェーズ 2-1 |
| **FL-03** | 加盟店オンボーディング（TRADOM管理者による登録） | 全スキーム | T-A, P-A | 🔴 必須 | Journey 1 フェーズ 1-2 |
| **FL-04** | クライアント登録 ＋ KYC審査 | 全スキーム | P-A, P-O, T-CO | 🔴 必須 | Journey 1 フェーズ 1-3 / Journey 2 フェーズ 2-2 |
| **FL-05** | ウォレット割当（精算ウォレット払い出し） | 全スキーム | T-A, SYS | 🔴 必須 | Journey 1 フェーズ 1-2 |
| **FL-06** | 決済フロー：支払先履行型（自社EC） | SC-1 | P-A/P-O, B, SYS | 🔴 必須 | Journey 2A フェーズ 2A-3 / Journey 3 全体 |
| **FL-07** | 決済フロー：支払先履行型（プラットフォーマー/PSP経由） | SC-2 | P-A/P-O, B, SYS | 🔴 必須 | Journey 2A フェーズ 2A-3 / Journey 3（SC-2 variant） |
| **FL-08** | 決済フロー：インボイス型（与信審査 → 債権譲渡 → 支払案内） | SC-3 / SC-4 | P-A/P-O, T-A, T-CO, B, SYS | 🔴 必須 | Journey 2B フェーズ 2B-3 / Journey 2C フェーズ 2C-3 / Journey 4A 全体 / Journey 4B 全体 |
| **FL-09** | 着金検知 ＋ 照合 ＋ スイープ（自動） | 全スキーム | SYS | 🔴 必須 | Journey 3 フェーズ 3-5 / Journey 4A フェーズ 4A-4 / Journey 4B フェーズ 4B-4 |
| **FL-10** | 照合差異 ＋ 例外処理（オペレーター手動対応） | 全スキーム | P-O, T-A, SYS | 🔴 必須 | Journey 5 ケースF |
| **FL-11** | 不足入金フロー（猶予期間 → 自動返金） | SC-1 / SC-2のみ | B, SYS | 🔴 必須 | Journey 3 フェーズ 3-6 / Journey 5 ケースB（SC-3/SC-4はケースC） |
| **FL-12** | 超過入金フロー | 全スキーム | B, SYS | 🔴 必須 | Journey 5 ケースD |
| **FL-13** | オフランプ ＋ Seller Fiat送金 | 全スキーム | SYS, T-SA | 🔴 必須 | Journey 1 フェーズ 1-5 / Journey 2 フェーズ 2-4 |
| **FL-14** | 返金フロー①（決済完了後のキャンセル） | 全スキーム | P-A, T-A, B, SYS | 🔴 必須 | Journey 5 ケースA |
| **FL-15** | 返金フロー②（不足入金 自動解消） | SC-1 / SC-2のみ | SYS, B | 🔴 必須 | Journey 5 ケースB |
| **FL-16** | ペイメントリンク期限切れ（SC着金済みの場合） | 全スキーム | SYS, T-A, B | 🟡 高優先度 | Journey 5 ケースE |
| **FL-17** | TRADOMダッシュボード ＋ レポート | 全スキーム | T-SA, T-A | 🟡 高優先度 | Journey 1 フェーズ 1-6 |
| **FL-18** | 加盟店ダッシュボード ＋ レポート | 全スキーム | P-A, P-O | 🟡 高優先度 | Journey 2 フェーズ 2-5 |

---

## FL-01：TRADOMユーザー ログイン・登録

**対応US：** P1-US-01 ｜ **アクター：** T-SA, T-A, T-CO

```
【ログイン】
ユーザーがユーザー名・パスワードを入力 → 認証 → 役割別ダッシュボードへ遷移

【新規ユーザー登録（T-SAのみ実行可能）】
T-SAがユーザー登録フォームに入力（名前・メール・役割・権限）
→ アカウント作成 → 招待メール送信
→ ユーザーが初回パスワード設定 → ログイン
```

**UX考慮点：** 役割によりログイン後のナビゲーションが変わる。パスワードリセット・MFAは低優先度（初回ローンチ対象外）。

---

## FL-02：加盟店 ログイン・ユーザー管理

**対応US：** P2-US-01 ｜ **アクター：** P-A, P-O

```
【ログイン】
加盟店ユーザーがユーザー名・パスワードを入力 → 認証 → Partner Dashboardへ遷移

【ユーザー管理（P-Aのみ実行可能）】
P-Aがチームメンバー（P-O）のアカウントを新規登録 → 権限（管理者 / 担当者）を設定 → 招待メール送信
P-Aはアカウントを有効化/無効化できる
```

---

## FL-03：加盟店オンボーディング

**対応US：** P1-US-06 ｜ **アクター：** T-A, P-A

```
T-Aが加盟店登録フォームに入力（法人名・住所・代表者・銀行口座等）
→ システムが銀行口座名義と法人名を自動照合
→ ✅ 一致 → ステータス「Active」→ 加盟店に招待メール送信
→ ❌ 不一致 → T-Aに確認アラート
```

**法的ゲート：** 銀行口座名義と法人名の一致確認（AML対策）

---

## FL-04：クライアント登録 ＋ KYC審査

**対応US：** P2-US-04, P3-US-01, P3-US-02 ｜ **アクター：** P-A, P-O, T-CO

```
【Step 1：クライアント情報登録（P-A / P-O）】
法人名・住所・代表者・UBO情報・送金元ウォレットアドレス・銀行口座を入力
必要書類（法人登記・本人確認書類）を添付アップロード
→ ステータス「審査中（Pending Review）」

【Step 2：KYC審査（T-CO）】
T-COが審査キューで確認 → 承認 / 却下 / 追加情報要求
→ P-Aにステータス変更通知（ダッシュボード + メール）

【Step 3：承認後】
ステータス「Active」→ FL-05（ウォレット割当）トリガー
```

**注意：** 初回ローンチではBridge/Nium外部連携なし。手動審査で対応。

---

## FL-05：ウォレット割当

**対応US：** P1-US-06, P4-US-02 ｜ **アクター：** T-A, SYS

```
KYC承認後 → T-Aまたはシステムが精算ウォレットを払い出し
設定：SC種類（USDC / USDT / JPYC）・チェーン（ETH / Polygon 等）
→ ウォレットアドレスをクライアントに永続的に紐づけ
→ Sellerはこのウォレットに一切アクセスできない
```

---

## FL-06：決済フロー — 支払先履行型（自社EC）

**対応US：** P1-US-02, P1-US-03, P2-US-02, P2-US-06, P2-US-07, P4-US-01〜04
**スキーム：** SC-1 ｜ **アクター：** P-A/P-O, B, SYS

```
【取引登録（P-A / P-O）】
クライアント選択・金額・通貨・商品名・支払期限を入力
インボイスPDF添付（任意）
→ ペイメントリンク（QRコード付き）生成 → ステータス「Pending」

【取引モニタリング（SYS）】
BuyerがリンクにアクセスするとAML/CFT・制裁スクリーニング自動実行
NG → リダイレクト / OK → 同意画面表示

【同意画面（Buyer）】
全必須項目への明示同意 → 「確認して支払う」タップ
→ 三者同時成立：①売買契約 ②債権譲渡 ③代物弁済契約
→ 同意ログ保存

【支払い画面（Buyer）】
送金先ウォレットアドレス（QR + テキスト）・SC金額・カウントダウンタイマー・
チェーン確認・ガス代注意書きを表示
Buyerがウォレットアプリ（外部）でSCを送金

【着金後 → FL-09へ】
全額着金確認 → 債務消滅
→ SellerにTRADOMから「発送可能通知」（ダッシュボード + メール + Webhook）
→ Sellerが出荷 → FL-13（オフランプ・Fiat送金）
```

---

## FL-07：決済フロー — 支払先履行型（プラットフォーマー/PSP経由）

**スキーム：** SC-2 ｜ **アクター：** P-A/P-O, B, SYS, Platform（API連携）

FL-06と同一フロー。以下の差分のみ：

```
取引登録はLingble等のプラットフォームAPIから自動送信される場合あり
支払い画面に「お支払い先はトレーダム株式会社のウォレットです
（Lingble・DENIMIOのウォレットではありません）」を明示
```

---

## FL-08：決済フロー — インボイス型（与信審査 → 債権譲渡 → 支払案内）

**対応US：** P2-US-08, P2-US-06, P4-US-01〜04
**スキーム：** SC-3 / SC-4 ｜ **アクター：** P-A/P-O, T-A, T-CO, B, SYS

```
【Step 1】SC-3：商品発送完了 / SC-4：インボイス確定
【Step 2】P-Aがインボイス情報をTRADOMに提出（Buyer情報・金額・期日・商品等）
【Step 3】TRADOMがBuyer与信審査実施
  ❌ 却下 → 加盟店に理由コードで通知。TRADOM経由では処理不可。
  ✅ 承認 → 個別債権譲渡成立（承認後は未払いのみを理由に譲渡取消し不可）
           審査記録・承認者ID・タイムスタンプを証跡保存
【Step 4】P-Aが「債権譲渡通知」ボタンを押す
  → SYSがBuyerへメール自動送信（支払案内リンク付き）
【Step 5】BuyerがリンクにアクセスしてAML/CFTスクリーニング
  → 同意画面（SC決済契約の成立タイミング）
  → 同意ログ保存（タイムスタンプ・IP・Buyer識別子・ウォレット・インボイス参照・同意文言バージョン）
【Step 6】BuyerがSC送金 → FL-09へ
【Step 7】全額着金確認 → 債務消滅
  → SellerにTRADOMから「支払完了通知」
  → SC-4のみ：この通知をトリガーにSellerが発送
  → FL-13（オフランプ・Fiat送金）
```

---

## FL-09：着金検知 ＋ 照合 ＋ スイープ

**対応US：** P4-US-02, P4-US-03, P4-US-04 ｜ **アクター：** SYS

```
【着金検知】
SYSが精算ウォレットへの着金を検知
受取記録作成：SC種類・金額・送金元ウォレット・受取ウォレット・ブロックチェーン確認時刻

【照合（トランザクション識別）】
照合ロジック：
  1. 金額完全一致 → 該当取引を特定
  2. 複数一致 → 直近の「期待支払日時」に最も近い取引を優先
  3. 一致なし / 特定不可 → 「Pending Identification」→ P-Oに手動照合依頼

【最終照合検証】
送金元ウォレットがホワイトリスト登録済みか確認
着金額が許容誤差範囲内か確認（例：±0.1%）
  ✅ 一致 → ステータス「Verified」
  ❌ 差異あり → ステータス「Discrepancy Detected」→ FL-10へ

【スイープ（内部送金）】
「Verified」確認後 → 精算ウォレット → マスターウォレットへSCを自動送金
ブロックチェーン確認後 → ステータス「Funds Collected」→ FL-13トリガー
```

---

## FL-10：照合差異 ＋ 例外処理

**対応US：** P4-US-04 ｜ **アクター：** P-O, T-A, SYS

```
「Discrepancy Detected」ステータス → オペレーターキューに積まれる
P-O / T-Aが差異内容を確認

対応アクション：
  ① 修正（Correct） → 登録情報を修正 → 再照合実行
  ② 承認オーバーライド → 理由入力必須 → 承認者ID・タイムスタンプ・理由を証跡記録
     注意：SC-1のみ適用可
           SC-3の一部入金オーバーライドは不可 → T-COへエスカレーション

承認後 → ステータス「Verified」→ スイープ実行
```

---

## FL-11：不足入金フロー（SC-1 / SC-2のみ）

**対応US：** P5-US-02 ｜ **アクター：** B, SYS

```
SYSが不足入金を検知
→ BuyerにSC不足通知（メール + 支払画面）「残り必要金額：○○USDC」
→ 猶予タイマー起動（例：1時間）

  ✅ タイマー内に残額入金 → 全額達成 → 正常処理
  ❌ タイマー切れ → 代物弁済契約解消
              → 受取済みSCをBuyerの送金元ウォレットに自動返金（ガス代Buyer負担）
              → Sellerにキャンセル通知

※ SC-3 / SC-4には適用しない（T-COエスカレーション）
※ 余剰額がガス代未満の場合は返金しない（規約に記載）
```

---

## FL-12：超過入金フロー

**アクター：** B, SYS ｜ **ステータス：** ⚠️ 仕様未確定

```
SYSが超過入金を検知 → 契約額分で債務消滅（✅ 全額充足）
余剰SCをBuyerの送金元ウォレットへ返金（ガス代Buyer負担）
余剰額がガス代を下回る場合は返金しない
Buyerに完了通知
```

---

## FL-13：オフランプ ＋ Seller Fiat送金

**対応US：** P1-US-04, P1-US-05 ｜ **アクター：** SYS, T-SA

```
「Funds Collected」確認 → SC → 法定通貨変換（DEX/CEX等の最適ルート）
変換レートを管理画面に記録
トレーダムが手数料（0.5%）を控除

【Seller Fiat送金】
締切日：弁済日が属する月の末日
支払日：翌月末日（個別契約がある場合は別途）
初回ローンチ：JPYのみ（外為口座開設後にUSD対応）

送金完了記録保存：元SC受取額・変換レート・手数料額・純振込金額・送金番号
```

---

## FL-14：返金フロー① — 決済完了後のキャンセル

**対応US：** P5-US-01 ｜ **アクター：** P-A, T-A, B, SYS

```
P-AがTRADOMダッシュボードでキャンセルフラグを設定
  ※ BuyerへのFiat直接返金は禁止。必ずTRADOM経由。
売買契約取消し → 債権譲渡契約解除
Sellerが受取済み代金（Fiat）をTRADOM指定口座に返金
T-Aが入金確認 → 返金を承認
SYSがBuyerの送金元ウォレットへSCを返金

返金金額算定（"Original Fiat Value"原則）：
返金実行時のレートでFiat建て金額をSCに再換算
控除：初回決済手数料 + ガス代
返金リンク有効期限：24時間

Sellerに完了通知（ダッシュボード + メール）
Buyerに完了通知
```

---

## FL-15：返金フロー② — 不足入金自動解消

FL-11と連動。Journey 5 ケースB参照。

---

## FL-16：ペイメントリンク期限切れ（SC着金済みの場合）

**ステータス：** ⚠️ 仕様未確定

```
有効期限切れ後にSCが着金 → 「Pending Identification」フラグ
T-Aへアラート → 手動確認 → Buyerへ連絡 → SC返金手続き
```

---

## FL-17：TRADOMダッシュボード ＋ レポート

**対応US：** P1-US-07 ｜ **アクター：** T-SA, T-A

```
【サマリーメトリクス（フィルター：本日 / 直近7日 / 月次 / カスタム）】
取引件数合計 / 取引ボリューム合計 / 手数料合計
資産種類別内訳（USDC / USDT / JPYC 等）/ チェーン別内訳

【直近50件取引テーブル】
日時 / クライアント名 / 取引種別 / 金額 / ステータス / 手数料
クライアント詳細・取引詳細へのリンク

【オペレーションアラート（上部優先表示）】
「Failed」ステータス / X時間以上「Pending」の取引
```

---

## FL-18：加盟店ダッシュボード ＋ レポート

**対応US：** P2-US-05 ｜ **アクター：** P-A, P-O

```
【サマリーメトリクス】
「Completed」取引に基づく総ボリューム・手数料

【取引テーブル（フィルター可）】
クライアント名 / インボイス番号 / 金額 / ステータス / 手数料

【決済スケジュール表示】
⚠️ 未定義 → 要設計
```

---

## 支払状態遷移図

```
[取引登録]
     │
     ▼
 PENDING（支払待ち）──────────────────────────── EXPIRED（期限切れ）
     │
     ├── 不足入金（SC-1/2）→ 猶予期間 → REFUNDED（自動返金）
     │
     ▼
 PENDING IDENTIFICATION（手動照合待ち）
     │ P-Oが手動照合
     ▼
 MATCHED（照合完了）
     │
     ├── 差異あり ──▶ DISCREPANCY DETECTED
     │                         │ P-O / T-Aが対応
     │                         ▼
     │                    VERIFIED
     │                         │
     ◄─────────────────────────┘
     ▼
 VERIFIED（検証済）
     │
     ▼
 FUNDS COLLECTED（SCスイープ完了）
     │
     ▼
 COMPLETED（Fiat決済完了）
     │（問題発生時）
     ▼
 FAILED ──▶ リトライキュー
```

---

## 権限マトリクス

| 機能 | T-SA | T-A | T-CO | P-A | P-O | Buyer |
|---|---|---|---|---|---|---|
| 加盟店アカウント管理 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| ウォレット払い出し | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| ペイメントリンク作成 | ✅ | ✅ | ❌ | ✅（自社分） | ✅（自社分） | ❌ |
| 取引登録・インボイス添付 | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ |
| SC送金（支払い） | — | — | — | — | — | ✅ |
| 取引参照 | ✅（全件） | ✅（全件） | ✅（全件） | ✅（自社分） | ✅（自社分） | ❌ |
| 照合差異 オーバーライド | ✅ | ✅ | ✅ | ❌ | ✅（SC-1のみ） | ❌ |
| 返金申請 | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
| 返金承認 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| KYC審査（承認/却下） | ✅ | ✅ | ✅（専任） | ❌ | ❌ | ❌ |
| Fiat取引作成 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| FXレート管理 | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| 手数料設定 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |

---

## 未解決事項・UXギャップ

### 🔴 ブロッカー（解決なしでは設計確定不可）

| # | 課題 | 影響範囲 |
|---|---|---|
| 1 | **レートロックのタイミング：** 同意時点でSC金額が確定するか、着金時点で再計算されるか | 支払い画面のレート表示・カウントダウンタイマー設計（Journey 3 / 4A / 4B） |
| 2 | **同意画面の法的文言：** 債権譲渡通知・代物弁済合意の正確な表現。MHM確定待ち。 | 同意画面は文言確定まで設計確定不可（Journey 3 / 4A / 4B、それぞれ文脈が異なる） |
| 3 | **国内Buyer（B2）向け要件：** 日本居住者が海外発行のSCで支払う際に特別な開示・同意要件があるか | B2フローの同意・支払画面設計 |
| 4 | **ローンチ時のサポートSC/チェーン確定** | チェーンセレクター・QRコード・ウォレットアドレス表示 |
| 5 | **スクリーニングNGのUX：** Buyerへの表示内容・文言 | 却下画面設計（Journey 3 / 4A / 4B） |

### 🟡 高優先度

| # | 課題 | 影響範囲 |
|---|---|---|
| 6 | **超過入金の取り扱い確定：** 返金 / クレジット / 保留 | 支払確認画面・通知文言 |
| 7 | **期限切れリンク + 着金済みの返金フロー確定** | 期限切れ状態画面・通知設計 |
| 8 | **発送前キャンセルのUX** | キャンセルフロー画面 |
| 9 | **チェーン選択時の警告表示の強度** | 支払指示画面（Journey 3 / 4A / 4B） |
| 10 | **照合差異オペレーター画面の設計** | オペレーターダッシュボード |
| 11 | **コンプライアンス担当者の画面構成** | 管理画面ナビゲーション |
| 12 | **決済スケジュール表示（加盟店向け）** | Journey 2A / 2B / 2C フェーズ 2X-5 |

---

## スコープ外（初回ローンチ）

| 機能 | 備考 |
|---|---|
| Bridge / Nium 外部コンプライアンス連携 | 初回は手動KYC審査で代替 |
| JPY→JPYC受取 | 後日実装 |
| USD決済（Seller受取） | 外為口座開設後に対応 |
| SolanaチェーンのネイティブSC | Bridge経由は将来対応 |
| 加盟店自己登録フォーム | Phase 2 |
| MFA（Google Authenticator） | 低優先度 |
| パスワードリセット | 低優先度 |
| CSV一括登録・API登録 | 低優先度 |
| EURCその他のSC追加 | 後日追加 |

---

*このドキュメントの管理：トレーダム プロダクト / UXチーム*
*Buyer向けUI文言の最終確定は必ず森・濱田松本法律事務所のレビューを経ること*
*最終更新：2026-05-14*