Yerleşim döngüleri ve kesme

1) Kavramsal taban

Uzlaşma - PSP/Acquirer ile tüccar (operatör) arasında, başarılı bir şekilde ele geçirilen işlemler için paranın tüccar hesabına aktarıldığı anlaşma.
Kesme - belirli bir faturalandırma döngüsüne giren günlük bir işlem "dilimi" (genellikle sağlayıcının saat diliminde sabit bir zaman).
T + N - fonların gönderilmesindeki gecikme için tipik gösterim: T - kesme tarihi, N - gerçek kayıttan önceki iş günü sayısı.

• Kartlar (Visa/Mastercard): Genellikle T + 2/T + 3 bankacılık günleri, kesim 23:00 UTC (yaklaşık).
• A2A/Open Bankacılık: T + 0 - T + 1.
• SEPA Kredi Transferi: T + 1/T + 2 (Anında - T + 0).
• ACH (ABD): T + 2/T + 3; Aynı gün ACH - T + 0/T + 1.
• RTP (ABD): T + 0, ancak raporları kesmek mümkündür.
• Crypto: Aslında ağ üzerinden T + 0, ancak PSP kendi finansman pencerelerini uygulayabilir (T + 0/1).

2) Kesim nasıl çalışır ve içine ne girer

1. Sağlayıcı toplama penceresini düzeltir (örneğin, 00: 00-23: 00 UTC).
2. Bu penceredeki tüm yerleşmiş/yakalanmış işlemler bir yığın haline gelir.
3. Geri dönüşler, ters ibrazlar, düzeltmeler brüt ve net finansmanı hesaplamak için pakete toplanır.
4. Kesildikten sonra, bir yerleşim dosyası oluşturulur ve T + N zamanlayıcısı kayıttan önce başlar.

Önemli: yakalama olmadan yetkilendirme pakete dahil değildir. İptal edilen sonuçlar - ayrıca değil.

3) Yerleşim türleri: brüt vs net, rezervler ve komisyonlar

Brüt ödeme - brüt yakalama miktarı aktarılır (eksi ayrı bir komisyon ücreti).
Net uzlaşma - sağlayıcı ücretler, ters ibrazlar, geri ödemeler, haddeleme rezervi tutar ve net tutarı listeler.
Rolling rezervi - riski karşılamak için N gün için cironun % stopajı (örneğin, 180 gün için %10).
Negatif taşıma - "net" günde eksi olursa, açık aktarılır ve bir sonraki döngülerde ödenir.

Öneri: Her iki düzlemin de şifresinin çözülmesi - operasyonel brüt (işlemlere göre) ve finansman ağı (sağlayıcı dosyalarına göre).

4) Zaman Dilimleri, Yerel Çıktı ve DST

Kesme, tedarikçinin sizinkinden farklı olabilecek saat dilimine göre belirlenir.
DST'yi (gün ışığından yararlanma saati) düşünün - dilimler yerel saate göre ± 1 saat değişebilir.
Alıcı bankanın yetki alanındaki tatiller/hafta sonları T + N cinsinden N'yi etkiler (örneğin, T + 2 bankacılık günleri tatillerde T + 4 olur).
Uygulama: UTC'deki tüm teknik zamanları normalleştirin, aynı anda 'provider _ tz _ cutoff _ at've' local _ tz _ posted _ at 'depolayın.

5) Yerleşim takvimi (finansman takvimi) ve SLA

• Her yöntem/PSP için kesme süresi ve tz,
• Standart T + N ve istisnalar (tatiller),
• Beklenen miktarlar (tahminler),
• SLA makbuzu: örneğin,'en geç 12:00 Avrupa/Kiev'de T + 2 gününde ".

Herhangi bir SLA sapması - uyarı ve Ops/Finance bileti.

6) Net Mevduat ve Çıkışlarla İlişki

ND (net katkılar), yerleşmiş işlemlere sayılır (ilgili makaleye bakınız).
Sonuçlar (para çekme), mevduat konusunda PSP'den fonlamaya katılmaz, ancak tüccarın nakit masasını etkiler.
Likidite planlaması: ödemeler/vergiler/işletme giderleri ile yerleşim eksi çıkış yoluyla giriş.

7) Uzlaşma ve sağlayıcı eserler

• 'batch _ id/ settlement_id', tz sağlayıcısında kesim tarihi,
• суммы по типам: 'yakalanan _ mevduatlar', 'geri ödemeler', 'geri ödeme _ borçlar', 'geri ödeme _ krediler', 'ücretler', 'rezerv _ delta', 'net _ finansman',
• Yöntemlere/tüccar hesaplarına göre şifre çözme ('MID', 'descriptor', 'MCC'),
• İşlem referansları ('provider _ tx _ id', 'rrn', 'arn' - eğer kartlar),
• Dosya (lar): CSV/XML/JSON + insan tarafından okunabilir deyimi (PDF/HTML).

1. İşlemlerden dosyalara (dosyada olduğunu düşündüğümüz her şey?)

2. Dosyalardan işlemlere (dosyadaki her şey vitrinimizde mi? Statüler eşleşiyor mu?)

8) Ödeme raylarının özellikleri (genel anlamda)

Haritalar: sık sunum gecikmesi senaryoları; Geç 'geri ödeme' mümkündür (dava için 120-540 güne kadar); Değişim şeması ücretleri dosyalarda görünür, ND'de düşülmez.
SEPA/ACH: Partiler banka pencerelerine bağlıdır; İptaller/iadeler kendi kodlarına sahiptir Aynı Gün seçenekleri ayrı kesintilerdir.
Açık Banking/A2A: T + 0/1, ancak dosyalar post-factum'a gidebilir; Eşleşmeler için sıkı RPP/Benzersiz Kimlik ihtiyacı.
RTP/Anında: para hızlı bir şekilde gelir, ancak rapor dosyası programa uygundur.
Kripto: Onchain yerleşim anında, ancak sağlayıcı 'ödeme pencereleri' yapar; Mağaza 'fx _ at _ settle'.

9) Muhasebe (FI/Muhasebe)

9. 1. Tahakkuk vs önbellek yöntemi

Yönetim raporlaması için tahakkuk sıklıkla kullanılır: 'settled _ at' zamanında geliri/hareketi tanırız.
Hazine/DDS için - önbellek yöntemi: 'funded _ at' makbuzu gerçeğini kabul ediyoruz.

9. 2. Tipik kablolama (basitleştirilmiş)

• JT: PSP ile anlaşmada nakit (AR: PSP)
• KT: Oyuncu Bağlılığı (Çanta/Oyuncu Bakiyesi)

• Dt: Banka (kasiyer ofisi)
• Kt: PSP ile anlaşmalarda nakit
• JT: Giderler (PSP ücretleri), JT: Karşılıklar (değiştirilirse)

Bir demet saklarsınız 'transaction _ id> batch_id funding_id' iz için.

10) Risk yönetimi ve uyarılar

Cevapsız dosya: X: YY - P1'den önce çözüm dosyası yok.
Finansman gecikmesi: T + N süresi dolmuş, para yok - P1.
Delta eşikleri: varyans 'our _ gross' vs 'file _ gross'> 0. %5 - P2; Kapsama alanı dışında 'fies' - P2.
Negatif taşıma: Bir dizi negatif net paketi - bir soruşturma.
Tatil etkisi: takvimi dikkate alarak otomatik tahmin; Gerçek ise <80 % tahmini - bilet.

11) Veri modeli (basitleştirilmiş)

finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12) SQL şablonlarına örnekler

12. 1. Kesme kaydı

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12. 2. İşlemden dosyaya mutabakat

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_cr
FROM finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12. 3. Gelir Tahmini (nakit akışı T + N)

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13) İşlemler ve SLO'lar

SLO 1: import settlement files - T + 0, until 08:00 Europe/Kyiv.
SLO 2: ilk mutabakat - 09:00'a kadar, varyanslar> 0. 5%.

SLO 3: Nakit akışı tahmini güncellemesi - saat 10: 00'a kadar

SLO 4: Günün kapanışı - tüm finansman maçları DWH'ye yönlendirilir.

14) Kenar durumları ve bunların nasıl ele alınacağı

Geç sunum: işlem bir sonraki partiye girdi - "kaynak gerçeğini" ('presented _ in _ batch _ id') saklayın.
Kısmi yakalama: yetkilendirme başına çoklu yakalama - toplu olarak doğru şekilde toplanın.
Multi-MID: bir sağlayıcı, geo/markaya göre farklı MID'ler - tek bir grupta karıştırmayın.
Yeniden işleme: bir dosya sıkıştırıldığında - 'batch _ revision' sürümü ve tam yeniden doğrulama.
FX yarışları: kurslar - 'settled _ at' üzerinde; Farklı bir para biriminde fonlama - 'fx _ at _ funding've delta'yı başlatın.

15) Gösterge panoları ve KPI'lar

Finansman ETA: beklenen tarih/makbuz saati vs gerçek.
Hit-rate SLA: Zamanında gelen dosyaların yüzdesi.
Delta brüt/net sağlayıcıya göre, yöntem, MID'ler.
Hacim ücretleri %, Rezerv dengesi, Negatif taşıma çizgisi.
Tatil etkisi: Tatil ile haftaya göre gerçek vs tahmin.

16) En iyi uygulamalar (kısa)

1. Zamanı UTC'ye normalleştirin, ancak kesme provider_tz tutun.
2. Ayrı operasyonel brüt ve finansman ağı; ND ve finansmanı karıştırmayın.
3. Önceden girilmiş resmi tatillerle bir finansman takvimi uygulayın.
4. Yerleşim dosyalarının içe aktarılmasını ve mutabakatını otomatikleştirin + SLA'lara/deltalara uyarılar.
5. Batch _ revision ve deterministik yeniden işleme uygulayın.
6. Tip tek gerçek kaynağı: 'işlem ↔ toplu ↔ finansmanı' bağlantıları.
7. ARN/RRN ve kart edinme alanlarını kaydedin - anlaşmazlıklar için kritik önem taşır.
8. Hafta sonları/tatiller, rezervler ve komisyonları dikkate alarak nakit akışını tahmin edin.

17) Uygulama kontrol listeleri

Veri ve diyagramlar

• Таблицы 'payment _ transactions', 'settlement _ batches', 'funding _ receipts', 'recon _ links'.
• Zaman dilimi alanları UTC + provider_tz.
• Поля FX: 'fx _ rate _ at _ settle', 'fx _ at _ funding'.

İçe aktarma ve doğrulama

• CSV/XML/JSON ayrıştırıcılar + dosya karmaları.
• Miktarların/para birimlerinin/tarihlerin doğrulanması; 'provider _ tx _ id/ARN' по eşleştir.
• İşleyicilerin "geç sunumu", "kısmi yakalama", "tersine çevirme".

İşlemler ve Uyarılar

• SLA monitör kesintisi, cevapsız dosyalar, finansman gecikmeleri.
• Delta eşiği uyarıları (brüt, ücretler, net).
• Tatil etkisi ve olumsuz taşıma raporu.

18) SSS

S: T + 2 neden T + 4 oldu?
C: Muhabir bankada veya alıcı bankada hafta sonları/tatiller vardı; см. finansman takvimi.

S: Net dosyada net hesaplamamızdan daha az var. Ne izleyeyim?
A: Ücretleri, reserve_delta, geç geri ödeme/ters ibraz ve kursların doğruluğunu kontrol edin.

S: Crypt için nasıl hesap yapıyorsunuz?
C: Fiat eşdeğeri ile 'settled _ at'; Finansman USDT/fiat'a gelebilir - ayrı bir 'fx _ at _ funding' tutun.

S: Tüm sağlayıcılar için ortak bir kesinti olması mümkün mü?
C: Hayır, her PSP'nin kendi tz/saati vardır. Dilimleri üzerinde toplama görüntüsü oluşturun.

Özet

• Sağlayıcıları doğru bir şekilde doğrulamak,
• Tahmin likidite ve teminat ödemeleri,
• SLA'lara uymak ve operasyonel riskleri azaltmak,
• Finans ve uyum ile aynı dili konuşur.

Tek bir finansman takvimi, titiz bir veri modeli ve otomatik mutabakat uygulayarak, nakit akışını öngörülebilir ve yönetilebilir hale getirirsiniz.