Структура комиссий: 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 платежей.