MoR：モデルと責任

1）レコード（MoR）の商人とは何ですか、なぜそれが必要なのですか

レコードの商人は、最終顧客に製品/サービスを正式に販売し、小切手/請求書を発行し、支払いを受け取り、税金と消費者の義務を負い、紛争を行い、銀行明細書（記述子）に反映される法人です。

• 規制当局と税金（GGR/VAT/GST/WHTを支払う場所）、
• 消費者責任（払い戻し/チャージバック、KYC/SoF、 RG）、
• 市場への参入の運用速度（他人のライセンス/MoRインフラストラクチャを使用して）、
• 金融ロジスティクス（マルチGEO、マルチ通貨、決済、FX）。

MoRよりも≠ PSP： PSP-お金を受け取るチャネル（インフラストラクチャ）、MoR-法律による売り手。アグリゲータは、MoRステータスなしでPSPにすることができます。MoRプロバイダは、そのスタック内にPSPを含めることができます。

2）基本的なMoRモデル

2.1.ダイレクトマーチャント（クラシック）

iGaming演算子自体はMoRです。

長所：ブランド、関税、データ、税金の完全な制御；仲介者の最低証拠金。
欠点：各国の複雑なライセンス/ローカル登録、VAT/GST、 GGR会計、WHT、 PCI DSS、 KYC/AML；長い市場への時間。

2.2.フルMoRプロバイダ

外部MoRはB2Cを販売しています。あなたはMoR 'yのコンテンツ/サービスプロバイダーです。

長所：クイックローンチ、VAT/GST/チャージバック/請求書のシフト、マーケットプレイス税、ローカルウォレット。
短所：MoRマージン、決済/データの制御が少ない、マーケティング/UXの制限、収益シェアの計算が困難。

2.3.リセラー/ディストリビューターMoR

再販業者パートナーは、あなたから「卸売」（B2B）を購入し、そのMoRの下でB2Cを販売しています。

長所：ローカルの専門知識、あなたのリスクを減らします。

短所： ブランド共食い、リセラーSLAへの依存のリスク

2.4.マーケットプレイス/プラットフォームMoR（多くの商人のための1つのMoR）

プラットフォーム-MoR；オペレーター/スタジオは「salespeople」ですが、MoRではありません。

長所：シングルチェック、PSP/メソッド集計、単一の財政化。
短所：複雑な分割決済、税金とレポートの割り当て、クロスライビリティリスク。

2.5.ハイブリッドモデル

グリーン市場-ダイレクトマーチャント、グレー/高価な市場-フルMoR/リセラー。

長所：速度/制御/コストのトレードオフ。
短所：会計、ルーティング、および「二重」レポートの複雑さの増加。

3）責任の概要： 誰が何に責任があるか

4）キャッシュ・フローと決済

4.1.ダイレクト（Direct

プレーヤー→PSP/acquirer→オペレータのアカウント（gross/net）。オペレーターはパートナー/税金を支払います。

4.2.フルMoR

プレーヤー→PSP MoR→MoR→報告書（レベニューシェア/CPA）に従ってオペレータへの支払い口座。手数料、付加価値税、払い戻し/CB-MoR内。可能なホールドバック/ローリングリザーブ。

4.3.マーケットプレイス・スプリット

プレーヤー→MoRプラットフォーム→分割決済：プラットフォーム、オペレータ、スタジオ、アフィリエイト（マイナス料金/税金）のシェア。

キー：カットオフ/T+Nの修正、資金調達通貨、FXルールと和解の儀式：'Tx→ファイル→資金'。

5）税金とMoR

VAT/GST （B2C）：チェックを持っている人、およびVAT/GST（通常はMoR）。ダイレクト-演算子。
GGR：管轄の規則に従って認可されたオペレーターによって支払われる（MoR ≠常にGGRの支払者）。
WHT：パートナーへの支払いの源泉徴収-支払う人（MoR/オペレーター）。
支払手数料PSP： MoRまたはオペレータから（モデルに従って）；ND/Finレポートで-別途。
財政/チェック処理：通常、MoR上のローカル要件（例えば、電子請求書、財政領収書）。

6）法律および契約（必須条件）

MoRの定義（各国/チャネルで誰ですか）、記述子、消費者保護の責任。
税金：VAT/GST/GGR/WHTを支払う人。グロスアップメカニクス、証明書交換（DTT、 VAT/EORI）。
KYC/AML/制裁：役割の割り当て、チェックのSLA、拒否/ブロックの権利。
返金/チャージバック：プロセス、タイミング、証拠ベース、損失を被る人。
データとプライバシー：GDPR/データ法、DPA、コントローラ/プロセッサの役割、国境を越えた伝送。
PSP/PCI DSS：商人アカウントを所有し、スキームの罰金を負う人。
設定/リザーブ：T+N、ローリングリザーブ、負のキャリーオーバー、監査/レポート。
不可抗力/制裁：フリーズ注文、終了権、エスクロー。

7）運用プロセス

地政学とライセンス：許可された市場のマトリックス（「Geoblocks」を参照）。
KYC/KYB/SoF： MoR/operator上の均一な標準そしてステップアップのルーティング。
Antifraudと3DS：設定、ABテスト、リスクのしきい値に対する責任。
支払のルーター：MoRモデルに従うBIN/method/PSP；フォールバックとカットオーバーの手順。
和解：毎日の「トランザクション↔決済ファイル↔資金調達」、分散レポート。
報告：オペレータ（GGR/NGR）とMoR （VAT/払い戻し/CB）のための個別のショーケース。

8）どのモデルを選択するか（Decision Matrix）

9） KPIとダッシュボード

モデル別のオールインテイクレート（PSP手数料+MoRマージン+FXスリッページ）。
geo/PSP/modelでパスをAR/DR/3DSします。
責任ある事業体による返金/チャージバック率と責任。
決済SLA： T+Nヒット率、資金調達遅延、準備残高。
税務エクスポージャー：MoRによるVAT/GST、オペレータによるGGR、パートナーによるWHT。
データ遅延と完全性-完全なMoRコンテキストを持つトランザクションの割合。

10）データとモデル（簡略化）

ref. mor_models (
model_id PK, name, type -- DIRECT      FULL_MOR      RESELLER      MARKETPLACE
, legal_role_b2c -- SELLER      PLATFORM
, fx_policy, refund_policy, chargeback_liability, vat_responsible, ggr_responsible, notes
)

payments. transactions (
id, user_id, method, provider, status, amount_original, currency_original,
settled_at, funded_at,
mor_model_id, mor_entity_id, descriptor, country_player,
vat_mode, ggr_mode, cb_liability_party, refund_owner, meta
)

finance. mor_settlements (
mor_entity_id, period_start, period_end, gross_sales, refunds, chargebacks,
vat_due, fees_psp, fees_mor, reserve_delta, net_payable_to_operator, currency
)

tax. ggr_rollup (
d, license_country, product, stakes, payouts, ggr, ggr_tax
)

tax. vat_ledger (
d, mor_entity_id, country, net_sales, vat_rate, vat_amount
)

11） SQLテンプレート

11.1.MoRモデルによる収益の内訳

sql
SELECT m. type AS mor_model,
DATE(t. settled_at) AS d,
SUM(t. amount_reporting) AS sales_rep,
SUM(CASE WHEN t. status='REFUNDED' THEN t. amount_reporting ELSE 0 END) AS refunds_rep
FROM dw. transactions_flat t
JOIN ref. mor_models m ON m. model_id = t. mor_model_id
WHERE t. settled_at BETWEEN:from AND:to
GROUP BY 1,2
ORDER BY 2,1;

11.2.Full-MoRで支払われるネット

sql
SELECT s. mor_entity_id,
SUM(s. gross_sales - s. refunds - s. chargebacks
- s. vat_due - s. fees_psp - s. fees_mor + s. reserve_delta) AS net_payable
FROM finance. mor_settlements s
WHERE s. period_start >=:from AND s. period_end <:to
GROUP BY 1;

11.3.GGR（オペレータ）vs VAT （MoR）

sql
SELECT g. d, g. license_country,
g. ggr, g. ggr_tax,
v.country AS vat_country, v.vat_amount
FROM tax. ggr_rollup g
LEFT JOIN tax. vat_ledger v ON v.d = g. d;

11.4.紛争の責任マトリックス

sql
SELECT t. id, t. mor_model_id, t. cb_liability_party, t. refund_owner,
CASE
WHEN t. cb_liability_party='MOR' THEN 'Escalate to MoR'
WHEN t. cb_liability_party='OPERATOR' THEN 'Handle internally'
ELSE 'Check contract'
END AS action
FROM payments. transactions t
WHERE t. status IN ('CHARGEBACK','DISPUTED')
AND t. settled_at BETWEEN:from AND:to;

12）セキュリティとデータ

PCI DSS： PANを「オン」に保管/処理する人。フルMoRでは、しばしばMoRでPANスコープ。
GDPR/プライバシー： DPAと役割（コントローラ/プロセッサ）、国境を越えた送信、データの最小化、保存期間のためのSCC/IDTA。
制裁/REP：誰がスクリーニングを行うか-契約および責任ログに記録します。
SCA/3DS：紛争の流れと証拠を設定する責任。

13）リスクとアラート

ポリシードリフト：割り当てられたMoRモデルなしのトランザクション-P1。
決済遅延：T+N MoRの支払いが違反-P1。
Variance VAT/GGR：計算されたレポートとMoRレポートの違い>しきい値-P2。
MoR/オペレータ側のCBスパイク-運用対策（3DS、制限、ルーティング）。
MoR決済によるFX Slippage-効果的な対参照を比較します。
データの完全性-ファイル/署名なしのレポート-支払いのために停止します。

14）ベストプラクティス（短い）

1.各GEO/チャネルのモデルを文書化する：誰がMoRであり、誰がVAT/GGRを支払い、誰がPANを保持し、誰が紛争の責任を負います。
2.別の店舗：食料品（GGR/NGR）とMoR-financial （VAT/払い戻し/CB/手数料）。
3.明確なSLA/しきい値と支払い/手数料/準備計算式を持つ契約。
4.フルMoRでもPSP ABルーティング-AR/DRとコスト。
5.ポリシーとディレクトリバージョニング（mor_model v1/v2）、決定論的再処理。
6.「Tx ↔決済↔資金調達」の毎日の和解、分散アラート。
7.法的トレース：各GEOの法的根拠（ライセンス、付加価値税、制裁）。

15）実装/移行チェックリスト

データ/ダイアグラム

• '参照。mor_models'、支払い。トランザクション'フィールド'mor_'
• ケース'mor_settlements'、 'vat_ledger'、 'ggr_rollup'を表示します。
• GEO/BIN/MoRバウンドルーティング

契約/プロセス

• MoR/リセラーとの契約：税金、紛争、データ、SLA、準備金。
• PCI/GDPR：役割、監査、DPIA。
• 操作：カットオフ/T+N、 FXルール、分散手順。

モニタリング/アラート

• 決済SLA、 VAT/GGR分散、CBスパイク、FXスリッページ。
• データの完全性/整合性とファイル署名。

概要

MoRは"別のPSPではありません。"これは、税金、消費者および運用上の責任を持つ売り手の法的役割です。ダイレクト、フルMoR、リセラー、マーケットプレイスを選択することは、スピード、コントロール、コスト、リスクのバランスです。各GEOのモデルを修正し、GGR（オペレータ）とVAT （MoR）の輪郭を分離し、和解と報告を自動化し、法的驚きなく予測可能な収益化を実現します。