Travel Rule Entegrasyonu Nasıl Yapılır: 8 Adımlı Mimari

Travel Rule entegrasyonu mevcut müşteri verisi + transfer akışı + counterparty ekosistemine bağlanan operasyonel bir sistem. "Endpoint çağır, mesaj gönder" basitliğinde değil — protokol seçiminden sunrise fallback politikasına, monitoring'den regülatör raporlamasına kadar uçtan uca tasarım gerektirir. Bu rehber sıfırdan başlayan bir VASP için 8 adımlı pratik blueprint sunuyor.

FATF Travel Rule rehberimiz konunun büyük resmini ve regülasyon arka planını veriyor; bu yazı uygulama tarafına odaklı.

1. Adım: Protokol seçimi — Hangisi(leri), neden?

Tek bir protokole bağlanmak yetersiz. Modern bir Travel Rule altyapısı çoklu protokol orkestrasyon yapar. Seçim kriterleri:

• Counterparty pazarı: AB merkezli iseniz TRP yaygın; ABD odaklı iseniz TRISA daha sık; Asya borsalarıyla iş tutuyorsanız Sygna Bridge sık.
• Operasyonel olgunluk: TRP REST-tabanlı, kolay debug. TRISA gRPC + mTLS, daha sıkı güvenlik ama operasyon kompleksitesi yüksek. Sygna ticari ürün katmanlı.
• Ekosistem güveni: Bir directory hizmeti (Notabene, Sumsub, Veriscope vb.) seçtiğinizde, o directory'nin desteklediği protokoller default seçiminizi şekillendirir.

Pratik öneri: TRP + Sygna + TRISA üçünü destekleyin; counterparty capability check sonucuna göre dinamik rota. Tek protokol = sunrise gap'i kendi elinizle büyütmek.

2. Adım: Counterparty VASP discovery

Mesajı kime göndereceğinizi bilmeden mesaj üretilmez. Discovery için iki yaklaşım:

Directory hizmeti entegrasyonu

Üçüncü taraf directory:

• Notabene: En büyük VASP directory'si, ticari, kapsamlı capability data.
• Sumsub Travel Rule: KYC + Travel Rule entegre.
• Veriscope: Bağımsız directory.
• TRISA Global Directory Service (GDS): Açık kaynak, TRISA'ya özel.

Kendi directory'inizi tutma

Counterparty VASP listesini kendi tarafınızda güncel tutmak (regülatör listelerinden + bilateral keşiften). Operasyonel yük yüksek; ama özellikle Türk borsalar için ulusal counterparty'leri MASAK lisans listesinden tutmak pragmatik.

Hybrid yaklaşım: 3rd-party directory primary, kendi liste fallback ve enrichment için.

3. Adım: IVMS 101 mapping

IVMS 101 standardı rehberimizde anlattığımız üzere, mevcut KYC verisini IVMS 101 alanlarına eşlemek beklenenden zor — özellikle çok-ülkeli müşteri tabanında.

Mapping checklist:

• İsim: primaryIdentifier ve secondaryIdentifier doğru ayrılıyor mu? (Çoklu ad senaryolarına dikkat.)
• Adres: AddressType doğru kodlanıyor mu (HOME vs BIZZ)?
• National ID: T.C. kimlik no → NIDN; ehliyet → DRLC; pasaport → PASS. Country code TR.
• Doğum yeri: Şehir adı + country code ayrı alanlarda.
• Cüzdan adresi: Account number alanına geçerli formatta (checksum'lı).
• Müşteri ID: customerIdentification olarak internal ID.

Tavsiye: Mapping kodunu izole bir modüle taşıyın. Test coverage yüksek tutun. Schema validator entegre edin (IVMS 101 JSON schema açık kaynak).

4. Adım: Transfer-anı orkestrasyon

Transfer talebi geldiğinde sistemin akışı:

1. Eşik kontrolü: Transfer tutarı Travel Rule eşiğinin üstünde mi? (TR/UK/AB için farklı.)
2. Counterparty discovery: Alıcı cüzdan adresinden hangi VASP'a ait olduğunu directory'den sorgula.
3. Capability check: Counterparty hangi protokolleri destekliyor? Hangi IVMS 101 versiyonu?
4. Mesaj oluşturma: IVMS 101 mapping çağrılır, JSON payload üretilir, schema validate.
5. İletim: Uygun protokol üzerinden mesaj gönderilir.
6. Yanıt bekleme: Sync mi async mi protokole bağlı; TRP async ack pattern kullanır.
7. Karar: Yanıt geldiyse transferi onaylama veya bekletmeye al.

Bu akış senkron blocking yapılırsa transfer latency'si artar — pratikte async event-driven mimari tercih edilir (örn. transfer queue + Travel Rule mesaj worker + sonuç callback).

5. Adım: Sunrise fallback politikası

Sunrise problem rehberimizin detaylandırdığı politika kararları:

• Red politikası: Counterparty cevaplayamıyorsa transfer ret. Aggressive.
• Bekletme: IVMS 101 mesajını üret, sakla, capability gelene kadar bekle.
• Risk-bazlı: Tutar + müşteri risk + counterparty risk üçlüsüne göre dinamik politika.

Politika engine YAML/UI ile yapılandırılabilir olmalı — kod deployment compliance ekibinin işlemesi gereken bir politika değişikliği için kabul edilebilir değil. Örnek policy DSL:

- if: counterparty.capability == none && transfer.amount_usd < 1000
  then: retain_and_proceed
- if: counterparty.capability == none && transfer.amount_usd >= 1000
  then: hold_for_manual_review
- if: customer.risk_score == high
  then: hold_for_manual_review

6. Adım: Hata yönetimi ve retry mantığı

Travel Rule mesajları başarısız olabilir; yaygın hatalar:

• Counterparty timeout: Mesaj iletildi ama yanıt gelmedi (network, downtime, vb.).
• Schema validation hata: Counterparty'nin IVMS 101 implementasyonu mesajı reddetti.
• Protocol negotiation fail: Capability check yanıltıcı oldu, gerçek protokol seviyesinde uyumsuzluk.
• Authentication hatası: mTLS sertifika sorunu (TRISA için yaygın).

Her hata tipi için ayrı retry policy: timeout için exponential backoff (örn. 1m, 5m, 30m, 2h, 6h), schema hatası için manuel inceleme (otomatik retry yararsız), auth hatası için sertifika rotasyonu süreci.

Dead-letter queue zorunlu — hiçbir mesaj sessizce kaybolmamalı. Compliance ekibi DLQ'yu görmeli.

7. Adım: Monitoring ve KPI dashboard

Hangi metrikleri izleyeceksiniz:

• Mesaj başarı oranı (gönderme + yanıt alma): hedef ≥95%.
• Sunrise gap oranı: counterparty'lerin yüzde kaçı capability'siz.
• Ortalama mesaj round-trip latency: <500ms beklenir (TRP/TRISA), Sygna biraz daha yüksek olabilir.
• Schema validation hata oranı: <%2 hedef; aşması mapping bug'larına işaret.
• Bekletilmiş transfer hacmi: sunrise fallback metriği.
• Manual review queue derinliği: compliance ekibi yükü göstergesi.

Dashboard'lar Grafana/Datadog/Prometheus ile entegre — uyarılar düştüğünde compliance ve mühendislik birlikte görmeli.

8. Adım: Regülatör raporlama

Regülatörün hangi formatta ne istediği jurisdiksiyona göre değişir:

• MASAK (Türkiye): KVHS yürürlüğe girdiğinde Travel Rule raporlama formatı netleşecek. Şimdilik genel AML raporlama içine entegre.
• FCA (UK): REP-CRIM raporları (yıllık cryptoasset business raporu) Travel Rule etkinliğini sorar. JMLSG rehberi format detayı veriyor.
• AB: EBA üzerinden ulusal yetkililer (BaFin, AFM, MFSA) — TFR raporlama standardı 2025'te netleşmesi bekleniyor.

Raporlama altyapısı:

• Tüm mesajlar zaman damgalı, immutable log.
• Periyodik export (PDF + CSV) — denetim talebine hızlı yanıt için.
• Olay bazlı raporlama (örn. Travel Rule mesajı reddi sürekli yüksek bir counterparty için).
• Veri saklama süresi: minimum 5 yıl (jurisdiksiyona göre 10 yıla kadar).

Adımları zaman çizelgesinde toplama

Tipik bir orta-büyüklük borsa için entegrasyon süreleri:

Parallelleştirme ile 3-5 aya çekilebilir; mevcut Legichain tipi altyapı kullanıldığında 4-8 haftaya düşer.

Sıkça Sorulan Sorular

Travel Rule entegrasyonunu in-house mu yapmalıyım, vendor mu kullanmalıyım?

In-house yaklaşım: protokol değişimleri (yeni versiyon, yeni protokol), counterparty directory bakımı, sunrise politika engine'i geliştirme — sürekli bakım yükü. Ekip kapasiteniz yüksek ve bu uzmanlığa stratejik yatırım planınız varsa anlamlı. Çoğu VASP için vendor yaklaşımı (Notabene, Sumsub, Legichain gibi platformlar) hem maliyet hem time-to-market avantajlı. Tipik vendor entegrasyonu 4-8 hafta, in-house build 6-9 ay.

Sandbox ortamında test etmek mümkün mü?

Evet — tüm major protokollerin sandbox/testnet'i var. TRP testnet ortamı, TRISA test directory'si, Sygna sandbox. Pratik öneri: production'a geçmeden önce her counterparty kategorisinden (AB borsa, UK borsa, Asya borsa, ABD borsa) en az birer test partner ile gerçek mesaj akışı test edin. Sandbox'tan production'a çıkarken sertifika rotasyonu, endpoint değişimi, sandbox-özel parametreler gibi gotcha'lar yaygın.

Yeni bir protokol çıkarsa entegrasyon ne kadar?

Modüler tasarım yaparsanız 2-4 hafta. Protocol adapter pattern kullanın — her protokol kendi adapter sınıfında, ortak interface (IVMS 101 mesaj al, gönder, yanıt al). Yeni protokol = yeni adapter; iş mantığı (IVMS mapping, policy engine, monitoring) etkilenmez. Bu ayrımı baştan yapmak, sonradan refactor etmekten 5-10x ucuz.

Birkaç counterparty tek bir transfer için mesaj istiyor (chain hop) ne yaparım?

Multi-hop transferler nadirdir ama olur — özellikle aggregator broker üzerinden geçen transferlerde. Pratik: her hop kendi Travel Rule mesajını üretir. Sizin sorumluluğunuz sadece direkt counterparty'ye karşı. Aggregator'ın downstream counterparty'lerine Travel Rule veri taşıyıp taşımadığı sizin değil onun sorumluluğu, ama high-risk aggregator'larla iş tutuyorsanız due diligence'a yansır.

Transfer engellendiğinde müşteriye ne demeli?

Şeffaf ama hukuki riskten kaçınan dil. "Travel Rule uyumluluğu" tabirini kullanmaktan çekinmeyin — müşteri eğitimi sektör için faydalı. Örnek metin: "Bu transferin alıcı tarafındaki kuruluş yasal veri paylaşım gereksinimlerini henüz desteklemiyor. Transfer beklemede; kuruluş kapasiteyi sağladığında otomatik tamamlanacak. Detaylar için [link]." Müsteriye blame yüklemeyin (counterparty'nin altyapı sorunu, müşterinin değil).

Legichain ile

Yukarıdaki 8 adımı in-house build yaptığınızda 6-9 ay; Legichain Travel Rule modülüyle 4-8 haftada üretime alabilirsiniz. Mevcut dijital KYC entegrasyonunuz üzerinden IVMS 101 mapping otomatik, çoklu protokol (TRP, Sygna, TRISA) destek built-in, counterparty directory (Notabene + kendi directory'imiz) bağlı geliyor. Sunrise fallback policy engine YAML ile yapılandırılabilir, monitoring dashboard hazır, MASAK/FCA/EBA raporlama formatları template olarak mevcut. /travel-rule sayfasında sandbox erişimi var; gerçek mesaj akışını 24 saat içinde test edebilirsiniz.

Sonraki adımlar

• FATF Travel Rule rehberi — regülasyon ve büyük resim.
• IVMS 101 veri standardı — mesaj mapping'inin derin teknik detayı.
• Sunrise problem ve fallback — 5. adımın derin dalışı.
• Kripto borsa çözümleri — entegrasyonun borsa operasyonuna nasıl oturduğu.