ISO 20022 dan JSON, menyeimbangkan standardisasi dan fleksibilitas dalam API

Meningkatnya adopsi ISO 20022 dan meningkatnya permintaan akan API telah menyebabkan banyak inovasi di Industri Keuangan. Namun, standar data yang kaya dari ISO 20022 dapat berbenturan dengan kesederhanaan dan minimalis yang didorong oleh JSON, format data de facto yang digunakan dalam API. Masalah ini berpotensi menghambat industri dalam merealisasikan manfaat yang dapat diberikan oleh ISO 20022.

Dalam artikel ini, kami membahas masalah yang dihadapi pengembang dan industri saat mencoba menyelaraskan fleksibilitas dan kesederhanaan JSON dengan kekayaan data ISO 20022. Kami juga akan melihat upaya-upaya yang sedang berlangsung untuk mengatasi masalah penting ini.

ISO 20022 adalah standar global untuk pertukaran data antara lembaga keuangan dan mencakup domain pembayaran, valuta asing, kartu, pembiayaan perdagangan, dan sekuritas. Standar ini kaya, terstruktur, dan fleksibel sehingga menjadikannya sebuah lompatan besar dari standar global sebelumnya, ISO 15022 (Format MT SWIFT) dan ISO 8583 (digunakan untuk pembayaran kartu dan pembayaran antar rekening).

Telah ada upaya bersama di seluruh industri untuk mendorong adopsi ISO 20022 karena manfaatnya sangat jelas ketika semua orang menggunakannya. Laju perubahan ini semakin cepat dengan semakin banyaknya inisiatif yang beralih - dengan banyak Automated Clearing Houses (ACH) di seluruh dunia yang kini menggunakan format baru untuk pembayaran bernilai tinggi dan rendah, serta sistem Pembayaran Lintas Batas SWIFT. Penggunaannya belum ada di mana-mana, dengan beberapa sistem yang mendukung format lama terutama untuk pembayaran massal, namun, untuk sistem pembayaran waktu nyata lokal, penggunaan ISO 20022 tersebar luas.

Ruang lingkup ISO 20022 berfokus pada pertukaran informasi, tetapi manfaat utamanya berasal dari institusi yang menggunakan Kamus Data yang terbuka di tab baru untuk mendukung model data internal mereka, yang pada intinya, mengadopsi bahasa yang sama. Hal ini berarti, misalnya, bahwa atribut yang membentuk suatu Pihak (Nama, Alamat, Tanggal dan Tempat Lahir, dll.) konsisten ketika Pihak tersebut adalah Debitur dalam transaksi lintas batas atau Pemilik Rekening dalam Permintaan Pengalihan Rekening.

ISO 20022, sebagai sebuah standar, adalah format agnostik tetapi skema pesan tertentu hanya secara resmi diterbitkan sebagai XSD (Definisi Skema XML) dan tersedia dari katalog pesan yang terbuka di tab baru, hal ini menyebabkan XML menjadi format yang paling banyak digunakan untuk bertukar pesan ISO 20022.

Seiring dengan meningkatnya penggunaan ISO 20022, permintaan akan kasus penggunaan baru dan cara-cara baru untuk bertukar data, dengan contoh yang menonjol adalah API yang digunakan oleh lembaga keuangan untuk berbagai aplikasi seperti memungkinkan Access ke informasi akun, inisiasi pembayaran, Open Banking, atau integrasi sistem internal.

Pengembang API, terutama ketika merancang REST API1, sering kali mengambil pendekatan minimalis, memprioritaskan efisiensi dan hanya mengirimkan data penting yang diperlukan untuk permintaan dan respons tertentu. Informasi yang dipertukarkan melalui API biasanya dikirim dalam JSON (JavaScript Object Notation), yang mirip dengan XML tetapi memiliki beberapa ketidaksesuaian.

Karena ISO 20022 tidak mempublikasikan Skema JSON dan saat ini tidak ada aturan yang diikuti secara umum tentang cara merepresentasikannya dalam format ini2, hal ini dapat menjadi tantangan bagi para pengembang API yang ingin menggunakan standar ini.

ISO 20022 mendukung kasus penggunaan pesan keuangan secara global, yang berarti bahwa setiap pesan akan mencakup banyak elemen. Meskipun elemen-elemen kunci yang diperlukan untuk melaksanakan pertukaran pesan bisnis tertentu, misalnya transfer kredit, tetap konsisten (Nama Debitur, Nama Kreditur, Jumlah, Mata Uang, dll.), namun terdapat variasi dalam cara elemen-elemen ini digunakan. Sebagai contoh, di lembaga kliring lokal, Agen Debitur (Bank Debitur) di Jerman didefinisikan menggunakan BIC (Kode Pengenal Bisnis) atau Bankleitzahl (BLZ - berasal dari IBAN), tetapi di Australia diidentifikasi menggunakan Nomor BSB (Bank State Branch).

Untuk mengakomodasi hal ini, pesan ISO 20022 disusun sedemikian rupa sehingga Anda dapat menyediakan salah satu atau keduanya, tetapi fleksibilitas ini menyebabkan pesan yang lebih besar daripada yang diperlukan untuk kasus penggunaan tertentu.

Ketika pengembang mendesain API, dengan penekanan pada minimalis, mereka sering kali hanya akan menyertakan elemen-elemen yang spesifik untuk kasus penggunaan mereka, misalnya, jika mereka berada di Inggris, tidak banyak alasan untuk menyertakan Nomor BSB, karena semua Agen akan diidentifikasi dengan Kode Urutan. Demikian pula, jika Agen hanya dapat diidentifikasi dengan Kode Urutan, lalu mengapa menyertakan beberapa struktur pesan ISO 20022 ketika nama elemen dapat diubah, contoh berikut menyoroti hal ini:

Berikut adalah tampilan Kode Urutan Inggris dan Nomor Akun dalam contoh ISO 20022 berbasis XML:

</CdtrAcct>

    <CdtrAgt> 

        <FinInstnId> 

            <ClrSysMmbId> 

                <ClrSysId> 

                    <Cd>GBDSC</Cd> 

                </ClrSysId> 

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

    </CdtrAgt> 

    <CdtrAcct> 

        <Id> 

            <Othr> 

                <Id>21325698</Id> 

            </Othr> 

        </Id> 

    </CdtrAcct> 

Kode "GBDSC" mendefinisikan bahwa ID Anggota adalah "Kode Sortir Domestik Inggris", sedangkan Id/Lainnya berisi Nomor Rekening.

Sebagai perbandingan, berikut ini adalah bagaimana data yang sama akan ditransmisikan melalui API Open Banking Inggris, yang 'dirancang menggunakan elemen dan komponen pesan ISO 20022 jika tersedia'3, perhatikan ukurannya yang lebih kecil tetapi juga perubahan nama elemen, kode, dan struktur:

"Akun Kreditur": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Identifikasi": "08080021325698"
}

Masalah ini tidak spesifik untuk UK Open Banking dan terjadi di seluruh industri, dengan API berbasis ISO 20022 yang diimplementasikan tanpa panduan yang jelas tentang praktik terbaik atau Skema JSON resmi yang diterbitkan. Risiko fragmentasi pendekatan menjadi tinggi, yang menyebabkan ketidakcocokan antara implementasi dan tidak tercapainya beberapa manfaat yang ingin dicapai oleh standardisasi. Industri ini telah mengidentifikasi risiko ini dan ISO 20022 telah mengambil beberapa langkah untuk memitigasinya:

• API SEG (Grup Evaluasi Standar) terbuka di tab baru didirikan untuk mendaftarkan, mengembangkan, dan memelihara sumber daya API.
• ISO/TC 68/WG4 (Komite Teknis 68/Kelompok Kerja 4), kelompok yang bertanggung jawab untuk mengelola/memperbaharui standar ISO 20022, telah menyelidiki cara mengubah standar untuk memformalkan pengenalan sumber daya ISO 20022 berbasis JSON serta memperkenalkan templat untuk membantu pemodel yang ingin mendaftarkan format yang berbeda untuk standar yang akan diterbitkan (yaitu Skema JSON).
• Kelompok Dukungan Teknis ISO 20022 (TSG) terbuka di tab baru sedang berupaya memperbarui dan merevisi Whitepaper praktik terbaik JSON mereka (direferensikan di bagian footer) untuk memberikan panduan lebih lanjut tentang pemodelan JSON.

Karena industri keuangan terus berkembang, standardisasi dan interoperabilitas yang berkelanjutan sangatlah penting. Adopsi pesan berbasis JSON adalah pendorong utama untuk inovasi, tetapi juga menimbulkan potensi jebakan yang perlu diwaspadai oleh industri. Jika tidak, maka akan menghadapi risiko membatalkan banyak pekerjaan menantang yang telah dilakukan sebelumnya.

Mastercard secara aktif terlibat dalam inisiatif ini dan akan terus berkolaborasi dengan industri untuk mendorong kerangka kerja yang memungkinkan adopsi format baru sambil mempertahankan standarisasi dan interoperabilitas yang penting untuk inovasi masa depan.