MoR: მოდელები და პასუხისმგებლობა

1) რა არის Merchant of Record (MoR) და რატომ არის ეს საჭირო

Merchant of Record არის იურიდიული პირი, რომელიც ოფიციალურად ყიდის საქონელს/მომსახურებას საბოლოო კლიენტისთვის, ადგენს ჩეკს/ანგარიშს, იღებს გადახდას, ახორციელებს საგადასახადო და სამომხმარებლო ვალდებულებებს, ატარებს დავებს და აისახება საბანკო განცხადებაში (descriptor).

• რეგულატორები და გადასახადები (სად უნდა გადაიხადოთ GGR/VAT/GST/WHT),
• სამომხმარებლო პასუხისმგებლობა (refunds/chargebacks, KYC/SoF, RG),
• ბაზარზე შესვლის ოპერაციული სიჩქარე (სხვისი ლიცენზიის/MoR ინფრასტრუქტურის გამოყენება),
• ფინანსური ლოჯისტიკა (multi-GEO, multi-currence, settlement და FX).

ვიდრე MoR - PSP: PSP - ფულის მიღების არხი (ინფრასტრუქტურა), MoR - გამყიდველი კანონით. აგრეგატორები შეიძლება იყვნენ PSP MoR სტატუსის გარეშე; და MoR პროვაიდერი შეიძლება შეიცავდეს PSP- ს მის დასტის შიგნით.

2) ძირითადი MoR მოდელები

2. 1. პირდაპირი მერჩანტი (კლასიკა)

თავად iGaming ოპერატორი არის MoR.

უპირატესობები: ბრენდის, ტარიფების, მონაცემების, გადასახადების სრული კონტროლი; შუამავლების მინიმალური ზღვარი.
უარყოფითი: რთული ლიცენზიები/ადგილობრივი რეგისტრაცია, VAT/GST, GGR აღრიცხვა, WHT, PCI DSS, KYC/AML თითოეულ ქვეყანაში; გრძელი დრო.

2. 2. Full-MoR Provider (autsors MoR)

გარე MoR ყიდის B2C, თქვენ ხართ MoR 'y შინაარსის/მომსახურების მიმწოდებელი.

უპირატესობები: სწრაფი გაშვება, VAT/GST/ჩარჟბეკების/ინვოისების მოწყობა, ბაზრის გადასახადები, ადგილობრივი საფულეები.
უარყოფითი მხარეები: MoR ზღვარი, გადახდების/მონაცემების დაბალი კონტროლი, მარკეტინგის შეზღუდვები/UX, გამოთვლების სირთულე.

2. 3. Reseller/Distributor MoR

გამყიდველი პარტნიორი ყიდულობს თქვენგან „საბითუმო“ (B2B), ყიდის B2C- ს მისი MoR- ის ქვეშ.

დადებითი: ადგილობრივი შემოწმება, თქვენი რისკების შემცირება.
უარყოფითი: ბრენდის კანიბალიზაციის რისკი, SLA გამყიდველის დამოკიდებულება.

2. 4. Marketplace/Platform MoR (ერთი MoR მრავალი გამყიდველისთვის)

პლატფორმა - MoR; ოპერატორები/სტუდიები - „გამყიდველები“, მაგრამ არა MoR.

უპირატესობები: ერთი შემოწმება, PSP/მეთოდების ერთობლიობა, ერთიანი ფისკალიზაცია.
უარყოფითი მხარეები: რთული split settlement, გადასახადებისა და ანგარიშგების განაწილება, ჯვრის რისკი.

2. 5. ჰიბრიდული მოდელი

მწვანე ბაზრებზე - Direct Merchant, „ნაცრისფერი/ძვირი“ - Full-MoR/Reseller.

დადებითი: კომპრომისი სიჩქარე/კონტროლი/ღირებულება.
უარყოფითი მხარეები: ბუღალტრული აღრიცხვის, როუტინგის და „ორმაგი“ ანგარიშგების გაზრდილი სირთულე.

3) პასუხისმგებლობის წრე: ვინ არის პასუხისმგებელი რაზე

4) ფულადი ნაკადები და ნაკადები

4. 1. Direct

PSP/Exwairer მოთამაშე ოპერატორის ანგარიშს (gross/net). ოპერატორი იხდის პარტნიორებს/გადასახადებს.

4. 2. Full-MoR

PSP MoR- ის მოთამაშემ MoR-payout- ის ანგარიში გადასცა საანგარიშო ოპერატორს (revenue share/CPA). კომისიები, VAT, refunds/CB - MoR- ის შიგნით. შესაძლებელია holdback/rolling reserve.

4. 3. Marketplace Split

მოთამაშე - MoR პლატფორმა - split stettlement: პლატფორმის, ოპერატორის, სტუდიის, აფილიატის წილი (minus fees/taxes).

საკვანძო: ჩაწერეთ cut-off/T + N, funding ვალუტა, FX წესები და შერიგების რიტუალები: 'Tx' File 'Funding'.

5) გადასახადები და MoR

VAT/GST (B2C): ვისაც აქვს შემოწმება, აქვს VAT/GST (ჩვეულებრივ MoR). პირდაპირი ოპერატორის ქვეშ.
GGR: ლიცენზირებული იურისდიქციის ოპერატორი იხდის (MoR - ყოველთვის GGR გადამხდელი).
WHT: წყაროს შენარჩუნება პარტნიორების გადახდაზე - მას, ვინც იხდის (MoR/ოპერატორს).
PSP გადახდის საფასური: MoR- ში ან ოპერატორში (მოდელის მიხედვით); ND/Fin ანგარიშგებაში - ცალკე.
ფისკალიზაცია/შემოწმება: ადგილობრივი მოთხოვნები (მაგალითად, ელექტრონული ინვესტიცია, fiscal ჩანაწერები) ჩვეულებრივ MoR- ზე.

6) იურიდიკა და ხელშეკრულებები (must-have კლასები)

MoR- ის განმარტება (ვინ არის იგი ყველა ქვეყანაში/არხში), descriptor, პასუხისმგებლობა consumer დაცვაზე.
გადასახადები: ვინ იხდის VAT/GST/GGR/WHT; Gross-up მექანიკა, სერთიფიკატების გაცვლა (DTT, VAT/EORI).
KYC/AML/სანქციები: როლების განაწილება, შემოწმება SLA, უარის თქმის/დაბლოკვის უფლება.
Refunds/Chargebacks: პროცესი, ვადები, მტკიცებულება, ვინ განიცდის ზარალს.
მონაცემები და კონფიდენციალურობა: GDPR/მონაცემთა კანონი, DPA, კონტროლის/პროფესორის როლი, ტრანსსასაზღვრო გადაცემები.
PSP/PCI DSS: ვინ ფლობს ციმციმულ ანგარიშებს, ვინ ჯარიმებს უწევს სქემებს.
Settlent/რეზერვი: T + N, rolling reserve, negative carry-over, audit/reporting.
Force-majeure/სანქციები: freeze ბრძანება, შეწყვეტის უფლებები, escrow.

7) ოპერაციული პროცესები

გეოპოლიტიკა და ლიცენზია: ნებადართული ბაზრების მატრიცა (იხ. „გეობლოკაცია“).
KYC/KYB/SoF: ერთიანი სტანდარტები და step-up მარშრუტიზაცია MoR/ოპერატორზე.
ანტიფროდი და 3DS: პასუხისმგებლობა პარამეტრებზე, AB ტესტებზე, რისკის ბარიერზე.
გადახდის როუტერი: BIN/მეთოდი/PSP MoR მოდელის მიხედვით; fallback და cut-over პროცედურა.
Cryptions: ყოველდღიურად „ტრანსპორტირება - settlement files - funding“, variance ანგარიშები.
მოხსენებები: ინდივიდუალური ფანჯრები ოპერატორისთვის (GGR/NGR) და MoR (VAT/refunds/CB).

8) როდის უნდა აირჩიოთ რომელი მოდელი (Decision Matrix)

9) KPI და დაშბორდი

Take-rate all-in მოდელის მიხედვით (PSP fees + MoR margin + FX slippage).
AR/DR/3DS პასები გეო/PSP/მოდელებისთვის.
Refund/Chargeback rate და liability პასუხისმგებელი სუბიექტისთვის.
Settlement SLA: T+N hit-rate, funding delays, reserve balance.
Tax exposure: VAT/GST MoR, 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. Net payable 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 - ის და „იწვის“; Full-MoR- ით ხშირად PAN-scope MoR- ში.
GDPR/Privacy: DPA და როლები (Controller/Processor), SCC/IDTA ტრანსსასაზღვრო პროგრამებისთვის, მონაცემების მინიმუმამდე შემცირება, შენახვის დრო.
სანქციები/RER: ვინ აწარმოებს სკრინინგს - ჩაწერეთ ხელშეკრულებაში და პასუხისმგებლობის ჟურნალში.
SCA/3DS: პასუხისმგებლობა დავის დროს ფლეშ და მტკიცებულებების პარამეტრებზე.

13) რისკები და ალერტები

Policy Drift: გარიგებები მინიჭებული MoR მოდელის გარეშე - P1.
Settlement Delay: დაირღვა T + N MoR გადახდები - P1.
Variance VAT/GGR: შეუსაბამობები ანგარიშსწორებასა და MoR ანგარიშებს შორის> ბარიერი - P2.
CB Spike MoR/ოპერატორის მხარეს არის ოპერატიული ზომები (3DS, ლიმიტები, როუტინგი).
FX Slippage on MoR settlement - შეადარეთ effective vs reference.
Data Completeness: ანგარიში ფაილების/ხელმოწერების გარეშე - გადახდის გაჩერება.

14) საუკეთესო პრემიები (მოკლედ)

1. მოდელის დოკუმენტირება თითოეული GEO/არხისთვის: ვინ არის MoR, რომელიც იხდის VAT/GGR- ს, რომელიც ფლობს PAN- ს, ვინ არის პასუხისმგებელი დებატზე.
2. გაზიარეთ ფანჯრები: პროდუქტი (GGR/NGR) და MoR ფინანსური (VAT/refund/CB/fees).
3. კონტრაქტები მკაფიო SLA/ბარიერებით და payout/fees/reserve გაანგარიშების ფორმულებით.
4. AB routing PSP, თუნდაც Full-MoR - AR/DR და ღირებულებისთვის.
5. პოლიტიკოსისა და საცნობარო წიგნების ვერსია (mor _ model v1/v2), დეტერმინირებული რეპროცესი.
6. ყოველდღიური შერიგება 'Tx - Settlement - Funding', variance-alerts.
7. იურიდიული კვალი: იურიდიული ბასი თითოეული GEO- სთვის (ლიცენზია, VAT, სანქციები).

15) განხორციელების/მიგრაციის შემოწმების სია

მონაცემები/სქემები

• `ref. mor_models`, `payments. transactions 'ერთად ველები' mor _ '.
• ვიტრინები 'mor _ settlements', 'vat _ ledger', 'ggr _ rollup'.
• მარშრუტიზაცია GEO/BIN/მეთოდით MoR მოდელის მითითებით.

კონტრაქტები/პროცესები

• ხელშეკრულებები MoR/გამყიდველებთან: გადასახადები, დავები, მონაცემები, SLA, რეზერვი.
• PCI/GDPR: როლები, აუდიტები, DPIA.
• ოპერაციები: cut-off/T + N, FX წესები, variance პროცედურები.

მონიტორინგი/ალერტები

• Settlement SLA, VAT/GGR variance, CB spike, FX slippage.
• მონაცემთა კონფიგურაცია/კონსულტაცია და ფაილების ხელმოწერა.

რეზიუმე

MoR არ არის „კიდევ ერთი PSP“. ეს არის გამყიდველის იურიდიული როლი საგადასახადო, სამომხმარებლო და საოპერაციო პასუხისმგებლობით. არჩევანი პირდაპირი, Full-MoR, Reseller და Marketplace შორის არის სიჩქარის, კონტროლის, ღირებულებისა და რისკების ბალანსი. დააფიქსირეთ მოდელი თითოეული GEO- სთვის, გაიზიარეთ GGR (ოპერატორი) და VAT (MoR) კონტურები, ავტომატიზაცია მოახდინეთ შერიგებასა და ანგარიშგებაში - და მიიღებთ პროგნოზირებულ მონეტიზაციას იურიდიული სიურპრიზების გარეშე.