Bankacılıkta MASAK uyumu ve işlem izleme
Bir bankada uyum görevlisi tek bir müşteriyi değerlendirmek için bugün dört ayrı uygulamaya giriyor: AML bir üründen, kimlik tespiti başka bir üründen, işlem izleme üçüncüsünden, danışmanlık dördüncü bir firmadan. MASAK'ın bankalar için yayımladığı rehber ise 173 şüpheli işlem tipi sayıyor ve bunların önemli bir bölümü tek bir sistemin içinden görünmüyor. TruvaLI bu dördünü tek müşteri görünümünde birleştirir. Kimlik tespiti, tarama, Transaction Monitoring, risk skorlama ve vaka yönetimi aynı kural motorunu ve aynı denetim izini paylaşır.
Bankacılıkta aklama ile mücadele yükümlülüğü, 5549 sayılı Kanun kapsamındaki müşterini tanı, işlemi izle ve şüpheliyi bildir zincirinden oluşur. MASAK'ın bankalara yönelik şüpheli işlem bildirim rehberi sektöre özgü göstergeleri tek tek sayar ve bu göstergelerin çoğu tek bir sistemden görünmez: müşteri, hesap, işlem ve kanal verisinin bir arada okunmasını gerektirir.
Kimler yükümlü, süreç nasıl işliyor?
Bankalar ve bankacılık faaliyetleriyle sınırlı olmak üzere PTT, 5549 sayılı Suç Gelirlerinin Aklanmasının Önlenmesi Hakkında Kanun kapsamında yükümlü. MASAK bu grup için ayrı bir şüpheli işlem bildirim rehberi yayımlıyor ve bildirimlerin MASAK.Online sistemi üzerinden elektronik ortamda yapılmasını bekliyor.
Rehberin kapsamı yalnızca "hangi işlem şüphelidir" sorusu değil. Bildirim formunun her bölümünün hangi alanları taşıyacağını, işlemlerin hangi referans tablolarına göre kodlanacağını ve şüphenin hangi kategoriye yerleştirileceğini de tanımlıyor. Bu, bir bankanın izleme yazılımından beklediği çıktıyı doğrudan belirliyor.
Rehber hangi göstergeleri sayıyor?
| Grup | Tip sayısı | Neye bakıyor |
|---|---|---|
| Müşteri profili | 8 | Beyanın kendisi ve beyandan kaçınma |
| Genel işlemler | 4 | Tutar ve akış |
| Bankacılık işlemleri | 112 | Havale, nakit, kart, kredi, kanal |
| Terör örgütleri ve riskli ülkeler | 23 | Taraf ve coğrafya |
| Kitle imha silahlarının finansmanı | 9 | Yaptırım rejimi |
| Diğer | 17 |
En kalabalık grup olan 112 bankacılık tipinin dağılımı bir bankanın kuracağı izleme yapısını belirliyor: 41'i havale ve transferle, 18'i nakit ve parçalamayla, 19'u dijital kanallarla, 12'si kredi ve teminatla, 9'u kart ve ATM işlemleriyle ilgili.
Göstergeler neden tek bir sistemden görünmüyor?
Rehberdeki tipleri okuyup hangi verinin gerektiğine bakmak, sorunun neden bir izleme ürünü satın almakla bitmediğini gösteriyor.
| Tip | Ne diyor | Hangi sistemler buluşmak zorunda |
|---|---|---|
| T-001-3.21 | Aynı bankanın birden fazla şubesindeki düşük bakiyeli durağan hesaplara gelen transferlerin ATM'lerden azami tutarla çekilmesi | Hesap ana verisi, şube, transfer, ATM |
| T-001-3.95 | Finansal işlemler sonrası kiralık kasa ziyaretlerinin olağandışı artması | Şube kiralık kasa erişim kaydı, çekirdek bankacılık |
| T-001-3.44 | Kredi kartından sürekli nakit çekimi ve kartın altın gibi kolay nakde çevrilen mallarda sıra dışı kullanımı | Kart sistemi, üye iş yeri kategorisi |
| T-001-3.60 | Cebe havaleyle gönderilen çok sayıda transferin aynı ATM'den kısa sürede çekilmesi | Transfer sistemi, ATM |
Bu dördü birlikte okunduğunda ortaya çıkan sonuç şu: bir bankada asıl soru hangi izleme ürününün alınacağı değil, ürünün çekirdek bankacılıkla ve yan sistemlerle ne kadar tam entegre olabildiğidir. Kiralık kasa erişim kaydı şube tarafında, finansal işlem çekirdek bankacılıkta durur; ikisi bir araya gelmeden T-001-3.95 hiçbir zaman tetiklenmez.
Bağlantılı hesaplar
T-001-3.7, görünürde birbirinden bağımsız hareket eden müşterilerin aynı adres ve telefon bilgilerini vermesini, aynı lehtarlara havale göndermesini, aynı amirlerden havale almasını veya hesaplarında imza yetkisini aynı kişilere vermesini tek bir tip altında topluyor.
Dört sinyal, dört ayrı yerde durur: iletişim bilgisi müşteri ana verisinde, lehtar ve amir bilgisi transfer kayıtlarında, imza yetkisi ise hesap açılış dosyasında. Tekil işlem kontrolü bunların hiçbirini birbirine bağlamaz.
T-001-3.16 makul açıklama olmaksızın çok sayıda kişinin aynı hesaba para yatırmasını veya birçok ayrı hesaptan aynı hesaba transfer yapılmasını sayıyor. Bu, tek bir hesabın etrafındaki ağın çıkarılmasını gerektirir.
Parçalama, nakit ve mesleğin referans olması
T-001-3.14 müşterilerin bildirim prosedürlerinden kaçınmak amacıyla parayı birden fazla hesaba, havaleye veya nakde bölmesini sayıyor ve teşebbüsü de kapsıyor. Yani gerçekleşmemiş bir işlem de bildirime konu olabilir; sistemin reddedilen ve yarıda kalan işlemleri de saklaması gerekir.
T-001-3.18 hesaplardaki nakit hareketlerinin müşterinin hayat standardı, işi ve gelir seviyesiyle ilişkisinin kurulamamasını gösterge sayıyor. Bu, meslek ve gelir beyanının kabul anında alınıp bırakılan bir alan olmadığını gösteriyor: her işlemle karşılaştırılan bir referans. T-001-3.2 zaten müşteriden faaliyeti, mesleği ya da kimlik, adres ve telefon bilgilerinin alınmasında zorluk yaşanmasını ayrı bir tip olarak sayıyor.
Bildirim formu ne istiyor?
Rehber bildirim formunun bölümlerini ve her bölümün alanlarını tanımlıyor. İzleme yazılımının üretmesi gereken çıktı budur.
Parasal değer içermeyen şüpheli hususlar, örneğin şüphe duyulan hesap açılış ve kapanışları, kiralık kasa ziyaretleri, kefalet ve vekâlet işlemleri, formun şüpheli işlem bölümüne değil açıklama bölümüne yazılır. Yani bir vaka, parasal olmayan olayları da taşıyabilmelidir.
Bir bildirim tek bir işleme dayanabileceği gibi belli bir tarih aralığındaki birden fazla işleme de dayanabilir. Çoklu işlem hâlinde toplam tutar ve tarih aralığı birlikte raporlanır. Şüpheli işlemler farklı kanallarda, şubelerde veya türlerde yoğunlaşıyorsa form bölümü her bir küme için tekrarlanabilir.
Bu üçü birlikte, vaka yönetiminden somut bir şey istiyor: vaka hem parasal olmayan olayı taşıyabilmeli, hem bir tarih aralığındaki işlemleri toplayıp tek kalem olarak verebilmeli, hem de kanala ve şubeye göre ayrı kümeler üretebilmeli.
Şüphe kategorisi nasıl seçiliyor?
Bildirim yapılırken şüphe, MASAK'ın referans tablosundaki 38 kategoriden birine yerleştiriliyor ve her kategori ilgili yasal düzenlemeyle eşleştirilmiş durumda. Tefecilik ve POS tefeciliği 5237 sayılı Kanun'un 241 inci maddesine, fuhuşa teşvik veya aracılık 227 nci maddesine bağlanıyor. Liste vergi kaçakçılığından hileli iflasa, yasa dışı bahis oynatmaktan kitle imha silahlarının yayılmasının finansmanına kadar uzanıyor.
Bu, vaka yönetiminin kendi serbest etiketleriyle değil bu taksonomiyle çalışması gerektiği anlamına geliyor. Kategori seçimi bildirimin kendisinin bir parçası.
Erteleme talepli bildirimde eşik nedir?
5549 sayılı Kanun'un "İşlemlerin ertelenmesi" başlıklı 19/A maddesine dayanan yönetmelik, bildirime istinaden işlemin ertelenmesini düzenliyor. Erteleme talepli bildirim için rehber açık bir eşik koyuyor: işleme konu mal varlığının aklama veya terörizmin finansmanı suçuyla ilişkili olduğuna dair salt şüpheden öte, şüpheyi destekleyen belge veya ciddi emare bulunması ve gerekçeleriyle birlikte gönderilmesi.
Bu eşik doğrudan bir sistem gereksinimi üretiyor: kanıtın vakaya iliştirilmiş, gerekçenin yazılı ve kararın kim tarafından verildiğinin kayıtlı olması gerekir. Uyarı ekranındaki bir not bu eşiği karşılamaz.
Veri nerede duruyor?
Bankaların bilgi sistemleri BDDK denetimine tabi. Bu, izleme ürününün nerede çalıştığını ve müşteri verisinin nereye çıktığını teknik bir tercih olmaktan çıkarıp denetlenebilir bir konu hâline getiriyor.
TruvaLI kurum içi kurulumu destekler: yazılım bankanın kendi altyapısında çalışır, müşteri verisi bankanın bilgi sistemlerinde kalır, anahtarlar ve denetim izi bankanın kontrolündedir. Bulut ve özel bulut da seçenek olarak durur, karar bankanındır.
TruvaLI bunu nasıl karşılıyor?
Tek müşteri görünümü
Çekirdek bankacılıktan gelen hesap ve işlem verisi, kart sisteminden gelen ATM ve harcama kayıtları, kredi tarafındaki teminat hareketleri ve şube tarafındaki kayıtlar aynı müşteri kaydına bağlanır. Alan eşleme dinamiktir, bankanın kendi veri modeli değiştirilmeden bağlanır; yeni bir alan geldiğinde kural yazılabilir hâle gelir. Teşebbüs aşamasında kalmış ve reddedilmiş işlemler de saklanır, çünkü T-001-3.14 teşebbüsü de kapsıyor.
Kural motoru ve ilişki analizi
Rehberdeki tipler kurala dönüştürülür: iç içe mantık, serbest toplama pencereleri ve kuraldan callback ile. Ortak adres, telefon, cihaz ve IP üzerinden bağlantılı hesap ağları çıkarılır, T-001-3.7 ve T-001-3.16 gibi ilişki temelli tipler tekil işlem kontrolüne bırakılmaz.
Yeni bir kuralı canlıya almadan önce simülasyonda geçmiş trafikte denersiniz, üreteceği uyarı hacmini görürsünüz. Geçmiş bir tarih verip o günün trafiğinde sonucu da görebilirsiniz. Kuralı prompt ile kendi dilinizle tarif edip taslağı onaylayabilirsiniz.
Vaka, kanıt ve kategori
Uyarı sahibi, süresi ve kanıtı olan bir vakaya dönüşür. Vaka parasal olmayan olayları da taşır, bir tarih aralığındaki işlemleri toplam olarak verebilir ve kanala göre ayrı kümeler üretebilir. Şüphe kategorisi MASAK'ın 38 kategorilik taksonomisinden seçilir.
Kim, hangi yetkiyle, hangi veriyle ve ne zaman karar verdi bilgisi değiştirilemez denetim izine yazılır; ikinci çift göz onayı maker/checker ile yürür. Erteleme talepli bildirimin gerektirdiği belge ve gerekçe vakaya iliştirilir. Bildirim taslağı aynı vaka verisinden hazırlanır ve imza bankada kalır.
Bankaların düzenleyicisi BDDK'dır; aklama yükümlülükleri bakımından muhatap MASAK'tır ve çerçeve MASAK yükümlülükleri sayfasındadır. İlgili akışlar: müşteri kabulü, sürekli izleme, yaptırım uyumu, fon kaynağı incelemesi ve düzenleyici raporlama. Kural tarafı kural ve senaryo motoru, kurulum kurum içi kurulum sayfasında.
Kaynak
MASAK, "Bankalar ve Bankacılık Faaliyeti ile Sınırlı Olmak Üzere PTT Şüpheli İşlem Bildirim Rehberi", MSK-RHB-ŞİB-001, sürüm 2.0.
Bu sayfa mevzuat yorumu değildir, rehberde sayılan göstergeleri ve usulleri aktarır. Kurallar, eşikler ve aksiyonlar bankanın kendi risk politikasına ve yükümlülüklerine göre yapılandırılır.
Sık sorulan sorular
- TruvaLI çekirdek bankacılık sistemiyle entegre olabilir mi?
- Evet. Alan eşleme dinamiktir, bankanın kendi veri modeli değiştirilmeden bağlanır. Kart, kredi ve şube tarafındaki kayıtlar da aynı müşteri görünümüne bağlanabilir; rehberdeki tiplerin bir bölümü zaten bu sistemlerin birlikte okunmasını gerektiriyor.
- Rehberdeki 173 tipin hepsini kural olarak yazmak zorunda mıyız?
- Rehber bunun tersini söylüyor: yükümlüler kendilerini sayılan tiplerle sınırlandırmamalı, şüphe doğuran bir işlem hiçbirine uymasa dahi bildirimde bulunmalıdır. Tipler asgari ortak zemin, tavan değil.
- Müşteri verisi bankanın dışına çıkar mı?
- Kurum içi kurulumda çıkmaz. Yazılım bankanın kendi altyapısında çalışır, veri bankanın bilgi sistemlerinde kalır, anahtarlar ve denetim izi bankanın kontrolündedir. Bulut ve özel bulut da seçenektir, karar bankanındır.
- Yeni bir kural canlıya almadan önce denenebilir mi?
- Evet. Kural simülasyonda geçmiş trafik üzerinde çalıştırılır ve üreteceği uyarı hacmi görülür. İstediğiniz bir tarihi verip o günün trafiğinde sonucu da görebilirsiniz.
- Bankaların düzenleyicisi kim?
- Bankacılık faaliyetlerinin düzenleyicisi BDDK'dır. Aklama ve terörizmin finansmanı yükümlülükleri bakımından muhatap MASAK'tır.
- Göstergeler neden tek bir sistemden görünmüyor?
- Çoğu gösterge müşteri, hesap, işlem ve kanal verisinin bir arada okunmasını gerektirir; bu veriler bankalarda genellikle ayrı sistemlerde durur.
- Bağlantılı hesaplar nasıl tespit ediliyor?
- Ortak IP, cihaz, telefon, adres ve karşı taraf üzerinden hesaplar arasındaki ilişki ağı çıkarılır; tek tek hesaplara bakıldığında görünmeyen kümeler böyle ortaya çıkar.
- Çekirdek bankacılık sistemiyle entegrasyon nasıl oluyor?
- Uygulama olayları gönderir, sistem skoru ve kararı döndürür. Finansal olmayan olaylar da aynı yoldan geçer ve kurallarda kullanılır.