Ödeme sistemlerinde her işlem birkaç saniye içinde gerçekleşir, ancak arka planda onlarca kontrol, doğrulama ve güvenlik katmanı çalışır. Bu katmanların amacı yalnızca işlem hızını değil, aynı zamanda finansal bütünlüğü korumaktır.
Bu yazıda, provizyon (authorization) ve takas (clearing) süreçlerinde alınması gereken önlemleri, reversal mekanizmasının kritik rolünü ve sahada en sık karşılaşılan finansal kayıp senaryolarını ele alıyoruz.
Provizyon Aşamasında Risk Kontrolleri
Provizyon, kartın geçerliliğinin, bakiyesinin ve işlem yetkilerinin kontrol edildiği ilk aşamadır. Bu noktada yapılan bir hata, takas sürecinde finansal kayıplara dönüşebilir.
Temel Önlemler
- Limit kontrolleri: Kartın günlük, işlem başı ve sektör bazlı limitlerinin sistematik olarak doğrulanması.
- PIN ve CVV doğrulaması: Özellikle çevrimiçi işlemlerde (CNP), sahteciliği önleyen en temel güvenlik katmanı.
- Velocity kontrolü: Aynı karttan kısa sürede çok sayıda işlem yapılması durumunda alarm tetiklenmesi.
- Cross-border risk değerlendirmesi: Kartın ve POS’un bulunduğu ülkelerin farklı olması durumunda risk skoru yükseltilmeli.
- ISO 8583 alan kontrolleri: DE 2, DE 4, DE 11, DE 37, DE 41, DE 42 gibi alanlarda format ve tutarlılık kontrolü yapılmalı.
Mesaj Tutarlılığı
- Her provizyon mesajı, benzersiz bir STAN (DE11) ve RRN (DE37) ile tanımlanır. Bu kombinasyonun tekrar eden (replay) mesajlarda kullanılmaması gerekir.
- Dual message (authorization + financial) işlemlerinde, sistem izleme katmanı bu iki mesajın eşleştiğini doğrulamalıdır.
Takas (Clearing) Sürecinde Tutarlılık
Takas süreci, provizyonu alınan işlemlerin finansal olarak hesaplara yansıtıldığı aşamadır. Burada yaşanacak bir tutarsızlık doğrudan zarar riski oluşturur.
Veri ve Muhasebe Kontrolleri
- Authorization–Clearing eşleşmesi: DE37 (RRN), DE38 (Auth Code) ve DE62 (Issuer Data) alanlarının birebir uyumlu olması gerekir.
- Tutar uyuşmazlığı (amount mismatch) kontrolleri: Özellikle dövizli işlemlerde ISO 4217 para birimi kodları (DE49) mutlaka doğrulanmalı.
- Duplicate clearing önleme: Aynı işlem iki kez gönderilirse sistem bunu reddetmelidir.
Mutabakat ve Raporlama
- Günlük otomatik mutabakat sistemleriyle provizyon, takas ve muhasebe kayıtları arasında fark tespiti yapılmalıdır.
- Hatalı, eksik veya mükerrer işlemler “exception report” olarak günlük analiz edilmelidir.
Reversal Mekanizması: Finansal Dengeyi Koruyan Unsur
Reversal, bir işlemin provizyon alındıktan sonra başarısız sonuçlanması ya da teknik hatalar nedeniyle tamamlanamaması durumunda, önceden ayrılan bakiyenin geri serbest bırakılması sürecidir.
Eğer reversal süreci doğru yönetilmezse, hem kart hamili hem de banka tarafında haksız bloke veya çift tahsilat gibi sorunlar yaşanabilir.
Ne Zaman Reversal Gönderilir?
- İşlem POS veya ağ kesintisi nedeniyle zamanında tamamlanamadığında, terminal veya issuer host tarafından “timeout reversal” gönderilir.
- İşlem merchant tarafından iptal edildiğinde (örneğin POS’tan iptal tuşuna basıldığında) manuel reversal oluşur.
- İşlem network time-out sonrası acquirer ile issuer arasında onay alınmadan sonuçlanırsa, acquirer tarafı otomatik reversal tetikler.
Teknik Uygulama: ISO 8583 Alanları
Reversal mesajı (MTI 0400 veya 0420), orijinal işlemi referans almak zorundadır. Bunun için:
- DE90 (Original Data Elements) alanı, iptal edilen işlemdeki DE7, DE11, DE32 ve DE37 bilgilerini taşır.
- DE39 (Response Code) ile işlem sonucunun “00” dışında bir hata kodu dönmesi reversal’ın tetikleyicisi olabilir.
- DE95 (Replacement Amounts) alanı bazı ağlarda kısmî tutar iadesi için kullanılır.
Operasyonel Önlemler
- Zaman kuralı: Timeout reversal’lar belirli bir sürede (ör. 30 saniye) gönderilmezse, işlem “open authorization” olarak kalır.
- Takip sistemi: Her reversal mesajının ilgili authorization mesajıyla birebir eşleştiği, transaction monitor katmanında doğrulanmalıdır.
- Gün sonu izleme: Gün sonunda açık (reverse edilmemiş) provizyonlar tespit edilip manuel işlemle kapatılmalıdır.
Reversal Hatalarının Tipik Sonuçları
- Kart hamili bakiyesi düşer, ancak işlem gerçekleşmemiştir.
- Acquirer tarafı, clearing dosyasında reversal olmayan işlemi tekrar takasa gönderirse çift tahsilat oluşabilir.
- Issuer, reversal kaydı almadığı için unmatched transaction (eşleşmeyen işlem) olarak kalabilir.
En Çok Yaşanan Finansal Kayıp Senaryoları
Gerçek saha tecrübelerinde sık karşılaşılan finansal kayıp senaryoları genellikle üç ana kategoriye ayrılır: işlemsel hatalar, sistemsel tutarsızlıklar ve operasyonel eksiklikler.
Timeout Reversal Gönderilememesi
- POS veya acquirer host, işlem başarısız olduğunda reversal mesajını zamanında göndermez.
- Kart hamili hesabı blokelenir, clearing tarafında ise işlem yeniden takasa girer → çift çekim riski.
Duplicate Authorization (Çift Provizyon)
- Terminal aynı STAN veya RRN’i yeniden kullanır.
- Issuer iki provizyonu da onaylar; ancak sadece biri takasa girer → blokaj farkı ve müşteri şikâyeti.
Reversal–Clearing Uyumsuzluğu
- Issuer reversal alır, ancak acquirer clearing dosyasını yine de gönderir.
- Bu durumda issuer tarafında “duplicate settlement” oluşur → zarar issuer’a yazılır.
Amount Mismatch (Tutar Uyumsuzluğu)
- Özellikle dövizli işlemlerde, provizyon tutarı ile clearing tutarı farklı hesaplanır.
- Kur farkı, decimal hatası veya rounding farkı → muhasebe farkı.
Gecikmiş Reversal (Stale Reversal)
- Gün sonunda reversal yerine gönderilen mesaj clearing sonrası ulaşır.
- Issuer reversal’ı kabul etmez, acquirer clearing kaydını iptal edemez → uzun süren dispute.
Terminal veya Network Replay
- POS veya ağ, önceden onaylanmış bir mesajı yeniden gönderir.
- Eğer replay kontrolü (STAN + RRN) yapılmamışsa işlem ikinci kez işlenir → duplicated debit.
Sistemin sorunsuz çalışması için neler dikkat edilmeli?
- Reversal simülasyonu: Geliştirme ortamında ağ kesintisi ve timeout senaryoları test edilmelidir.
- Otomatik mutabakat: Reversal, clearing ve core banking kayıtları arasında günlük eşleştirme yapılmalı.
- Fraud motoru entegrasyonu: Çok sayıda reversal gönderen üye işyerleri veya terminaller yakından izlenmeli.
- PCI DSS loglama gereksinimleri: Her reversal işlemi, 10.2 ve 10.5 maddeleri kapsamında loglanmalı.
Sonuç
Ödeme sistemlerinde finansal kayıpların önlenmesi yalnızca fraud önlemleriyle değil, teknik bütünlüğün korunmasıyla mümkündür.
Provizyon, takas ve reversal süreçleri, zincirin üç halkasıdır — biri zayıf olduğunda tüm sistem risk altına girer.
Bu nedenle reversal mekanizmasının zamanında ve doğru uygulanması, finansal güvenliğin ve müşteri memnuniyetinin temelidir.
