Bankacılıkta Risk Yönetimi: Kredi, Fraud, AML ve Ödeme Sistemlerinde Riskler Nasıl Yönetilir?

Bir bankadan kredi çektiğimizde, kredi kartımızla alışveriş yaptığımızda veya başka bir hesaba para gönderdiğimizde, gördüğümüz işlem genellikle birkaç saniyede tamamlanır. Ancak arka planda yalnızca para transferi ya da bakiye kontrolü yapılmaz. Bankalar, her gün çok sayıda finansal ve operasyonel riski değerlendirmek zorundadır.

Örneğin, bir müşteri 20.000 TL tutarında internet alışverişi yaptığında bankanın yalnızca kart limitini kontrol ettiğini düşünebiliriz. Oysa bu işlemde kartın geçerliliği, güvenlik doğrulamaları, dolandırıcılık riski, işlem limitleri ve çeşitli operasyonel kontroller de devreye girebilir.

Üstelik bankacılıkta risk yönetimi yalnızca kart işlemlerinden ibaret değildir. Bir müşteriye kredi verilmesi, bankanın döviz pozisyonu taşıması, mevduatların yönetilmesi, yeni bir yazılımın canlı ortama alınması veya dışarıdan bir teknoloji hizmeti satın alınması da risk yönetiminin kapsamına girer.

Bankacılıkta başarılı bir işlemin yalnızca teknik olarak tamamlanmış olması yeterli değildir. İşlemin finansal olarak doğru, güvenli, izlenebilir ve mevzuata uygun olması da gerekir.

Bu yazıda bankacılık risklerini, gerçek hayatta karşılaşılabilecek örnekler üzerinden inceleyeceğiz. Özellikle ödeme sistemlerinde çalışan yazılımcıların bilmesi gereken fraud, AML, chargeback, operasyonel dayanıklılık ve risk değerlendirme mimarilerine odaklanacağız.

Not: Yazıda kullanılan müşteri isimleri, işlem tutarları, oranlar ve risk puanları öğretici amaçlarla oluşturulmuş örneklerdir. Gerçek bankaların iç politikalarını veya karar eşiklerini temsil etmez.

1. Bankacılıkta Risk Yönetimi Nedir?

Risk yönetimi (Risk Management), bir bankanın faaliyetlerinden kaynaklanabilecek olumsuz olayların belirlenmesi, değerlendirilmesi, kontrol edilmesi ve sürekli izlenmesidir.

Buradaki önemli nokta, risk yönetiminin bütün riskleri ortadan kaldırmayı hedeflememesidir.

Bir banka kredi vermeyi tamamen durdurursa kredi kaynaklı zarar ihtimalini azaltabilir. Ancak bu durumda temel faaliyetlerinden birini de gerçekleştiremez.

Benzer şekilde bir banka bütün yüksek tutarlı kart işlemlerini reddederse bazı dolandırıcılık girişimlerini engelleyebilir. Fakat gerçek müşterilerinin alışverişlerini de gereksiz yere kısıtlamış olur.

Bu nedenle bankalar Risk Appetite (Risk İştahı) adı verilen bir yaklaşım benimser.

Risk iştahı, bankanın stratejik hedefleri doğrultusunda kabul etmeye hazır olduğu risklerin seviyesini ifade eder.

Örneğin bir banka:

• Belirli sektörlerdeki kredi yoğunlaşmasını sınırlayabilir.
• Yüksek riskli üye işyerleri için daha sıkı kontroller uygulayabilir.
• Kritik ödeme sistemleri için düşük kesinti toleransı belirleyebilir.
• Belirli işlemlerde ek müşteri doğrulaması isteyebilir.
• Olağanüstü ekonomik koşullara karşı likidite tamponu bulundurabilir.

Risk yönetimi temel olarak beş aşamada düşünülebilir:

Riskin tanımlanması → Ölçülmesi → Kontrol edilmesi → İzlenmesi → Raporlanması

Örneğin yeni geliştirilen bir sanal POS uygulamasını düşünelim.

Sistem canlıya alınmadan önce şu soruların cevaplanması gerekir:

1. Aynı ödeme isteği iki kez gönderilirse ne olacak?
2. Fraud servisi yanıt vermezse işlem nasıl yönetilecek?
3. Bankadan başarılı yanıt alınmasına rağmen uygulama timeout verirse ne olacak?
4. Gün sonundaki işlem kayıtları banka kayıtlarıyla uyuşmazsa sorun nasıl tespit edilecek?
5. Sisteme yetkisiz erişim sağlanırsa hangi veriler tehlikeye girecek?

Bu soruların her biri farklı bir riskin değerlendirilmesini gerektirir.

2. Bankacılıkta Temel Risk Türleri

Bankacılık risklerini anlamak için önce temel kategorileri öğrenmek gerekir.

Bu risk türleri bazen birbirleriyle ilişkilidir.

Örneğin bir siber saldırı bankanın ödeme sistemini durdurabilir. İlk bakışta bu olay bir siber güvenlik problemidir. Ancak sonuçları operasyonel kayıplara, müşteri şikâyetlerine, itibar kaybına ve bazı koşullarda likidite baskısına kadar uzanabilir.

Dolayısıyla bankacılıkta riskler birbirinden tamamen bağımsız ele alınmaz.

3. Credit Risk: Banka Kredi Verirken Nasıl Risk Alır?

Kredi riski (Credit Risk), bir borçlunun finansal yükümlülüğünü yerine getirememesi nedeniyle bankanın zarara uğrama olasılığıdır.

Basit bir örnek üzerinden inceleyelim.

Senaryo: Ahmet 500.000 TL kredi kullanmak istiyor

Ahmet, bankadan 500.000 TL ihtiyaç kredisi talep ediyor.

Bankanın değerlendirebileceği unsurlar arasında şunlar bulunur:

• Müşterinin gelir ve gider durumu
• Mevcut kredi borçları
• Önceki kredi ödeme performansı
• Kredi vadesi ve ödeme planı
• Mevcut teminatlar
• Ekonomik koşullar
• Müşterinin toplam borçluluk seviyesi

Banka, bu bilgilerden hareketle kredinin geri ödenememe riskini değerlendirir.

Burada üç önemli kavram bulunur.

3.1. PD — Probability of Default

PD, borçlunun belirli bir zaman aralığında temerrüde düşme olasılığıdır.

Örneğin, bir müşterinin 12 aylık PD değeri %3 olarak tahmin edilmiş olsun.

Bu, modelin müşteri için ilgili dönemde %3 temerrüt olasılığı öngördüğü anlamına gelir. Müşterinin kesinlikle temerrüde düşeceğini söylemez.

3.2. LGD — Loss Given Default

LGD, müşteri temerrüde düştüğünde bankanın risk tutarının ne kadarını kaybetmesinin beklendiğini gösterir.

Örneğin bankanın 500.000 TL alacağı olduğunu varsayalım.

Banka teminatları, tahsilat imkânlarını ve diğer faktörleri değerlendirdiğinde temerrüt hâlindeki kayıp oranını %45 olarak tahmin edebilir.

3.3. EAD — Exposure at Default

EAD, temerrüt anında bankanın maruz kaldığı risk tutarını ifade eder.

Örneğimizde temerrüt anındaki risk tutarının 500.000 TL olduğunu varsayalım.

3.4. Expected Loss nasıl hesaplanır?

Basitleştirilmiş beklenen kayıp hesabı şu şekildedir:

Expected Loss = PD × LGD × EAD

Örneğimizde:

• PD = %3
• LGD = %45
• EAD = 500.000 TL

Hesaplama:

0,03 × 0,45 × 500.000 = 6.750 TL

Bu varsayımlar altında ilgili dönem için basitleştirilmiş beklenen kredi kaybı 6.750 TL olur.

Ancak bu tutar, bankanın kesin olarak 6.750 TL kaybedeceği anlamına gelmez. İstatistiksel bir beklenen kayıp tahminidir. Gerçek karşılık, fiyatlama ve sermaye gereksinimi hesaplamalarında daha kapsamlı yöntemler kullanılır.

3.5. Gerçek dünyada neye dikkat edilir?

Banka yalnızca müşterileri ayrı ayrı değerlendirmez; kredi portföyünün bütününe de bakar.

Örneğin toplam kredi portföyünün çok büyük kısmı inşaat sektöründeki şirketlerden oluşuyorsa, sektörde yaşanacak bir daralma birçok müşteriyi aynı anda etkileyebilir.

Buna Concentration Risk, yani yoğunlaşma riski denir.

Banka bu nedenle müşteri, sektör, ülke ve diğer risk yoğunlaşmaları için limitler belirleyebilir.

4. Market Risk ve Liquidity Risk: Banka Karlı Olsa Bile Neden Sorun Yaşayabilir?

Bankaların finansal olarak güçlü görünmesine rağmen ciddi problemler yaşamasının nedenlerinden biri piyasa ve likidite riskleridir.

4.1. Market Risk — Piyasa Riski

Piyasa riski; faiz oranları, döviz kurları ve diğer piyasa fiyatlarındaki değişimlerin bankanın finansal pozisyonlarını olumsuz etkileme ihtimalidir.

Örneğin banka belirli bir faiz oranından tahvil satın almış olsun.

Piyasadaki faiz oranları yükseldiğinde, sabit faizli tahvilin piyasa değeri düşebilir.

Benzer şekilde döviz cinsinden varlık ve yükümlülükler arasındaki uyumsuzluk, kur değişimlerinde zarara neden olabilir.

Bankalar bu riskleri yönetebilmek için pozisyon limitleri, senaryo analizleri, duyarlılık ölçümleri ve stres testleri uygular.

4.2. Liquidity Risk — Likidite Riski

Likidite riski, bankanın finansal yükümlülüklerini zamanında karşılayamaması ihtimalidir.

Bir örnek düşünelim.

Bir bankanın uzun vadeli kredilerde önemli miktarda varlığı bulunuyor. Ancak çok sayıda mevduat sahibi kısa süre içinde parasını çekmek istiyor.

Bankanın gelecekte tahsil edeceği kredi alacakları olabilir. Fakat bu alacaklar hemen nakde dönüştürülemeyebilir.

Bu durumda banka geçici veya ciddi bir likidite problemi yaşayabilir.

4.3. LCR ve NSFR

Bankaların likidite riskini değerlendirmesinde kullanılan iki önemli göstergeden bahsedelim.

LCR (Liquidity Coverage Ratio), bankanın belirlenen 30 günlük stres senaryosunda net nakit çıkışlarını karşılayabilecek yüksek kaliteli likit varlıklarını ölçer.

Basitleştirilmiş örnek:

• Yüksek kaliteli likit varlıklar: 120 milyon TL
• 30 günlük stres dönemi net nakit çıkışı: 100 milyon TL

LCR = 120 / 100 × 100 = %120

Bu örnekte oran %120 olur. Gerçek hesaplamalarda varlık uygunluk kriterleri, nakit akışı varsayımları ve düzenleyici kurallar dikkate alınır.

NSFR (Net Stable Funding Ratio) ise bankanın daha uzun vadede istikrarlı fonlama yapısına sahip olup olmadığını değerlendirir.

Yazılım geliştirici açısından önemli nokta şudur: Bu göstergeler için birçok farklı sistemden doğru ve güncel veri toplanması gerekir.

Yanlış bakiye, eksik veri veya hatalı raporlama yalnızca teknik bir problem değildir; bankanın risk durumunun yanlış değerlendirilmesine de neden olabilir.

5. Operational Risk: Bir Yazılım Hatası Nasıl Finansal Zarara Dönüşür?

Operasyonel risk (Operational Risk), yetersiz veya başarısız iç süreçler, insanlar, sistemler ya da dış olaylardan kaynaklanan zarar riskidir.

Yazılımcılar açısından en somut risk türlerinden biridir.

Senaryo: 10.000 TL iki kez transfer edildi

Mehmet'in bankacılık uygulamasından başka bir hesaba 10.000 TL gönderdiğini düşünelim.

Normal akış şöyle ilerler:

1. Mehmet transfer talebini oluşturur.
2. Bankanın API sistemi isteği alır.
3. Gerekli limit ve güvenlik kontrolleri yapılır.
4. Para transferi gerçekleştirilir.
5. Sonuç mobil uygulamaya iletilir.

Ancak dördüncü aşamada transfer başarıyla gerçekleşmesine rağmen, beşinci aşamada bağlantının koptuğunu varsayalım.

Mobil uygulama başarılı yanıtı alamadığı için işlemi başarısız sanabilir.

Mehmet tekrar gönder butonuna basarsa ne olacak?

Sistem gerekli kontrolleri içermiyorsa aynı transfer ikinci kez gerçekleştirilebilir.

İşte burada Idempotency kavramı devreye girer.

5.1. Idempotency neden önemlidir?

Idempotency, aynı mantıksal isteğin tekrar iletilmesinin ek bir finansal işleme neden olmamasını sağlamak için kullanılan önemli bir tasarım prensibidir.

Örneğin transfer oluşturulurken benzersiz bir işlem anahtarı üretilebilir.

İlk istekte:

• İşlem anahtarı: transfer-10001
• Tutar: 10.000 TL
• Alıcı: Mehmet'in belirlediği hesap
• Durum: İşleniyor

Sistem aynı işlem anahtarıyla ikinci istek aldığında yeniden para göndermek yerine önceki işlemin durumunu kontrol etmelidir.

Ancak yalnızca bir anahtar üretmek yeterli değildir.

Gerçek bir sistemde anahtarın kalıcı olarak kaydedilmesi, aynı anahtarla farklı içerikte istek yapılmasının engellenmesi, eşzamanlı isteklerin yönetilmesi ve işlem sonucunun doğru şekilde saklanması gerekir.

5.2. Reconciliation neden gereklidir?

Diyelim ki uygulamanın veritabanında 1.000 adet başarılı işlem görünüyor.

Ancak banka veya ödeme kuruluşundan alınan finansal kayıtlar 999 adet işlem içeriyor.

Bu durumda bir tutarsızlık vardır.

Reconciliation (Mutabakat), farklı sistemlerde tutulan finansal kayıtların karşılaştırılarak tutarsızlıkların tespit edilmesini sağlayan süreçtir.

Örneğin aşağıdaki bilgiler karşılaştırılabilir:

Bu durumda TX-1006 için araştırma yapılmalıdır.

İşlem gerçekten gerçekleşmemiş olabilir, banka kaydı gecikmiş olabilir veya uygulama yanlış başarı durumu üretmiş olabilir.

Burada doğru yaklaşım, işlemi otomatik olarak tekrar çalıştırmadan önce gerçek finansal durumunu doğrulamaktır.

Dağıtık ödeme sistemlerinde bir isteğin başarılı yanıt döndürmesi ile finansal işlemin gerçekten ve yalnızca bir kez gerçekleşmesi aynı şey değildir.

5.3. Diğer önemli mühendislik kontrolleri

Bankacılık sistemlerinde aşağıdaki teknik yaklaşımlar operasyonel riskin azaltılmasına yardımcı olur:

• Audit Trail: İşlemlerin ve önemli sistem değişikliklerinin izlenebilir olması.
• Maker-Checker: Kritik işlemlerde hazırlayan ve onaylayan kişilerin ayrılması.
• Role-Based Access Control: Kullanıcıların yalnızca yetkili oldukları işlemleri yapabilmesi.
• Circuit Breaker: Bir servisin arızasının diğer servislere yayılmasının azaltılması.
• Retry Policy: Tekrarlanan isteklerin kontrollü ve güvenli yönetilmesi.
• Transactional Outbox: Veritabanı işlemleri ile mesaj yayımlama arasındaki tutarsızlık riskinin azaltılması.
• Disaster Recovery: Büyük arıza veya felaket sonrasında sistemlerin geri kazanılması.

Bu kontroller birbirini tamamlar; hiçbirinin tek başına eksiksiz finansal güvenlik sağladığı düşünülmemelidir.

6. Fraud Risk: Bir Kart İşleminin Riskli Olduğuna Nasıl Karar Verilir?

Fraud, bir kişi veya kuruluşun kasıtlı aldatma yoluyla haksız kazanç elde etmeye çalışmasıdır.

Kartlı ödeme sistemlerinde çalıntı kart kullanımı, hesap ele geçirme, sahte üye işyeri faaliyetleri ve benzeri yöntemler fraud riskinin örnekleridir.

Bu noktada gerçekçi bir e-ticaret senaryosu üzerinden ilerleyelim.

Senaryo: Ahmet 25.000 TL tutarında alışveriş yapıyor

Ahmet'in bir e-ticaret platformundan 25.000 TL değerinde elektronik ürün satın aldığını varsayalım.

İşlemde:

• Kart sahibi: Ahmet
• Issuer: Garanti BBVA
• Acquirer: İş Bankası
• Ödeme kanalı: E-ticaret
• İşlem tutarı: 25.000 TL

Bu örnekte kullanılan kurum isimleri yalnızca issuer ve acquirer rollerini açıklamak içindir.

Bir kartlı ödeme işleminde, işlemin yönlendirilmesine ve tarafların kullandığı altyapıya bağlı olarak şu bileşenler rol oynayabilir:

Kart sahibi → Üye işyeri → Ödeme altyapısı / Acquirer → Kart ağı → Issuer

Fraud değerlendirmesi, bu akışın farklı noktalarında gerçekleştirilebilir.

Acquirer tarafı üye işyerini ve işlemi değerlendirebilirken, issuer tarafı kart sahibinin işlem davranışlarını inceleyebilir.

6.1. Fraud Engine hangi verilere bakabilir?

Örneğin aşağıdaki sinyaller değerlendirilebilir:

İşlem tutarı: Ahmet normalde 500–2.000 TL arasında alışveriş yaparken ilk kez 25.000 TL harcıyor olabilir.

Velocity kontrolü: Kartla son birkaç dakika içerisinde çok sayıda ödeme denemesi gerçekleştirilmiş olabilir.

Cihaz bilgileri: Alışveriş daha önce görülmemiş bir cihazdan yapılıyor olabilir.

Konum ve ağ sinyalleri: İşlemin geldiği ağın veya coğrafi bilginin önceki davranışlardan farklı olması dikkat çekebilir.

Üye işyeri geçmişi: Üye işyerinde daha önce yüksek sayıda dolandırıcılık bildirimi veya itiraz yaşanmış olabilir.

Müşteri davranışı: İşlem, müşterinin geçmişteki alışveriş alışkanlıklarından önemli ölçüde farklı olabilir.

Bununla birlikte tek başına yeni cihaz kullanılması veya yüksek tutarlı alışveriş yapılması dolandırıcılığın kanıtı değildir.

6.2. Risk Score nasıl çalışır?

Bir risk motoru, farklı sinyalleri değerlendirerek bir skor üretebilir.

Tamamen örnek olması için 0 ile 100 arasında bir risk skoru kullanalım.

Bu aralıklar herhangi bir bankanın gerçek karar kuralları değildir.

Gerçek sistemlerde skorun nasıl yorumlanacağı; modelin yapısına, geçmiş kayıp verilerine, işlem türüne, risk iştahına ve uygulanabilir düzenlemelere göre belirlenir.

Önemli bir ayrıntı da risk skorunun nihai provizyon kararıyla aynı şey olmamasıdır.

Bir işlem fraud kontrolünden geçmiş olsa bile issuer, yetersiz limit veya kart statüsü gibi başka nedenlerle işlemi reddedebilir.

6.3. 3D Secure fraud riskini tamamen ortadan kaldırır mı?

Hayır.

3D Secure, e-ticaret işlemlerinde kart sahibinin doğrulanmasına yönelik güvenlik mekanizmaları sağlar.

Ancak başarılı bir kimlik doğrulama, işlemin her koşulda dolandırıcılıktan arınmış olduğu anlamına gelmez.

Örneğin dolandırıcı müşteriyi manipüle ederek işlemi kendisinin onaylamasını sağlayabilir.

Ayrıca kimlik doğrulaması, fraud analizi ve kartın yetkilendirilmesi farklı kontrol süreçleridir.

Dolayısıyla güvenli bir ödeme altyapısında bu mekanizmalar birbirini tamamlamalıdır.

7. Fraud Sistemlerinde En Büyük Problemlerden Biri: False Positive

Dolandırıcılık sistemlerinde amaç yalnızca riskli işlemleri yakalamak değildir.

Gerçek müşterilerin işlemlerinin gereksiz yere engellenmemesi de önemlidir.

Burada iki kavram karşımıza çıkar:

False Positive: Gerçekte meşru olan bir işlemin hatalı biçimde riskli olarak işaretlenmesi.

False Negative: Gerçekte dolandırıcılık olan bir işlemin sistem tarafından tespit edilememesi.

Bir örnek oluşturalım.

Bankada bir gün içerisinde 10.000 kart işlemi gerçekleştiğini varsayalım.

• 100 işlem gerçekten dolandırıcılık.
• 9.900 işlem meşru.
• Fraud sistemi 100 dolandırıcılık işleminin 80'ini tespit ediyor.
• Meşru işlemlerin %2'si yanlışlıkla riskli işaretleniyor.

Sonuç:

Bu durumda sistemin Recall değeri %80 olur.

Ancak riskli olarak işaretlenen 278 işlemin yalnızca 80'i gerçekten fraud olduğu için Precision yaklaşık %28,8 olur.

Yani sistemin verdiği her risk alarmı doğru değildir.

Bu nedenle bankalarda yalnızca kaç fraud işleminin yakalandığı değil; yanlış alarmların oranı, müşteri deneyimi, finansal kayıp ve inceleme maliyetleri de değerlendirilmelidir.

Yanlış işaretlenen her işlem mutlaka reddedilmek zorunda değildir. Bazıları ek doğrulamayla veya manuel incelemeyle sonuçlandırılabilir.

İyi bir fraud sistemi, güvenlik ile müşteri deneyimi arasındaki dengeyi yönetebilmelidir.

8. Chargeback Risk: Onaylanan Bir İşlem Sonradan Nasıl Zarara Dönüşür?

Bir kart işleminin issuer tarafından onaylanması, ilgili işlemin gelecekte hiçbir itiraza konu olmayacağı anlamına gelmez.

Chargeback (Ters İbraz), kart sahibinin belirli nedenlerle işlemi itiraz konusu yapması ve ilgili kart ağı kuralları kapsamında finansal düzeltme sürecinin başlatılmasıyla ilişkilidir.

Senaryo: Müşteri 15.000 TL alışveriş yaptı ve itiraz etti

Mehmet'in bir e-ticaret sitesinden 15.000 TL tutarında telefon satın aldığını düşünelim.

Ödeme başarılı şekilde gerçekleşiyor ve satıcı ürünü kargoya veriyor.

Birkaç gün sonra Mehmet bankasına başvurarak işlemi kendisinin gerçekleştirmediğini bildiriyor.

Bu durumda işlem geçmişi ve ilgili kart ağı kuralları doğrultusunda bir itiraz süreci yürütülebilir.

Üye işyeri veya acquirer tarafında aşağıdaki bilgiler önemli olabilir:

• Sipariş tarihi ve tutarı
• İşlem referans numarası
• Uygun olduğu ölçüde doğrulama sonuçları
• Sipariş ve fatura bilgileri
• Teslimat belgeleri
• Müşteriyle yapılan yazışmalar
• Kullanılabilir diğer teknik işlem kayıtları

Bu bilgiler, uyuşmazlığın niteliği ve ilgili kart ağı kurallarına göre değerlendirilir.

Örneğin ürünün teslim edilmiş olması, bazı itiraz türlerinde önemli kanıt oluşturabilir. Ancak her itirazda tek başına yeterli değildir.

Benzer şekilde 3D Secure kullanılması da bütün chargeback türlerini otomatik olarak ortadan kaldırmaz.

8.1. Chargeback riskinin yazılım tarafı

Burada önemli bir yazılım ihtiyacı ortaya çıkar.

Bir e-ticaret platformunun milyonlarca işlem arasından belirli bir kart işlemine ait bütün ilgili kayıtları hızlıca bulabildiğini düşünelim.

İyi tasarlanmış bir sistem:

1. İtiraz konusu işlemi tanımlar.
2. Sipariş ve ödeme kayıtlarını ilişkilendirir.
3. Gerekli kanıtları yetkili kişilerin erişimine sunar.
4. İtiraz türüne uygun belge akışını yönetir.
5. Son tarihleri ve dosya durumlarını takip eder.
6. Sonuçlanan dosyaları finansal kayıtlarla eşleştirir.

Bu mimaride güvenilir veri ilişkilendirme, belge bütünlüğü, erişim kontrolü ve izlenebilirlik önemli rol oynar.

Chargeback yalnızca finansal bir operasyon değil, aynı zamanda ciddi bir veri ve süreç yönetimi problemidir.

9. Merchant Risk: Riskli Olan Her Zaman Kart Sahibi Değildir

Kartlı ödeme sistemlerinde risk değerlendirmesi yalnızca kart sahibi üzerinde yapılmaz.

Acquirer tarafında üye işyerleri de önemli bir risk kaynağı olabilir.

Senaryo: Yeni bir e-ticaret mağazası

Yeni kurulan bir e-ticaret firmasının sanal POS hizmeti almak istediğini varsayalım.

Firma ilk haftalarda düşük tutarlı işlemler gerçekleştiriyor.

Bir süre sonra işlem hacmi aniden yükseliyor ve çok sayıda yüksek tutarlı satış gerçekleşiyor.

Bu durum tek başına olumsuz bir olay değildir. Başarılı bir reklam kampanyası veya yeni ürün lansmanı işlem hacmini artırmış olabilir.

Ancak risk yönetimi açısından aşağıdaki sorular gündeme gelebilir:

• Şirketin gerçek faaliyet alanı nedir?
• Satılan ürünler ve işlem tutarları iş modeliyle uyumlu mu?
• Teslimat süreleri normal mi?
• İade ve chargeback oranları nasıl değişiyor?
• Şirketin finansal yükümlülüklerini karşılayabilecek durumu var mı?
• İşlemlerin belirli kartlarda veya cihazlarda yoğunlaşması söz konusu mu?

Örneğin firma yüksek miktarda tahsilat gerçekleştirdikten sonra ürünleri teslim edemezse iade ve itiraz yükümlülükleri ortaya çıkabilir.

Acquirer, anlaşma ve uygulanabilir kurallara bağlı olarak bu tür riskler için işlem izleme, limit, teminat, rezerv veya farklı kontrol mekanizmaları kullanabilir.

Bu nedenle Merchant Risk Management, ödeme kuruluşları ve üye işyeri kabulü yapan bankalar açısından önemli bir uzmanlık alanıdır.

10. AML Nedir? Fraud ile Arasındaki Fark Nedir?

AML (Anti-Money Laundering), suç gelirlerinin aklanmasının önlenmesine yönelik politika, kontrol ve süreçleri kapsar.

Fraud ve AML birbirleriyle ilişkili olabilir ancak aynı probleme odaklanmaz.

Fraud, dolandırıcılık faaliyetlerinin önlenmesine ve tespitine odaklanırken AML, finansal sistemin suç gelirlerinin aklanması ve ilgili mali suçlar için kullanılmasının önlenmesine odaklanır.

Senaryo: Bir hesap üzerinden olağandışı para hareketleri

Yeni açılan bir banka hesabına kısa süre içerisinde birbirinden farklı kişilerden çok sayıda transfer yapıldığını düşünelim.

Bu tutarların büyük bölümü kısa süre sonra başka hesaplara aktarılıyor olsun.

Böyle bir işlem yapısı, müşterinin ekonomik profili ve hesap kullanım amacıyla birlikte değerlendirildiğinde inceleme gerektirebilir.

Ancak bu davranış tek başına suç işlendiği anlamına gelmez.

Örneğin bir işletmenin çok sayıda müşteriden ödeme alması ve tedarikçilerine düzenli transfer yapması tamamen meşru bir ticari faaliyet olabilir.

AML kontrollerinde bu nedenle müşteri profili ve işlemin ekonomik amacı önemlidir.

10.1. KYC — Know Your Customer

KYC, müşterinin tanınmasına yönelik süreçleri ifade eder.

Kimlik bilgilerinin doğrulanması, müşterinin faaliyetinin anlaşılması, gerçek faydalanıcının tespit edilmesi ve risk profiline uygun izleme mekanizmalarının kurulması bu yaklaşımın parçalarıdır.

Kurumsal müşteriler açısından KYB (Know Your Business) süreçleri de önemli rol oynar.

10.2. Transaction Monitoring

Transaction Monitoring, müşteri işlemlerinin belirli kurallar ve analiz mekanizmalarıyla izlenmesidir.

Örnek kontroller:

• Müşteri profiliyle uyumsuz işlem hacimleri
• Ekonomik amacı açıklanamayan transfer örüntüleri
• Birbiriyle bağlantılı hesaplar arasındaki şüpheli hareketler
• Olağandışı işlem sıklığı
• Yüksek risk göstergeleri taşıyan işlem ilişkileri

AML kontrolünde en önemli prensiplerden biri, yalnızca işlem tutarına bakılarak karar verilmemesidir.

Türkiye'deki MASAK düzenlemelerinde şüpheli işlemlerin tutar gözetilmeksizin bildirilmesi gerektiği belirtilir.

10.3. AML sistemleri otomatik olarak suç kararı verir mi?

Hayır.

Bir AML sistemi şüpheli bir örüntüyü tespit ederek alarm üretebilir.

Bu alarm, işlemi gerçekleştiren kişinin suçlu olduğunu göstermez.

Gerekli inceleme ve değerlendirme süreçleri uygulanır; şüpheli işlem bildirimi gibi yükümlülükler yetkili kişiler tarafından ilgili mevzuat çerçevesinde yerine getirilir.

Bu ayrım, yapay zekâ destekli AML sistemleri tasarlanırken de korunmalıdır.

11. Cyber Risk: Bankacılıkta Bilgi Güvenliği Neden Farklı Bir Öneme Sahiptir?

Bankacılık altyapılarında kullanılan verilerin ve kriptografik anahtarların korunması kritik öneme sahiptir.

Bir ödeme sistemini düşünelim.

Sistem; kart bilgileri, müşteri hesapları, işlem geçmişi ve finansal mesajlar gibi hassas bilgilere erişebilir.

Saldırganın bu bilgilere yetkisiz erişim sağlaması, yalnızca veri sızıntısına değil finansal kayba ve hizmet kesintisine de neden olabilir.

Bu nedenle bankacılık yazılımlarında şu prensipler önemlidir:

Least Privilege: Kullanıcılara ve sistem bileşenlerine yalnızca ihtiyaç duydukları yetkiler verilmelidir.

Segregation of Duties: Kritik işlemlerde yetkiler ve görevler uygun biçimde ayrılmalıdır.

Encryption: Hassas veriler, kullanım senaryosuna uygun kriptografik yöntemlerle korunmalıdır.

Key Management: Kriptografik anahtarların yaşam döngüsü güvenli biçimde yönetilmelidir.

Audit Logging: Kritik faaliyetler izlenebilir olmalı; loglar yetkisiz değişikliklere karşı korunmalıdır.

Vulnerability Management: Güvenlik açıkları düzenli olarak tespit edilmeli ve risklerine göre giderilmelidir.

11.1. HSM neden kullanılır?

HSM (Hardware Security Module), hassas kriptografik anahtarların güvenli şekilde yönetilmesi ve belirli kriptografik işlemlerin korumalı bir ortamda gerçekleştirilmesi için kullanılan donanım tabanlı güvenlik bileşenidir.

Kartlı ödeme sistemlerinde HSM cihazları, örneğin PIN işlemleri ve belirli kart kriptogramlarının doğrulanması gibi alanlarda kullanılabilir.

Ancak HSM kullanılması bütün güvenlik risklerini ortadan kaldırmaz.

Uygulamanın yetkilendirme kontrolleri hatalıysa veya HSM'ye erişen servisler güvenli tasarlanmamışsa sistem yine risk taşıyabilir.

11.2. PCI DSS neden önemlidir?

PCI DSS (Payment Card Industry Data Security Standard), kart verilerinin işlendiği, saklandığı veya iletildiği ortamların güvenliğine yönelik sektörel bir standarttır.

Özellikle kart verilerinin korunması, güvenli erişim, sistem izleme ve düzenli güvenlik değerlendirmeleri gibi alanlarda gereklilikler içerir.

Örneğin bir yazılım geliştiricinin debug amacıyla hassas kart doğrulama verilerini loglaması ciddi bir güvenlik ve uyumluluk problemi oluşturabilir.

Kart verilerinin hangi sistemlerde bulunabileceği, nasıl korunacağı ve hangi bilgilerin saklanamayacağı sistem tasarımının başlangıcında değerlendirilmelidir.

12. Model Risk: Yapay Zekânın Verdiği Karar Yanlışsa Ne Olur?

Bankacılıkta yapay zekâ ve makine öğrenmesi kullanımı, risk yönetimini yeni bir boyuta taşımaktadır.

Fraud Detection, kredi skorlaması, işlem izleme ve operasyonel anomali tespiti gibi alanlarda tahmin modelleri kullanılabilir.

Ancak bu modeller de hata yapabilir.

Senaryo: Fraud modeli performansını kaybediyor

Bir banka, geçmiş işlemler üzerinden makine öğrenmesi modeli eğitmiş olsun.

Modelin ilk aylarda başarılı sonuçlar verdiğini düşünelim.

Ancak zaman içerisinde müşterilerin alışveriş davranışları değişiyor. Yeni ödeme yöntemleri ortaya çıkıyor ve dolandırıcılık örüntüleri farklılaşıyor.

Bu durumda modelin geçmiş veriler üzerinde başarılı olması, gelecekte de aynı performansı göstereceğini garanti etmez.

Bu probleme Model Drift kapsamında yaklaşılabilir.

12.1. Model Drift

Model drift, modelin performansını etkileyen veri dağılımlarında veya veri ile hedef arasındaki ilişkilerde değişiklik yaşanmasıyla ilişkilidir.

Örneğin geçmişte belirli tutarın üzerindeki alışverişler nadir görülüyorken, enflasyon ve müşteri davranışlarının değişmesi nedeniyle bu tutarlar zamanla yaygın hâle gelebilir.

Model güncellenmezse gereksiz fraud alarmları artabilir.

12.2. Explainability

Bir model işlemi riskli olarak değerlendirdiğinde, bu kararın hangi faktörlerden etkilendiğinin uygun düzeyde açıklanabilmesi önemlidir.

Örneğin:

• İşlem müşteri davranışından önemli ölçüde farklı mı?
• Kısa sürede çok sayıda başarısız deneme mi gerçekleşmiş?
• Üye işyeriyle ilişkili geçmiş risk sinyalleri mi bulunuyor?
• Kullanılan veriler eksik veya güncelliğini kaybetmiş mi?

Açıklanabilirlik, hem model performansının değerlendirilmesini hem de gerekli durumlarda insan incelemesini kolaylaştırır.

12.3. Human-in-the-Loop

Bütün kararların otomatik verilmesi her senaryo için uygun olmayabilir.

Bazı işlemler doğrudan sonuçlandırılabilirken, daha karmaşık veya yüksek etkili durumlar uzman incelemesine yönlendirilebilir.

İnsan incelemesinin nerede gerekli olduğu; kararın etkisine, düzenlemelere, modelin güvenilirliğine ve kurumun kontrol politikalarına göre belirlenmelidir.

12.4. Model Governance

Bankaların yalnızca modeli geliştirmesi yeterli değildir.

Modelin hangi verilerle eğitildiği, hangi sürümünün üretimde olduğu, nasıl doğrulandığı ve performansının nasıl izlendiği de önem taşır.

İyi bir model yönetilişi yaklaşımında şu sorular yanıtlanmalıdır:

• Modelin sahibi kim?
• Hangi veri setleri kullanıldı?
• Model bağımsız olarak doğrulandı mı?
• Performans düşüşü nasıl tespit edilecek?
• Yanlış kararlar nasıl incelenecek?
• Yeni sürüme geçiş ve geri dönüş nasıl yönetilecek?
• Kararların sonradan denetlenebilmesi mümkün mü?

Özellikle finansal kararları etkileyen sistemlerde modelin izlenebilirliği, en az tahmin başarısı kadar önem kazanabilir.

13. Gerçek Bir Risk Engine Yazılımı Nasıl Tasarlanabilir?

Şimdi konuyu yazılım mimarisi açısından ele alalım.

Bir ödeme kuruluşu veya bankanın kart işlemlerini değerlendirmek için Risk Engine geliştirmek istediğini düşünelim.

Bu sistemde bütün kontrollerin tek bir servis içerisinde toplanması zorunlu değildir.

Farklı sorumluluklara sahip bileşenlerden oluşan bir mimari kurulabilir.

13.1. Transaction Gateway

İşlemlerin sisteme giriş yaptığı bileşendir.

Gelen isteğin temel doğrulamaları, işlem referansı ve yönlendirme bilgileri bu katmanda ele alınabilir.

Örneğin gelen işlem şu alanlarla temsil edilebilir:

Bu alanlar öğretici bir örnek veri yapısıdır.

Gerçek sistemlerde kart bilgilerinin kapsamı, işlenmesi ve korunması ilgili standartlara uygun tasarlanmalıdır.

13.2. Feature Collection

Risk değerlendirmesinde kullanılacak verilerin toplandığı katmandır.

Örneğin:

• Son 10 dakikadaki işlem sayısı
• Önceki işlem tutarlarının dağılımı
• Üye işyeri risk göstergeleri
• Cihaz geçmişi
• Önceki güvenlik doğrulama sonuçları

Bu verilerin güncel, tutarlı ve doğru olması gerekir.

Yalnızca modelin güçlü olması yeterli değildir. Yanlış veya gecikmiş veriler doğru karar verilmesini engelleyebilir.

13.3. Rule Engine

Rule Engine, önceden tanımlanmış iş kurallarını değerlendirir.

Örneğin bir işlemde belirli sayıda başarısız deneme tespit edilirse ek kontrol uygulanması yönünde bir kural bulunabilir.

Kurallar farklı seviyelerde çalışabilir:

• İşlem seviyesinde
• Kart seviyesinde
• Müşteri seviyesinde
• Üye işyeri seviyesinde
• Cihaz seviyesinde

Kuralların versiyonlanması ve yapılan değişikliklerin denetlenebilmesi önemlidir.

13.4. Machine Learning Model

Machine Learning bileşeni, geçmiş verilerden öğrenilen örüntülere göre işlemler hakkında tahmin üretebilir.

Burada önemli nokta, modelin ürettiği skorun her zaman doğrudan nihai karar olmamasıdır.

Model skoru, kural sonuçları ve diğer kontroller karar mekanizması tarafından birlikte değerlendirilebilir.

13.5. Decision Engine

Decision Engine, risk değerlendirmelerinin çıktısını işlem politikalarına göre yorumlar.

Örnek kararlar:

• İşlemi normal akışa yönlendirmek
• Ek doğrulama istemek
• İşlemi reddetmek
• İncelemeye almak

Bu kararlar, sistemin rolüne ve işlemin hangi aşamada olduğuna göre değişebilir.

Örneğin acquirer tarafındaki bir engelleme kararıyla issuer tarafından verilen provizyon reddi teknik ve operasyonel açıdan aynı işlem değildir.

13.6. Audit ve Case Management

Risk motorunun verdiği kararlar sonradan incelenebilir olmalıdır.

Örneğin bir müşteri işleminin neden reddedildiğini sorguladığında, yetkili personelin uygun kayıtlar üzerinden değerlendirme yapabilmesi gerekir.

Bu nedenle sistemde ilgili işlem için şu bilgiler tutulabilir:

• İşlem referansı
• Karar zamanı
• Uygulanan kural sürümleri
• Model sürümü
• Uygun ölçüde risk değerlendirme sonucu
• Nihai kararın kaynağı
• Varsa manuel inceleme geçmişi

Kayıtların kapsamı belirlenirken veri minimizasyonu, kişisel verilerin korunması, erişim yetkileri ve saklama yükümlülükleri dikkate alınmalıdır.

13.7. Fraud servisi yanıt vermezse ne olur?

Bu, production ortamında önceden cevaplanması gereken en önemli sorulardan biridir.

Risk motoru erişilemez olduğunda bütün işlemlerin koşulsuz onaylanması da her işlemin koşulsuz reddedilmesi de ciddi sonuçlar doğurabilir.

Kuruluşun, işlem türüne ve risk seviyesine göre önceden belirlenmiş bir hata yönetimi politikası bulunmalıdır.

Örneğin bazı işlemler güvenli biçimde reddedilebilir, bazıları ek kontrol mekanizmalarına yönlendirilebilir, bazıları ise belirli koşullar altında alternatif sistemlerle değerlendirilebilir.

Burada amaç yalnızca servis sürekliliği sağlamak değildir.

Bir sistem arızası sırasında hangi riskin kabul edildiği ve hangi riskin engellendiği önceden tanımlanmalıdır.

14. Risk Engine İçin Hangi Metrikler İzlenmeli?

Bir risk sistemini geliştirirken yalnızca API response time değerine bakmak yeterli değildir.

Sistemin iş sonuçlarının da ölçülmesi gerekir.

Bu metriklerin bir kısmı finansal performansı, bir kısmı güvenlik ve model başarısını, bir kısmı da teknik hizmet kalitesini gösterir.

Örneğin fraud tespit oranının yükselmesi olumlu görünebilir. Ancak aynı anda çok sayıda meşru işlem engelleniyorsa toplam etki beklenen kadar iyi olmayabilir.

Aynı şekilde API gecikmesinin düşük olması olumlu bir teknik göstergedir, fakat yanlış finansal sonuç üreten hızlı bir sistem başarılı kabul edilemez.

15. Third-Party Risk: Dışarıdan Alınan Fraud Servisi Yeterli midir?

Günümüzde bankalar bütün teknik bileşenleri kendi bünyelerinde geliştirmek zorunda değildir.

Fraud analizi, kimlik doğrulama, bulut altyapısı, veri analitiği ve diğer alanlarda dış hizmet sağlayıcıları kullanılabilir.

Ancak bir çözümün dışarıdan alınması, ilgili riskin tamamen hizmet sağlayıcıya devredildiği anlamına gelmez.

Örneğin bir banka iki farklı fraud servisiyle entegre çalışıyor olsun.

Bu durumda hâlâ şu sorulara cevap verilmelidir:

1. Servislerden biri erişilemez olursa ne olacak?
2. İki sistem birbirinden farklı sonuç üretirse karar nasıl alınacak?
3. Hangi müşteri verileri dış sistemlere aktarılıyor?
4. Hizmet sağlayıcıların güvenlik ve erişim kontrolleri yeterli mi?
5. Üretilen risk kararları denetlenebiliyor mu?
6. Servis performansı zaman içerisinde nasıl ölçülüyor?
7. Dış hizmet sağlayıcıyla çalışma sona ererse süreç nasıl sürdürülecek?

Birden fazla servis kullanmak bazı riskleri azaltabilir; ancak farklı servislerin aynı veriye, altyapıya veya modele bağımlı olması yeni yoğunlaşma riskleri oluşturabilir.

Basel Bankacılık Denetim Komitesinin Aralık 2025'te yayımladığı üçüncü taraf risk yönetimi ilkeleri, finansal kuruluşların dış hizmet sağlayıcılarına artan bağımlılığını özellikle ele almaktadır.

Dolayısıyla dış kaynaklı bir fraud sistemi kullanılsa bile kuruluşun kendi risk politikaları, gözetim mekanizmaları ve iş sürekliliği kontrolleri önemini korur.

16. Türkiye'de Risk Yönetimini Etkileyen Düzenlemeler

Bankacılık ve ödeme sistemlerinde teknik çözümler geliştirilirken düzenleyici çerçeveyi bilmek gerekir.

Türkiye'de özellikle şu kurum ve standartlar önemlidir.

BDDK

Bankacılık Düzenleme ve Denetleme Kurumu, bankacılık sektörüne yönelik düzenleme ve denetim faaliyetlerini yürütür.

Bankaların iç sistemleri, bilgi sistemleri, risk yönetimi ve sermaye yeterliliği gibi alanlar BDDK düzenlemeleriyle ilişkilidir.

Yazılım ekipleri açısından özellikle bilgi sistemleri, elektronik bankacılık ve denetim gereklilikleri önem taşır.

TCMB

Türkiye Cumhuriyet Merkez Bankası, ödeme sistemleri ile ödeme ve elektronik para kuruluşlarının faaliyetlerine ilişkin düzenleme ve gözetim alanlarında önemli sorumluluklara sahiptir.

6493 sayılı Kanun ve ilgili ikincil düzenlemeler, ödeme hizmetleri alanının temel hukuki çerçevesini oluşturur.

MASAK

Mali Suçları Araştırma Kurulu, suç gelirlerinin aklanması ve terörizmin finansmanıyla mücadele alanındaki yükümlülükler bakımından önemlidir.

Müşterinin tanınması, şüpheli işlem bildirimleri ve risk temelli kontrol süreçleri bu çerçevede değerlendirilir.

Basel Standartları

Basel Bankacılık Denetim Komitesi tarafından geliştirilen uluslararası standartlar, bankacılıkta sermaye, likidite, risk yönetimi ve operasyonel dayanıklılık açısından önemli referanslar sunar.

PCI DSS

PCI DSS, ödeme kartı verilerinin korunmasına yönelik sektörel güvenlik standardıdır.

Bir düzenleyici kurum değildir ve tüm bankacılık risklerinin yerine geçen bir kontrol çerçevesi olarak değerlendirilmemelidir.

NIST AI Risk Management Framework

Yapay zekâ sistemlerinin risklerinin yönetilmesi için geliştirilen gönüllü bir çerçevedir.

Finansal kararları etkileyen yapay zekâ uygulamalarında güvenilirlik, ölçüm, izleme ve yönetilişi açısından faydalı bir başvuru kaynağıdır.

Bu çerçevelerin hangilerinin doğrudan bağlayıcı olduğu, kurumun faaliyet türüne, tabi olduğu mevzuata ve ilgili uygulamanın kapsamına göre değerlendirilmelidir.

17. Yazılım Geliştiriciler İçin Risk Yönetiminden Çıkarılması Gereken Dersler

Bankacılık yazılımları geliştirirken klasik uygulama geliştirme yaklaşımının ötesinde düşünmek gerekir.

Örneğin bir e-ticaret uygulamasında sipariş listesinin birkaç saniye geç yüklenmesi çoğunlukla performans problemidir.

Ancak finansal bir sistemde aynı transferin iki kez gerçekleşmesi veya başarısız bir işlemin başarılı olarak kaydedilmesi doğrudan finansal sonuca neden olabilir.

Bu nedenle finansal sistemlerde yazılım geliştirirken bazı soruları tasarım aşamasında sormayı önemli buluyorum.

İşlemin gerçekten başarılı olduğunu nereden biliyoruz?

HTTP 200 yanıtı almak tek başına yeterli midir? Harici sistemin sonucu ile yerel veritabanı durumu uyuşuyor mu?

Aynı işlem tekrar gönderilirse ne olur?

İşlem referansları ve idempotency mekanizmaları doğru tasarlandı mı?

Kayıtlar birbiriyle tutarlı mı?

Gün sonu mutabakatında eksik veya fazla işlem varsa nasıl tespit edilecek?

Sistem arızalandığında güvenli davranıyor mu?

Fraud servisi, veritabanı veya mesajlaşma altyapısı erişilemez olduğunda ne olacağı belli mi?

Verilere kim erişebiliyor?

Finansal kayıtlar, müşteri bilgileri ve kritik konfigürasyonlar uygun yetki kontrolleriyle korunuyor mu?

Kararları sonradan açıklayabiliyor muyuz?

Bir işlem reddedildiğinde, bir risk kuralı değiştirildiğinde veya model sürümü güncellendiğinde gerekli denetim izleri bulunuyor mu?

Sistem yalnızca teknik açıdan mı izleniyor?

CPU, memory ve API latency dışında finansal tutarsızlıklar, fraud kayıpları ve hatalı kararlar da takip ediliyor mu?

Bu soruların cevapları, yazılım mimarisini doğrudan etkiler.

18. Bankacılıkta Risk Yönetiminin Geleceği: Veri, Yapay Zekâ ve Dayanıklılık

Bankacılık sistemlerinde işlem hacimleri büyüdükçe, risk değerlendirmesinde kullanılan veri miktarı ve sistemler arasındaki bağımlılıklar da artıyor.

Geleneksel kural tabanlı kontroller önemini korurken, makine öğrenmesi ve veri analitiği daha karmaşık örüntüleri değerlendirmek için kullanılabiliyor.

Ancak burada önemli bir problem bulunuyor.

Daha fazla veri ve daha karmaşık model, otomatik olarak daha iyi risk yönetimi anlamına gelmez.

Yanlış veriyle eğitilmiş bir model sistematik olarak hatalı kararlar üretebilir.

Güçlü bir risk motoru, bağlantılı olduğu ödeme sistemi yanlış tasarlanmışsa finansal tutarsızlıkları engelleyemeyebilir.

Yüksek erişilebilirliğe sahip bir servis de kritik erişim yetkileri hatalı yönetiliyorsa güvenli sayılmaz.

Bu nedenle geleceğin bankacılık risk yönetiminde üç alanın birlikte gelişmesi gerektiğini düşünüyorum:

Veri kalitesi ve yönetilişi: Risk kararları için güvenilir, güncel ve izlenebilir veriler.

Akıllı karar sistemleri: Kural motorları, istatistiksel modeller ve gerektiğinde insan incelemesini bir araya getiren mekanizmalar.

Operasyonel dayanıklılık: Saldırı, hata veya dış hizmet kesintisi sırasında kritik finansal işlemleri kontrollü biçimde sürdürebilen altyapılar.

Basel Komitesinin BCBS 239 ilkeleri de bankaların risk verilerini doğru, eksiksiz ve zamanında bir araya getirebilmesinin önemini vurgular.

Bu konunun yalnızca veri mühendisliği değil, aynı zamanda risk yönetilişi konusu olduğunu söylemek mümkündür.

Nasıl Bir Sonuç Çıkarılabilir ?

Bankacılıkta risk yönetimi, yalnızca dolandırıcılık işlemlerini tespit etmek veya kredi başvurularını değerlendirmekten çok daha geniş bir alanı kapsar.

Kredi riski, piyasa riski, likidite riski, operasyonel risk, fraud, AML, siber güvenlik ve model riski birbirleriyle ilişkili biçimde yönetilmelidir.

Ödeme sistemleri açısından bakıldığında ise bu risklerin çoğu aynı işlem akışında karşımıza çıkabilir.

Bir kart işlemi güvenli biçimde doğrulanmış ancak yeterli limit olmadığı için reddedilmiş olabilir. Başka bir işlem teknik olarak başarılı sonuçlanmış ancak gün sonu mutabakatında tutarsızlık oluşturabilir. Bir diğer işlem ise onaylandıktan haftalar sonra chargeback sürecine konu olabilir.

Yazılım mühendisliği açısından bu örnekler önemli bir gerçeği gösteriyor:

Finansal sistemlerde doğru kod yazmak, yalnızca işlevsel bir uygulama geliştirmek değil; oluşabilecek riskleri önceden düşünerek güvenli, tutarlı, denetlenebilir ve dayanıklı sistemler tasarlamaktır.

Bankacılık ve ödeme sistemleri teknolojileriyle ilgilenen yazılımcılar için risk yönetimi, yalnızca finans ekiplerinin sorumluluğunda olan uzak bir konu değildir.

Geliştirilen API'lerden veri modellerine, işlem kayıtlarından yapay zekâ algoritmalarına kadar birçok teknik karar risk yönetiminin parçasıdır.

Bu nedenle bankacılık alanında çalışan bir yazılımcının yalnızca işlemlerin nasıl gerçekleştiğini değil, hangi durumlarda yanlış gidebileceğini ve bu durumların nasıl yönetileceğini de anlaması gerektiğini düşünüyorum.

Bu içerik teknik bilgilendirme amacıyla hazırlanmıştır. Hukuki, finansal veya düzenleyici uyum danışmanlığı niteliğinde değildir. Mevzuat ve teknik standartlar zaman içerisinde değişebileceğinden uygulama öncesinde güncel resmî metinler kontrol edilmelidir.