# TRADOM Payment — UX Design Background Reference **Version:** 0.1 (Draft) **Last updated:** 2026-05-11 **Status:** Internal working document — based on user stories (Parts 1–5), user flow spec, action plan Ver.1.1, and MHM legal brief Ver.1.4 --- ## Table of Contents 1. [Service Overview](#1-service-overview) 2. [Legal Framework — Why UX Must Understand This](#2-legal-framework) 3. [Actors & Personas](#3-actors--personas) 4. [Transaction Types](#4-transaction-types) 5. [Master User Flow — Payment Journey (Pre-Pay Type)](#5-master-user-flow--pre-pay-type) 6. [Master User Flow — Invoice-Based Post-Pay Type](#6-master-user-flow--invoice-based-post-pay-type) 7. [Master User Flow — Platform / PSP Type (Lingble × DENIMIO)](#7-master-user-flow--platform--psp-type) 8. [Refund & Cancellation Flows](#8-refund--cancellation-flows) 9. [Admin & Operator Flows](#9-admin--operator-flows) 10. [Payment States Reference](#10-payment-states-reference) 11. [Edge Cases & Exception Handling](#11-edge-cases--exception-handling) 12. [Role Permission Matrix](#12-role-permission-matrix) 13. [Open UX Questions & Gaps](#13-open-ux-questions--gaps) 14. [Glossary](#14-glossary) --- ## 1. Service Overview **TRADOM Payment** (internal codename: **Kilimanjaro**) is a stablecoin payment settlement service targeting cross-border e-commerce merchants (Sellers) and their overseas/domestic buyers (Buyers). ### Core Value Proposition | Party | Benefit | |---|---| | **Seller (Client A)** | Transacts in fiat currency as usual. No crypto exposure. Gets paid in fiat (JPY or USD). | | **Buyer (Client B)** | Can pay with stablecoins (USDC, USDT, JPYC, etc.) across multiple chains. No credit card needed. | | **TRADOM** | Acts as intermediary — receives SC from Buyer, converts to fiat, settles to Seller after fee deduction. | ### What This Service Is NOT - It is **not** a simple payment gateway where TRADOM holds Seller's funds as an agent. - It is **not** a crypto exchange for the Buyer. - TRADOM does **not** bear FX risk or depeg risk. Rates are based on the actual conversion rate at time of settlement. --- ## 2. Legal Framework > **Critical for UX designers.** The entire product is built on a specific legal structure. Every screen that touches Buyer consent, payment instructions, or confirmation must be designed with this in mind. ### 2.1 The Two-Law Mechanism (債権譲渡 + 代物弁済) The service operates under Japanese civil law using a combination of two legal concepts: #### 債権譲渡 (Assignment of Receivables) Seller assigns their right to collect payment from Buyer → to TRADOM. - After assignment, **TRADOM becomes the legal creditor** — Buyer now owes TRADOM, not Seller. - This means TRADOM is collecting its *own* receivable when it receives stablecoin. It is not "handling Seller's money." - This is the legal basis that allows TRADOM to operate as a settlement agent without necessarily requiring a funds transfer license (subject to ongoing regulatory review). #### 代物弁済 (Payment in Kind / Substitute Performance) Buyer agrees to settle the fiat-denominated debt → by sending stablecoin instead of fiat currency. - The original debt is denominated in fiat (e.g., USD 100). - Buyer agrees: "I will settle this debt by sending USDC equivalent." - **Debt is extinguished only when the full agreed amount arrives on-chain** (not at the moment of agreement). ### 2.2 Legal Timeline — When Does What Happen? ``` [Contract Formation] [Payment Execution] [Debt Extinguishment] ↓ ↓ ↓ Buyer agrees to terms Buyer sends stablecoin Full amount confirmed (Step 7 in flow) (Step 8 in flow) on blockchain (Step 9) ``` > **UX implication:** The confirmation screen after Buyer sends SC must clearly communicate that the transaction is only complete once full amount is confirmed — not at the moment of wallet submission. ### 2.3 Why the Consent Screen Is Legally Critical Buyer must explicitly agree to ALL of the following at Step 7: 1. That the original Seller-Buyer sales contract is fiat-denominated 2. That Seller has assigned the receivable to TRADOM 3. That Buyer agrees to pay TRADOM (not Seller) in stablecoin 4. The exact fiat amount owed 5. The payment deadline 6. The stablecoin type and blockchain network they will use 7. TRADOM's Terms of Service **Missing or ambiguous consent = the entire legal scheme collapses.** This screen cannot be a simple "I agree" checkbox. Each element above must be presented and confirmed. ### 2.4 Transaction Monitoring Gate Before legal consent is obtained, TRADOM performs a transaction screening check. If screening result = **NG** → redirect Buyer back without displaying the consent screen. No legal agreement is formed. > Source: *TRADOM AML/CFT体制のフレームワーク（概要）* #### 2.4.1 Cross-Border EC Screening (5-Step Process) For all TRADOM Payment transactions (SC-1 / SC-2 / SC-3 / SC-4), the following sequential checks are applied: | Step | Check | Detail | Outcome | |---|---|---|---| | **Step 1** | 制裁対象国チェック (Sanctions Country) | Client B's country of residence is checked against sanctions lists (US Treasury OFAC, Japan MOF). | **Sanctioned country → 取引停止 (transaction blocked)**. No further processing. | | **Step 2** | 金額閾値チェック (Amount Threshold) | Transaction amount is auto-evaluated. | **< $3,000 → auto-approved.** ≥ $3,000 → proceed to Step 3. | | **Step 3** | 顧客情報照合 (Customer Info Matching) | Client B's info is matched against sanctions person lists using TRADOM's proprietary similarity scoring. Reference: `shisantouketsu20260305.xlsx` | **Similarity < 80% → approved.** ≥ 80% → proceed to Step 4. | | **Step 4** | 取引パターン検知 (Transaction Pattern Detection) | Flags: ① Same Client B purchases same product 10+ times within 7 days, OR ② Single transaction ≥ $10,000. | **Neither condition met → auto-approved.** Either condition met → alert → Step 5. | | **Step 5** | AMLチームレビュー (AML Team Review) | Manual review by AML team: ① Price anomalies (product value mismatch), ② Structuring patterns (split payments), ③ Self-dealing (Client A ↔ Client B identity overlap). | **Clear → approved.** Suspicious → CCO escalation (SAR filing if warranted). **High risk → 取引停止.** | **Record Retention:** All AML review records (Alert ID, Customer ID, Transaction ID, review content, reviewer, decision, timestamp) are retained for **7 years**. #### 2.4.2 Trade-Related Payment Screening (Invoice-Based: SC-3 / SC-4) For invoice-based transactions, an additional trade compliance layer applies: | Step | Role | Check | |---|---|---| | **① 取引受付** | Operations | Collect required documents from Client A: Invoice (必須), Purchase Order, Contract, Packing List, Bill of Lading (as needed). | | **② 書類レビュー** | Trade Compliance | **Ⅰ. Product Eligibility:** Sanctions items, dual-use goods, CITES restrictions. **Ⅱ. Price Reasonableness:** Market price deviation, economic rationality. **Ⅲ. Entity Integrity:** Verify real business existence, check for paper companies, confirm trade flow consistency. | | **③ AMLチーム判断** | AML / CCO | **Clear → approved.** Need info → request additional documents from Client A. **Suspicious → 取引停止 + CCO escalation.** | Records are retained for **7 years**. ### 2.5 KYC / KYB Data Requirements > Source: *TRADOM AML/CFT体制のフレームワーク（概要）* #### 2.5.1 Client A (Merchant / KYB) | Category | Required Fields | |---|---| | **Basic Info** | Entity type, Company name, Email, Country, Prefecture, Address, Postal code, Phone, Tax ID, Industry, Business registration number, Establishment date, Registered address/postal code/country | | **Optional** | Sub-industry, Source of funds, Geography/jurisdiction (sending/receiving country), Monthly expected activity, Account purpose | | **Verification Docs** | Certificate of incorporation, Articles of association, Shareholder register, Proof of business address, Business activity documentation | #### 2.5.2 Client A — Beneficial Ownership Information (BOI) BOI is required for **every individual or entity holding >25% ownership or control** of Client A. | Category | Required Fields | |---|---| | **Entity BOI** | BOI entity name, Country, Prefecture, Address, Postal code, Tax ID, Ownership percentage | | **Individual BOI** | First/Last name, Title, Affiliation, Country, Prefecture, Address, Postal code, Tax ID, Date of birth, Nationality, Ownership percentage | | **Verification** | Government-issued ID copy (passport for non-Japanese nationals) | #### 2.5.3 Client B (Buyer) **Individual Client B:** | Field | Required | |---|---| | Last name, First name, Email, Country, Address, Postal code | 必須 | | Phone, Industry | オプション | > Note: Client B info is submitted by Client A (the merchant), not directly by Client B. **Corporate Client B:** | Field | Required | |---|---| | Company name, Representative name, Country, Address | 必須 | --- ## 3. Actors & Personas ### System Actors | Actor | Role | Entry Point | |---|---|---| | **TRADOM Super Admin** | Full system control. FX management, audit, system config. | `/administration/` | | **TRADOM Admin** | Day-to-day operations: client management, KYC review, transaction monitoring, refund approval. | `/admin/` | | **TRADOM Compliance Officer** | Specialized TRADOM Admin role. Reviews KYC submissions from Partners before clients can go Active. | `/admin/` (separate queue) | | **Client A / Partner Admin** | Merchant/Seller. Manages clients, creates payment links, views transactions, applies for refunds. | `/partner/` | | **Client A / Partner Operator** | Supports Partner Admin. Handles daily transaction registration and reconciliation discrepancies. | `/partner/` | | **Client B / Buyer** | End-payer. Uses a payment link to send stablecoin. | Public payment URL | | **System (Kilimanjaro)** | Automated backend: wallet monitoring, matching, sweeping, off-ramp, notifications. | Webhook endpoints | ### Key Personas for May 2026 Pilot Transactions | ID | Name | Role | Location | Transaction | |---|---|---|---|---| | B1 | ひろみ (母) | Buyer | Overseas | DENIMIO denim (pre-pay), Edute toy (invoice/post-pay) | | B2 | ひなた | Buyer | Japan (domestic) | DENIMIO denim (pre-pay), Edute toy (pre-pay) | | — | DENIMIO | Seller / Client A | Japan | Cross-border EC via Lingble platform | | — | Lingble | Platform (non-MoR) | — | Operational support only. Does NOT receive/hold/transfer SC. | | — | Edute | Seller / Client A | Japan | Direct EC — two contract types (pre-pay + post-pay) | --- ## 4. Transaction Types TRADOM Payment supports three transaction types, defined by **fulfillment order** (not by industry or customer type). ### Type 1: 支払先履行型 (Pre-Pay / Payment-First) Buyer pays first → Seller ships after payment confirmed. - **Typical use:** Cross-border EC, Proforma Invoice, prepaid orders - **Risk profile:** Low for TRADOM and Seller. Buyer bears timing risk. - **Key UX requirement:** Seller must NOT be prompted to ship until TRADOM sends confirmation. Payment link must expire if not paid within deadline. ### Type 2: 商品引渡し先履行型 (Post-Pay / Delivery-First / Invoice-Based) Seller delivers goods first → Buyer pays after, based on invoice. - **Typical use:** Export invoice (Net 30/60), B2B transactions, Edute B1 transaction - **Risk profile:** Higher. TRADOM must approve debt assignment before accepting the receivable. - **Key UX requirement:** TRADOM approval step is mandatory. Once approved, Buyer non-payment alone does NOT automatically unwind the assignment. ### Type 3: プラットフォーマー／PSP経由型 (Platform / PSP-Mediated) TRADOM provides service through a platform operator (e.g., Lingble) to multiple Sellers (e.g., DENIMIO). - **Sub-types:** - **Non-MoR / Agency type (Lingble model):** Platform is NOT the Merchant of Record. Seller remains the legal Seller and debt assignor. - **MoR type:** Platform is the Merchant of Record. Platform assigns the receivable to TRADOM. - **Technical connector type:** Platform is just a technical integration layer. - **Key UX requirement:** Stablecoin must flow directly from Buyer wallet → TRADOM wallet. Platform must never touch SC. This must be visually clear to Buyer on the payment screen. --- ## 5. Master User Flow — Pre-Pay Type > Applies to: DENIMIO B1, DENIMIO B2, Edute B2 ``` [Seller Site] [TRADOM Payment] [Blockchain] │ │ │ ├─ Buyer selects │ │ │ "TRADOM Payment" │ │ │ │ │ ├─ Redirect to TRADOM ────────>│ │ │ ├─ Receive order info │ │ ├─ Display: fiat amount, │ │ │ deadline, SC options │ │ │ │ │ ┌─────────┤ Transaction Monitoring │ │ │ NG │ (AML/CFT screening) │ │<───────────────────┘ │ │ │ Redirect back │ │ │ (no consent shown) │ OK │ │ ↓ │ │ ┌─────────────────────┐ │ │ │ CONSENT SCREEN │ │ │ │ • Fiat amount │ │ │ │ • Assignment notice │ │ │ │ • 代物弁済 agreement│ │ │ │ • Deadline │ │ │ │ • SC type + chain │ │ │ │ • Terms of Service │ │ │ └─────────┬───────────┘ │ │ │ Buyer agrees │ ├─<── Redirect back ───────────┤ │ │ to Seller checkout │ │ │ │ │ ├─ Buyer clicks │ │ │ "Confirm Purchase" ─────────> │ │ │ │ │ ┌────────────────────┤ │ │ │ THREE SIMULTANEOUS│ │ │ │ LEGAL EVENTS: │ │ │ │ ① Sales contract │ │ │ │ ② Debt assignment │ │ │ │ ③ 代物弁済 active │ │ │ └────────────────────┤ │ │ │ │ │ ┌─────────────────────┐ │ │ │ PAYMENT SCREEN │ │ │ │ • QR code │ │ │ │ • Wallet address │ │ │ │ • SC amount (live │ │ │ │ rate update) │ │ │ │ • Countdown timer │ │ │ │ • Chain selector │ │ │ └─────────┬───────────┘ │ │ │ │ │ │<── Buyer sends SC ──────────>│ │ │ │ │ ├─ Detect deposit │ │ ├─ Match to transaction │ │ ├─ Verify: amount ✓, │ │ │ source wallet ✓ │ │ │ │ │ │ Full amount confirmed │ │ │ → Debt EXTINGUISHED ✓ │ │ │ │ ├─<── Ship notification ───────┤ │ │ │ │ │ ├─ Sweep SC to master wallet │ │ ├─ Off-ramp (SC → fiat) │ │ ├─ Settle to Seller bank │ ``` --- ## 6. Master User Flow — Invoice-Based Post-Pay Type > Applies to: Edute B1 (overseas, post-pay) ``` Step 1 Seller delivers goods / completes service Step 2 Invoice issued → fiat-denominated receivable established Step 3 Seller submits transaction data to TRADOM └─ Product info, invoice number, amount, currency, Buyer info, shipping destination Step 4 TRADOM conducts Buyer + transaction screening ├─ NG → Notify Seller. Debt assignment not accepted. └─ OK → Proceed to Step 5 Step 5 TRADOM approves. Debt assignment executed (Seller → TRADOM). └─ Individual assignment record (個別債権譲渡明細書) created. └─ From this point: Buyer non-payment alone does NOT unwind the assignment. Step 6 TRADOM sends to Buyer: • Debt assignment notification • Payment instruction • Deadline Step 7 Buyer agrees to (contract formation point): • Terms of Service • 代物弁済 agreement • Exact fiat amount • Payment deadline • SC type and blockchain network Step 8 Buyer sends stablecoin to TRADOM wallet Step 9 Full agreed amount confirmed on-chain → Buyer's fiat debt EXTINGUISHED ✓ → TRADOM notifies Seller: payment complete → Off-ramp: SC → fiat → Settlement to Seller bank account ``` ### Key Differences from Pre-Pay Type (UX Implications) | | Pre-Pay | Invoice Post-Pay | |---|---|---| | Transaction registration | Before payment | After delivery (Step 3) | | TRADOM approval screen | Not required | Required (Step 4–5) | | Consent screen trigger | At payment link open | After Buyer receives Step 6 notification | | Seller ships | After payment confirmed | Already shipped (Step 1) | | If Buyer doesn't pay | Order expires / cancelled | Assignment remains. TRADOM holds receivable. | --- ## 7. Master User Flow — Platform / PSP Type > Applies to: Lingble × DENIMIO (Non-MoR / Agency model) ### Role Responsibilities | Party | Does | Does NOT | |---|---|---| | **DENIMIO** (Seller / Client A) | Assigns receivable to TRADOM. Ships goods. | Receive or hold SC. | | **Lingble** (Platform) | Operational support: order info relay, post-payment logistics coordination. | Receive, hold, exchange, or transfer SC. Acts as non-MoR. | | **TRADOM** | Receives SC directly from Buyer. Converts and settles to designated payee. | — | | **Buyer (B1/B2)** | Sends SC directly to TRADOM wallet (NOT to Lingble). | — | > **Critical UX point:** The payment screen must visually confirm to Buyer that they are sending to **TRADOM's wallet**, not to Lingble or DENIMIO. This is both a legal and trust requirement. --- ## 8. Refund & Cancellation Flows ### 8.1 Post-Delivery Refund (P5-US-01) *Triggered after goods delivered, e.g. product return.* ``` Seller notifies TRADOM → Seller returns fiat funds to TRADOM bank account → TRADOM verifies receipt → TRADOM refunds SC to Buyer's source wallet → TRADOM notifies Seller: refund complete ``` ### 8.2 Underpayment — Grace Period (P5-US-02) *Buyer sends SC but amount is less than required.* ``` TRADOM detects underpayment → Notify Buyer: "Insufficient. Remaining balance: X" → Start countdown timer (e.g., 1 hour) ├─ Buyer sends remaining balance within timer → Full amount reached │ → Debt extinguished. Transaction proceeds normally. └─ Timer expires without resolution → 代物弁済 contract dissolved (unexecuted) → TRADOM auto-refunds original SC received → Buyer source wallet → TRADOM notifies Seller: transaction cancelled (insufficient funds) ``` ### 8.3 Pre-Delivery Cancellation *⚠️ Not yet defined in user stories. Required before launch.* Covers: Buyer or Seller cancels before shipment (Pre-Pay type only). - If SC already received → TRADOM refunds SC to Buyer - If SC not yet received → Order expires. No financial action needed. ### 8.4 Expired Payment Link (with funds received) *⚠️ Not yet defined. Required before launch.* Scenario: Buyer sends SC after the payment link has expired. - Funds arrive at TRADOM wallet but no active transaction record to match against - Required: Flag for manual review → notify Buyer → refund SC ### 8.5 Overpayment *⚠️ Not yet defined. Required before launch.* Scenario: Buyer sends more SC than required. - Debt is extinguished (full amount received) ✓ - Excess amount needs defined treatment: refund? credit? hold? ### 8.6 Wrong Chain / Wrong Address *⚠️ Not yet defined. Required before launch.* Scenario: Buyer sends SC on incorrect blockchain network. - Funds may be unrecoverable depending on chain - TRADOM liability needs to be capped via Terms of Service - Buyer-facing copy must clearly warn about chain selection --- ## 9. Admin & Operator Flows ### 9.1 TRADOM Admin — Daily Operations ``` Login → Dashboard ├─ Monitor Transactions │ ├─ Failed Tx → Retry │ └─ Flagged Tx → Manual review ├─ Manage Client A Accounts (/companies/) ├─ Review Refund Requests → Approve / Reject ├─ Review KYC Queue (Compliance Officer view) └─ Analytics (/analytics/) ``` ### 9.2 TRADOM Super Admin ``` Login → Admin Hub (/administration/) ├─ Fiat Transactions (/fiat-transactions/) │ ├─ Create Fiat Tx │ └─ Lock FX Rate / Initiate Transfer ├─ FX Rates (/fx-rates/) │ ├─ Create Custom Rate │ └─ View Rate History └─ System Admin (/admin/) ├─ Django Admin └─ Audit & Webhook Logs ``` ### 9.3 Client A (Partner) — Self-Service Dashboard ``` Login → Partner Dashboard (/partner/) ├─ Manage Clients (/partner/clients/) │ └─ Add Client → Upload KYC documents ├─ Payment Links (/partner/payment-links/) │ └─ Create Link (select client, SC, network, amount, expiry) ├─ Transactions (/partner/transactions/) │ └─ View Detail + Commission → Attach Invoice / EUC └─ Refunds └─ Apply for Refund → Track Status ``` ### 9.4 KYC / Compliance Flow ``` Partner submits Client B / Client A KYC documents → Stored in media/kyc_documents/ → Added to TRADOM Compliance Officer review queue → Compliance Officer reviews: ├─ Approve → Client status: Active │ → Trigger: External compliance integration (Bridge/Nium) │ ⚠️ NOTE: External integration OUT OF SCOPE for initial launch. │ Manual handling required for initial launch. └─ Reject → Notify Partner + Request re-upload ``` ### 9.5 Refund Lifecycle (Partner-Initiated) ``` Client A → POST refund request → TRADOM Admin notified → Admin: Approve / Reject ├─ Approved: │ → Initiate recall / payout reversal via Veem (or channel) │ → Webhook: status update from Veem │ → Confirm to Partner: COMPLETED └─ Rejected: → Notify Partner: REJECTED + reason ``` --- ## 10. Payment States Reference ### Transaction Status Lifecycle ``` PENDING IDENTIFICATION │ ▼ PENDING ──────────────────────────────── EXPIRED │ ▼ MATCHED ──── discrepancy ──── DISCREPANCY DETECTED │ │ │ Operator resolves │ │ ▼ ▼ PROCESSING ◄───────────────────────── VERIFIED │ ▼ FUNDS COLLECTED (SC swept to master wallet) │ ▼ COMPLETED (fiat settled to Seller) │ (if issue) ▼ FAILED → retry queue ``` ### Refund Status Lifecycle ``` PENDING → (Admin review) → APPROVED / REJECTED │ PROCESSING │ COMPLETED ``` --- ## 11. Edge Cases & Exception Handling | Scenario | Current Status | Handling | |---|---|---| | Buyer underpays | Defined (P5-US-02) | Grace period → auto-refund | | Buyer overpays | ⚠️ Not defined | TBD | | Payment link expires, SC arrives | ⚠️ Not defined | Manual review → refund | | Wrong chain/network sent | ⚠️ Not defined | Terms of Service cap + warn in UI | | Double payment (same invoice) | ⚠️ Not defined | TBD | | Stablecoin depeg during payment window | Partially defined | TRADOM not liable. Rate at actual conversion time. | | Off-ramp fails after SC collected | ⚠️ Not defined | SC in master wallet. No rollback story. | | Transaction screening NG | Defined (business flow) | Redirect to Seller. No consent shown. | | Reconciliation discrepancy | Defined (P4-US-04) | Operator override with audit log | | Buyer doesn't pay (invoice type) | Defined (MHM brief) | Assignment remains. TRADOM holds receivable. | | Inbound fiat unidentified (US bank) | Defined (P1-US-05) | Flag for manual review | --- ## 12. Role Permission Matrix | Capability | Super Admin | TRADOM Admin | Client A (Partner Admin) | Client A (Partner Operator) | Client B | |---|---|---|---|---|---| | Manage Client A accounts | ✅ | ✅ | ❌ | ❌ | ❌ | | Create wallets | ✅ | ✅ | ❌ | ❌ | ❌ | | Create payment links | ✅ | ✅ | ✅ (own) | ✅ (own) | ❌ | | Register transaction / invoice | ✅ | ✅ | ✅ | ✅ | ❌ | | Send stablecoin | — | — | — | — | ✅ | | View transactions | ✅ all | ✅ all | ✅ own | ✅ own | ❌ | | Retry failed transactions | ✅ | ✅ | ❌ | ❌ | ❌ | | Request refund | ✅ | ✅ | ✅ | ❌ | ❌ | | Approve refund | ✅ | ✅ | ❌ | ❌ | ❌ | | Create fiat transactions | ✅ | ❌ | ❌ | ❌ | ❌ | | Manage FX rates | ✅ | ❌ | ❌ | ❌ | ❌ | | Configure fees | ✅ | ✅ | ❌ | ❌ | ❌ | | Review KYC queue | ✅ | ✅ (Compliance Officer) | ❌ | ❌ | ❌ | | Django admin access | ✅ | 🔄 limited | ❌ | ❌ | ❌ | --- ## 13. Open UX Questions & Gaps The following items are unresolved and require decisions before detailed UX design can be finalized. ### 🔴 Blocking (Cannot design without resolution) | # | Question | Impact | |---|---|---| | 1 | **Rate lock timing:** Is the SC amount locked at Step 7 (consent) or recalculated at Step 9 (arrival)? | Payment screen design, rate display, countdown timer behavior | | 2 | **Consent screen legal copy:** What exact wording is required for the 債権譲渡 notice and 代物弁済 agreement? MHM must provide. | Consent screen cannot be built without approved copy | | 3 | **B2 domestic Buyer + overseas SC:** Are there specific display/consent requirements for a Japan-resident Buyer paying with a foreign-issued stablecoin? | Consent and payment screen for B2 flows | | 4 | **Supported wallets / chains at launch:** Which SC types and blockchain networks will be active at initial launch? | Chain selector, QR code, wallet address display | | 5 | **Screening NG UX:** What does Buyer see when transaction monitoring returns NG? Error message copy? | Rejection screen design | ### 🟡 High Priority (Design will need revision without resolution) | # | Question | Impact | |---|---|---| | 6 | **Overpayment handling:** What happens when Buyer sends excess SC? | Payment confirmation screen, edge case messaging | | 7 | **Expired link + funds received:** How is Buyer notified? What is the refund flow UX? | Expired state screen, notification design | | 8 | **Pre-delivery cancellation UX:** How does Buyer or Seller initiate cancellation before shipment? | Cancellation flow screen | | 9 | **Wrong chain UX:** How prominently must chain selection warnings be shown? | Payment instruction screen | | 10 | **Reconciliation discrepancy — Operator UX:** What does the manual review / override interface look like? | Operator dashboard design | | 11 | **TRADOM Compliance Officer role:** Is this a separate dashboard view or a queue within TRADOM Admin? | Admin navigation and access design | | 12 | **Settlement schedule display:** How does Client A see their pending/upcoming settlement amounts? | Partner dashboard design | ### 🔵 Post-Launch / Phase 2 | # | Item | |---|---| | 13 | MFA / 2-factor authentication for all admin roles | | 14 | Partner self-registration (currently admin-only) | | 15 | Bridge + Nium external compliance integration (explicitly out of scope for initial launch) | | 16 | Bulk client registration via CSV / API (P3-US-01) | | 17 | Screen-based consent capture (initial launch uses email/PDF) | --- ## 14. Glossary | Term | Meaning | |---|---| | **債権譲渡** | Assignment of receivables. Seller assigns the right to collect payment to TRADOM. | | **代物弁済** | Substitute performance / payment in kind. Buyer settles fiat debt by sending stablecoin. | | **代物弁済同意** | Buyer's agreement to pay in stablecoin instead of fiat. Legally required consent. | | **Client A** | Seller / Partner (merchant). Receives goods/service orders from Buyers. | | **Client B** | Buyer / End-payer. Sends stablecoin to complete purchase. | | **支払先履行型** | Pre-pay type: Buyer pays before Seller ships. | | **商品引渡し先履行型** | Post-pay / invoice type: Seller delivers before Buyer pays. | | **MoR** | Merchant of Record. The legal seller entity in a transaction. | | **PSP** | Payment Service Provider. | | **SC** | Stablecoin (e.g., USDC, USDT, JPYC). | | **Tx Hash** | Transaction hash. Unique identifier of a blockchain transaction. Used as payment proof. | | **Off-ramp** | The process of converting stablecoin → fiat currency. | | **Master Wallet** | TRADOM's central internal wallet. All collected SC is swept here before off-ramp. | | **Liquidation Wallet** | Client-specific persistent wallet assigned to each Client A. Used to receive SC. | | **Sweeping** | Automated transfer of SC from liquidation wallet → master wallet after reconciliation. | | **Kilimanjaro** | Internal system/product codename for TRADOM Payment. | | **MHM** | 森・濱田松本法律事務所. Law firm providing all contracts, consent language, and legal review. | | **改正資金決済法** | Revised Payment Services Act (Japan). Key regulatory framework governing the service. | | **経過措置** | Transitional / grandfathering provision under the revised law. May 2026 deadline is tied to this. | | **第三者対抗要件** | Third-party opposition requirements for debt assignment under Japanese civil law (Article 467). | | **JFSA** | Japan Financial Services Agency (金融庁). Regulator. | | **Bridge** | External crypto infrastructure provider (wallet whitelisting). Out of scope for initial launch. | | **Nium** | Cross-border payment rails provider (KYC sync, international transfer). Out of scope for initial launch. | | **Veem** | International payout / recall channel. Used for refund execution and USD→JP settlement. | | **Fireblocks** | Institutional digital asset custody and transfer platform. Used in JPY off-ramp channel. | | **SAR** | Suspicious Activity Report (疑わしい取引報告). Filed with authorities when a transaction is deemed suspicious. | | **CCO** | Chief Compliance Officer. Final escalation point for AML/sanctions decisions. | | **BOI** | Beneficial Ownership Information (実質的支配者情報). Required for all entities/individuals with >25% ownership of Client A. | | **TBML** | Trade-Based Money Laundering. Exploitation of trade transactions to disguise illicit funds. | | **OFAC** | Office of Foreign Assets Control (US Treasury). Maintains US sanctions lists. | | **Dual-use goods** | Products with both civilian and military applications, subject to export controls. | | **TRADOM USA Inc.** | US subsidiary of TRADOM Inc. Both entities fall under the AML/CFT framework. | --- *Document maintained by: TRADOM Product / UX team* *Legal review required before any Buyer-facing copy is finalized: 森・濱田松本法律事務所*