IVMS 101 — InterVASP Messaging Standard 101 — Travel Rule mesajının küresel veri standardıdır. Joint Working Group on InterVASP Messaging Standards tarafından 2020'de yayımlanan bu standart, gönderici ve alıcı VASP'lerin hangi veriyi hangi yapıda taşıyacağını netleştirir. Standardın varlık nedeni basit: standart olmadan her VASP çifti kendi format anlaşmasını yapar, interoperability çöker. Bu makale IVMS 101'in tam anatomisini, alan-alan beklentilerini ve örnek bir mesaj payload'u üzerinden teknik detayını ele alıyor.
Standardın amacı ve kapsamı
IVMS 101 sadece veri şemasıdır. Mesajın nasıl taşınacağı (HTTPS, mesajlaşma protokolü, decentralized network), nasıl şifreleneceği, nasıl imzalanacağı standardın kapsamı değil — bunlar TRP, OpenVASP, Sygna, TRISA gibi protokollerin sorumluluğu. IVMS 101 bu protokollerin "ne taşıyacağı" sorusunu standartlaştırır.
FATF Travel Rule rehberimizde gördüğümüz üzere, FATF Tavsiye 16'nın sanal varlık uyarlaması ulusal regülatörlerin VASP'lere mesaj formatı dayatmamasını sağlamak için pratik bir endüstri standardı gerektiriyordu. IVMS 101 bu boşluğu doldurdu.
Mesaj yapısı — Yüksek seviye
Bir IVMS 101 mesajı dört ana objeden oluşur:
- Originator (gönderici): Transferi başlatan kişi/kuruluş bilgileri.
- Beneficiary (alıcı): Transferi alacak kişi/kuruluş bilgileri.
- OriginatingVASP (gönderici VASP): Göndericinin hesap tuttuğu VASP.
- BeneficiaryVASP (alıcı VASP): Alıcının hesap tuttuğu VASP.
Her originator ve beneficiary objesi iki alt yapıyla taşınabilir:
- naturalPerson: Gerçek kişi.
- legalPerson: Tüzel kişi.
Her transfer için bu dördünden biri zorunlu (originator/beneficiary), diğer ikisi (VASP) protokol katmanında genelde otomatik doldurulur.
naturalPerson — Gerçek kişi alan yapısı
Gerçek bir gönderici için aşağıdaki alanlar tanımlanmıştır:
- name (zorunlu):
primaryIdentifier(soyad),secondaryIdentifier(ad),nameIdentifierType(LEGL = legal name, BIRT = birth name vb.). - geographicAddress (önerilen): Sokak, bina, şehir, ülke, postal code. AddressType kontrollü liste: HOME, BIZZ, GEOG.
- nationalIdentification: Ulusal kimlik numarası, tipi (NIDN = National ID, DRLC = Driver License, PASS = Passport, vb.), veren ülke kodu.
- dateAndPlaceOfBirth: Doğum tarihi, doğum yeri (şehir + ülke).
- customerIdentification: VASP'in iç müşteri ID'si.
- countryOfResidence: ISO 3166-1 alpha-2 ülke kodu.
İsim alanı en sıkı kısımdır — primaryIdentifier ve secondaryIdentifier'ın doğru ayrılması gerekir. "Mehmet Ali Yılmaz" gibi çoklu ad durumlarında "Mehmet Ali" tek secondaryIdentifier olarak gönderilir, "Yılmaz" primaryIdentifier'a gider.
legalPerson — Tüzel kişi alan yapısı
Tüzel kişi gönderici için:
- name:
legalPersonName(ticari unvan),legalPersonNameIdentifierType(LEGL, TRAD = trading name, SHRT = short name). - geographicAddress: Yasal merkez adresi.
- customerNumber: Müşteri tanımlayıcı.
- nationalIdentification: LEI (Legal Entity Identifier) en yaygın olanı.
- countryOfRegistration: Ülke kodu.
LEI zorunlu değil ama tavsiye edilir — küresel tüzel kişi tanımlaması için 20 karakterlik standart.
Kontrollü kelime listeleri
IVMS 101'in interoperability'sinin sırrı kontrollü kelime listelerinde. Free-form alanlar yerine standartlaştırılmış kodlar kullanılır:
- nameIdentifierType: LEGL, BIRT, MAID (maiden), ALIA (alias), MISC, vb.
- addressType: HOME, BIZZ, GEOG.
- nationalIdentifierType: NIDN, DRLC, PASS, ARNU, RAID, CCPT, vb. (yaklaşık 15 tip).
- countryCode: ISO 3166-1 alpha-2 (TR, GB, DE, US, vb.).
Bu listeler IVMS 101 spesifikasyonunun ekinde tam tanımlı — implementasyonda mutlaka referans alınmalı.
Örnek mesaj (sade JSON)
Türk borsa A'nın AB borsası B'ye 0.5 BTC transferi:
{
"originator": {
"originatorPersons": [{
"naturalPerson": {
"name": {
"nameIdentifiers": [{
"primaryIdentifier": "Yılmaz",
"secondaryIdentifier": "Mehmet Ali",
"nameIdentifierType": "LEGL"
}]
},
"geographicAddresses": [{
"addressType": "HOME",
"streetName": "Bağdat Caddesi",
"buildingNumber": "121",
"townName": "İstanbul",
"country": "TR"
}],
"nationalIdentification": {
"nationalIdentifier": "12345678901",
"nationalIdentifierType": "NIDN",
"countryOfIssue": "TR"
},
"dateAndPlaceOfBirth": {
"dateOfBirth": "1985-03-17",
"placeOfBirth": "Ankara"
},
"countryOfResidence": "TR"
}
}],
"accountNumbers": ["bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh"]
},
"beneficiary": {
"beneficiaryPersons": [{
"naturalPerson": {
"name": {
"nameIdentifiers": [{
"primaryIdentifier": "Schmidt",
"secondaryIdentifier": "Anna",
"nameIdentifierType": "LEGL"
}]
},
"countryOfResidence": "DE"
}
}],
"accountNumbers": ["bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"]
},
"originatingVASP": {
"originatingVASP": {
"legalPerson": {
"name": {
"nameIdentifiers": [{
"legalPersonName": "Borsa A A.Ş.",
"legalPersonNameIdentifierType": "LEGL"
}]
},
"countryOfRegistration": "TR"
}
}
}
}
Bu sade örnek; gerçek üretimde beneficiaryVASP objesi ve protokol-spesifik wrapper'lar (TRP envelope, Sygna metadata, vb.) eklenir.
Yaygın hatalar — IVMS 101 mapping'inde
KYC veri tabanından IVMS 101'e mapping yaparken sık görülen hatalar:
- İsim ayrıştırma: "Mehmet Ali Yılmaz" gibi çoklu adların yanlış bölünmesi. Standart: tüm orta + ön adlar
secondaryIdentifier, soyadprimaryIdentifier. - Adres tipi: Müşterinin iş adresi mi yoksa ev adresi mi olduğunun yanlış kodlanması (BIZZ vs HOME).
- Doğum yeri: "Türkiye" yazıp şehir verilmemesi. Standart şehir adı bekliyor; ülke ayrı alanda.
- National ID tipi: T.C. kimlik numarasının yanlışlıkla DRLC kodlanması. Doğru: NIDN.
- Cüzdan adresi formatı: Account number alanına cüzdan adresinin yanlış formatlanması (örn. checksum'sız Ethereum adresi).
Bu hatalar karşı VASP'in validation katmanında mesajın reddedilmesine yol açar — sunrise problem'le karıştırılmaması gerekir; mesaj iletilir ama veri kalitesi nedeniyle red gelir.
IVMS 101 ve protokol katmanı ilişkisi
IVMS 101 mesajının taşıyıcısı protokoldür:
- TRP: REST API üzerinden, JSON-IVMS 101 wrap'lenmiş.
- TRISA: gRPC üzerinden, mTLS sertifika imzalı, protobuf serialize edilmiş IVMS 101.
- Sygna Bridge: WebSocket + REST hybrid, kendi metadata sarmalı.
- OpenVASP: Ethereum mesajlaşma katmanı, IVMS 101 mesajı şifrelenmiş payload olarak.
Tüm bu protokoller IVMS 101'i destekler — fark sadece nasıl serialize edilip taşındığında. Travel Rule entegrasyon how-to rehberimiz protokol seçimini ve mapping katmanını detaylandırıyor.
Sıkça Sorulan Sorular
IVMS 101 sürüm güncellemeleri nasıl yönetiliyor?
IVMS 101 versiyonu major.minor formatında (örn. 1.0.0, 1.1.0). Major güncelleme breaking change içerir — şema değişimi. Minor güncellemeler genelde yeni opsiyonel alanlar eklenmesi. Pratik tavsiye: mevcut versiyonu (1.0 hâlâ baskın) destekleyen tüm protokollerle uyumluluk koruyun; yeni sürüme geçişte counterparty desteğini önce doğrulayın. Geriye dönük uyumluluk standardın tasarım hedefi ama edge case'lerde dikkatli olun.
Tüm alanlar zorunlu mu, hangileri opsiyonel?
Zorunlu alanlar jurisdiksiyona göre değişir. FATF baseline: gönderici adı, hesap numarası ve yeterli kimlik bilgisi (national ID veya doğum tarihi/yeri) — alıcı için sadece ad ve hesap numarası. Ama AB TFR daha geniş veri ister (gönderici adresi zorunlu), UK MLR farklı. IVMS 101 spesifikasyonu alanları "required" (şema seviyesinde zorunlu) ve "conditional" (jurisdiksiyon bağımlı) olarak işaretler. Pratik öneri: her zaman maksimum veri seti gönderin; karşı tarafın hangi alanları nasıl yorumlayacağı sizin sorumluluğunuzda değil.
IVMS 101 dışında alternatif kullanabilir miyim?
Teknik olarak evet — örneğin bilateral anlaşmayla karşı VASP'le özel format çıkarabilirsiniz. Pratikte hayır. Tüm üretim Travel Rule protokolleri IVMS 101 üzerine kurulu; özel format ile entegre olabileceğiniz VASP sayısı çok sınırlı kalır. Ölçek hedefiniz varsa IVMS 101 zorunlu.
Müşterinin doğum yerini bilmiyorsam ne yapmalıyım?
dateAndPlaceOfBirth opsiyonel bir alan; ama eğer national identification eksikse (NIDN, PASS gibi), birçok karşı VASP doğum tarih/yeri'ni alternatif kimlik olarak bekler. KYC sürecinde bu alanın doldurulmasını zorunlu hale getirmek pratiktir. Mevcut müşteri tabanında eksikse: backfill KYC süreci başlatın; mesajda alanı boş bırakıp karşı tarafın red oranını kabul edebilirsiniz, ama bu sürdürülebilir değil.
Legichain ile
IVMS 101 mapping'i parçalı tutmak operasyonel hata kaynağıdır. Legichain Travel Rule modülü mevcut dijital KYC ve müşteri veri tabanınızla doğrudan entegre — KYC sırasında toplanan alanlar (T.C. kimlik, doğum yeri, adres) otomatik IVMS 101 formatına çevriliyor, manuel mapping kodu yazılması gerekmiyor. Eksik alanlar için müşteri-tarafı düzeltme akışı (validation hatası → müşteri güncelle → otomatik retry) hazır geliyor. Protokol katmanı (TRP, Sygna, TRISA) çoklu desteklendiği için karşı VASP'in tercihine göre rota otomatik. /travel-rule sayfasında sandbox üzerinden örnek mesaj akışını test edebilirsiniz.
Sonraki adımlar
- FATF Travel Rule rehberi — IVMS 101'in içinde durduğu büyük resmi.
- Travel Rule entegrasyonu nasıl yapılır — IVMS 101 mapping'inin 8 adımlı entegrasyon içindeki yeri.
- Sunrise problem ve çözüm stratejileri — IVMS 101 mesajı üretildikten sonra karşı tarafın kabul edememesinin sorunu.