Gebührenstruktur: MDR, scheme, PSP

1) Begriffskarte und woraus sich der MDR zusammensetzt

1. Interchange (ausstellende Bank): Prozentsatz nach Kartentyp/Region/Kategorie.

2. Scheme fees (Zahlungssysteme): Bewertung, Verarbeitung, Cross-Border, Markengebrauch usw.

3. Acquirer/PSP markup: Acquirer/Provider-Zuschlag (Prozent + Fix).

4. Dop. Gebühren: Chargeback-Gebühr, Refund-Gebühr, Representation, Retrieval, Auth-Gebühr, Gateway-Gebühr, Rolling Reserve (keine Provision, aber Auswirkungen auf den Cash-Flow), FX-Spread bei der Konvertierung.

Die Gesamtkosten für den Händler = Interchange + Scheme + Markup + Feste Gebühren + FX-Effekte ± Reserve.

2) Preismodelle

2. 1. Blended (flat)

Ein Prozent + fix. All-inclusive-Gebühr. Einfach, aber undurchsichtig: blendet interchange/scheme und FX-Spread aus.

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

Interchange und Scheme gehen „as is“, oben gibt es einen festen Markup-Anbieter. Transparent, leichter zu überprüfen, vorteilhaft mit einem „billigen“ Kartenportfolio.

2. 3. Tiered/Pricing buckets

Mehrere „Körbe“ (inländisch, intra-EWR, inter-regional, kommerziell, premium). Bequem für die Berichterstattung, kann die tatsächlichen Kosten verschleiern.

2. 4. Alternative Methoden (A2A/Wallet/Crypto)

Häufiger Flat-Fee oder% unter Karten; separate Netz-/Anbietergebühren und FX-Effekt bei der Konvertierung.

3) Wo und wann eine Provision entsteht

Auth ./Validation: Gebühr für Autorisierungsversuch (Usp ./Nesp.) .
Capture/Settle: Hauptanteil der MDR.
Refund/Teilrefund: Retouren werden oft separat abgerechnet (+ Neuberechnung scheme).
Chargeback/Representment: фикс. Fall-/Etappengebühren.
Gateway/Plattform: monatliche Abonnementgebühr, Gebühr für Webhooks, Reporting, Tokenisierung von Karten.
FX/Conversion: implicit-Marge PSP/Bank (Spread), wenn die Umwandlung auf ihrer Seite ist.
Kalender: minimum monthly fee, early termination, PCI-Board, 3DS-fee, fraud-suite fee.

4) Zuschläge und Tarifkorrektoren

Cross-Border (Emittent ≠ Land), CNP (Card-Not-Present), Premium/Commercial Card.
High-risk verticals (iGaming) - erhöhte markup/reserve.
Schematische Strafen/Schwellenmetriken: CBR-Überschreitung → zusätzliche Gebühren.
SCA/3DS: separate Gebühr pro Transaktion/Versuch.
Mindestticket/Kleinticket: Erhöhte Fix. Gebühren für kleine Schecks.

5) Gross vs Net settlement und „wo die Zinsen gingen“

Gross-Einstellung: Die Welle wird mit der PSP berechnet, die Provisionen werden in einer separaten Zeile entfernt (einfacher zu überprüfen).
Net settlement: net funding = Umsatz − interchange − scheme − markup − fix. Gebühren − Reserve.
In Net-Szenarien ist es kritisch, die Aufteilung einer Komponente zu importieren, sonst „springt“ die Take-Rate.

6) Formeln und „effektive“ Metriken

6. 1. Effektive Take-Rate (nach Methode/PSP)

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

6. 2. Zerlegung in Komponenten

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

6. 3. Ausfallkosten (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. Die Kosten für Charjbacks

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

7) Datenmodell (vereinfacht)

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) Überleitung: von Transaktionen zur Datei und zurück

8. 1. Tx → File (überprüfen Sie, was „wie in der Datei“ gezählt wurde)

Aggregieren Sie Ihren Einkaufswagenumsatz (BIN/Region/Kartentyp) × den Preisregeln.
Wenden Sie interchange/scheme/markup/fix-Gebote an.
Überprüfen Sie mit 'settlement _ fees. total_fees` по batch. Delta> Schwelle → Ticket.

8. 2. File → Tx (überprüfen Sie, ob die Datei nicht „extra“ ist)

Verteilen Sie Batch-Fee proportional zum Umsatz/Anzahl der Transaktionen bis zum TX-Level (mit Blended/No Detail).
Entdecken Sie unerwartete Positionen (extra fee line, penalty, minimum monthly top-up).

9) Beispiele für SQL-Vorlagen

9. 1. Berechnung der effektiven Take-Rate nach Methoden/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. Umverteilung von Batch-Fee auf Transaktionen (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. Ablehnungskosten und Genehmigungskosten

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-Spread hervorheben (wenn es eine effektive Rate gibt)

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) KPIs und Dashboards

Effektive Take-Rate% nach PSP/Methode/MID/Land.
Komponenten-Stack: Interchange%, Scheme%, Markup%, Fixed per trx.
Cost-per-Approval und Decline-burden (wie viel kosten die Ausfälle).
FX Slippage (bps und in Berichtswährung).
Refund/CB Kosten pro 1000 Transaktionen.
Penalty/Minimum-monthly Vorfälle.
Reserve als% von GMV (um die Auswirkungen auf den Cache-Flow zu verstehen).

11) Alerts und Schwellenwerte

Take-rate spike: Wachstum> X bps d/d oder> Y bps w/w.
Scheme delta: Abweichung der berechneten scheme-fees von der Datei> 0. 3–0. 5%.
FX Slippage:> 80 bps für Dur oder> 150 bps für Moll.
Decline cost surge: Anstieg der Genehmigungskosten bei sinkender AR.
Unmapped fee line: Neue Zeile in der Datei ohne Mapping der Komponente.
Minimum monatlicher Shortfall: Umsatzausfall zum Minimum (vor Zuschlag).

12) Verhandlung und Kostensenkung

1. Wechseln Sie zu IC++, wenn das Portfolio günstig ist (Haushalts-, Verbraucherdebit).
2. BIN-Routing/Smart-Routing: Streams nach Geo/Kartentyp auf „billige“ Acquirer aufteilen.
3. A2A/Open Banking/Local-Methoden zur Reduzierung des Anteils teurer Karten.
4. Tiered volume discounts: Schwellen und Revue vierteljährlich erfassen.
5. Cap auf Fixed-Fees für Micro-Ticket-Segmente.
6. Transparent FX: Referenzrate + feste spread_bps, Berichte zu effective FX.
7. Penalty shields: Legen Sie die Grenzen/Bedingungen der Scheme-Strafen und ihre Beweisgrundlage fest.
8. Separate MIDs für High-Risk/Low-Risk-Portfolios - nicht „infizieren“ Tarife.
9. Performance-Klauseln: SLA durch Autorisierungen/3DS, ansonsten Markup-Reduktion.

13) Edge-cases

Fan-out-Autorisierungen (Wiederholungsversuche) → auth-fees nehmen Fahrt auf. Aktivieren Sie Rate-Limit/Soft-Decline-Strategien.
Partielle Erfassung: Schematische Berechnungen werden neu berechnet; Es ist wichtig, richtig zu aggregen.
Ex-post-Repricing: Im Nachhinein hat der Anbieter die fees neu berechnet - Dateiversionen und Batch-Revisionen speichern.
Refunds später cutoff: gefangen im nächsten Zyklus - Berichte anpassen.
Corporate/Premium-Karten: Achten Sie auf den Anteil - „zieht“ den durchschnittlichen Wechselkurs.

14) Best Practices (kurz)

1. Die fees Berechnungsmaschine auf Ihrer Seite + Mapping aller Dateilinien zu den Komponenten.
2. IC++ und transparentes FX, wo es vorteilhaft ist; blended - nur mit einem echten Rabatt.
3. Smart-Routing nach BIN/Geo/Kartentyp; PSP A/B-Tests.
4. Getrennte Buchführung von festen Gebühren und Zinsen; nicht mit FX-Gewinn/Verlust zu verwechseln.
5. Versionierung von Preisen und Dateien; deterministische Reprocess.
6. Wöchentliche „variance-reports“ nach Take-Rate-Komponenten.
7. Verhandeln Sie einmal im Quartal mit einem Paket von Metriken: CBR, 3DS Pass-Rate, AR, Fraud-Rate, Anteil der inländischen.

15) Checkliste Umsetzung

• Referenz' fee _ components' und 'psp _ pricing' mit Versionen und Gültigkeitszeiträumen.
• Import 'settlement _ fees' mit Interchange/Scheme/Markup/Fixed Detail.
• ETL Berechnung unserer fee Version durch tx und Abgleich mit der Datei.
• Take-Rate und Komponenten-Stack Dashboards.
• Алерты: spike, mismatch, FX slippage, minimum monthly.
• Verhandlungsverfahren: vierteljährliche Prüfung und Roadmap zur Reduzierung.

Zusammenfassung

MDR ist kein „ein Prozent“, sondern ein Satz von Schichten: interchange, scheme, markup, fix boards und FX. Ein transparentes Datenmodell, die eigene Berechnung der „Benchmark“ -Gebühren, der regelmäßige Abgleich mit den PSP-Dateien und das sinnvolle Payment-Routing machen aus den Empfangskosten einen überschaubaren KPI. Mit dieser Disziplin sehen Sie eine echte Take-Rate, finden „Leaks“ in FX und Fix-Gebühren und senken den TCO der Zahlungen zuversichtlich.