ISO 20022 ve JSON, API'lerde standardizasyon ve esnekliği dengeleme

ISO 20022'nin giderek daha fazla benimsenmesi ve API'lere yönelik artan talep, Finans Sektöründe pek çok yeniliğe yol açmıştır. Ancak ISO 20022'nin zengin veri standartları, API'lerde kullanılan fiili veri formatı olan JSON'un teşvik ettiği basitlik ve minimalizm ile çatışabilir. Bu sorun, sektörün ISO 20022'nin sağlayabileceği faydaları gerçekleştirmesini engelleme potansiyeline sahiptir.

Bu makalede, JSON'un esnekliği ve basitliği ile ISO 20022'nin veri zenginliğini uzlaştırmaya çalışan geliştiricilerin ve sektörün karşılaştığı sorunları inceliyoruz. Ayrıca bu önemli konuyu ele almaya yönelik devam eden çabalara da bir göz atacağız.

ISO 20022, finansal kurumlar arasında veri alışverişi için küresel bir standarttır ve ödemeler, döviz, kartlar, ticaret finansmanı ve menkul kıymetler alanlarını kapsar. Standart zengin, yapılandırılmış ve esnektir, bu da onu önceki küresel standartlar olan ISO 15022 (SWIFT'in MT Formatı) ve ISO 8583'ten (kart ödemeleri ve hesaptan hesaba ödemeler için kullanılır) büyük bir sıçrama yapar.

ISO 20022'nin benimsenmesi için sektör genelinde yoğun bir çaba sarf edilmektedir, zira faydalar en belirgin şekilde herkes tarafından kullanıldığında ortaya çıkmaktadır. Daha fazla girişimin geçiş yapmasıyla birlikte bu değişimin hızı artmıştır - dünya genelinde birçok Otomatik Takas Odası (ACH) artık yüksek ve düşük değerli ödemeler için yeni formatı ve SWIFT'in Sınır Ötesi Ödemeler sistemini kullanmaktadır. Kullanımı henüz yaygın değildir, bazı sistemler özellikle toplu ödemeler için eski formatları desteklemektedir, ancak yerel gerçek zamanlı ödeme sistemleri için ISO 20022 kullanımı yaygındır.

ISO 20022'nin kapsamı bilgi alışverişine odaklanır, ancak temel fayda, kurumların Veri Sözlüğü 'nü kullanmalarından geliryeni bir sekmede açılır kendi iç veri modellerini desteklemek için, özünde ortak bir dil benimsemek. Bu, örneğin, bir Tarafı oluşturan niteliklerin (Ad, Adres, Doğum Tarihi ve Yeri, vb.), Taraf sınır ötesi bir işlemde Borçlu veya Hesap Değiştirme Talebinde Hesap Sahibi olduğunda tutarlı olması anlamına gelir.

ISO 20022 bir standart olarak formattan bağımsızdır, ancak belirli mesaj şemaları yalnızca resmi olarak XSD'ler (XML Şema Tanımları) olarak yayınlanır ve mesaj kataloğundan edinilebiliryeni bir sekmede açılır, bu da XML'in ISO 20022 mesajlarını değiştirmek için en yaygın kullanılan format olmasına yol açmıştır.

ISO 20022'nin kullanımı arttıkça, yeni kullanım alanlarına ve veri alışverişi için yeni yollara olan talep de artmaktadır. Bunun en önemli örneği, finans kurumları tarafından hesap bilgilerine erişim, ödemelerin başlatılması, Açık Bankacılık veya dahili sistem entegrasyonları gibi çok sayıda uygulama için kullanılan API'lerdir.

API geliştiricileri, özellikle REST API'leri1 tasarlarken, genellikle minimalist bir yaklaşım benimser, verimliliğe öncelik verir ve yalnızca belirli bir istek ve yanıt için gereken temel verileri iletir. API aracılığıyla değiş tokuş edilen bilgiler genellikle XML gibi olan ancak bazı küçük uyumsuzlukları olan JSON (JavaScript Object Notation) ile gönderilir.

ISO 20022 JSON Şemalarını yayınlamadığından ve şu anda bu formatta nasıl temsil edileceğine dair yaygın olarak takip edilen kurallar olmadığından2 bu, standardı kullanmayı uman API geliştiricileri için zorluklar yaratabilir.

ISO 20022, finansal mesajlaşma kullanım durumlarını küresel olarak destekler, bu da her mesajın birçok öğe içereceği anlamına gelir. Örneğin bir kredi transferi gibi belirli bir iş mesajı alışverişini yürütmek için gerekli temel unsurlar oldukça tutarlı kalırken (Borçlu Adı, Alacaklı Adı, Tutar, Para Birimi vb.), bu unsurların kullanım biçiminde farklılıklar vardır. Örneğin, yerel takas odalarında Almanya'daki bir Borçlu Temsilcisi (Borçlunun Bankası) bir BIC (İşletme Tanımlayıcı Kodu) veya bir Bankleitzahl (BLZ - IBAN'dan türetilmiştir) kullanılarak tanımlanır, ancak Avustralya'da bir BSB Numarası (Banka Eyalet Şubesi) kullanılarak tanımlanır.

Buna uyum sağlamak için ISO 20022 mesajları, birini veya diğerini sağlamanıza izin verecek şekilde yapılandırılmıştır, ancak bu esneklik, herhangi bir kullanım durumu için kesinlikle gerekli olandan daha büyük mesajlara yol açar.

Geliştiriciler API'leri tasarlarken, minimalizme vurgu yaparak, genellikle yalnızca kullanım durumlarına özgü unsurları dahil edeceklerdir; örneğin, Birleşik Krallık'talarsa, BSB Numarasını dahil etmek için çok az neden vardır, çünkü tüm Acenteler bir Sıralama Kodu ile tanımlanacaktır. Benzer şekilde, bir Aracı yalnızca Sıralama Kodu ile tanımlanabiliyorsa, öğe adı değiştirilebilecekken neden ISO 20022 mesajının yapısının bir kısmı dahil edilsin, aşağıdaki örnek bunu vurgulamaktadır:

Birleşik Krallık Sıralama Kodu ve Hesap Numarası XML tabanlı bir ISO 20022 örneğinde bu şekilde görünecektir:

</CdtrAcct>

    <CdtrAgt> 

        <FinInstnId> 

            <ClrSysMmbId> 

                <ClrSysId> 

                    <Cd>GBDSC</Cd> 

                </ClrSysId> 

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

    </CdtrAgt> 

    <CdtrAcct> 

        <Id> 

            <Othr> 

                <Id>21325698</Id> 

            </Othr> 

        </Id> 

    </CdtrAcct> 

"GBDSC" kodu, Üye Kimliğinin bir "Birleşik Krallık Yurtiçi Sıralama Kodu" olduğunu tanımlar, Id/Diğer/Id ise Hesap Numarasını içerir.

Karşılaştırmalı olarak, aynı verilerin 'mevcut olduğu yerlerde ISO 20022 mesaj öğeleri ve bileşenleri kullanılarak tasarlanan'3 Birleşik Krallık Açık Bankacılık API'leri aracılığıyla nasıl iletileceği aşağıda gösterilmektedir; daha küçük boyuta ve aynı zamanda öğe adları, kodları ve yapısındaki değişikliğe dikkat edin:

"CreditorAccount": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Tanımlama": "08080021325698"
}

Bu sorun Birleşik Krallık Açık Bankacılığına özgü değildir ve ISO 20022 tabanlı API'lerin en iyi uygulamalara ilişkin net kılavuzlar veya resmi JSON Şemaları yayınlanmadan uygulanmasıyla sektör genelinde meydana gelmektedir. Yaklaşımın parçalanması riski yüksektir, bu da uygulamalar arasında uyumsuzluğa ve standardizasyonun elde etmeyi amaçladığı bazı faydaların gerçekleştirilememesine yol açar. Sektör bu riski tespit etmiş ve ISO 20022 bu riski azaltmak için bazı adımlar atmıştır:

• API SEG (Standartları Değerlendirme Grubu)yeni bir sekmede açılır API kaynaklarını kaydetmek, geliştirmek ve korumak için kurulmuştur.
• ISO 20022 standardının yönetiminden/güncellenmesinden sorumlu grup olan ISO/TC 68/WG4 (Teknik Komite 68/Çalışma Grubu 4), JSON tabanlı ISO 20022 kaynaklarının tanıtımını resmileştirmek için standardın nasıl değiştirileceğini ve standardın yayınlanması için farklı formatları kaydetmek isteyen modelcilere yardımcı olacak bir şablonun nasıl sunulacağını araştırmaktadır (örn. JSON Şeması).
• ISO 20022 Teknik Destek Grubu (TSG)yeni bir sekmede açılır JSON modelleme konusunda daha fazla rehberlik sağlamak için JSON en iyi uygulamaları Beyaz Bültenini (altbilgide referans verilmiştir) güncellemek ve revize etmek istiyor.

Finans sektörü gelişmeye devam ettikçe, standardizasyon ve birlikte çalışabilirliğin sürdürülmesi çok önemlidir. JSON tabanlı mesajlaşmanın benimsenmesi inovasyon için önemli bir kolaylaştırıcıdır, ancak aynı zamanda sektörün farkında olması gereken potansiyel tuzakları da beraberinde getirmektedir. Aksi takdirde, daha önce yapılan pek çok zorlu işi geri alma riskiyle karşı karşıya kalır.

Mastercard bu girişimlerde aktif olarak yer almaktadır ve gelecekteki yenilikler için gerekli olan standardizasyon ve birlikte çalışabilirliği korurken yeni formatların benimsenmesine olanak tanıyan bir çerçeveye doğru ilerlemek için sektörle işbirliği yapmaya devam edecektir.