MoR: Models and Responsibility

1) What is Merchant of Record (MoR) and why is it needed

Merchant of Record is a legal entity that formally sells a product/service to an end customer, issues a check/invoice, accepts payment, incurs tax and consumer obligations, conducts disputes and is reflected in a bank statement (descriptor).

• regulators and taxes (where to pay GGR/VAT/GST/WHT),
• consumer responsibility (refunds/chargebacks, KYC/SoF, RG),
• operational speed of entering the market (using someone else's license/MoR infrastructure),
• financial logistics (multi-GEO, multi-currency, settlement and FX).

Than MoR ≠ PSP: PSP - money receiving channel (infrastructure), MoR - seller by law. Aggregators can be PSPs without MoR status; and the MoR provider may include a PSP within its stack.

2) Basic MoR models

2. 1. Direct Merchant (classic)

The iGaming operator itself is MoR.

Pros: full control of brand, tariffs, data, taxes; minimum margin of intermediaries.
Disadvantages: complex licenses/local registrations, VAT/GST, GGR accounting, WHT, PCI DSS, KYC/AML in each country; long time-to-market.

2. 2. Full-MoR Provider

External MoR sells B2C, you are the content/service provider of MoR'y.

Pros: quick launch, shifting VAT/GST/chargebacks/invoicing, marketplace taxes, local wallets.
Cons: MoR margin, less control over payments/data, marketing/UX restrictions, difficulty in calculating revenue share.

2. 3. Reseller/Distributor MoR

Reseller partner buys from you "wholesale" (B2B), sells B2C under its MoR.

Pros: local expertise, reducing your risks.

Cons: risk of brand cannibalization, reliance on reseller SLAs

2. 4. Marketplace/Platform MoR (one MoR for many merchants)

Platform - MoR; operators/studios are "salespeople," but not MoRs.

Pros: single check, PSP/method aggregation, single fiscalization.
Cons: complex split-settlement, tax and reporting allocation, cross-liability risk.

2. 5. Hybrid model

In green markets - Direct Merchant, in gray/expensive markets - Full-MoR/Reseller.

Pros: Speed/control/cost tradeoff.
Cons: increased complexity of accounting, routing and "double" reporting.

3) Responsibility outline: who is responsible for what

4) Cash flows and settlement

4. 1. Direct

The player → the PSP/acquirer → the operator's account (gross/net). Operator pays partners/taxes.

4. 2. Full-MoR

The player → the PSP MoR → the MoR → payout account to the operator according to the report (revenue share/CPA). Commissions, VAT, refunds/CB - within MoR. Possible holdback/rolling reserve.

4. 3. Marketplace Split

Player → MoR platform → split settlement: share of platform, operator, studio, affiliate (minus fees/taxes).

Key: fix cut-off/T + N, funding currency, FX rules and reconciliation rituals: 'Tx → File → Funding'.

5) Taxes and MoRs

VAT/GST (B2C): who has a check, and VAT/GST (usually MoR). With Direct - operator.
GGR: paid by a licensed operator according to the rules of jurisdiction (MoR ≠ always the payer of GGR).
WHT: withholding on payments to partners - the one who pays (MoR/operator).
Payment fees PSP: from MoR or from the operator (according to the model); in ND/Fin reporting - separately.
Fiscalization/check-processing: local requirements (for example, e-invoicing, fiscal receipt) usually on MoR.

6) Legal and contracts (must-have clauses)

Definition of MoR (who is it in each country/channel), descriptor, responsibility for consumer protection.
Taxes: who pays VAT/GST/GGR/WHT; gross-up mechanics, certificate exchange (DTT, VAT/EORI).
KYC/AML/sanctions: role allocation, SLA for checks, right to refuse/block.
Refunds/Chargebacks: process, timing, evidence base, who suffers losses.
Data and privacy: GDPR/data law, DPA, controller/processor roles, cross-border transmissions.
PSP/PCI DSS: who owns merchant accounts, who bears the fines of schemes.
Setting/reserve: T + N, rolling reserve, negative carry-over, audit/reporting.
Force-majeure/sanctions: freeze order, termination rights, escrow.

7) Operational processes

Geopolitics and licenses: matrix of permitted markets (see "Geoblocks").
KYC/KYB/SoF: uniform standards and step-up routing over MoR/operator.
Antifraud and 3DS: responsibility for settings, AB tests, risk threshold.
Payment router: BIN/method/PSP according to the MoR model; fallback and cut-over procedures.
Reconciliation: daily'transactions ↔ settlement files ↔ funding ', variance reports.
Reporting: separate showcases for the operator (GGR/NGR) and MoR (VAT/refunds/CB).

8) When to select which model (Decision Matrix)

9) KPI and dashboards

Take-rate all-in by model (PSP fees + MoR margin + FX slippage).
AR/DR/3DS pass by geo/PSP/model.
Refund/Chargeback rate and liability by responsible entity.
Settlement SLA: T+N hit-rate, funding delays, reserve balance.
Tax exposure: VAT/GST by MoR, GGR by operator, WHT by partner.
Data latency & completeness - The percentage of transactions with a complete MoR context.

10) Data and model (simplified)

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 templates

11. 1. Revenue Breakdown by MoR Model

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. Net payable at 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 (operator) 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. Responsibility Matrix for Disputes

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) Security and data

PCI DSS: who stores/processes PAN is "on"; at Full-MoR often PAN-scope at MoR.
GDPR/Privacy: DPA and Roles (Controller/Processor), SCC/IDTA for cross-border transmissions, data minimization, retention periods.
Sanctions/REP: who conducts the screening - record in the contract and in the liability log.
SCA/3DS: responsibility for setting flow and evidence in disputes.

13) Risks and Alerts

Policy Drift: transactions without assigned MoR model - P1.
Settlement Delay: T + N MoR payments violated - P1.
Variance VAT/GGR: discrepancies between calculated and MoR reports> threshold - P2.
CB Spike on the MoR/operator side - operational measures (3DS, limits, routing).
FX Slippage by MoR-settlement - compare effective vs reference.
Data Completeness - report without files/signatures - stop for payment.

14) Best practices (short)

1. Document the model for each GEO/channel: who is MoR, who pays VAT/GGR, who holds PAN, who is responsible for the dispute.
2. Separate storefronts: grocery (GGR/NGR) and MoR-financial (VAT/refund/CB/fees).
3. Contracts with clear SLA/thresholds and payout/fees/reserve calculation formulas.
4. PSP AB routing even at Full-MoR - for AR/DR and cost.
5. Policy and directory versioning (mor_model v1/v2), deterministic reprocess.
6. Daily reconciliation of 'Tx ↔ Settlement ↔ Funding', variance alerts.
7. Legal tracing: legal basis for each GEO (licenses, VAT, sanctions).

15) Implementation/migration checklist

Data/Diagrams

• `ref. mor_models`, `payments. transactions' with fields' mor _ '.
• Display cases' mor _ settlements', 'vat _ ledger', 'ggr _ rollup'.
• GEO/BIN/MoR-bound routing

Contracts/Processes

• Contracts with MoR/resellers: taxes, disputes, data, SLA, reserve.
• PCI/GDPR: roles, audits, DPIA.
• Operations: cut-off/T + N, FX rules, variance procedures.

Monitoring/Alerts

• Settlement SLA, VAT/GGR variance, CB spike, FX slippage.
• Data completeness/consistency and file signatures.

Summary

MoR is not "another PSP." This is the legal role of a seller with tax, consumer and operational responsibility. Choosing between Direct, Full-MoR, Reseller and Marketplace is a balance of speed, control, cost and risk. Fix the model for each GEO, separate the contours of GGR (operator) and VAT (MoR), automate reconciliation and reporting - and you get predictable monetization without legal surprises.