ISO 20022 és JSON, a szabványosítás és a rugalmasság egyensúlya az API-kban

Az ISO 20022 egyre szélesebb körű elfogadása és az API-k iránti megnövekedett igény sok újítást eredményezett a pénzügyi ágazatban. Az ISO 20022 gazdag adatszabványai azonban ütközhetnek az API-kban használt de facto adatformátum, a JSON által ösztönzött egyszerűséggel és minimalizmussal. Ez a probléma akadályozhatja az iparágat abban, hogy kihasználja az ISO 20022 által nyújtott előnyöket.

Ebben a cikkben azokat a problémákat vizsgáljuk, amelyekkel a fejlesztők és az iparág szembesül, amikor megpróbálják összeegyeztetni a JSON rugalmasságát és egyszerűségét az ISO 20022 adatgazdagságával. Megvizsgáljuk azokat a folyamatban lévő erőfeszítéseket is, amelyek megpróbálják kezelni ezt a fontos kérdést.

Az ISO 20022 a pénzügyi intézmények közötti adatcserére vonatkozó globális szabvány, amely a fizetések, a deviza, a kártyák, a kereskedelem finanszírozása és az értékpapírok területére terjed ki. A szabvány gazdag, strukturált és rugalmas, ami nagy előrelépést jelent a korábbi globális szabványokhoz, az ISO 15022-hez (a SWIFT MT formátumához) és az ISO 8583-hoz (amelyet a kártyás fizetésekhez és a számla-számla közötti fizetésekhez használnak) képest.

Az egész iparágban összehangolt erőfeszítéseket tettek az ISO 20022 elfogadásának előmozdítására, mivel az előnyök akkor a legnyilvánvalóbbak, ha mindenki használja. A változás üteme felgyorsult, mivel egyre több kezdeményezés váltott át - világszerte számos automatizált elszámolóház (ACH) használja már az új formátumot a nagy és kis értékű fizetésekhez, valamint a SWIFT határokon átnyúló fizetési rendszeréhez. Használata még nem mindenütt elterjedt, egyes rendszerek támogatják a régi formátumokat, különösen a tömeges fizetések esetében, azonban a helyi valós idejű fizetési rendszerek esetében az ISO 20022 használata széles körben elterjedt.

Az ISO 20022 alkalmazási köre az információcserére összpontosít, de a legfontosabb előnye az, hogy az intézmények az adatszótárat új lapon nyílik meg belső adatmodelljeik támogatására használják, lényegében közös nyelvet alkalmazva. Ez például azt jelenti, hogy a felet alkotó attribútumok (név, cím, születési dátum és hely stb.) konzisztensek, ha a fél egy határokon átnyúló tranzakcióban adós, vagy egy számlaváltási kérelemben számlatulajdonos.

Az ISO 20022 mint szabvány nem ismeri a formátumot, de a konkrét üzenetsémákat hivatalosan csak XSD-ként (XML Schema Definitions) teszik közzé, és azok az üzenetkatalógusból elérhetőkmegnyílik egy új lapon, ez vezetett ahhoz, hogy az ISO 20022 üzenetek cseréjére az XML a legszélesebb körben használt formátum.

Az ISO 20022 használatának növekedésével párhuzamosan az új felhasználási esetek és az adatcsere új módjai iránti igény is növekszik, amire kiemelkedő példa az API-k, amelyeket a pénzintézetek számos alkalmazásban használnak, például a számlainformációkhoz való hozzáférés, a fizetések kezdeményezése, az Open Banking vagy a belső rendszerintegrációk.

Az API-fejlesztők, különösen a REST API-k1 tervezésekor gyakran minimalista megközelítést alkalmaznak, a hatékonyságot helyezik előtérbe, és csak az adott kéréshez és válaszhoz szükséges alapvető adatokat továbbítják. Az API-n keresztül kicserélt információkat általában JSON (JavaScript Object Notation) formátumban küldik, amely olyan, mint az XML, de van néhány kisebb inkompatibilitása.

Mivel az ISO 20022 nem tesz közzé JSON-sémákat, és jelenleg nincsenek általánosan követett szabályok arra vonatkozóan, hogy hogyan kell ebben a formátumban ábrázolni2 , ez kihívást jelenthet a szabványt használni kívánó API-fejlesztők számára.

Az ISO 20022 globálisan támogatja a pénzügyi üzenetküldési felhasználási eseteket, ami azt jelenti, hogy minden üzenet számos elemet tartalmaz. Míg egy adott üzleti üzenetváltás, például egy átutalás végrehajtásához szükséges kulcselemek (adós neve, hitelező neve, összeg, pénznem stb.) meglehetősen egységesek maradnak, addig ezen elemek használatának módja változó. Például a helyi elszámolóházakban az adós ügynököt (az adós bankját) Németországban BIC (Business Identifier Code) vagy Bankleitzahl (BLZ - az IBAN-ból származtatva) segítségével határozzák meg, Ausztráliában azonban BSB számmal (Bank State Branch) azonosítják.

Ennek figyelembevétele érdekében az ISO 20022 üzenetek úgy vannak felépítve, hogy lehetővé teszik, hogy vagy az egyiket, vagy a másikat adjuk meg, de ez a rugalmasság nagyobb üzeneteket eredményez, mint amekkorára egy adott felhasználási esethez feltétlenül szükség lenne.

Amikor a fejlesztők API-kat terveznek, a minimalizmusra helyezve a hangsúlyt, gyakran csak a felhasználási esetükre jellemző elemeket tartalmazzák, például ha az Egyesült Királyságban vannak, akkor nincs sok értelme a BSB-számot feltüntetni, mivel minden ügynököt Sort Code-mal azonosítanak. Hasonlóképpen, ha egy ügynök csak a Sort kóddal azonosítható, akkor miért kellene az ISO 20022 üzenet szerkezetének egy részét beépíteni, ha az elem neve megváltoztatható, a következő példa ezt mutatja be:

Így jelenik meg egy brit Sort Code és számlaszám egy XML-alapú ISO 20022 példányban:

</CdtrAcct>

    <CdtrAgt> 

        <FinInstnId> 

            <ClrSysMmbId> 

                <ClrSysId> 

                    <Cd>GBDSC</Cd> 

                </ClrSysId> 

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

    </CdtrAgt> 

    <CdtrAcct> 

        <Id> 

            <Othr> <Egyéb> 

                <Id>21325698</Id> 

            </Othr> 

        </Id> 

    </CdtrAcct> 

A "GBDSC" kód azt határozza meg, hogy a tag azonosítója "UK Domestic Sort Code", az Id/Other/Id pedig a számlaszámot tartalmazza.

Összehasonlításképpen a következőkben bemutatjuk, hogyan továbbítanák ugyanezeket az adatokat az Egyesült Királyság nyílt banki API-ival, amelyeket "az ISO 20022 üzenetelemek és -komponensek felhasználásával terveztek, ahol azok rendelkezésre állnak "3 , megjegyezve a kisebb méretet, de az elemnevek, kódok és a struktúra változását is:

"CreditorAccount": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Identification": "08080021325698"
}

Ez a probléma nem csak a brit nyílt banki rendszerre jellemző, hanem az egész iparágban előfordul, mivel az ISO 20022-alapú API-kat a legjobb gyakorlatokra vonatkozó egyértelmű iránymutatások vagy hivatalos JSON-sémák közzététele nélkül hajtják végre. Nagy a kockázata a megközelítés széttöredezettségének, ami a megvalósítások közötti inkompatibilitáshoz vezet, és nem valósul meg a szabványosítással elérni kívánt előnyök egy része. Az iparág felismerte ezt a kockázatot, és az ISO 20022 szabvány tett néhány lépést ennek mérséklésére:

• Az API SEG (Standards Evaluation Group)új lapon nyílik meg az API-források nyilvántartására, fejlesztésére és karbantartására hozták létre.
• Az ISO/TC 68/WG4 (Technical Committee 68/Working Group 4), az ISO 20022 szabvány kezeléséért/frissítéséért felelős csoport vizsgálja, hogyan lehetne a szabványt úgy módosítani, hogy a JSON-alapú ISO 20022 erőforrások bevezetése hivatalos legyen, valamint egy sablon bevezetése, amely segíti a modellezőket, akik különböző formátumokat kívánnak regisztrálni a szabvány közzétételéhez (pl. JSON séma).
• Az ISO 20022 Technical Support Group (TSG)új lapon nyílik meg a JSON legjobb gyakorlatok Whitepaper (a láblécben hivatkozott) frissítése és felülvizsgálata céljából további útmutatást kíván nyújtani a JSON modellezéséhez.

A pénzügyi ágazat folyamatos fejlődésével a folyamatos szabványosítás és az interoperabilitás alapvető fontosságú. A JSON-alapú üzenetküldés elfogadása az innováció egyik legfontosabb elősegítője, de egyben potenciális buktatókat is rejt magában, amelyekkel az iparágnak tisztában kell lennie. Ellenkező esetben fennáll a veszélye annak, hogy a korábbi kihívásokkal teli munka nagy részét visszacsinálja.

A Mastercard aktívan részt vesz ezekben a kezdeményezésekben, és továbbra is együttműködik az iparággal egy olyan keretrendszer kialakítása érdekében, amely lehetővé teszi az új formátumok elfogadását, ugyanakkor megőrzi a jövőbeli innovációhoz elengedhetetlen szabványosítást és interoperabilitást.