SWIFT

MT ve MX Mesajlarıyla SWIFT Transferleri ve İletişim

SWIFT (Society for Worldwide Interbank Financial Telecommunication), bankalar gibi finansal kuruluşların ödeme talimatları ve teyitleri gibi finansal işlemlere ilişkin standartlaştırılmış mesajları göndermesini ve almasını sağlayan güvenli bir mesajlaşma ağıdır. SWIFT hesap tutmaz ve fon transfer etmez; yalnızca bilgi alışverişi için güvenli ve güvenilir bir platform sunar.

Standart SWIFT transferleri, MT (Message Type) mesajları olarak bilinen bir dizi standartlaştırılmış mesaj türünü kullanır. Bu mesajlar önceden tanımlanmış biçimlere ve alanlara sahiptir; böylece finansal kuruluşlar içerdikleri bilgileri kolaylıkla anlayabilir ve işleyebilir.

MX (ISO 20022) mesajları, XML (eXtensible Markup Language) tabanlı, daha yeni bir finansal mesajlaşma standardıdır. Daha zengin ve daha yapılandırılmış bir format sunarak gelişmiş veri alışverişine ve iyileştirilmiş baştan sona otomatik işlemeye imkân tanır. MX mesajları, SWIFT ağında kademeli olarak MT mesajlarının yerini almaktadır; amaç, daha iyi birlikte çalışabilirlik ve veri işleme yetenekleri sağlamaktır.

Geleneksel SWIFT transferleri onlarca yıldır uluslararası ödemelerin omurgasını oluştursa da şeffaflığın sınırlı olması, işlem sürelerinin daha uzun olması ve verilerin yapılandırılmamış olması gibi bazı sınırlamaları vardır.

Swift 103+ STP (Straight Through Processing – Kesintisiz İşleme)

Swift 103+ STP, Uçtan Uca Otomatik İşlem (Straight Through Processing, STP) için optimize edilmiş eski MT formatıydı; birlikte kullanım döneminin sona ermesinden bu yana rolünü pacs.008 STP kullanım kılavuzu üstlenmiştir. STP, ödeme sürecinin başlatılmasından nihai takasına kadar tamamının manuel müdahale gerekmeksizin elektronik ortamda gerçekleştirilmesini sağlar.

Ek Özellikler:

1. Standart Format: Standartlaştırılmış formata sıkı bağlılık gerektirir; bu da hataları ve gecikmeleri azaltır.
2. Otomatik İşleme: İşlemler otomatik olarak yürütülür; bu da işlemlerin daha hızlı ve daha verimli biçimde gerçekleştirilmesini sağlar.
3. Azaltılmış Manuel Müdahale: Manuel giriş ve doğrulama ihtiyacı en aza indirilir; böylece hata ve gecikme riski azalır.
4. Daha Hızlı Takas: İşlemler geleneksel yöntemlere kıyasla daha hızlı sonuçlandırılır.

STP için Dikkat Edilecek Hususlar:

1. Doğru Veri Girişi: Gecikmeleri veya ret durumlarını önlemek için verilerin doğru girilmesi gerekir.
2. Format Gereksinimlerine Uyum: Bankalar, 103+ STP format gereksinimlerine sıkı sıkıya uyulmasını sağlamalıdır.
3. Yazılım ve Sistemler: Bankaların, STP'yi etkin biçimde yürütebilmek için uygun yazılım ve sistemlere sahip olması gerekir

Mesajlaşma ile ödemenin kesinleşmesi arasındaki ayrımı yapmak esastır. SWIFT, kurumlar arasında yapılandırılmış finansal mesajları iletir; ancak kendisi fon transferi gerçekleştirmez ve bakiye tutmaz. pacs.008 mesajı da dâhil olmak üzere bir SWIFT teyidi, yalnızca katılımcı kurumların bankacılık sistemlerinde fiilen işleme alınmış ve mutabakatı yapılmış bir işleme karşılık geldiğinde geçerlidir.

Kurumsal doğrulama yapılmaksızın tek başına sunulan hiçbir SWIFT belgesi, ekran görüntüsü veya mesajı, tamamlanmış bir takas ve ödemenin kanıtı olarak değerlendirilmemelidir.

SWIFT gpi transferleri.

SWIFT gpi (Global Payments Innovation):

2017 yılında hayata geçirilen SWIFT gpi, sınır ötesi ödemelerin hızını, şeffaflığını ve izlenebilirliğini artırarak geleneksel SWIFT transferlerinin sınırlamalarını gidermek üzere tasarlanmış bir girişimdir. SWIFT gpi, ödeme hizmetlerini iyileştirmek için mevcut MT ve MX mesaj formatlarından yararlanır. SWIFT gpi'nin temel özellikleri şunlardır:

• Daha hızlı ödemeler: gpi, süreçleri basitleştirir ve bankalar arasında daha sıkı hizmet seviyesi sözleşmeleri (SLA) oluşturur; bu da işlem sürelerinin kısalmasını, çoğu zaman dakikalar veya saniyeler içinde tamamlanmasını sağlar.
• Ödeme takibi: gpi Tracker, işlemlerin gerçek zamanlı izlenmesini sağlayarak şeffaflığı artırmakta ve manuel incelemeleri azaltmaktadır.
• Ücret şeffaflığı: Bankalar, işlem ücretlerine ilişkin bilgileri müşterilere önceden sunarak daha sağlıklı karar alınmasını sağlayabilir.
• Daha zengin veri: gpi, daha ayrıntılı ve yapılandırılmış bilgi alışverişini destekleyerek mutabakatın ve mevzuata uyumun iyileştirilmesini kolaylaştırır.

SWIFT gpi, geleneksel SWIFT transferlerinin sınırlamalarını; sınır ötesi ödemeleri uçtan uca izleme, daha hızlı işlem süresi ve daha zengin veri ile geliştirerek giderir.

SWIFT gpi Katılımcısı Olmayanlar İçin Temel Parametreler

SWIFT gpi katılımcısı olmayan bir taraf (örneğin gpi'ye doğrudan kayıtlı olmayan bir banka veya finans kuruluşu), gpi katılımcısı bir bankaya ödeme talimatı gönderdiğinde, gpi katılımcısı banka bu talimatı gerekli SWIFT mesaj formatlarına (müşteri havaleleri için pacs.008, karşılık (cover) ödemeleri için pacs.009 COV ve finansal kuruluşlar arası havaleler için pacs.009) dönüştürebilir. Talimatın, zorunlu alanların doldurulması ve uçtan uca izlenebilirlik gibi gpi kurallarına uyulması için yeterli veriyi içermesi koşuluyla, bu dönüşüm ödemenin gpi ağı içinde işlenmesini ve izlenmesini mümkün kılar.

gpi'ye katılmayan kurumlar bu parametreleri genellikle yurt içi ödeme şemaları, API'ler veya eski formatlar aracılığıyla sağlar; gpi'ye katılan banka ise gpi'ye özgü ilaveleri (örneğin, sağlanmamışsa UETR üretilmesi; ancak bunun iletilmesi gpi'ye katılmayan kurumlar için isteğe bağlıdır) üstlenir. Kesin gereklilikler yetki alanına, para birimine ve ikili anlaşmalara göre değişebilir; ancak temel parametreler CBPR+ (Cross-Border Payments and Reporting Plus) kılavuzlarından ve ISO 20022 standartlarından alınmıştır. 22 Kasım 2025'te birlikte kullanım (coexistence) döneminin sona ermesinin ardından, sınır ötesi ödeme talimatları ISO 20022 formatında iletilmektedir; aşağıdaki eski MT alan göndermeleri yalnızca bilgi amacıyla verilmiştir.
1. Tarafların Kimlik Bilgileri (Borçlu ve Alacaklı Bilgileri)
Bunlar, gönderici ve lehtarı tanımlayarak seyahat kuralı gerekliliklerine ilişkin FATF 16 No'lu Tavsiye Kararı'na uyumu sağlar.

• Borçlu/Talimat Veren Müşteri: Tam ad, yapılandırılmış adres (cadde, şehir, posta kodu, ülke) ve hesap tanımlayıcısı (örneğin IBAN veya hesap numarası). Eski MT 103/MT 202 COV'da bu bilgi Alan 50a'ya, pacs.008/pacs.009'da ise <Dbtr> ve <DbtrAcct> alanlarına karşılık gelir.
• Alacaklı/Lehtar Müşteri: Tam ad, yapılandırılmış adres ve hesap tanımlama bilgileri. Eski MT 103/MT 202 COV mesajlarındaki 59a Alanı ile; pacs.008/pacs.009 mesajlarında ise <Cdtr> ve <CdtrAcct> öğeleriyle eşleşir.
• Nihai Borçlu/Alacaklı (varsa): Asıl taraflardan farklı olmaları halinde, gelişmiş şeffaflık için bilgilerini ekleyiniz (isteğe bağlı olmakla birlikte gpi takibi için önerilir). pacs.008/pacs.009 içinde <UltmtDbtr>/<UltmtCdtr> alanlarıyla eşleşir.

Neden gereklidir: Doğru yönlendirmeyi ve düzenleyici kontrolleri mümkün kılar; eksik veriler reddedilmelere veya gecikmelere yol açabilir.

2. Aracı Kuruluş ve Yönlendirme Bilgileri
Zincirde yer alan finansal kuruluşları belirtir.

• Borçlunun Bankası (Debtor Agent): Gönderen bankanın BIC (Bank Identifier Code) veya diğer tanımlayıcısı. Eski MT 103'teki 52a alanına karşılık gelir; pacs.008/pacs.009'da <DbtrAgt> olarak yer alır.
• Alacaklı Banka: Alıcı bankanın BIC kodu. Eski MT 103/MT 202 COV'de 57a alanına, pacs.008/pacs.009'da ise <CdtrAgt> öğesine karşılık gelir.
• Aracı Bankalar (biliniyorsa): Muhabir bankaların BIC kodları (en fazla 3 kademe). Eski MT formatındaki 56a alanına karşılık gelir; pacs.008/pacs.009'da <IntrmyAgt1-3> olarak yer alır.
• Talimat Veren/Talimat Alan Kuruluşlar: Zincirdeki doğrudan gönderici/alıcı için BIC kodları. İsteğe bağlıdır; ardışık (serial) veya karşılık (cover) yöntemlerinde yardımcı olur.
• Önceki Talimat Veren Aracılar (varsa): Çok aşamalı zincirlerde en fazla 3 önceki aracı.

Neden gereklidir: Aracı kurumlar üzerinden doğru yönlendirmeyi sağlar; pacs.009 COV mesajında kesinlik için kurum adları yerine BICFI kullanılmalıdır.

3. İşlem Ayrıntıları
Takas ve mutabakat için temel finansal unsurlar.

• Tutar ve Para Birimi: Bankalar arası takas tutarı ve ISO 4217 para birimi kodu (örn. USD, EUR). Önceki MT 103/MT 202 COV mesajlarındaki 32A alanına karşılık gelir; pacs.008/pacs.009'da <IntrBkSttlmAmt> olarak yer alır.
• Talimat Verilen Tutar (farklıysa): Kesintilerden önceki asıl tutar.
• Bankalararası Takas Tarihi: Takas için valör tarihi. MT mesajlarında 32A alanının bir bölümüne, pacs.008/pacs.009 mesajlarında ise <IntrBkSttlmDt> alanına karşılık gelir.
• Takas Yöntemi: RTGS (CLRG), karşılık (COVE) veya aracı banka (INDA/INGA) yoluyla olup olmadığını belirtin. Doğrudan bir MT karşılığı yoktur, ancak zımnen mevcuttur.

Neden gereklidir: Değer transferini tanımlar; tüm formatlar için zorunludur.

4. Referans ve Takip Tanımlayıcıları
Özellikle gpi kapsamında izlenebilirlik için.

• Uçtan Uca Tanımlama: Tüm zinciri birbirine bağlayan bir referans (ör. fatura veya işlem numarası). pacs.008/pacs.009 içinde <EndToEndId>.
• Talimat Tanımlayıcısı: Gönderenin referansı (MT'de 16 karakterle sınırlıdır). Eski MT'deki 20. alana karşılık gelir; pacs.008/pacs.009'da <InstrId> olarak eşlenir.
• Benzersiz Uçtan Uca İşlem Referansı (UETR): Uçtan uca izleme için kullanılan bir UUID'dir. pacs.008/pacs.009 mesajlarında ve eski MT 103/MT 202 mesajlarının 121 numaralı alanında zorunludur; başlatıcı kanal bunu sağlamazsa zincirdeki ilk Swift bankası tarafından oluşturulur.
• İşlem Tanımlayıcısı: Ek dahili referans.

Neden gereklidir: gpi takibini ve bağlantılandırmasını (ör. pacs.008 ile pacs.009 COV arasında) mümkün kılar; UETR, evrensel teyitler için temel unsurdur.

5. Amaç ve Hizmet Bilgileri
Ödeme türünü sınıflandırır.

• Amaç ve Kategori Amacı kodları: İşlemin niteliğini belirten ISO kodlarıdır (örn. maaş için SALA). Bazı koridorlarda zorunludur; pacs.008'de <Purp> ve <CtgyPurp> olarak yer alır.
• Hizmet Düzeyi Kodu: gpi hizmetini belirtir (örneğin gpi müşteri kredi transferi için G001); gpi kapsamında olmayan bankalar, üzerinde mutabık kalınmadıkça gpi'ye özgü kodları eklememelidir. MT'de 23E alanına; pacs.008/pacs.009'da <SvcLvl> öğesine karşılık gelir.
• Yerel Enstrüman Kodu: Belirli şemalar için (ör. grup içi transferler).

Neden gereklidir: Düzenleyici uyumu ve işlem önceliğini sağlar; ISO geçişinin ardından giderek zorunlu hale gelmektedir.

6. Havale ve Ek Talimatlar

• Havale Açıklama Bilgisi: Yapılandırılmamış (en fazla 140 karakter) veya yapılandırılmış (ör. fatura ayrıntıları). Eski MT 103'teki 70. alana karşılık gelir; pacs.008/pacs.009'da <RmtInf> olarak eşleştirilir.
• Aracı Bankalara Talimatlar: Örneğin alıcı için /REC/, hesap için /ACC/ veya telefonla verilen talimatlar (PHOB). Eski MT'de 72 numaralı alana karşılık gelir; pacs.008/pacs.009'da <InstrForNxtAgt>/<InstrForCdtrAgt> unsurlarına eşlenir.
• Takas Zamanı Göstergeleri: Talep edilen saatler (örneğin CLS saati için CLSTm).

Neden gereklidir: Bağlam ve işleme talimatlarını sağlar; pacs.009 COV kapsamında karşılık (cover) yöntemiyle yapılan ödemeler için gereklidir.

7. Düzenleyici ve Uyum Verileri

• Düzenleyici Raporlama: Kodlar veya ayrıntılar (ör. vergi kimlik numarası, CRED/DEB gibi raporlama göstergesi). MT'de Alan 77B'ye; pacs.008/pacs.009'da ise <RgltryRptg> alanına karşılık gelir.
• İade Neden Kodları (iadeler için uygulanabilirse): Örneğin kapatılmış hesap için AC04; pacs.004 içinde asıl mesajlara bağlanır.

Neden gereklidir: AML/KYC ve raporlama yükümlülüklerini karşılar; düzenlemeye tabi koridorlarda zorunludur.

En iyi uygulamalar bakımından, gpi katılımcısı olmayan kurumlar, MT'den MX'e dönüşümler sırasında verilerin kesilmesini önleyecek şekilde veri yapılandırmalı ve özel gereksinimler için gpi üyesi bankaya danışmalıdır. Ödemenin cover yöntemlerini içermesi halinde, temel müşteri bilgileri mesajlar arasında birebir örtüşmelidir (ör. pacs.008'den pacs.009 COV'a).

SWIFT gpi’de Ödeme Mesajları

SWIFT gpi (Global Payments Innovation) çerçevesinde, orijinal ödeme mesajları (ör. müşteri transferleri için pacs.008 veya karşılık (cover) ödemeleri için pacs.009 COV) gönderildikten sonra değiştirilemez kabul edilir. Alıcı bankalar bu mesajların içeriğini doğrudan değiştiremez; zira SWIFT mesajları, ödeme zinciri boyunca bütünlüğü ve denetlenebilirliği koruyacak şekilde tasarlanmıştır. Bunun yerine her türlü değişiklik, düzeltme veya iptal, ayrı takip mesajları, gpi Tracker üzerinden durum güncellemeleri veya gSRP (gpi Stop and Recall Payment) gibi özel hizmetler aracılığıyla gerçekleştirilir. Bu yöntem, Benzersiz Uçtan Uca İşlem Referansı (UETR) kullanılarak uçtan uca izlenebilirliği güvence altına alır.

Alıcı bankalar (genellikle alacaklı temsilcisi veya aracı olarak hareket eden) ise gönderenin değişiklik taleplerine yanıt verebilir ya da ödeme sonucunda fiilen değişiklik doğuran işlemler (ör. iadeler veya bloke işlemleri) başlatabilir. Belirli koşullar altında gönderenden açıklama veya değişiklik de talep edebilirler. Bu süreçler SWIFT'in kural kitapları, piyasa uygulama kılavuzları (ör. Ödeme Piyasası Uygulama Grubu – PMPG) ve düzenleyici gerekliliklerle yönetilmekte olup otomasyonu, şeffaflığı ve dolandırıcılığın önlenmesini ön planda tutmaktadır.

Alıcı Bankaların Değişiklik Talep Etmesi veya Kolaylaştırması İçin Koşullar
Alıcı bankalar, orijinal ödeme talimat verildiği şekilde işleme alınamadığında değişiklik talep edebilir (örneğin bilgilerin düzeltilmesi) veya değişiklik ihtiyacına işaret eden işlemler yapabilir. Bu genellikle sorgu mesajları (örneğin MT 195/199) veya gönderici tarafından başlatılan taleplere verilen yanıtlar aracılığıyla gerçekleştirilir. Temel koşullar şunlardır:

• Ödeme Bilgilerindeki Hatalar: Hatalı lehtar hesabı (ör. kapatılmış hesap – AC04 kodu), yanlış para birimi (CURR kodu), hatalı aracı banka yönlendirmesi (AGNT kodu) veya teknik sorunlar (TECH kodu) gibi yanlışlıklar bulunması halinde alıcı banka ödemeyi beklemeye alabilir ve göndericiden düzeltilmiş bilgi sunmasını veya yeni bir ödeme göndermesini talep edebilir. Bu yöntem, doğrudan reddi önlerken sorunun çözümüne imkân tanır.
• Ödemenin Uygulanamaması: CUTA (Cancel Upon Unable to Apply) kodu uyarınca, ödeme uyuşmazlıklar nedeniyle (örn. ad/hesap uyuşmazlığı veya yetersiz bilgi) hesaba geçirilemiyorsa, alıcı banka sorunun giderilmesi için gönderenden iptal veya düzeltme ayrıntılarını talep edebilir.
• Şüpheli Dolandırıcılık veya Yetkisiz İşlemler: Dolandırıcılık (FRAD kodu) durumunda alıcı banka, sorunları bağımsız olarak tespit edebilir ve göndericiden önceden bir talep gelmeksizin fonların iadesini başlatabilir. Ayrıca, göndericinin geri çağırma taleplerine, fonları bloke ederek ve fonlar halihazırda hesaba alacak kaydedilmişse tazmin taahhüdü (INDM kodu) talep ederek yanıt verebilir; böylece iade öncesinde riski azaltır.
• Mükerrer veya Yersiz Ödemeler: DUPL (mükerrer ödeme) veya UPAY (yersiz ödeme) gibi kodlar, işlemin hatalı veya gerekçesiz olması halinde alıcı bankanın bunu işaretlemesine ve iptal talep etmesine imkân tanır.
• Düzenleyici veya Uyum Sorunları: Ödemenin yerel yasaları, yaptırımları veya AML gerekliliklerini ihlal etmesi hâlinde (LEGL kodu), alıcı banka ödemeyi reddedebilir veya bekletebilir ve göndericiden ek belge veya düzeltme talep edebilir.
• Müşteri veya Lehtar Kararları: Lehtarın ödemeyi reddetmesi hâlinde (kod CUST veya NOAS – lehtardan yanıt alınamadı), alıcı banka ödemeyi iade edebilir ve göndericiyi bilgilendirerek değişikliklerin teyit edilmesini talep edebilir.
• Bekleyen Çözümlemeler: Borçlandırma yetkisinin beklenmesi (RQDA) veya bir sonraki aracı kurumdan yanıt beklenmesi (PTNA) gibi bekleyen durumlarda (PDCR kodu), alıcı banka ödemeyi bekletebilir ve işlemin ilerlemesi için ek talimat veya değişiklik talep edebilir.

Her durumda, talepler otomasyona uygun biçimde yapılandırılmalıdır (örneğin UETR'nin, 20/32A/50/59 alanları gibi orijinal referansların ve mesajların 79. alanındaki belirli kodların eklenmesi); bu, uçtan uca otomatik işlemeyi (straight-through processing) destekler. Fonların hesaba alınması hâlinde ikili tazminat sözleşmeleri istenebilir; alıcı banka talepleri kabul etmekle yükümlü değildir, ancak acil talepleri (örneğin dolandırıcılıkla ilgili olanları) önceliklendirmek zorundadır.

İlgili Süreçler

• Gönderen Tarafından Başlatılan Geri Çağırmalara Yanıt: Gönderen (borçlu bankası) genellikle geri çağırmayı gSRP hizmeti üzerinden MT 192/292 (veya camt.056 gibi ISO 20022 karşılıkları) ile başlatır; mesaj seri olarak veya doğrudan alıcı bankaya iletilir. Alıcı banka derhal teyit etmeli ve CNCL (iptal edildi), RJCR (gerekçeyle reddedildi) veya PDCR (beklemede) gibi kodlar kullanarak MT 196/296 (veya yapılandırılmışsa MT 199/299) ile yanıt vermelidir. Kabul edilmesi hâlinde fonlar pacs.004 (Ödeme İadesi) ile iade edilir.
• Alıcı Bankaların Bağımsız Eylemleri: Dolandırıcılık dahilî olarak tespit edilirse alıcı banka, yapılandırılmış ayrıntılarla pacs.004 kullanarak fonları iade edebilir ve gerçek zamanlı durum güncellemeleri için Tracker üzerinden bildirimde bulunabilir.
• Değişiklik/Açıklama Talepleri: Alıcı bankalar, ek bilgi gibi değişiklikleri talep etmek için sorgu mesajlarını (ör. MT 195/295) kullanır. Bu durum, beklemeye alınan ödemelerde yaygındır.
• Tracker Entegrasyonu: Tüm işlemler gpi Tracker'ı gerçek zamanlı olarak günceller; bu bilgilere API'ler veya grafik arayüz üzerinden erişilebilir ve böylece tüm taraflar için görünürlük sağlanır. gpi üyeleri gCCT (Müşteri Kredi Transferi), gCOV (Cover) ve gSRP için zorunlu kural kitaplarına uymak zorundadır.
• Sınırlamalar ve Başarı Faktörleri: Değişiklik yapılacağı garanti edilmez; başarı, ödemenin hangi aşamada olduğuna (alacaklandırma öncesinde değişiklik yapmak daha kolaydır), lehtarın iş birliğine ve ilgili yargı alanına bağlıdır. Tutar lehtarın hesabına alacak kaydedilmişse, iade için lehtarın onayı veya tazminat taahhüdü gerekir. Mevzuat hükümleri her zaman yönergelere göre önceliklidir.

Bu uygulamalar öncelikle gpi üyeleri için geçerlidir; ancak gpi üyesi olmayan bankalar da ağ geçitleri aracılığıyla sürece katılabilir. En güncel ayrıntılar için SWIFT'in resmî kural kitaplarına başvurunuz; zira süreçler (örneğin ISO 20022 geçişiyle birlikte) gelişmeye devam etmektedir.

SWIFT gpi'de Mesajlaşma ve Takasın Ayrıştırılması

SWIFT gpi esas olarak mesajlaşma yoluyla ödeme talimatlarını ve izlemeyi yönetir (ör. müşteri transferleri için pacs.008, finansal kuruluş transferleri için pacs.009 gibi ISO 20022 formatları veya eski MT 103/MT 202 mesajları); ancak paranın fiilî hareketi tasfiye düzeyinde ayrıca gerçekleşir. Tasfiye genellikle muhabir bankacılık ilişkileri (nostro/vostro hesapları), ikili netleştirme veya Gerçek Zamanlı Brüt Tasfiye (RTGS) sistemleri gibi Takas ve Tasfiye Mekanizmaları (CSM) aracılığıyla gerçekleşir (ör. Avrupa'da T2 (eski adıyla TARGET2), ABD'de Fedwire veya Birleşik Krallık'ta CHAPS). gpi Tracker, mesaj durumuna ilişkin gerçek zamanlı görünürlük sağlar; ancak fon transferi bu altta yatan sistemlere dayanır.

Sınır ötesi ödeme talimatları için birlikte yürütme dönemi 22 Kasım 2025 tarihinde sona erdi: MT 103 ve MT 202 gibi ödeme talimatlarının yerini pacs.008 ve pacs.009 gibi ISO 20022 (MX) mesajları almıştır; diğer MT kategorileri ise sonraki tarihlerde kullanımdan kaldırılmaktadır. Aşağıda, iade ve bloke çözümü işlemlerinin hesap/takas/mutabakat düzeyinde nasıl gerçekleştiği açıklanmaktadır.

Paranın Hesap/Takas/Mutabakat Düzeyinde İadesi
İadeler, başarılı bir geri çağırma talebinin (gSRP – gpi Stop and Recall Payment hizmeti aracılığıyla) veya bağımsız bir tespitin (ör. dolandırıcılık, hatalar) ardından başlatılır. gSRP, gönderici tarafından iletilen camt.056 (Ödeme İptal Talebi) mesajını kullanır ve bu mesaj camt.029 (Soruşturma Çözümü) ile yanıtlanır. Talep kabul edildiğinde, fonların iadesi akışı tersine çeviren yeni bir ödeme talimatıyla gerçekleştirilir; alıcı bankanın hesabı borçlandırılır ve zincir boyunca geriye doğru alacaklandırma yapılır. Bu, orijinal mesajın değiştirilmesi değil, ayrı bir işlemdir.

Başlıca Takas Yöntemleri ve İade Süreçleri
Takas yöntemleri, iadelerin nasıl gerçekleşeceğini belirler:

• CLRG (Piyasa Altyapısı Üzerinden Takas): Bir RTGS veya CSM üzerinden (örneğin bir merkez bankası aracılığıyla) uzlaştırma. İadelerde pacs.004 kullanılır; bu mesaj, piyasa altyapısına alıcı aracı kurumun hesabını borçlandırma ve önceki aracı kurumun hesabını alacaklandırma talimatını verir ve işlem çoğunlukla gerçek zamanlı olarak ya da aynı gün içinde gerçekleşir.
• INGA (Instructing Agent Settles First): Gönderen, mesajı iletmeden önce fonları uzlaştırır. pacs.004 ile yapılan iadeler, uzlaştırma sonrasında talimat alan aracı kuruluşun hesabına borç kaydedilir.
• INDA (Instructed Agent Settles on Receipt): Alıcı, mesajı aldığı anda takası gerçekleştirir. Takas yapılmamışsa pacs.002 ile reddedilir (fon hareketi olmaz); takas yapılmışsa pacs.004 ile iade edilir.
• COVE (Cover Yöntemi): Cover transferi (pacs.009 COV) içeren yüksek tutarlı ödemeler için kullanılır. İadeler ters zincir izler: pacs.004 mesajı, lehtar bankasından aracı bankalara geri iletilir ve muhabir hesaplar buna göre borçlandırılır/alacaklandırılır.

Takas Düzeyinde Adım Adım İade Süreci

1. Başlatma ve Kabul: Gönderen taraf iade talebinde bulunur (ör. UETR ile camt.056 aracılığıyla). Alıcı taraf yanıt verir (camt.029) ve fonların mevcut olması/henüz lehtara alacak kaydedilmemiş olması halinde kabul eder (alacak kaydından önce daha kolaydır). Fonlar lehtara alacak kaydedilmişse, lehtarın onayı veya tazminat taahhüdü gerekebilir.

2. Fon İade Talimatı: Alıcı, pacs.004 (Ödeme İadesi) veya iade kodlarını (örn. RETN) içeren eski tip MT 103/MT 202 mesajı düzenler. Bu mesaj şunları içerir:

• Orijinal referanslar (UETR, End-to-End ID, Instruction ID).
• Rollerin tersine çevrilmesi: Asıl alacaklı borçlu olur; asıl borçlunun bankası alacaklı olur.
• Takas ayrıntıları: Orijinal Bankalararası Takas Tutarı/Tarihi, Döviz Kuru (döviz işlemi söz konusuysa), Masraflar (kesinti yapılmışsa).
• İade Neden Kodu (örn. kapalı hesap için AC04, dolandırıcılık için FRAD).
• Alacaklandırılacak hesabı belirtmek için Uzlaştırma Hesabı alanı (orijinal mesajda mevcutsa).

3. Uzlaştırmanın Gerçekleştirilmesi:

• pacs.004, alıcı bankanın nostro/vostro hesabından (bir önceki aracı kurum veya MI nezdinde tutulan) borç kaydını tetikler.
• Fonlar, aynı takas yöntemi (örneğin CLRG'de RTGS transferi) kullanılarak zincir boyunca adım adım geri alacak kaydedilir.
• Kısmi iade söz konusuysa, Ek Bilgiler alanında orantılı tutarla birlikte “PART” ibaresini belirtiniz.
• İzleme sistemi durumu (örneğin “İade Edildi”) gerçek zamanlı olarak günceller; durum API veya grafik arayüz üzerinden görüntülenebilir.

4. Nihai Alacaklandırma: Asıl gönderenin hesabı alacaklandırılır; çoğu zaman ücret kesintileri uygulanır. İşlem CSM üzerinden gerçekleştirilirse takas atomiktir; ikili düzenlemelerde gün sonu netleştirmesi söz konusu olabilir.

5. İade Sonrası Bildirimler: Defter güncellemelerini teyit etmek için camt.053/054 (Hesap Ekstresi/Borç-Alacak Bildirimi) kullanın. “İadenin iadesi” için ayrıca pacs.004 kullanılmaz: bunun yerine sorgu mesajları kullanılır.
İadeler mümkün olduğunda otomatik gerçekleştirilir, ancak uyum nedeniyle veya fonların bloke edilmesi halinde manuel müdahale gerekebilir. Geri alım garanti edilmez; her şeyden önce geri çağırma talebinin ne kadar hızlı gönderildiğine ve fonların halihazırda alacak kaydedilip kaydedilmediğine bağlıdır. Takas edilmemişse (örneğin takas öncesinde reddedilmişse) hiçbir fon hareketi gerçekleşmez: bunun yerine pacs.002 kullanın.

Bekletilen Ödemeler Hesap/Takas/Mutabakat Düzeyinde Nasıl Serbest Bırakılır (Onaylanır)

Bekletme durumu, bir ödemenin derhal işleme alınamaması (örneğin hatalar, uyum kontrolleri veya açıklama beklenmesi nedeniyle) ve ödemenin takas edilmeden “beklemede” durumuna alınması halinde ortaya çıkar. Sorun çözülene kadar hesaplara borç veya alacak kaydedilmez. gpi Tracker, “On Hold” veya “Pending” (örneğin PDCR kodu) gibi durumları gösterir; çözüm ise sorgu mesajları (MT 195/199 veya camt.029) aracılığıyla sağlanır.

Bloke Uygulanmasına Yol Açan Durumlar

• Uyumsuzluklar (ör. hesap/ad uyumsuzluğu – CUTA kodu).
• Düzenleyici kontroller (ör. yaptırımlar – LEGL kodu).
• Lehtarın yanıtı (NOAS kodu) veya borçlandırma yetkisi (RQDA) bekleniyor.
• Lehtar bankada çevrimdışı saatler veya toplu işlem.

Takas Düzeyinde Serbest Bırakma Süreci
1. Bekletme Bildirimi: Alıcı, beklemede durum koduyla birlikte pacs.002 (durum güncellemesi) veya MT 199 gönderir; kısmen uzlaştırılmışsa (örneğin cover yöntemlerinde) fonlar bir askı/escrow hesabında tutulur.
2. Çözüm: Gönderen, düzeltme veya açıklamaları (örneğin MT 195 yanıtı veya camt.029 aracılığıyla) iletir. Sorun giderilirse alıcı, asıl talimatı işleme alarak onay verir.
3. Takas İcrası:

• Orijinal pacs.008/pacs.009 bekletmeden serbest bırakılır.
• Fonlar, belirlenen yöntemle uzlaştırılır: Gönderenin hesabı borçlandırılır, alıcının hesabı alacaklandırılır (örneğin CLRG'deki RTGS aracılığıyla) ve ardından lehtarın hesabına nihai alacak kaydı yapılır.
• Lehtar tarafı (alıcı bankadan nihai müşteriye) gecikmelerin sıkça yaşandığı aşamadır; özellikle sermaye kontrollerinin veya sınırlı altyapının bulunduğu piyasalarda.
• İzleyici “Alacaklandırıldı” veya “Tamamlandı” olarak güncellenir; pacs.002 (Ödeme Durum Raporu) bunu teyit eder.

4. Serbest Bırakılmaması Halinde: Sorun giderilmezse (örneğin zaman aşımından sonra), yukarıda belirtildiği şekilde pacs.004 ile iade edilir veya pacs.002 ile reddedilir (takas yapılmaz).

gpi kuralları, mümkün olduğunda aynı gün hesaba alacak kaydedilmesini öngörür; Swift, 2018'de gpi ödemelerinin neredeyse %50'sinin 30 dakika içinde, neredeyse tamamının ise 24 saat içinde hesaba alacak kaydedildiğini bildirmiştir. Sermaye kontrolleri veya bankaların çevrimdışı olduğu saatler gibi etkenler bekletme sürelerini uzatabilir; ancak gpi, bunları en aza indirmek için otomasyona önem verir.

SwiftNet Instant

SwiftNet Instant. Düşük gecikme süreli, 7/24 erişilebilir ve Takas ve Uzlaşma Mekanizmaları (CSM) ile katılımcıları arasında anlık ödeme akışlarının güvenli biçimde değişimini destekleyen gerçek zamanlı bir mesajlaşma platformudur.

Müşteriler, VPN cihazları, kiralık hatlar ve donanım güvenlik modülleri dahil olmak üzere mevcut Swift bağlantı ve güvenlik altyapıları üzerinden SwiftNet Instant'a bağlanabilir. Bankanın BT ortamıyla entegrasyon, Alliance Gateway Instant (AGI) aracılığıyla sağlanır.

Anlık ödeme zincirindeki tüm taraflar AGI ve SwiftNet Instant mesajlaşmasını kullanabilir. Uygulamalar arasında bir bindirme (overlay) hizmetinden ödeme başlatma, sponsor bir üyeyle dolaylı üye iletişimi veya bir kurumsal müşterinin ödeme teyidi alması yer almaktadır.

SWIFT Instant, ISO 20022 standardını kullanarak yurt içi anlık ödeme sistemleriyle bağlantı kurar ve işlemlerin hem yurt içinde hem de uluslararası düzeyde gerçek zamanlı olarak işlenmesini sağlar. Bu sistemler, finans sektöründe ödeme süreçlerini modernize etme ve basitleştirme yönündeki sürekli çabaları temsil etmektedir.

SWIFT Doğrudan Borçlandırma

SWIFT sistemindeki doğrudan borçlandırma (direct debit), işletmelerin ve bireylerin birden çok para biriminde ve farklı ülkelerdeki borçlu banka hesaplarından fon tahsil etmesine olanak tanıyan bir ödeme yöntemidir. Özellikle SEPA bölgesi için tasarlanmış ve yalnızca euro cinsi işlemlerle sınırlı olan SEPA Direct Debit'ten farklı olarak, SWIFT'teki doğrudan borçlandırma küresel kapsama sahiptir ve çok çeşitli para birimlerini destekler.

SWIFT sistemi içinde bir doğrudan borçlandırma işleminin başlatılması süreci tipik olarak aşağıdaki adımları içerir:

1. Alacaklı ile borçlu arasındaki anlaşma: Alacaklı ve borçlu arasında, doğrudan borçlandırma işlemlerine ilişkin hüküm ve koşulları içeren önceden kurulmuş bir anlaşma bulunmalıdır. Bu anlaşma, alacaklının borçlunun banka hesabından tahsilat yapmasına imkân tanıyan bir talimat veya yetkilendirmenin tesisini de içerebilir.
2. Mesaj iletimi: Alacaklının bankası, borçlunun bankasına bir SWIFT mesajı göndererek otomatik ödeme talimatını başlatır; ISO 20022'de bu mesaj pacs.003 (müşteri otomatik ödeme talimatı) veya pacs.010 (finansal kuruluş otomatik ödeme talimatı), önceki adlandırmayla MT 104 veya MT 204'tür. Bu mesaj, tutar, para birimi, borçlunun hesap bilgileri ve gerekli diğer bilgiler gibi işleme ilişkin ayrıntıları içerir.
3. Doğrulama ve yetkilendirme: Borçlunun bankası işlem ayrıntılarını doğrular, borçlunun hesabındaki fonların yeterliliğini kontrol eder ve işlemin yetkilendirildiğini teyit eder. Her şey usulüne uygunsa, borçlunun bankası ilgili tutarı borçlunun hesabına borç kaydeder.
4. Fon transferi: Fonlar, borçlunun bankası ile alacaklının bankası arasında muhabir hesaplar veya bir takas ve mutabakat sistemi aracılığıyla mutabakata bağlanır.
5. Teyit: Alacaklının bankası, fonları aldıktan sonra alacaklıya, otomatik ödeme (direct debit) işleminin başarıyla gerçekleştiğini bildiren bir teyit mesajı gönderir.

SWIFT sisteminde bir otomatik ödeme (direct debit) işlemini başlatmanın ön koşulları şunlardır:

1. Banka hesapları: Hem alacaklı hem de borçlu, SWIFT ağına dahil finansal kuruluşlarda banka hesabı bulundurmalıdır.
2. Mutabakat ve yetkilendirme: Doğrudan borçlandırma işlemlerinin yapılabilmesi için alacaklı ile borçlu arasında önceden mevcut bir mutabakat ve yetkilendirme (talimat) bulunmalıdır.
3. SWIFT mesaj formatları: Alacaklı ve bankası uygun mesaj formatlarını kullanmalıdır: doğrudan borçlandırmayı başlatmak için pain.008, bankalar arasında ise pacs.003 veya pacs.010.
4. Banka ücretleri: Alacaklı ve borçlu, SWIFT sistemi içindeki otomatik ödeme işlemleriyle ilişkili ve ilgili bankalara ve ülkelere göre değişebilen ücretlerden haberdar olmalıdır.

Bankalararası SWIFT Mesajlaşmasında RMA

Bankacılık ve finansta bankalar arasında güvenli ve verimli iletişim zorunludur. SWIFT (Society for Worldwide Interbank Financial Telecommunication), uluslararası bankalar arası mesajların büyük çoğunluğunu taşıyarak bu noktada kritik bir rol oynar. Bu iletişimin güvenliğini ve seçiciliğini sağlayan temel unsur ise İlişki Yönetimi Uygulaması'dır (RMA).

RMA nedir?

İlişki Yönetimi Uygulaması (RMA), finansal kuruluşların hangi muhataplarının kendilerine SWIFT mesajı gönderebileceğini tanımlamasına olanak tanıyan ve SWIFT ağı iletişiminin yalnızca kimliği doğrulanmış kullanıcılarla sınırlı kalmasını sağlayan bir SWIFT yazılım uygulamasıdır. RMA, yetkisiz mesajları filtrelediği ve sahtecilik riskini azalttığı için bankalar arası iletişimin yönetiminde temel bir güvenlik katmanıdır.

RMA’nın Önemi

IFB gibi uluslararası finans alanında faaliyet gösteren bankalar için RMA aracı vazgeçilmezdir. Bu araç yalnızca güvenlik protokollerini güçlendirmekle kalmaz, aynı zamanda küresel bankacılık düzenlemelerine uyumu da güvence altına alır. Hangi kuruluşların kendilerine mesaj gönderebileceğini yöneten bankalar, yetkisiz bilgi taleplerinin ve finansal talimatların önüne geçerek hem kendi menfaatlerini hem de müşterilerinin menfaatlerini korur.

RMA Nasıl İşler

RMA süreci birkaç temel adımdan oluşur:

1. RMA İlişkilerinin Kurulması: İki banka SWIFT üzerinden bilgi alışverişine başlamadan önce, bir RMA kurulması konusunda karşılıklı olarak anlaşmalıdır. Bu anlaşma, güveni ve iletişim kurmaya yönelik rızayı ifade eden dijital bir el sıkışmaya benzer.
2. Anahtar Değişimi: Her banka, RMA uygulaması aracılığıyla bir RMA yetkilendirmesi gönderir ve karşı taraf bunu kabul eder. RMA, daha önceki ikili anahtar değişiminin (BKE) yerini almıştır; mesajların kendisi SWIFTNet PKI (Açık Anahtar Altyapısı) aracılığıyla doğrulanır.
3. RMA Ayarlarının Yapılandırılması: Her banka, RMA aracını kullanarak yetkileri yapılandırır ve diğer bankadan hangi mesaj türlerinin kabul edileceğini belirler. Bu yapılandırma genel kategoriler düzeyinde yapılabileceği gibi, belirli mesaj türlerini ve alt sınıfları içerecek şekilde ayrıntılı olarak da ayarlanabilir.
4. Etkinleştirme ve İzleme: RMA ayarları yapılandırılıp etkinleştirildikten sonra bankalar, gelen mesajları oluşturulan yetkilere uygunluk açısından izleyebilir. RMA ayrıca, iş ihtiyaçları veya güvenlik kaygıları gerektirdiğinde yetkileri değiştirmek veya iptal etmek için araçlar sunar.

Uygulama Alanları

Yüksek net değerli bireylere ve kurumsal yapılara yönelik yatırım ve varlık yönetiminde uzmanlaşmış olan IFB için RMA çeşitli yararlar sağlamaktadır:

• Gelişmiş Güvenlik: Mesaj trafiğini kontrol ederek IFB, müşteri işlemlerini ve hassas bilgileri yetkisiz erişime karşı güvence altına alabilir.
• Operasyonel Verimlilik: Güvenilir kurumlarla yürütülen kolaylaştırılmış iletişim, meşru mesajların daha hızlı işlenmesini sağlayarak yanıt sürelerini ve müşteri memnuniyetini artırır.
• Mevzuata Uyum: RMA, kara para aklama ve dolandırıcılık gibi mali suçları önlemek amacıyla bilgi alışverişinin sıkı biçimde kontrol edilmesini zorunlu kılan uluslararası bankacılık düzenlemelerine uyuma katkı sağlar.

RMA ve MT799. Bankalar, kanal izin verdiği takdirde bir RMA ilişkisi talep etmek veya koordine etmek için MT799 kullanabilir. RMA yetkisinin kendisi RMA sisteminde verilir; tek başına bir MT799 hiçbir izni etkinleştirmez. MT799 için gereken RMA yetkisinin bulunmadığı durumlarda, doğrudan MT799 gönderilerek bu eksiklik aşılamaz. Bu durumda düzenleme, yetkiler karşılıklı olarak tesis edilmeden önce karşı taraflarla koordinasyon sağlamak üzere tasarlanmış olan Swift İlişki Yönetimi Portalı'nın RMA iletişim özelliği üzerinden veya izin verilen başka bir kanal aracılığıyla kararlaştırılır. Dolayısıyla “MT799 ile RMA” ifadesi eşlik eden banka yazışmasını tanımlayabilir; teknik RMA yetkisi ise ayrı bir adımdır.

Özetle

IFB için RMA'nın etkin biçimde uygulanması yalnızca teknik bir gereklilik değil, aynı zamanda küresel faaliyetlerinde stratejik bir varlıktır. Bu uygulama, bankanın güvenliğe ve düzenleyici uyuma olan bağlılığını pekiştirirken iletişim ağlarının verimliliğini de artırır. Uluslararası finans ortamı gelişmeye devam ederken RMA gibi araçlar, operasyonel bütünlük ve müşteri hizmetinde en yüksek standartları korumaya kararlı bankaların vazgeçilmez araçları olmayı sürdürmektedir.

RMA'lar, güvenli ve seçici bankalararası iletişimin omurgasını oluşturur ve SWIFT ağı üzerinden değiş tokuş edilen her mesajın en yüksek güvenlik standartlarına uygun ve tam olarak doğrulanmış olmasını sağlar. IFB gibi bankalar için RMA'ları anlamak ve yönetmek, operasyonlarını korumak ve küresel iş ortaklarıyla güven oluşturmak açısından büyük önem taşır.

Swift Dijital Blokzincir Finansal Talimatları

Eylül 2025'te Swift, 30'dan fazla finansal kurumla birlikte ortak bir dijital defterin tasarımına ve geliştirilmesine başladığını duyurmuştur. Swift, 9 Temmuz 2026'da defterin ilk kullanıma hazır olduğunu açıklamış; 17 banka, tokenleştirilmiş mevduat işlemlerinin canlı pilot uygulamasına hazırlanmaktadır: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB ve Wells Fargo. İlk uygulama, bankalar arasında gerçek zamanlı, 7/24 sınır ötesi talimatların iletilmesini mümkün kılmaya odaklanacaktır; bu, uluslararası işlem süreçlerinin altyapısı açısından kritik bir iyileştirmedir.

İlk kavramsal prototip Consensys ile geliştirilmiştir. Defter, kurumlar arasındaki finansal talimatların güvenli, değiştirilemez ve gerçek zamanlı bir kaydı olarak tasarlanmıştır. İşlem mesajlarını kaydedecek, sıralayacak ve doğrulayacak; operasyonel ve uyum kurallarını ise akıllı sözleşmeler aracılığıyla uygulayacaktır. Birlikte çalışabilirlik temel bir ilkedir: defter, Swift'in ayırt edici özelliği olan dayanıklılığı, güveni ve düzenleyici uyumu koruyarak hem mevcut hem de gelişmekte olan altyapılarla bağlantı kuracaktır.

Swift Genel Müdürü Javier Pérez-Tasso şu açıklamada bulunmuştur:
“Ortak bir defterin Swift'in mevcut mesajlaşma, API'ler ve ISO 20022 altyapısıyla birleştirilmesi, riskleri, kontrolleri ve uyum gerekliliklerini baştan itibaren işlem akışlarına entegre edebilen, aynı zamanda Swift'in tanındığı güven, güvenlik, dayanıklılık, ölçeklenebilirlik ve operasyonel mükemmellikle 7/24 gerçek zamanlı bankalararası sınır ötesi talimatlara imkân tanıyan daha da güçlü bir yapı ortaya koymaktadır. Bunların tümü, her zaman benimsediğimiz sorumlu inovasyon yaklaşımı doğrultusundadır.”

Altyapının Genişletilmesi

Paylaşılan defter, Swift'in mevcut altyapılarını tamamlar; onların yerini almaz. Finansal kuruluşların talimatları daha hızlı, daha öngörülebilir biçimde ve gerçek anlamda küresel ölçekte iletebilmesini sağlamak üzere orkestrasyonu ve birlikte çalışabilirliği genişletmek için tasarlanmıştır.

Sibos'ta Pérez-Tasso bu çift hatlı yaklaşımın altını çizdi:
“Finansal altyapılar, operasyonel mükemmellik, düzenleyici uyum ve yönetişimin temel unsurlarına durmaksızın odaklanmalıdır. Aynı zamanda geleceğe de hazırlanmaları gerekir. Swift olarak yaklaşımımız, iki paralel hatta yenilik yapmaktır.”

Sektör Genelinde İş Birliği

16 ülkeden finansal kuruluşlar, ortak defterin tasarımını, yönetişimini ve gelişim yol haritasını şekillendirme sürecine en baştan dahil olmuştur. Bu ortak çaba, bankalar arası talimatlara yönelik küresel altyapının geliştirilmesinin ölçek ve iş birliği gerektirdiği yönündeki ortak kanaati ortaya koymaktadır.

İleriye Bakış

Ortak defter, Swift'in daha önceki dijital varlık denemelerinin doğal bir devamıdır ve hem kamusal hem de özel ağlar arasında birlikte çalışabilirliğe yönelik daha geniş taahhüdün bir parçasıdır. Bu sayede düzenlemeye tabi tokenleştirilmiş değerler ile geleneksel enstrümanlar sistemler arasında sorunsuz biçimde dolaşabilecektir.

Pérez-Tasso vizyonu şöyle özetledi:
“Bu, gelecek için güçlü bir platformdur. Ve gelecekte daha da dönüştürücü olabilir.”

Sıkça Sorulan Sorular

Swift blokzincir tabanlı ortak defter nedir?
Kurumlar arasında finansal talimatların ortak ve gerçek zamanlı bir kaydını sunan, kesintisiz ve mevzuata uygun sınır ötesi işlemeyi mümkün kılan bir blokzincir altyapısıdır.

Kimler için?
Dijital geleceğe hazırlanırken daha hızlı ve daha şeffaf işlem talimatları sunması gereken bankalar ve finansal kuruluşlar.

Faydaları nelerdir?

• Talimatların gerçek zamanlı görünürlüğü ve sıralanması
• Akıllı sözleşmeler aracılığıyla otomatik uyum
• Geleneksel ve dijital ağlar arasında birlikte çalışabilirlik
• Düzenlemeye tabi tokenleştirilmiş değer akışlarının güvenli şekilde yönetilmesi

Swift’in platformuna nasıl uyum sağlar?
Swift’in güvenilir altyapısını genişleterek dijital talimat verme yeteneklerini bünyesine katar; bu sırada dayanıklılığı, güvenliği ve uyumu korur.

İlk kullanım alanı nedir?
Gerçek zamanlı, 7/24 sınır ötesi bankalar arası işlem talimatları.

Kimler yer alıyor?
16 ülkeden 30'dan fazla finansal kuruluş tasarımın şekillenmesine katkıda bulundu; 17 banka ilk canlı işlemleri pilot olarak yürütmektedir.

Ne zaman kullanıma sunulacak?
Swift, defteri 9 Temmuz 2026 tarihinde ilk kullanıma hazır ilan etmiştir. Pilot bankalar, kontrollü bir canlıya geçiş aşamasında ilk canlı işlemlerini gerçekleştirmektedir; nihai mutabakat halen mevcut sistemler üzerinden yürütülmektedir. İşlevsellik ve erişilebilirlik sonraki aşamada genişletilecektir.

Fonların muhabir bankacılık sistemi üzerinden nasıl aktarılacağı hakkında daha fazla bilgi almak isterseniz, lütfen Muhabir Bankacılık Müdürümüz M. Amri Elarisse ile iletişime geçin.