Türk Ödeme Kuruluşları (PSP'ler), bankalardan farklı ama eşdeğer ağırlıkta AML/yaptırım tarama yükümlülüklerine tabidir. 5549 sayılı Kanun'un 4. maddesi PSP'leri yükümlü olarak listeler; BDDK PSP'leri lisanslar ve denetler; MASAK raporlama beklentilerini doğrudan PSP'ye yöneltir. Bu yazı PSP-spesifik yaptırım tarama mimarisini — merchant onboarding, işlem akışı, settlement süreci — ve Türk regülasyon çerçevesini ele alır.
PSP'lerin AML Karmaşıklığı: Bankadan Ne Farkı Var?
PSP'nin AML perspektifinden ana fark, "müşterinin" çift katmanlı olması:
- Merchant (üye işyeri): PSP'nin doğrudan kontrat müşterisi; e-ticaret sitesi, perakende mağaza, B2B fatura ödeme platformu
- End-user (son kullanıcı): Merchant'ın müşterisi; PSP teknik olarak ona hizmet vermez ama ödemeyi işler
PSP'nin AML yükümlülüğü öncelikle merchant'a, ikincil olarak yüksek-riskli işlem örüntülerinde end-user'a yöneliktir. Klasik bir tier-2 PSP'nin ölçeği:
- ~30.000 aktif merchant
- Günlük ~150.000 işlem (kartlı + havale + alternatif ödeme)
- Aylık 5-12 milyar TL toplam volume
- AML ekibi: 6-12 kişi
Mimari Bileşenler
1. Merchant Onboarding
Bir e-ticaret sitesi veya perakende işletme PSP'ye merchant olarak başvurduğunda:
- KYB (Know Your Business) süreci: Şirket tüzel kişilik bilgileri (vergi kimlik no, ticaret sicil), faaliyet alanı, web sitesi, sahiplik yapısı
- UBO (Ultimate Beneficial Owner) tespiti: %25+ pay sahibi gerçek kişileri çıkar
- Yaptırım/PEP taraması: Şirket + UBO + yetkili temsilci(ler) tüm listelere karşı
- Endüstri risk değerlendirmesi: Yüksek riskli sektör mü (kumar, yetişkin içerik, kripto, döviz, silah, vb.)
- Merchant risk seviyesi atama: Düşük/orta/yüksek; izleme yoğunluğunu belirler
Onboarding latency hedefi: 5-30 saniye (bankaya göre gevşek; merchant başvuru süreci zaten dakikalar sürer).
BDDK lisans çerçevesi gereği, PSP merchant onboarding'de standart KYC ve AML adımlarını uygulamak zorundadır.
2. End-User Tarama (İşlem Anında)
End-user (kart sahibi veya havale yapan kişi) tarama:
- Yüksek tutarlı işlemler: Belirli eşik üstü (örn. 50.000 TL+) işlemlerde end-user adı taranır
- Yüksek riskli ülke kartı: Yurtdışı kart işlemlerinde, kart sahibi ve issuer bank kontrol
- Tekrarlayan örüntü: Aynı end-user'ın çoklu merchant'ta tekrarlayan işlemleri (KYC alt-eşik altında kalma örüntüsü)
- Refund/chargeback örüntüsü: Anormal chargeback hızı yaptırım kaçınma sinyali
PSP'nin teknik kısıtı: kart bilgisi PCI-DSS kapsamında, end-user ismi sınırlı bilgide. Buna rağmen, gerekli alanlar AML tarama için yeterlidir.
3. Settlement Akışı
Merchant'a ödeme aktarımı (settlement) öncesi:
- Merchant aktif yaptırım eşleşmesi yok mu kontrol et
- Settlement hesabı sahibi (genelde merchant tüzel kişiliği) tarama
- Merchant ülke transferi yapılıyorsa hedef ülke kontrolü
4. Yüksek Tutarlı İşlem Akışı
Belirli eşik üstü (örn. 200.000 TL üstü tek işlem) için:
- End-user KYC bilgisi merchant'tan istenir (örn. kart sahibinin tam adı, kimlik no)
- Yaptırım/PEP taraması
- Anomali tespiti (örn. düşük-tutarlı geçmişe sahip merchant'ta ani yüksek-tutarlı işlem)
MASAK Yükümlülükleri PSP'ye Özgü
MASAK 16 No'lu Yönetmeliği PSP'leri yükümlü olarak tanımlar ve şüpheli işlem raporlama (STR) yükümlülüğünü belirler:
- STR zamanlaması: 10 iş günü içinde MASAK'a sunum
- STR formatı: GoAML XML
- Saklama: Tüm tarama kararları + STR + denetim verisi 8 yıl
- Yüksek riskli müşteri kategorisi: MASAK 5 No'lu Tebliği'ne göre yabancı PEP, yüksek riskli ülke vatandaşı/kuruluşu, FATF gri/kara liste, vb.
PSP-spesifik MASAK beklentisi: merchant'ın altındaki end-user davranış örüntülerini izleme. Bir merchant'ın altında benzer örüntülü çoklu yüksek-tutarlı işlem örüntüsü STR tetikleyici olabilir.
Detaylı çerçeve için MASAK uyumluluğu rehberi.
E-ticaret PSP'si vs B2B PSP'si
E-ticaret PSP'si (kart + alternatif ödeme):
- Hacim yüksek (günde 100K+ işlem)
- Tutar düşük (ortalama 200-2000 TL)
- End-user tarama selektif (yüksek-tutarlı ve risk sinyali olanlar)
- Chargeback yönetimi kritik
- Liste taraması: BM, OFAC, AB, UK, MASAK
B2B PSP'si (kurumsal ödemeler, fatura ödeme):
- Hacim düşük (günde 1K-10K işlem)
- Tutar yüksek (ortalama 50K-500K TL)
- End-user (alıcı kuruluş) tam tarama
- Sahiplik şeffaflığı kritik (UBO derinlemesine)
- Liste taraması: Yukarıdaki + ek sektörel listeler
Mimari aynı, ayar farklı. Aynı API'yi farklı segment-bazlı kurallarla kullanmak yaygın.
E-Ticaret Sezonsal Hazırlığı (Black Friday, Yılbaşı)
E-ticaret PSP'lerinin yılın en yoğun dönemlerinde (Black Friday haftası, yılbaşı, sevgililer günü, anneler günü) günlük işlem hacmi 5-10x'e fırlar. AML tarama altyapısı bu yüke hazır olmalı:
Kapasite: Tarama API throughput'u tipik günün 10x'ine ölçeklenebilir olmalı. Vendor SLA'sı bu kapasiteyi taahhüt ediyor mu? Capacity test sezona 6-8 hafta önce yapılmalı.
False-positive kontrolü: Yoğun hafta boyunca FP spike olursa AML ekibi boğulur. Pre-season threshold review; pattern eğitimi (özellikle yeni merchant'lar için); analist throughput planı.
Yeni merchant velocity: Sezona doğru yeni merchant kayıt sayısı artar. Onboarding tarama latency ve manuel review SLA korunabilmeli. Önceden hazırlık: extra analist ataması, otomasyon eşik ayarı.
Chargeback spike: Sezon sonrası 30-60 gün chargeback yoğunluğu artar. Bu, sanctions evasion red flag pattern'ini gizleyebilir. Sezon sonu özel pattern detection raporları faydalı.
Yüksek-tutar kart işlemleri: Sezon hediye dönemlerinde tek tutar 50K+ kart işlemleri artar. Risk-based threshold otomatik gevşemesi (sezon ayarı) düşünülebilir — ama compliance birim onayı gerek.
Cross-border: Black Friday özellikle ABD/AB satıcılarından TR alıcılarına yapılan işlemleri tetikler. Yaptırım ülke listesi taraması artırılmalı; ABD kart issuerlarının BIN profilleri güncel olmalı.
Vaka: Bir Orta-Büyüklük Türk PSP'sinin Migrasyonu
Tier-2 Türk PSP'si (~25.000 merchant, günlük ~120.000 işlem) eski parçalı AML sistemini Legichain'e migrate etti. Önceki durum:
- Manuel merchant onboarding tarama (saatlerce sürüyor)
- İşlem-anı tarama yok (sadece batch, gün sonu)
- False-positive %91 (sanctions name-only)
- AML ekibi: 8 kişi, %85'i manuel review
Migrasyon sonrası (4 aylık proje):
- Merchant onboarding tarama: ortalama 4 saniye (sahiplik yapısı UBO çıkarma dahil)
- İşlem-anı tarama: aktif, p99 <120 ms
- False-positive: %2-4 (multi-attribute scoring sonrası)
- AML ekibi: 5 kişi (azalan iş yükü, terfi/yeniden kullanım)
- MASAK STR raporlama: case management'tan tek-tık GoAML
PSP'nin ölçeği bankadan küçük, ama AML mimari ihtiyacı eşdeğer karmaşık.
PSP'ye Özgü Risk Senaryoları
PSP iş modelinin getirdiği AML risk senaryoları ve azaltma yolları:
Merchant'ı kötüye kullanma: Düşük-tutar kayıtlı bir merchant'ın altında yüksek-tutar veya yaptırım rejimi ile ilişkili işlemler. Tespit: merchant beklenen hacim profili → gerçek davranış kıyaslaması; anomali eşiği.
Friendly fraud + sanctions: End-user kasıtlı olarak yaptırım rejimine ödeme yapıp sonra chargeback çağırıyor. Tespit: anormal chargeback hızı + chargeback ülke profili.
Müşteri tarafı yaptırım kaçınma: Sanctioned bir kişi alt-eşik tutarlı işlemlerle yaptırım kontrolünden kaçınmaya çalışıyor. Tespit: structuring pattern algoritması (aynı end-user farklı merchant'larda çoklu küçük tutar).
Merchant mismatch: Kayıtlı endüstri kategori ile gerçek işlem örüntüsü uyumsuz (örn. "kıyafet satışı" kayıtlı merchant gambling sitesi gibi davranıyor). Tespit: MCC + tutar dağılımı + işlem frekansı kıyaslaması.
Money mule: End-user'ın hesabı arada bir başkası adına işlem yapıyor (klasik money mule yapısı). Tespit: işlem örüntü değişimi + IP/cihaz değişikliği + havale kaynağı analizi.
Sahte merchant başvurusu: Yaptırım kapsamındaki kişi proxy bireyler aracılığıyla merchant açıyor. Tespit: UBO derinlemesine doğrulama + ortaklık bağ kontrolü.
Bu senaryoların hepsi için pure-list-screening yetersiz; PSP'nin transaction monitoring + behavioural analytics katmanı şart.
Pratik Mimari Önerileri
1. API-first. Modern PSP yığını mikroservis tabanlı; AML tarama da API olarak entegre olmalı. Onboarding servisi + işlem servisi + settlement servisi her biri tarama API'sini ayrı ayrı çağırır.
2. Risk segmentasyonu. Tüm merchant'lara aynı tarama hassasiyeti = pahalı. Risk seviyesine göre eşik ayarı. AML risk skorlama modeli merchant tarafında uygulanır.
3. Batch + real-time hibrit. Yüksek-tutar işlemler real-time; küçük tutar işlemler batch (gün sonu) yeterli olabilir. Real-time kapsamı operasyonel maliyetle dengelenir.
4. PCI-DSS sınırı. Kart bilgisi tokenize edilmiş şekilde tutulur; AML tarama için sadece gerekli alanlar (cardholder name, BIN, tutar) gönderilir. Hassas kart numarası asla tarama API'sine gitmemeli.
5. Chargeback örüntüsü ile tarama bütünleştir. Anormal chargeback hızı AML alarm sistemine bağlanmalı; sadece yaptırım eşleşmesi değil, davranış örüntüsü de izlenir.
Sıkça Sorulan Sorular
PSP'nin yaptırım tarama yükümlülüğü banka kadar mı?
Yapısal olarak evet — 5549 sayılı Kanun açısından PSP de yükümlü, bankayla aynı kapsamda. Pratik farklı: PSP'nin müşteri tabanı genelde merchant (B2B); end-user (kart sahibi) doğrudan müşterisi değil. Bu yüzden PSP'nin onboarding AML yükü banka kadar yoğun değil, işlem tarama yükü ise eşit veya daha yüksek (yüzlerce bin günlük işlem).
Merchant onboarding'de UBO bilgisi alınamıyorsa ne yapılır?
UBO bilgisi alınamıyor = onboarding tamamlanamaz; 5549 sayılı Kanun yükümlü müşteri tanıma kalitesini şart koşar. Pratikte: merchant tüm sahiplik bilgisini paylaşmıyorsa, onboarding reddedilir veya yüksek risk merchant olarak işaretlenir + manuel sahiplik araştırması yapılır (ticaret sicil kayıtları, Merkez Sicil Kayıt Sistemi). Anonim merchant kabul edilemez.
E-ticaret PSP'sinde end-user yaptırım taraması nasıl yapılır?
Tüm işlemleri tek tek yaptırım tarama maliyetli ve kullanıcı deneyimini öldürür. Pratik yaklaşım: belirli eşik üstü işlemler (örn. 50K TL+) tek-tek tarama; düşük tutarlı işlemler için merchant-bazlı toplam analiz (aynı merchant'taki tüm end-user'ların toplam hacmi). Yüksek riskli ülke kartlarında (BIN'e göre tespit) eşik daha düşük tutulur.
Yüksek riskli sektör merchant'ı (örn. kripto, kumar) almak zorunda mıyız?
PSP risk iştahı kararı. Yüksek riskli sektörler için MASAK ek belge ve daha sıkı izleme bekliyor; bazı PSP'ler bu yükten kaçınmak için bu sektörleri komple reddediyor. Lisanslı KVHS'ler için Türkiye'de bankalar genelde hizmet veriyor; PSP'ler genelde tercih meselesi. Kabul ettiğinizde EDD süreci, ek liste taraması, daha sık review zorunlu.
MASAK STR raporu PSP için kim hazırlar?
MLRO (Money Laundering Reporting Officer) — Türkçe karşılığı "Uyum Görevlisi". PSP içinde bu görevi taşıyan kişi STR'yi hazırlar, MASAK GoAML portalına gönderir, 8 yıl saklar. Compliance ekibinin diğer üyeleri de STR taslak çalışmasında olabilir ama nihai onay ve gönderim MLRO sorumluluğundadır.
Legichain ile PSP Yaptırım Taraması
Legichain AML tarama API'si PSP yığını için merchant onboarding, işlem tarama ve settlement akışlarına ayrı endpoint'ler sunar. Merchant KYB akışında UBO çıkarma, sahiplik yapısı analizi, küresel + Türkiye PEP veritabanı taraması tek API çağrısıyla.
İşlem tarama tarafında p99 <80 ms, PCI-DSS uyumlu data minimization (sadece tarama için gerekli alanlar), webhook tabanlı match notification, GoAML formatına STR ihracı. Bir tier-2 Türk PSP'sinde 4 aylık migrasyon sonrası AML ekibi efor %60 azaldı, false-positive %72 düştü.
PSP'ler için solution sayfamız bu segmentin gereksinim setini detaylı sunuyor.