Fin ve Tech: Dijital Onboarding ve KYC — Bir Müşteriyi Saniyeler İçinde Tanımak

Fin ve Tech serisinin bu bölümünde, her fintech ve bankacılık ürününün ilk ve en kritik adımına odaklanıyoruz: müşteri onboarding ve KYC (Know Your Customer) süreçleri.

Bir kullanıcı uygulamayı indirdiğinde, hesap açma ekranı ile gerçek ürün deneyimi arasında geçen o birkaç dakika, aslında bankacılık dünyasının en yoğun mühendislik ve regülasyon yükünü taşıyan alanlardan biridir. Kimlik doğrulama, risk skorlama, sahtecilik kontrolü ve yasal uyumluluk hepsi bu kısa pencerede gerçekleşir.

Bu yazıda, gerçek bir onboarding sistemini nasıl tasarlayacağımızı ve bunu yaparken 4 kritik katmanı nasıl uygulayacağımızı inceleyeceğiz.

Onboarding ve KYC Nedir?

Müşteri onboarding, bir kullanıcının bir finansal ürünle ilk tanıştığı, kayıt olduğu ve kullanıma hazır hale geldiği uçtan uca süreçtir.

KYC (Know Your Customer) ise bu sürecin yasal ve güvenlik temelidir: bir finansal kurumun müşterisinin kimliğini doğrulama ve risk profilini değerlendirme zorunluluğudur.

Klasik alternatifler neden yetersiz kalır?

• Tek tip, sabit akış: Her müşteriye aynı derinlikte kontrol uygulamak, düşük riskli kullanıcıyı kaybettirir, yüksek riskliyi ise gözden kaçırır.
• Manuel, şube-bağımlı süreç: Ölçeklenmez, saatler/günler sürer, dijital ürün deneyimini baştan bozar.

Mimari Genel Bakış

Sistemimiz, bağımsız mikroservislerden oluşuyor. Her servisin kendi sorumluluğu var ve aralarındaki akış bir Onboarding Orchestrator üzerinden state machine ile yönetiliyor:

Onboarding Flow: Started → IdentityVerificationPending → RiskScoringPending → ManualReviewRequired / Approved / Rejected

Domain Contracts: Servisler Arası Sözleşme

Onboarding orkestrasyonunun temeli iyi tanımlanmış olay ve modellerdir. Tüm sözleşmeleri ayrı bir Contracts katmanında tutmak, servisler arası ortak “dil” görevi görür:

// Onboarding.Contracts/Events/OnboardingEvents.cs

public interface IOnboardingEvent
{
    Guid ApplicationId { get; }
    Guid CorrelationId { get; }   // Orchestrator için
    DateTime OccurredAt { get; }
}

public record IdentityVerificationCompletedEvent : IOnboardingEvent
{
    public Guid ApplicationId { get; init; }
    public Guid CorrelationId { get; init; }
    public bool IsVerified { get; init; }
    public bool LivenessPassed { get; init; }
    public string? NationalId { get; init; }
    public DateTime OccurredAt { get; init; } = DateTime.UtcNow;
}

İki önemli tasarım kararı: record kullanıyoruz — immutable ve value equality sağlar. CorrelationId, aynı başvuruya ait tüm adımları birbirine bağlayan kilit alan.

Katman 1: Identity Verification

Problem: Uzaktan Kimlik Teyidi

Geleneksel KYC, şubeye gidip kimlik fotokopisi vermeyi gerektirir. Dijital bir üründe bu adım saniyeler içinde, uzaktan ve sahteciliğe kapalı şekilde tamamlanmalıdır.

// ❌ YANLIŞ: Sadece belge fotoğrafına güvenmek
var idPhoto = await _upload.GetAsync(applicationId);
return idPhoto != null; // Sahte/fotokopi belge de "doğrulanmış" sayılır

Çözüm: Çok Katmanlı Doğrulama

Kimlik belgesi, selfie ve resmi kayıt sorgusu birlikte değerlendirilir:

// IdentityVerificationService.cs
public async Task<IdentityResult> VerifyAsync(IdentityVerificationRequest request)
{
    var ocrResult = await _ocr.ExtractAsync(request.DocumentImage);
    var livenessPassed = await _liveness.CheckAsync(request.SelfieVideo);
    var faceMatchScore = await _faceMatch.CompareAsync(request.SelfieImage, ocrResult.PhotoFace);
    var registryMatch = await _mernis.VerifyAsync(ocrResult.NationalId, ocrResult.FullName);

    return new IdentityResult
    {
        IsVerified = livenessPassed && faceMatchScore > 0.92 && registryMatch,
        NationalId = ocrResult.NationalId
    };
}

💡 Neden Liveness + Face Match Birlikte?

Sadece face match, statik bir fotoğrafla da geçilebilir. Liveness detection, karşıdaki kişinin o anda canlı olduğunu kanıtlar — ikisi birlikte kullanıldığında fotoğraf/video tabanlı sahtecilik önemli ölçüde engellenir.

Katman 2: Risk Scoring (Hibrit Yaklaşım)

Problem: Tek Yöntemin Yetersizliği

Sadece sabit kurallar, regülatöre açıklanabilir ama esnek değildir; sadece bir ML modeli, esnek ama denetlenemezdir.

// ❌ YANLIŞ: Modele tüm kararı bırakmak
var score = await _riskModel.PredictAsync(input);
return score < 0.5 ? RiskLevel.Low : RiskLevel.High;
// Sanctions listesindeki biri bile model hatasıyla "low risk" çıkabilir

Çözüm: Kural Katmanı Önce, Model Katmanı Sonra

Kesin ihlaller kural katmanında elenir; kalan başvurular için model bir olasılık skoru üretir:

// RiskScoringService.cs
public async Task<RiskLevel> EvaluateAsync(CustomerApplication application)
{
    // 1. Kural tabanlı katman: kesin ihlaller burada elenir
    if (await _sanctionsList.IsListedAsync(application.FullName, application.NationalId))
        return RiskLevel.High;

    if (application.IsPoliticallyExposed)
        return RiskLevel.High;

    // 2. ML tabanlı katman: kalan başvurular için olasılıksal skor
    var modelScore = await _riskModel.PredictAsync(new RiskModelInput
    {
        Age = application.Age,
        Country = application.Country,
        DeviceFingerprint = application.DeviceFingerprint,
        TransactionIntent = application.ExpectedMonthlyVolume
    });

    // 3. Skor -> seviye dönüşümü (eşikler compliance tarafından yönetilir)
    return modelScore switch
    {
        < 0.3 => RiskLevel.Low,
        < 0.7 => RiskLevel.Medium,
        _ => RiskLevel.High
    };
}

⚠️ Önemli Not

Eşik değerleri (0.3, 0.7) kod içine sabit yazılmamalı; compliance ekibinin kod deploy etmeden güncelleyebileceği bir konfigürasyon katmanında tutulmalıdır.

Katman 3: CDD / EDD — Risk Seviyesine Göre Katmanlı İnceleme

Problem: Herkese Aynı Derinlikte Kontrol

Düşük riskli bir müşteriyi yüksek riskli biri gibi sorgulamak kullanıcı kaybına, yüksek riskli bir müşteriyi düşük riskli biri gibi geçirmek ise regülasyon ve fraud riskine yol açar.

Çözüm: Risk Seviyesine Göre Farklı Yollar

EDD kapsamında ek olarak şunlar istenir:

• Gelir kaynağının belgelenmesi
• Daha sık işlem izleme
• Üst yönetim onayı

Bu akış, bir state machine üzerinden açık şekilde modellenir:

// OnboardingStateMachine.cs
public OnboardingState GetNextState(OnboardingState current, RiskLevel risk, bool identityVerified)
{
    return current switch
    {
        OnboardingState.Started when identityVerified
            => OnboardingState.RiskScoringPending,

        OnboardingState.Started when !identityVerified
            => OnboardingState.Rejected,

        OnboardingState.RiskScoringPending when risk == RiskLevel.Low
            => OnboardingState.Approved,

        OnboardingState.RiskScoringPending when risk == RiskLevel.Medium
            => OnboardingState.ManualReviewRequired,

        OnboardingState.RiskScoringPending when risk == RiskLevel.High
            => OnboardingState.Rejected,

        _ => current
    };
}

Katman 4: Fraud Detection — Onboarding’e Özel Savunma

Problem: Hesap Açılmadan Önceki Kör Nokta

Onboarding, fraud’cuların en sevdiği giriş noktasıdır. Çünkü hesap henüz açılmamışken kontrol mekanizmaları daha esnektir.

Çözüm: Katmanlı Sinyal Toplama

// FraudSignalAggregator.cs
public async Task<FraudSignal> CollectAsync(CustomerApplication application)
{
    var deviceRisk = await _deviceFingerprint.EvaluateAsync(application.DeviceId);
    var velocityRisk = await _velocityCheck.CountRecentApplicationsAsync(application.DeviceId, TimeSpan.FromHours(1));
    var syntheticIdentityRisk = await _syntheticIdentityDetector.ScoreAsync(application);
    var documentForgeryRisk = await _documentForensics.AnalyzeAsync(application.DocumentImage);

    return new FraudSignal
    {
        DeviceRiskScore = deviceRisk,
        VelocityFlag = velocityRisk > 3,
        SyntheticIdentityScore = syntheticIdentityRisk,
        DocumentForgeryDetected = documentForgeryRisk.IsForged
    };
}

Bu sinyaller, risk skorlama katmanına ek girdi olarak beslenir — tek başına hiçbir sinyal nihai kararı vermez.

Use Case’ler: Farklı Risk Profillerinde Onboarding

Düşük riskli bireysel müşteri: Telefon + OTP, kimlik + selfie ile liveness/face match, MERNİS sorgusu, otomatik low-risk skoru → 15-30 saniyede onboard.

Yüksek riskli kurumsal müşteri: UBO (Ultimate Beneficial Owner) çıkarımı, her ortağın bireysel KYC’si, sanctions/PEP taraması, gelir kaynağı belgeleri, compliance onayı → 1-3 iş gününde EDD ile tamamlanır.

Kripto borsası: Tek seferlik KYC yerine sürekli transaction monitoring; ani hacim artışları yeniden risk skorlamasını tetikler; profil periyodik olarak yeniden değerlendirilir.

Geleneksel banka (şube + dijital): Şube ve mobil kanaldan gelen başvurular aynı merkezi risk skorlama servisine bağlanır; kanal farkı, kural setinde farklılığa dönüşmez.

Katman Özeti

Sık Yapılan Yanlışlar

❌ “Liveness check yaptık, fraud riski bitti” ✅ Fraud, çok katmanlı bir savunma gerektirir; tek bir kontrol asla yeterli değildir

❌ “KYC bir kere yapılır, biter” ✅ KYC, müşteri ilişkisi boyunca sürekli güncellenmesi gereken bir süreçtir (ongoing due diligence)

❌ “Risk skorlamayı senkron, tek bir çağrıda yapalım” ✅ Sanctions, PEP, kredi bürosu gibi farklı kaynaklara yapılan çağrılar paralel ve asenkron tasarlanmalı

❌ “Model skoru tek başına karar versin, kurallara gerek yok” ✅ Kural katmanı olmadan model kararları regülatöre açıklanamaz hale gelir

Sonuç: Onboarding, Güvenle Hızın Buluştuğu Yer

Dijital onboarding ve KYC ilk bakışta sadece bir kayıt formu gibi görünebilir. Ancak gerçekte:

• Bir finansal kurumun ilk savunma hattı
• Müşteri deneyiminin en kritik anı
• Regülasyon, güvenlik ve ürün tasarımının kesişim noktası

anlamına gelir.

Hızlı bir onboarding, güvenli bir onboarding ile çelişmek zorunda değildir. Identity Verification, Risk Scoring, CDD/EDD ve Fraud Detection — bu dört katman, production’da bu dengenin temelidir. Her zaman olduğu gibi kaynaklara mutlaka göz atılmasını tavsiye ediyorum. ⬇️

Kaynaklar

• FATF (Financial Action Task Force) — International Standards on AML/CFT
• MASAK — Mali Suçları Araştırma Kurulu Mevzuatı
• PCI Security Standards Council
• World Bank — eKYC Guidelines for Financial Inclusion
• OWASP — Identity Verification Best Practices