Структура комісій: MDR, scheme, PSP

1) Карта понять і з чого складається MDR

1. Interchange (банк-емітенту): відсоток за типом карти/регіону/категорії.

2. Scheme fees (платіжні системи): assessment, processing, cross-border, brand usage и т. п.

3. Acquirer/PSP markup: надбавка еквайрера/провайдера (відсоток + фікс).

4. Доп. збори: chargeback fee, refund fee, representment, retrieval, auth-fee, gateway-fee, rolling reserve (не комісія, але впливає на кеш-флоу), FX-спред при конверсії.

Підсумкова вартість для мерчанта = Interchange + Scheme + Markup + Фіксовані збори + FX-ефекти ± Резерв.

2) Моделі ціноутворення

2. 1. Blended (flat)

Один відсоток + фікс. збір «все включено». Просто, але непрозоро: приховує interchange/scheme і FX-спред.

2. 2. IC++ (Interchange++ / Interchange pass-through)

Interchange і scheme йдуть «як є», зверху - фіксований markup провайдера. Прозоро, легше звіряти, вигідно при «дешевому» портфелі карт.

2. 3. Tiered/Pricing buckets

Кілька «кошиків» (domestic, intra-EEA, inter-regional, commercial, premium). Зручно для звітності, може маскувати реальну собівартість.

2. 4. Альтернативні методи (A2A/Wallet/Крипто)

Частіше flat-fee або% нижче карт; окремі збори мережі/провайдера і FX-ефект при конвертації.

3) Де і коли виникає комісія

Auth/Validation: плата за спробу авторизації (усп ./неусп.) .
Capture/Settle: основна частка MDR.
Refund/Partial refund: повернення часто тарифікуються окремо (+ перерахунок scheme).
Chargeback/Representment: фікс. збори за кейс/етап.
Gateway/Platform: щомісячна абонплата, fee за вебхуки, звітність, токенізацію карт.
FX/Conversion: implicit-маржа PSP/банку (спред), якщо конвертація на їх стороні.
Календарні: minimum monthly fee, early termination, PCI-плата, 3DS-fee, fraud-suite fee.

4) Надбавки та коректори тарифів

Cross-border (емітент ≠ еквайр країна), CNP (card-not-present), premium/commercial карти.
High-risk verticals (iGaming) - підвищені markup/резерв.
Схемні штрафи/порогові метрики: перевищення CBR → додаткові збори.
SCA/3DS: окремий fee за транзакцію/спробу.
Minimum ticket/Small ticket: підвищені фікс. збори при маленьких чеках.

5) Gross vs Net settlement і «куди пішли відсотки»

Gross settlement: вал надходить на розрахунок з PSP, комісії знімаються окремим рядком (легше звіряти).
Net settlement: приходять net funding = оборот − interchange − scheme − markup − фікс. збори − резерв.
У net-сценаріях критично імпортувати розбивку компонент, інакше take-rate «стрибає».

6) Формули і «ефективні» метрики

6. 1. Effective take-rate (за методом/PSP)

take_rate_effective_% = (Σ Fees_all_components) / (Σ Captured_Gross) 100

6. 2. Розкладання на компоненти

Fees_all = Interchange + Scheme + Markup + Auth + Refund + Chargeback + Gateway
+ FX_spread_effect (if applicable)

6. 3. Вартість відмов (Decline cost)

Cost_per_approval = (Σ Auth_Fees + Σ Decline_Fees )/( Number of successful payments)

6. 4. Impact FX

FX_slippage = Σ (Settlement_amount_in_rep - Original_amount FX_reference_rate)

6. 5. Вартість чарджбеків

CB_cost_total = Σ (CB_fee + Representment_fee + Scheme_penalties) + Lost_principal (если не отбит)

7) Модель даних (спрощено)

ref. fee_components (
code PK, name, category, -- INTERCHANGE      SCHEME      MARKUP      AUTH      REFUND      CHARGEBACK      GATEWAY      FX_SPREAD unit,          -- PCT      FIX      MIXED is_variable, is_settlement_level
)

finance. psp_pricing (
provider, method, region, bin_range, card_type, card_category,
model,      -- BLENDED      IC++     TIERED pct_rate, --% rate (if applicable)
fix_fee,     -- фикс за trx cross_border_bps, premium_bps, cnp_bps,
refund_fix, cb_fix, auth_fix, gateway_monthly,
valid_from, valid_to, meta
)

finance. settlement_fees (
batch_id, provider, mid, method, period_start_at, period_end_at,
interchange_amt, scheme_amt, markup_amt,
auth_amt, refund_amt, cb_amt, gateway_amt,
fx_spread_amt, reserve_delta, total_fees, currency
)

dw. transactions_flat (
tx_id, provider, method, status, bin, brand, category, region,
amount_original, currency_original, amount_reporting, reporting_currency,
settled_at, funded_at, is_refund, is_cb, fx_reference_rate, fx_effective_rate, meta
)

8) Звірка: від транзакцій до файлу і назад

8. 1. Tx → File (перевіряємо, що нарахували «як у файлі»)

Аггрегуйте оборот по кошиках (BIN/регіон/тип карти) × правилами pricing.
Застосуйте ставки interchange/scheme/markup/фікс.
Звірте з'settlement _ fees. total_fees` по batch. Дельта> порогу → тікет.

8. 2. File → Tx (перевіряємо, що у файлі немає «зайвого»)

Розподіліть batch-fee пропорційно обороту/кількості транзакцій до рівня tx (при blended/немає деталізації).
Виявте несподівані позиції (extra fee line, penalty, minimum monthly top-up).

9) Приклади SQL-шаблонів

9. 1. Розрахунок effective take-rate за методами/PSP

sql
SELECT provider, method,
SUM(amount_reporting)              AS volume_rep,
SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_spread_amt) AS fees_rep,
100. 0 SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_spread_amt)
/ NULLIF(SUM(amount_reporting),0)     AS take_rate_effective_pct
FROM dw. transactions_flat t
JOIN finance. settlement_fees f
ON f. provider = t. provider
AND t. settled_at BETWEEN f. period_start_at AND f. period_end_at
GROUP BY 1,2
ORDER BY take_rate_effective_pct DESC;

9. 2. Перерозподіл batch-fee на транзакції (blended)

sql
WITH vol AS (
SELECT provider, batch_id, SUM(amount_reporting) AS batch_volume
FROM dw. transactions_flat
GROUP BY 1,2
)
SELECT t. tx_id, t. provider, t. batch_id,
(f. total_fees t. amount_reporting / NULLIF(v. batch_volume,0)) AS fee_allocated
FROM dw. transactions_flat t
JOIN finance. settlement_fees f USING (provider, batch_id)
JOIN vol v USING (provider, batch_id);

9. 3. Вартість відмов і вартість схвалення

sql
SELECT provider, method,
SUM(CASE WHEN status='DECLINED' THEN auth_fee ELSE 0 END) AS decline_cost,
SUM(CASE WHEN status='APPROVED' THEN auth_fee ELSE 0 END) AS approval_auth_cost,
COUNT() FILTER (WHERE status='APPROVED') AS approvals,
(SUM(auth_fee) / NULLIF(COUNT() FILTER (WHERE status='APPROVED'),0)) AS cost_per_approval
FROM dw. auth_events;

9. 4. Виділення FX-спреду (якщо є effective rate)

sql
SELECT provider, DATE(settled_at) AS d,
SUM((fx_effective_rate - fx_reference_rate) amount_original) AS fx_slippage_rep
FROM dw. transactions_flat
WHERE fx_effective_rate IS NOT NULL
GROUP BY 1,2;

10) KPI і дашборди

Effective Take-Rate% по PSP/методу/MID/країні.
Компонентний стек: Interchange %, Scheme %, Markup %, Fixed per trx.
Cost-per-Approval і Decline-burden (скільки обходяться відмови).
FX Slippage (bps і у валюті звіту).
Refund/CB Cost на 1000 транзакцій.
Penalty/Minimum-monthly інциденти.
Reserve as% of GMV (для розуміння впливу на кеш-флоу).

11) Алерти і пороги

Take-rate spike: зростання> X bps d/d або> Y bps w/w.
Scheme delta: розбіжність розрахованих scheme-fees з файлом> 0. 3–0. 5%.
FX slippage: > 80 bps для мажорів або> 150 bps для мінорів.
Decline cost surge: сплеск вартості схвалення при зниженні AR.
Unmapped fee line: новий рядок у файлі без маппінгу компонента.
Minimum monthly shortfall: недобір обороту до мінімалки (попереду доплата).

12) Переговори і зниження вартості

1. Перейти на IC++, якщо портфель сприятливий (domestic, consumer debit).
2. BIN-routing/Smart-routing: розбивайте потоки по гео/типу карт до «дешевих» еквайрів.
3. A2A/Open Banking/Local methods для зниження частки дорогих карт.
4. Tiered volume discounts: зафіксувати пороги і рев'ю щоквартально.
5. Cap на fixed-fees для micro-ticket сегментів.
6. Transparent FX: reference-rate + фіксований spread_bps, звіти по effective FX.
7. Penalty shields: обумовити ліміти/умови scheme-штрафів та їх доказову базу.
8. Окремі MIDs для high-risk/low-risk портфелів - не «заражати» тарифи.
9. Performance-clauses: SLA по авторизаціях/3DS, інакше - зниження markup.

13) Edge-cases

Fan-out авторизацій (повторні спроби) → auth-fees злітають. Увімкнути rate-limit/soft-decline-стратегії.
Partial capture: схемні розрахунки перераховуються; важливо правильно агрегувати.
Ex-post repricing: заднім числом провайдер перерахував fees - зберігати версії файлів і ревізії batch.
Refunds пізніше cutoff: потрапили в наступний цикл - скорегувати звіти.
Картки корпоративні/premium: слідкуйте за часткою - «витягує» середній interchange.

14) Best practices (коротко)

1. Рушій розрахунку fees на вашому боці + маппінг всіх ліній файлу до компонентів.
2. IC++ і прозорий FX там, де це вигідно; blended - тільки при реальній знижці.
3. Smart-routing по BIN/гео/типу карти; A/B-тести PSP.
4. Роздільний облік фіксованих зборів і відсотка; не змішувати з FX-прибутком/збитком.
5. Версіонування pricing і файлів; детермінований reprocess.
6. Щотижневі «variance-reports» по take-rate компонентам.
7. Переговори раз на квартал з пакетом метрик: CBR, 3DS pass-rate, AR, fraud-rate, share of domestic.

15) Чек-лист впровадження

• Довідник'fee _ components'і'psp _ pricing'з версіями і періодами дії.
• Імпорт'settlement _ fees'з деталізацією Interchange/Scheme/Markup/Fixed.
• ETL розрахунку нашої версії fee по tx і звірка з файлом.
• Дашборди take-rate і компонентного стеку.
• Альберти: spike, mismatch, FX slippage, minimum monthly.
• Процедури переговорів: щоквартальна ревізія і roadmap по зниженню.

Резюме

MDR - це не «один відсоток», а набір шарів: interchange, scheme, markup, фікс-плати і FX. Прозора модель даних, власний розрахунок «еталонних» комісій, регулярна звірка з файлами PSP і осмислена маршрутизація платежів перетворюють вартість прийому в керований KPI. З такою дисципліною ви бачите реальний take-rate, знаходите «витоки» в FX і фікс-зборах і впевнено знижуєте TCO платежів.