MoR: Modelle und Verantwortung

1) Was ist Merchant of Record (MoR) und warum wird es benötigt?

Merchant of Record - eine juristische Person, die formal ein Produkt/eine Dienstleistung an einen Endkunden verkauft, einen Scheck/eine Rechnung ausstellt, Zahlungen akzeptiert, Steuer- und Verbraucherverpflichtungen trägt, Streitigkeiten führt und sich in einem Kontoauszug (descriptor) widerspiegelt.

• Regulierung und Steuern (wo GGR/VAT/GST/WHT zu zahlen sind),
• Verbraucherhaftung (refunds/chargebacks, KYC/SoF, RG),
• Betriebsgeschwindigkeit des Markteintritts (Verwendung einer Lizenz/einer MoR-Infrastruktur einer anderen Person),
• Finanzlogistik (Multi-GEO, Multi-Currency, Settlement und FX).

Als MoR ≠ PSP: PSP - der Kanal der Annahme des Geldes (die Infrastruktur), MoR - der Verkäufer nach dem Gesetz. Aggregatoren können PSPs ohne MoR-Status sein; Ein MoR-Anbieter kann eine PSP in seinem Stack enthalten.

2) Grundmodelle MoR

2. 1. Direkthändler (klassisch)

Der Betreiber von iGaming selbst ist MoR.

Vorteile: vollständige Kontrolle über Marke, Tarife, Daten, Steuern; Mindestmarge für Intermediäre.
Nachteile: komplexe Lizenzen/lokale Registrierungen, VAT/GST, GGR-Buchhaltung, WHT, PCI DSS, KYC/AML in jedem Land; lange Zeit zum Markt.

2. 2. Full-MoR Provider (Außenseiter mit MoR)

Das externe MoR verkauft B2C, Sie sind der Content/Service Provider von MoR 'y.

Vorteile: schnelle Einführung, Umrechnung von VAT/GST/Chargebacks/Rechnungsstellung, Marktplatzsteuern, lokale Geldbörsen.
Nachteile: MoR-Marge, weniger Kontrolle über Zahlungen/Daten, Marketing/UX-Einschränkungen, Komplexität der Revenue-Share-Berechnungen.

2. 3. Reseller/Distributor MoR

Der Reseller-Partner kauft von Ihnen „Großhandel“ (B2B), verkauft B2C unter seinem MoR.

Vorteile: lokale Expertise, Reduzierung Ihrer Risiken.
Nachteile: Risiko der Kannibalisierung der Marke, Abhängigkeit vom SLA des Wiederverkäufers.

2. 4. Marktplatz/Plattform MoR (ein MoR für viele Verkäufer)

Plattform - MoR; Betreiber/Studios sind „Verkäufer“, aber nicht MoR.

Vorteile: Single Check, Aggregation von PSP/Methoden, Single Fiscalization.
Nachteile: komplexe Split-Settlement, Steuerverteilung und Berichterstattung, Cross-Liability-Risiko.

2. 5. Hybridmodell

Für „grüne“ Märkte - Direct Merchant, für „grau/teuer“ - Full-MoR/Reseller.

Vorteile: Kompromiss Geschwindigkeit/Kontrolle/Kosten.
Nachteile: erhöhte Komplexität der Buchhaltung, Routing und „doppelte“ Berichterstattung.

3) Verantwortungskreis: Wer wofür verantwortlich ist

4) Cashflows und Siedlung

4. 1. Direct

Der Spieler → PSP/Acquirer → Konto des Betreibers (gross/net). Betreiber zahlt Partner/Steuern.

4. 2. Full-MoR

Ein Spieler → PSP MoR → ein MoR-Konto → eine Auszahlung an den Betreiber des Berichts (Revenue Share/CPA). Provisionen, VAT, refunds/CB - innerhalb des MoR. Holdback/Rolling Reserve möglich.

4. 3. Marketplace Split

Der Spieler → die MoR-Plattform → split settlement: Anteil der Plattform, des Betreibers, des Studios, des Affiliates (minus fees/taxes).

Schlüssel: Fix cut-off/T + N, Währungs-Funding, FX-Regeln und Abstimmungsrituale: 'Tx → File → Funding'.

5) Steuern und MoR

MwSt./GST (B2C): Wer einen Scheck hat, hat auch MwSt./GST (in der Regel MoR). Bei Direct der Operator.
GGR: zahlt der lizenzierte Betreiber nach den Regeln der Gerichtsbarkeit (MoR ≠ immer der Zahler von GGR).
WHT: Quellenbindung bei Zahlungen an Partner - von demjenigen, der zahlt (MoR/Operator).
PSP-Zahlungsgebühren: beim MoR oder beim Betreiber (nach Modell); in ND/fin-Berichterstattung - getrennt.
Fiskalisierung/Checkout: Lokale Anforderungen (z.B. E-Invoicing, fiscal receipt) meist am MoR.

6) Recht und Verträge (muss-haben-Klauseln)

Definition MoR (wer ist es in jedem Land/Kanal), descriptor, Verantwortung für den Verbraucherschutz.
Steuern: wer zahlt VAT/GST/GGR/WHT; Gross-up Mechanik, Austausch von Zertifikaten (DTT, VAT/EORI).
KYC/AML/Sanktionen: Rollenverteilung, SLA für Prüfungen, Ablehnungs-/Sperrrecht.
Refunds/Chargebacks: Prozess, Timing, Evidenzbasis, wer die Verluste trägt.
Daten und Datenschutz: DSGVO/Datenrecht, DPA, Controller/Prozessor Rollen, grenzüberschreitende Übertragungen.
PSP/PCI DSS: Wer besitzt Merchant Accounts, wer trägt die Strafen der Systeme.
Einstellung/Reserve: T + N, Rolling Reserve, negative Carry-over, Audit/Reporting.
Force-majeure/sanctions: freeze order, Kündigungsrechte, Treuhandschaft.

7) Betriebliche Prozesse

Geopolitik und Lizenzen: Matrix der erlaubten Märkte (siehe „Geoblocking“).
KYC/KYB/SoF: einheitliche Standards und Step-up-Routing nach MoR/Operator.
Betrugsbekämpfung und 3DS: Verantwortung für Einstellungen, AB-Tests, Risikoschwelle.
Payment Router: BIN/Methode/PSP nach MoR-Modell; Fallback- und Cut-over-Verfahren.
Überleitung: täglich 'transactions ↔ settlement files ↔ funding', variance-reports.
Berichterstattung: separate Schaufenster für den Betreiber (GGR/NGR) und MoR (VAT/refunds/CB).

8) Wann welches Modell wählen (Decision Matrix)

9) KPIs und Dashboards

Take-rate all-in nach Modell (PSP fees + MoR margin + FX slippage).
AR/DR/3DS Pass auf Geo/PSP/Modell.
Refund/Chargeback Rate und Liability nach verantwortlicher Einheit.
Settlement SLA: T+N hit-rate, funding delays, reserve balance.
Tax exposure: MwSt./GST nach MoR, GGR nach Betreiber, WHT nach Partnern.
Data latency & completeness: Anteil der Transaktionen mit vollständigem MoR-Kontext.

10) Daten und Modell (vereinfacht)

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-Vorlagen

11. 1. Umsatzaufschlüsselung nach MoR-Modell

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. Netto bezahlbar bei 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. Haftungsmatrix für Dispute

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) Sicherheit und Daten

PCI DSS: Wer PAN speichert/verarbeitet, „brennt“; bei Full-MoR häufig PAN-Scope bei MoR.
DSGVO/Datenschutz: DPA und Rollen (Controller/Prozessor), SCC/IDTA für grenzüberschreitende Übertragungen, Datenminimierung, Aufbewahrungsfristen.
Sanktionen/RER: Wer das Screening durchführt - im Vertrag und im Haftungsprotokoll festhalten.
SCA/3DS: Verantwortung für die Flow- und Proof-Einstellung bei Disputen.

13) Risiken und Warnungen

Policy Drift: Transaktionen ohne zugeordnetes MoR-Modell - P1.
Settlement Delay: T + N MoR Auszahlungen verletzt - P1.
Variance VAT/GGR: Abweichungen zwischen Berechnungs- und MoR-Berichten> Schwelle - P2.
CB Spike auf MoR/Betreiberseite - operative Maßnahmen (3DS, Limits, Routing).
FX Slippage by MoR-settlement - Vergleichen Sie effektive vs Referenz.
Data Completeness: Bericht ohne Dateien/Unterschriften - Stopp zur Auszahlung.

14) Best Practices (kurz)

1. Dokumentieren Sie das Modell für jeden GEO/Kanal: Wer ist MoR, wer zahlt VAT/GGR, wer hält die PAN, wer ist verantwortlich für die Disputation.
2. Trennen Sie die Schaufenster: Produkt (GGR/NGR) und MoR-Finanz (VAT/refund/CB/fees).
3. Verträge mit klaren SLAs/Schwellenwerten und Berechnungsformeln payout/fees/reserve.
4. PSP AB Routing auch bei Full-MoR - für AR/DR und Kosten.
5. Versionierung von Richtlinien und Verzeichnissen (mor_model v1/v2), deterministisch reprocess.
6. Täglicher Abgleich „Tx ↔ Settlement ↔ Funding“, variance-alert.
7. Rechtsweg: rechtliche Basis für jeden GEO (Lizenzen, Umsatzsteuer, Sanktionen).

15) Checkliste Implementierung/Migration

Daten/Diagramme

• `ref. mor_models`, `payments. Transaktionen "mit den Feldern" mor _ ".
• Schaukästen 'mor _ settlements', 'vat _ ledger', 'ggr _ rollup'.
• Routing nach GEO/BIN/Methode mit Bezug zum MoR-Modell.

Verträge/Prozesse

• Verträge mit MoR/Resellern: Steuern, Dispute, Daten, SLA, Reserve.
• PCI/DSGVO: Rollen, Audits, DPIA.
• Operationen: cut-off/T + N, FX-Regeln, Varianzverfahren.

Überwachung/Warnungen

• Settlement SLA, VAT/GGR variance, CB spike, FX slippage.
• Daten completeness/consistency und Dateisignaturen.

Zusammenfassung

MoR ist nicht „eine andere PSP“. Dies ist die rechtliche Rolle des Verkäufers mit Steuer-, Verbraucher- und Betriebsverantwortung. Die Wahl zwischen Direct, Full-MoR, Reseller und Marketplace ist die Balance zwischen Geschwindigkeit, Kontrolle, Kosten und Risiken. Erfassen Sie das Modell für jeden GEO, trennen Sie die Konturen von GGR (Operator) und VAT (MoR), automatisieren Sie den Abgleich und das Reporting - und Sie erhalten eine vorhersehbare Monetarisierung ohne rechtliche Überraschungen.