MoR : modèles et responsabilité
1) Qu'est-ce que Merchant of Record (MoR) et pourquoi il est nécessaire
Merchant of Record est une personne morale qui vend officiellement un produit/service au client final, émet un chèque/facture, accepte le paiement, assume des obligations fiscales et de consommation, tient des disputes et est consigné dans un relevé bancaire (descriptor).
Dans le circuit iGaming, MoR est critique pour :- réglementation et taxes (où payer GGR/TVA/TPS/TPS),
- la responsabilité des consommateurs (refunds/chargebacks, KYC/SoF, RG),
- la vitesse opérationnelle de mise sur le marché (utilisation de la licence/de l'infrastructure MoR de quelqu'un d'autre),
- logistique financière (multi-GEO, multi-currency, settlement et FX).
Que MoR ≠ PSP : PSP est un canal de réception d'argent (infrastructure), MoR est un vendeur légalement. Les agrégateurs peuvent être PSP sans statut MoR ; et le fournisseur MoR peut inclure la PSP à l'intérieur de sa pile.
2) Modèles de base MoR
2. 1. Direct Merchant (classique)
L'opérateur iGaming lui-même est MoR.
Avantages : contrôle total de la marque, des tarifs, des données, des impôts ; marge minimale des intermédiaires.
Inconvénients : licences complexes/enregistrements locaux, TVA/GST, GGR-comptabilité, WHT, PCI DSS, KYC/AML dans chaque pays ; long time-to-market.
2. 2. Fournisseur Full-MoR (sous-traitance MoR)
Le MoR externe vend du B2C, vous êtes le fournisseur de contenu/service du MoR'y.
Avantages : démarrage rapide, transfert de TVA/GST/chargebacks/facturation, marketplace-taxes, portefeuilles locaux.
Inconvénients : marge MoR, moins de contrôle sur les paiements/données, restrictions marketing/UX, complexité du calcul du revenu partager.
2. 3. Reseller/Distributor MoR
Un partenaire revendeur vous achète en vrac (B2B), vend B2C sous son MoR.
Avantages : expertise locale, réduction de vos risques.
Inconvénients : risque de cannibalisation de la marque, dépendance à l'égard du revendeur SLA.
2. 4. Marketplace/Plateforme MoR (un MoR pour de nombreux vendeurs)
Plateforme - MoR ; les opérateurs/studios sont des « vendeurs », mais pas le MoR.
Avantages : chèque unique, agrégation PSP/méthodes, fiscalité unique.
Inconvénients : split-settlement complexe, répartition et déclaration des impôts, risque de croisement.
2. 5. Modèle hybride
Sur les marchés verts - Direct Merchant, « gris/cher » - Full-MoR/Reseller.
Avantages : compromis vitesse/contrôle/coût.
Inconvénients : augmentation de la complexité de la comptabilité, de l'itinérance et de la « double » déclaration.
3) Contour de la responsabilité : qui est responsable de quoi
4) Flux de trésorerie et établissement
4. 1. Direct
Le joueur → PSP/acquéreur → compte de l'opérateur (gross/net). L'opérateur paie les partenaires/taxes.
4. 2. Full-MoR
Le joueur → le PFP MoR → compte MoR → payout à l'opérateur sur le rapport (revenu partager/CPA). Commission, TVA, fonds/CB - au sein du MoR. Holdback/rolling reserve est possible.
4. 3. Marketplace Split
Le joueur → la plate-forme MoR → split settlement : part de la plate-forme, opérateur, studio, affiliation (minus fees/taxes).
Clé : fixez cut-off/T + N, devise funding, règles FX et rituels de rapprochement : 'Tx → File → Funding'.
5) Taxes et MOR
VAT/TPS (B2C) : qui a un chèque, et VAT/TPS (habituellement MoR). Dans Direct, l'opérateur.
GGR : paie l'exploitant autorisé selon les règles de compétence (MoR ≠ toujours payeur de GGR).
WHT : retenue à la source lors des paiements aux partenaires - à celui qui paie (MoR/opérateur).
Frais de paiement PSP : au MoR ou à l'opérateur (selon le modèle) ; en ND/états financiers - séparément.
Fiscalité/chèque : les exigences locales (par exemple, e-invoicing, receipt fiscal) sont généralement sur le MoR.
6) Droit et contrats (clauses must-have)
Définition du MoR (qui il est dans chaque pays/canal), descripteur, responsabilité de la protection des consommateurs.
Taxes : qui paie la TVA/TPS/GGR/WHT ; mécanique du gros-haut, échange de certificats (DTT, VAT/EORI).
KYC/AML/Sanctions : attribution des rôles, SLA à vérifier, droit de refus/blocage.
Refunds/Chargebacks : processus, délais, base de données probantes, qui est responsable des pertes.
Données et vie privée : RGPD/droit des données, DPA, rôle de contrôleur/processeur, transferts transfrontaliers.
PSP/PCI DSS : qui possède les comptes merchant, qui supporte les sanctions des régimes.
Settlement/reserve : T + N, rolling reserve, negative carry-over, audit/reporting.
Force-majeur/sanctions : ordre de freeze, droits de résiliation, escrow.
7) Processus opérationnels
Géopolitiques et licences : matrice des marchés autorisés (voir « Géoblocages »).
KYC/KYB/SoF : standard unique et routage step-up par MoR/opérateur.
Antifrod et 3DS : responsabilité des réglages, tests AB, seuil de risque.
Routeur de paiement : BIN/méthode/PSP selon le modèle MoR ; fallback et cut-over procédures.
Rapprochement : tous les jours 'transactions ↔ settlement files ↔ funding', variance-reporting.
Déclaration : vitrines séparées pour l'opérateur (GGR/NGR) et le MoR (TVA/fonds/CB).
8) Quand choisir quel modèle (Decision Matrix)
9) KPI et dashboards
Take-rate all-in par modèle (PSP fees + MoR margin + FX slippage).
AR/DR/3DS pass par géo/PSP/modèle.
Taux de Refund/Chargeback et de liability par entité responsable.
Settlement SLA: T+N hit-rate, funding delays, reserve balance.
Exposition fiscale : TVA/TPS selon MoR, RGG selon l'exploitant, TPS par partenaire.
Data latency & completeness : part des transactions avec un contexte MoR complet.
10) Données et modèle (simplifié)
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) modèles SQL
11. 1. Décomposition des recettes selon le modèle 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. Net payable avec 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 (opérateur) 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. Matrice de responsabilité pour les 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) Sécurité et données
PCI DSS : qui stocke/traite le PAN est celui et « brûle » ; en Full-MoR souvent PAN-scope chez MoR.
GDPR/Privacy : DPA et Rôles (Controller/Processor), SCC/IDTA pour les transferts transfrontaliers, minimisation des données, durées de conservation.
Sanctions/RRE : qui mène le dépistage - inscrire dans le contrat et dans le journal de responsabilité.
SCA/3DS : la responsabilité d'établir le flow et la preuve dans les disputes.
13) Risques et alertes
Policy Drift : transactions sans modèle MoR attribué - P1.
Settlement Delay : T + N-paiements MoR - P1 perturbé.
Variance VAT/GGR : écarts entre les rapports calculés et les rapports MoR> seuil - P2.
CB Spike du côté MoR/opérateur - mesures opérationnelles (3DS, limites, itinérance).
FX Slippage par MoR-settlement - comparer effective vs reference.
Data Completeness : Rapport sans fichiers/signatures - stop to payment.
14) Meilleures pratiques (en bref)
1. Documentez le modèle pour chaque GEO/canal : qui est le MoR, qui paie le VAT/GGR, qui tient le PAN, qui est responsable de la dispute.
2. Séparez les vitrines : produit (GGR/NGR) et MoR-financier (TVA/refund/CB/fees).
3. Contrats avec des SLA/seuils clairs et des formules de calcul payout/fees/reserve.
4. L'itinéraire AB PSP, même en Full-MoR, est pour AR/DR et le coût.
5. Versioning des politiques et des manuels (mor_model v1/v2), déterministe reprocess.
6. Rapprochement quotidien 'Tx ↔ Settlement ↔ Funding', variance-alertes.
7. Trace légale : base légale pour chaque GEO (licences, TVA, sanctions).
15) Chèque de mise en œuvre/migration
Données/schémas
- `ref. mor_models`, `payments. transactions 'c avec les champs' mor _ '.
- Vitrines 'mor _ settlements', 'vat _ ledger', 'ggr _ rollup'.
- Routage par GEO/BIN/méthode avec référence au modèle MoR.
Contrats/processus
- Contrats avec MoR/revendeurs : taxes, disputes, données, SLA, réserve.
- PCI/GDPR : rôles, audits, DPIA.
- Opérations : cut-off/T + N, règles FX, procédures variance.
Surveillance/alertes
- Settlement SLA, VAT/GGR variance, CB spike, FX slippage.
- Données complètes/consistency et signatures de fichiers.
Résumé
Le MoR n'est pas « un autre PSP ». C'est le rôle juridique du vendeur avec la responsabilité fiscale, de consommation et d'exploitation. Le choix entre Direct, Full-MoR, Reseller et Marketplace est un équilibre de vitesse, de contrôle, de coût et de risque. Fixez le modèle pour chaque GEO, séparez les contours GGR (opérateur) et VAT (MoR), automatisez les rapprochements et les rapports - et vous obtiendrez une monétisation prévisible sans surprise légale.