IP/IP ve IPZip Transferleri

IP to IP (IPIP)

IP'den IP'ye transferler, para veya varlıkların, borçların ve özkaynakların muhabir banka hesaplarından ya da verilerin farklı finansal kurumlar veya sistemler arasında İnternet Protokolü (IP) adresleri kullanılarak aktarılması sürecinin bir parçasını ifade eder. Finansal işlemler bağlamında IP adresi, internete bağlı her cihaza atanan benzersiz bir sayısal tanımlayıcıdır ve farklı sistemler arasında bilgi yönlendirmek için kullanılır. Bankacılıkta IP'den IP'ye transferler, bir finansal işlemi gerçekleştirmek üzere iki sistemin kendi IP adresleri üzerinden doğrudan iletişim kurmasını içerir. Bilgi bütünlüğünü ve güvenliğini sağlamak için bunun üzerine özel kimlik doğrulama ve yetkilendirme yöntemleri uygulanır.

Ancak, IP'den IP'ye transferlerin bankacılık sektöründe yaygın olmadığını ve tavsiye edilmediğini belirtmek önemlidir; bunun güvenlik, güvenilirlik ve uyum kaynaklı çeşitli nedenleri vardır. Aşağıdaki noktalar bu endişelere ilişkin bir çerçeve sunmaktadır:

1. Güvenlik: IP'den IP'ye transferler, birden fazla güvenlik, şifreleme ve kimlik doğrulama katmanı uygulayan SWIFT veya ACH gibi yerleşik bankacılık ağlarına kıyasla daha az güvenli olabilir. İki IP adresi arasındaki doğrudan iletişim, hassas bilgileri bilgisayar korsanlığı, kimlik avı veya ortadaki adam saldırıları gibi olası güvenlik tehditlerine maruz bırakabilir.
2. Güvenilirlik: IP'den IP'ye transferlerin kullanılması, işlemin güvenilirliğini garanti etmez; zira bankacılık sektöründe IP tabanlı transferler için evrensel olarak kabul görmüş herhangi bir standart veya protokol bulunmamaktadır. Bu durum, işlemin gerçekleştirilmesi, izlenmesi ve mutabakatı bakımından olası sorunlara yol açabilir.
3. Uyum: Bankalar ve finansal kuruluşlar, Kara Paranın Aklanmasının Önlenmesi (AML) ve Müşterini Tanı (KYC) politikaları dâhil çok sayıda düzenleme ve gerekliliğe tabidir. IP'den IP'ye transferler bu düzenleyici gerekliliklere uymayabilir; bu da ilgili tarafları hukuki ve finansal risklere maruz bırakabilir.

Bankalar ve finansal kurumlar, IP'den IP'ye transferler yerine, farklı kurumlar arasında güvenli, güvenilir ve mevzuata uygun fon transferlerini kolaylaştırmak için SWIFT, RTGS veya ACH/Anlık Ödeme gibi yerleşik ağları ve ISO 20022 gibi mesajlaşma standartlarını tercih eder.

Bankalarda İletişim Sunucuları ile Defter/Hesap Sunucuları Arasındaki Temel Farklar

Bankacılık teknolojisinde sunucular, finansal işlemlerin ve kayıt tutmanın sorunsuz yürütülmesini sağlamada belirleyici bir rol oynar. Bankaların dayandığı iki temel sunucu türü, iletişim sunucuları ile defter/hesap sunucularıdır. Her ikisi de kritik öneme sahip olmakla birlikte, farklı amaçlara hizmet eder ve farklı veri türlerini işler.

İletişim Sunucuları

İletişim sunucuları, bankalar ve finansal kuruluşlar arasındaki güvenli veri alışverişinin omurgasını oluşturur. İletişim sunucularının temel işlevleri ve özellikleri şunlardır:

1. Güvenli Veri Alışverişi: Bu sunucular güvenli veri alışverişini kolaylaştırarak hassas finansal bilgilerin kurumlar arasında ödün verilmeksizin iletilmesini sağlar.
2. Protokoller ve Standartlar: Bankalar arası iletişim için SWIFT, SEPA veya ACH gibi standartlaştırılmış protokolleri kullanarak farklı platformlar arasında tekdüzelik ve güvenilirlik sağlarlar.
3. Şifreleme ve Kimlik Doğrulama: Güvenliği sağlamak amacıyla iletişim sunucuları, veri iletimi sırasında verileri korumak için gelişmiş şifreleme yöntemleri ve sıkı kimlik doğrulama protokolleri kullanır.
4. İşlem Yürütme: Öncelikle işlem taleplerini, mesajları ve talimatları yürütür; işlemler için gerekli bilgilerin iletilmesini sağlayan aracı kurumlar olarak görev yaparlar.
5. Fon Hareketi Bulunmaması: Önemle belirtmek gerekir ki bu sunucular fonları hareket ettirmez veya hesap bakiyelerini doğrudan güncellemez; yalnızca bu tür işlemler için gerekli iletişimi kolaylaştırır.

Defter/Hesap Sunucuları

Defter/hesap sunucuları ise bir bankanın finansal kayıtlarının muhafızlarıdır. Başlıca özellikleri şunlardır:

1. Mali Kayıtların Tutulması: Bu sunucular, bankanın temel mali kayıtlarını saklar ve muhafaza eder; her işlemin doğru biçimde kaydedilmesini sağlar.
2. İşlem Kaydı: Borç ve alacak kayıtları dâhil tüm işlemleri kaydederler; cari hesap bakiyelerinin güncellenmesinden ve saklanmasından sorumludurlar.
3. Genel Defter Yönetimi: Defter sunucuları, bankanın genel defterini ve münferit müşteri hesaplarını yöneterek mali durumun bütüncül bir görünümünü sağlar.
4. Veri Bütünlüğü: Bu kayıtlar doğru finansal raporlama ve uyum için gerekli olduğundan, veri tutarlılığının ve bütünlüğünün sağlanması esastır.
5. Güçlü Güvenlik Önlemleri: Verilerin hassas niteliği nedeniyle, defter sunucularında genellikle ek şifreleme katmanları ve sıkı erişim denetimleri dahil olmak üzere daha sıkı güvenlik önlemleri uygulanır.

İletişim sunucusu işlemleri başlatır ve kolaylaştırır; ancak defter sunucusu, bu işlemleri bankanın kayıtlarında doğrulandıktan sonra nihai olarak kaydeder ve yansıtır.

Çağdaş bankacılık sistemlerinde bu işlevler çoğunlukla bütünleşik olup, güvenli banka içi iletişim protokolleri defter yönetimi sistemleriyle birlikte çalışır. Bu entegrasyon, bankanın tüm finansal ekosistemi genelinde gerçek zamanlı güncellemeleri ve tutarlılığı güvence altına alarak hem verimliliği hem de güvenliği artırır. Birçok banka, güvenlik, mevzuata uyum ve ölçeklenebilirlik gereksinimlerini dengelemek amacıyla şirket içi ve bulut tabanlı sunucuların bir kombinasyonunu kullanır.

Varlık, Yükümlülük ve Özkaynakların Fiilî Devri: Menkul kıymetlerin devirleri, mülkiyetin hukuki kaydını tutan merkezi menkul kıymet saklama kuruluşları (CSD) tarafından kaydedilir; krediler, sabit kıymetler ve diğer pozisyonlar ise geçerli hukuk uyarınca temlik veya devir sözleşmeleriyle geçer. Her ikisi de iletişim protokollerinin kapsamı dışındadır. Varlıkların ve özkaynakların devri, bankaların finansal tablolarını da etkiler; yükümlülük, varlık ve özkaynak bakiyelerini değiştirir. İlgili denetim otoritelerine yapılan bu finansal raporlama ve gerekli uyum boyutu, protokollerin veri iletim yeteneklerinin ötesindedir ve ek finansal ve düzenleyici süreçler gerektirir.

Özetle, protokoller IPIP işlemlerinde bilginin güvenli ve verimli biçimde değişimi için hayati önem taşısa da, sürecin tamamı; para, varlık, yükümlülük ve özkaynak hareketinin, takasın, hukuki kaydın ve finansal raporlamanın gerçekleştirilmesi için ek sistemleri de kapsar ve böylece işlemin tamamının düzenleyici bankacılık standartlarına uygun olarak yürütülmesi sağlanır.

IP ZIP Transferi

Kurumsal Ödeme Talimatlarının Güvenli Dosya Tabanlı İletimi

IP ZIP Transferi, yapılandırılmış ödeme talimatlarının ve ilgili işlem verilerinin, kimlik doğrulaması yapılmış kurumsal sistemler arasında Internet Protocol ağı üzerinden doğrudan ve güvenli biçimde iletilmesine yönelik dosya tabanlı bir yöntem olarak anlaşılmalıdır.

Terminoloji, özel bir hassasiyet gerektirmektedir.

IP ZIP iletimi; bir takas sistemi, mutabakat sistemi, ödeme kanalı veya parasal değer aktarımı için bağımsız bir mekanizma değildir. ZIP arşivi bir taşıma kapsayıcısıdır. IP bağlantısı ise iletişim kanalıdır. Arşivin içerdiği bilgi ise bir talimat, veri seti veya işlem mesajı niteliğindedir.

Buna göre:

IP ZIP, ödeme bilgilerini ve talimatlarını iletir. Tek başına fonların takasını gerçekleştirmez.

Kavramsal olarak bu durum, bir ISO 20022 pacs.008 (Finansal Kuruluştan Finansal Kuruluşa Müşteri Kredi Transferi) mesajı için geçerli olan ayrımla karşılaştırılabilir. Bir pacs.008 mesajı yüksek düzeyde yapılandırılmış bir bankalar arası kredi transferi talimatı taşıyabilir; ancak mesajın kendisi, merkez bankası parasının, ticari banka parasının veya muhabir hesap bakiyelerinin nihai hareketi ve uzlaşmasıyla karıştırılmamalıdır.

Aynı ilke, bir IP ZIP iletimi için de geçerlidir.

2. Güvenli İşlem Konteyneri Olarak ZIP Dosyası

ZIP bileşeni, esas olarak bir kapsülleme ve paketleme mekanizması işlevi görür.

Gönderen kurum, işlem bileşenlerini ayrı ayrı iletmek yerine, ilgili dosyaları tek bir kontrollü paket halinde derleyebilir.

Mutabık kalınan ikili şartnameye bağlı olarak, böyle bir paket şunları içerebilir:

• yapılandırılmış ödeme talimatları;
• XML ödeme mesajları;
• ISO 20022 ile uyumlu veri setleri;
• JSON işlem nesneleri;
• CSV veya sabit formatlı işlem kayıtları;
• tescilli (standart dışı) bankalar arası ödeme dosyaları;
• borçlu ve alacaklı bilgileri;
• gönderen ve lehtar hesap bilgileri;
• işlem tanımlayıcıları;
• para birimi ve tutar bilgileri;
• talep edilen icra ve valör tarihleri;
• muhabir banka talimatları;
• aracı banka bilgileri;
• ödeme açıklaması bilgileri;
• takas yönlendirme bilgileri;
• uyum belgeleri;
• KYC veya KYB referansları;
• fon kaynağına ilişkin bilgiler;
• işlem beyanları (manifestolar);
• dijital imzalar;
• kriptografik özetler (hash);
• sertifikalar;
• zaman damgaları;
• mutabakat dosyaları; ve
• kontrol toplamları.

Dolayısıyla arşiv, hem asıl ödeme talimatını hem de bu talimatın kimlik doğrulaması, geçerlilik kontrolü, işlenmesi ve mutabakatı için gerekli tamamlayıcı bilgileri içerebilir.

Sıkıştırma teknik açıdan tali bir unsurdur. Asıl amaç, paketlemenin ve iletimin kontrollü biçimde yapılmasıdır.

Bu nedenle bir ZIP arşivi, arşiv içinde gösterilen fonların mevcut, kullanılabilir, rehin veya takyidattan ari ya da takas edilmiş olduğuna dair bir kanıt olarak asla kabul edilmemelidir.

3. Yapılandırılmış Ödeme Talimatı

Uygun şekilde tasarlandığında, bir IP ZIP paketinde yer alan ödeme talimatı, geleneksel yapılandırılmış finansal mesajlaşmaya benzer bir işlev görebilir.

Örneğin bir kurum, ISO 20022 pacs.008 mesajında olağan olarak yer alan bilgilere karşılık gelen alanları içeren bir XML talimatı iletebilir; bu alanlar arasında şunlar bulunur:

• mesaj tanımlaması;
• oluşturulma tarihi ve saati;
• işlem sayısı;
• takas ve mutabakat bilgileri;
• talimat veren aracı;
• talimat verilen banka;
• borçlu;
• borçlu hesabı;
• borçlunun bankası (debtor agent);
• alacaklının bankası (creditor agent);
• alacaklı;
• alacaklı hesap;
• talimat verilen tutar;
• para birimi;
• masrafları yüklenen taraf;
• ödeme tanımlaması;
• uçtan uca tanımlama; ve
• havale bilgileri.

Belirleyici fark şudur: veri yapısı, takas mekanizmasını belirlemez.

Teknik açıdan geçerli bir ödeme talimatı, alıcı sistem tarafından alınabilir, doğrulanabilir ve kabul edilebilirken, buna karşılık gelen finansal uzlaştırma bekleyen durumda kalabilir.

Dolayısıyla:

Talimatın alınması ≠ fonların alınması

Talimatın doğrulanması ≠ fonların takasının tamamlanması

Dosyanın başarıyla içe aktarılması ≠ lehtara nihai fonların aktarılması

Sunucu onayı ≠ takas teyidi

Bu ayrım, IFB’nin alternatif transfer yöntemlerine yaklaşımının temelini oluşturur.

4. İletim Protokolleri

Kurumsal IP ZIP iletimleri yalnızca kontrollü ve kimlik doğrulamalı bir iletişim ortamı üzerinden gerçekleştirilmelidir.

İkili teknik düzenlemeye bağlı olarak, iletimde aşağıdaki gibi teknolojilerden yararlanılabilir:

SFTP

SSH üzerinden Güvenli Dosya Aktarım Protokolü, şifreli aktarım, sunucu kimlik doğrulaması ve kontrollü kullanıcı kimlik doğrulaması sağlar.

Kurumsal bağlantılarda, yalnızca parolaya dayalı kimlik doğrulama yerine genel olarak açık anahtarlı kimlik doğrulama tercih edilmelidir.

FTPS

Eski altyapının gerektirdiği durumlarda FTP, uygun sertifika doğrulaması, şifreleme standartları ve erişim kontrolleri uygulanması koşuluyla TLS ile korunabilir.

HTTPS / REST API

Paket, TLS ve uygun uygulama düzeyinde kimlik doğrulama kullanılarak, doğrulanmış bir HTTPS uç noktası veya API mimarisi üzerinden iletilebilir.

Karşılıklı TLS (Mutual TLS)

Daha yüksek güvence düzeyi gerektiren kurumsal bağlantılarda, karşılıklı TLS (mTLS) her iki uç noktanın dijital sertifikalar kullanarak birbirini doğrulamasına olanak tanır.

Bu yöntem, yalnızca tek taraflı sunucu kimlik doğrulamasına kıyasla yetkisiz uç noktalara karşı önemli ölçüde daha güçlü koruma sağlar.

VPN

Uygulama katmanı iletimi gerçekleşmeden önce, katılımcı kurumlar arasında site-to-site IPSec veya eşdeğer bir VPN ile şifreli özel bir tünel kurulabilir.

Özel Bağlantı Altyapısı

İşlem hacimlerinin, güvenlik gerekliliklerinin veya kurumsal risk profillerinin gerektirdiği hâllerde, genel İnternet üzerinden iletime ek olarak veya onun yerine, özel tahsisli ya da özel ağ bağlantısı kullanılabilir.

Kesin protokol, operasyonel aktivasyondan önce ikili olarak üzerinde mutabık kalınmalıdır.

5. Uç Nokta Kimlik Doğrulaması

Alıcı kurum, iletimin temsil ettiğini ileri sürdüğü kurumdan geldiğini tespit etmelidir.

İlgili kontroller şunları içerebilir:

• kurumsal dijital sertifikalar;
• SSH genel/özel anahtar çiftleri;
• karşılıklı TLS sertifikaları;
• API kimlik bilgileri;
• IP adresi izin listesi;
• VPN kimlik doğrulaması;
• donanım güvenlik modülleri;
• uygun olduğu hallerde sertifika sabitleme (certificate pinning);
• çok faktörlü yönetici kimlik doğrulaması;
• kontrollü hizmet hesapları;
• role dayalı erişim kontrolleri; ve
• üretim ve test ortamlarının birbirinden ayrıştırılması.

Tek başına bir IP adresi, kurumsal kimliğin yeterli kanıtı değildir.

Aynı şekilde, bir uç noktaya, sunucu girişine, API kimlik bilgisine veya ZIP parolasına sahip olmak, söz konusu fonların mülkiyetini ispatlamaz.

6. Şifreleme

Gizlilik, olağan koşullarda birden fazla düzeyde tesis edilmelidir.

Aktarım Şifrelemesi

İletişim kanalı, TLS veya SSH gibi uygun biçimde yapılandırılmış güncel bir protokol kullanılarak şifrelenmelidir.

Bu, iletim sırasında bilgileri korur.

Yük Şifreleme

Gerekli görülen hallerde işlem paketinin kendisi de ayrıca şifrelenebilir.

Bu yöntem, finansal bilgilerin iletim kanalından bağımsız olarak korunmasını sağlar ve dosyaların geçici olarak depolandığı, aracı altyapılar üzerinden yönlendirildiği, arşivlendiği veya eşzamansız olarak işlendiği durumlardaki maruziyeti önemli ölçüde azaltabilir.

Bekleme Halinde Şifreleme (Encryption at Rest)

İşlem bekleyen dosyalar, uygun erişim kısıtlamaları ve depolanan verilerin şifrelenmesi ile kontrollü depolama ortamlarında korunmalıdır.

Ancak şifreleme, gizliliği sağlar. İşlemin mali geçerliliğini sağlamaz.

7. Kriptografik Bütünlük

Alıcı kurum ayrıca, iletilen paketin oluşturulmasından sonra değiştirilip değiştirilmediğini tespit edebilecek durumda olmalıdır.

Bu nedenle paket veya paketi oluşturan dosyalar için bir kriptografik özet (hash) üretilebilir.

Örneğin:

Orijinal işlem paketi
→ kriptografik özet (hash) üretilir
→ paket iletilir
→ alıcı sistem özeti bağımsız olarak hesaplar
→ hesaplanan özet, iletilen veya imzalanan özetle karşılaştırılır

Uyuşmazlık, alınan paketin başlangıçta doğrulanan paketle kriptografik olarak özdeş olmadığını gösterir.

Bütünlük doğrulaması için, uygulamaya uygun olduğu ölçüde SHA-2 veya SHA-3 ailesi üyeleri gibi güncel kriptografik özet algoritmaları kullanılabilir.

8. Dijital İmzalar

Dijital imza, şifrelemeden esaslı biçimde farklı bir işlev görür.

Şifreleme, gizliliği korur.

Karma (hash) işlemi, bütünlüğün tesis edilmesine yardımcı olur.

Usulüne uygun biçimde uygulanan bir dijital imza şunların tespitine yardımcı olabilir:

1. orijinallik - paket, ilgili özel anahtar kullanılarak imzalanmıştır;
2. bütünlük - imzalanan verilerin sonradan değiştirilmemiş olması; ve
3. hesap verebilirlik - imza, geçerli PKI ve yönetişim çerçevesine tabi olarak ilgili kurumsal kimlik bilgisiyle ilişkilendirilebilir.

Alıcı kuruluş, işlem talimatı ödeme işlemlerine girmeden önce imzayı ilgili güvenilir sertifika veya açık anahtar ile doğrulamalıdır.

Özel imza anahtarları, tercihen kurumsal anahtar yönetimi altyapısı aracılığıyla ve gerekli görüldüğünde Donanım Güvenlik Modülleri (HSM) ile uygun biçimde korunmalıdır.

9. Yeniden Oynatma ve Çoğaltma Koruması

Finansal dosya iletiminde, geçerli bir talimatın tekrar tekrar gönderilmesine karşı kontroller gereklidir.

Uygun şekilde tasarlanmış bir mimari bu nedenle benzersiz işlem tanımlayıcılarını ve aşağıdaki gibi uygun kontrolleri içermelidir:

• benzersiz mesaj kimlikleri;
• benzersiz işlem kimlikleri;
• zaman damgaları;
• sıra numaraları;
• dosya tanımlayıcıları;
• mükerrer mesaj tespiti;
• mükerrer işlem önleme (idempotency) kontrolleri;
• işlem durumu kayıtları; ve
• daha önce işleme alınmış talimatlarla mutabakat.

Alıcı kurum, mükerrer talimatları üzerinde mutabık kalınan işletim prosedürüne uygun olarak reddetmeli, karantinaya almalı veya incelemelidir.

10. Dosya Doğrulama

Bir dosyanın başarıyla alınması, otomatik uzlaştırmayı değil, doğrulama sürecini başlatmalıdır.

Güvenli bir işleme ortamı, paketi birbirini izleyen birkaç kontrole tabi tutabilir:

1. Aşama – Nakliye Doğrulaması

Paketin yetkili bir kanal aracılığıyla ulaştığının teyidi.

Aşama 2 – Uç Nokta Kimlik Doğrulaması

İletim yapan sistemin ve kurumsal kimlik bilgilerinin teyidi.

Aşama 3 – Kötü Amaçlı Yazılım ve Dosya Güvenliği Kontrolleri

Arşivin ve arşivi oluşturan dosyaların, ödeme altyapısına alınmadan önce incelenmesi.

4. Aşama – Kriptografik Doğrulama

Özet değerlerinin (hash), imzaların ve sertifikaların doğrulanması.

5. Aşama – Yapısal Doğrulama

Dosyaların üzerinde mutabık kalınan şemaya, adlandırma kurallarına, karakter kodlamasına ve veri spesifikasyonuna uygun olduğunun teyidi.

Aşama 6 – Anlamsal Doğrulama

Zorunlu ödeme alanlarının mevcut ve kendi içinde tutarlı olduğunun teyidi.

7. Aşama – İşlem Doğrulaması

Para biriminin, tutarın, hesapların, yönlendirme bilgilerinin, işlem referanslarının ve takas talimatlarının doğrulanması.

8. Aşama – Uyum Doğrulaması

AML, yaptırım, KYC/KYB, işlem izleme ve uygulanabilir diğer kontroller.

9. Aşama – Takas Doğrulaması

İlgili finansal değerin takas edilebileceği fiilî bir mekanizmanın mevcut olduğunun teyidi.

Talimat, ancak bu kontroller tamamlandıktan sonra, alıcı kuruluşun geçerli prosedürlerine uygun olarak icraya geçmelidir.

11. Teyit, Uzlaşma Anlamına Gelmez

Bir IP ZIP ortamı birden fazla teknik teyit mesajı üretebilir.

Örneğin:

ACK – Dosya alındı

Bu, yalnızca alıcı uç noktanın paketi edindiğini ortaya koyar.

ACK – Dosya doğrulandı

Bu durum, kimlik doğrulama kontrollerinin başarıyla tamamlandığını ortaya koyar.

ACK – Dosya doğrulandı

Bu, paketin geçerli yapısal veya teknik doğrulamayı karşıladığını ortaya koyar.

ACK – Talimat kabul edildi

Bu durum, ödeme talimatının alıcı kurumun işlem akışına girdiğini ortaya koyabilir.

Bu durumların hiçbiri zorunlu olarak şunları ifade etmez:

MUTABAKATI SAĞLANDI

Takas, ayrı bir finansal olay gerektirir.

Bu ayrım, bir ödeme mesajının başarıyla iletilmesi ve kabul edilmesi ile dayanak parasal yükümlülüğün nihai mutabakatının birbirinden ayrılması gereken konvansiyonel finansal mesajlaşmadaki duruma benzer.

12. Temel İşlemin Takası

Bir IP ZIP ödeme talimatı doğrulandıktan, onaylandıktan, kabul edildikten ve yetkilendirildikten sonra, dayanak parasal değerin uygun bir finansal altyapı aracılığıyla takas edilmesi gerekir.

İlgili para birimlerine, kurumlara ve yetki alanlarına bağlı olarak takas şu yollarla gerçekleşebilir:

• muhabir bankacılık;
• Nostro/Vostro hesapları;
• merkez bankası hesapları;
• RTGS altyapısı;
• tanınmış takas sistemleri;
• yurt içi ödeme sistemleri;
• anlık ödeme altyapıları;
• muhabir takas bankaları; veya
• hukuken ve operasyonel olarak tanınan başka bir takas düzenlemesi.

14. Güvenlik İlkesi

IFB, tüm alternatif transfer yöntemlerine temel bir ayrım gözeterek yaklaşır:

Güvenli iletim, verilerin güvenli biçimde iletilebildiğini kanıtlar. Paranın takas edilebildiğini kanıtlamaz.

• Şifreleme, fonların varlığını kanıtlamaz.
• Dijital imza, fonların varlığını kanıtlamaz.
• Bir sunucu bakiyesi, fonların varlığını kanıtlamaz.
• Bir işlem dosyası fonların varlığını kanıtlamaz.
• Dosyanın başarıyla sisteme alınması, fonların varlığını kanıtlamaz.
• Teknik bir onay, ödemenin kesinleştiğini (settlement) kanıtlamaz.

Belirleyici finansal soru, kaynak kurumun, ilgili parasal değeri tanınan bankacılık altyapısı üzerinden teslim edebilecek doğrulanmış likiditeye ve işler durumda bir takas yoluna sahip olup olmadığıdır.

15. IFB Kabul Çerçevesi

IFB, IP ZIP iletimlerini yalnızca onaylanmış kurumsal karşı taraflar ve kabul edilmiş müşteriler için, tatmin edici teknik, hukuki ve uyum incelemesinin ardından değerlendirebilir.

Canlı ortam bağlantısı kurulmadan önce IFB aşağıdakilerin doğrulanmasını talep edebilir:

• işlemi başlatan kurum;
• işlemin iletilmesine ilişkin kurumsal yetki;
• gerçek faydalanıcılar ve işlem tarafları;
• fonların kaynağı ve meşruiyeti;
• altta yatan ekonomik amaç;
• gönderim ve alım altyapısı;
• uç nokta sahipliği;
• IP ve ağ mimarisi;
• kimlik doğrulama yöntemi;
• sertifikalar ve kriptografik kimlik bilgileri;
• şifreleme standartları;
• dosya biçimi ve şema;
• ödeme mesajı yapısı;
• işlem tanımlama metodolojisi;
• onay bildirimi protokolü;
• mükerrer işlem ve yeniden oynatma (replay) kontrolleri;
• istisna yönetimi;
• mutabakat prosedürleri;
• muhabir ilişkileri;
• takas hesapları;
• likidite düzenlemeleri; ve
• nihai takas yolu.

Teknik birlikte çalışabilirlik tek başına yeterli değildir.

IFB, bir IP ZIP paketinin başarıyla iletilmesini fonların alındığı anlamında değerlendirmez. İşlem, ancak ilgili değer, mutabık kalınan bankacılık veya takas altyapısı aracılığıyla başarıyla takas edildiğinde ve takas bağımsız olarak mutabakata bağlanabildiğinde mali açıdan tamamlanmış sayılır.

Temel İlke

IP ZIP, bir talimatın güvenli iletimidir. Takas ve mutabakat ise karşılık gelen finansal değerin hareketidir.

Bu iki süreç aynı işlem iş akışının parçalarını oluşturabilir; ancak aynı olay değildir.

Kurumsal bankacılık terminolojisinde:

Mesaj iletimi → kimlik doğrulama → doğrulama → kabul → icra → uzlaştırma → mutabakat

İşlemin parasal ayağının tamamlandığı, yalnızca ilgili takas ve mutabakat sürecinin tamamlanmasıyla kesinleşir.

Alternatif veya eski transfer yöntemleriyle ilişkili terminoloji, bankacılık altyapısı bağlamında yorumlanmalıdır. Bu tür terimler iletişim kanallarını, dahili işlem yöntemlerini veya tarihsel uygulamaları tanımlayabilir; ancak düzenlemeye tabi kurumlara, tanınmış ödeme sistemlerine ve resmi takas ve mahsup usullerine duyulan gerekliliğin yerini almaz.

Terminolojisi ne olursa olsun, her transfer nihayetinde yerleşik finansal sistem içinde işlenmeli, takas edilmeli ve mutabakata bağlanmalıdır.

Hesaplarınıza fon veya varlık aktarımı hakkında daha fazla bilgi almak isterseniz lütfen Marie Mayer ile iletişime geçin.