ISO 20022 și JSON, echilibrând standardizarea și flexibilitatea în API-uri

Adoptarea tot mai frecventă a standardului ISO 20022 și cererea crescută de API-uri au dus la numeroase inovații în industria financiară. Totuși, standardele ISO 20022 privind bogata gamă de date pot intra în conflict cu simplitatea și minimalismul pe care le încurajează JSON, formatul de date de facto utilizat în API-uri. Această problemă are potențialul de a împiedica industria să realizeze beneficiile pe care le poate oferi ISO 20022.

În acest articol, explorăm problemele cu care se confruntă dezvoltatorii și industria atunci când încearcă să reconcilieze flexibilitatea și simplitatea JSON cu bogăția de date a standardului ISO 20022. De asemenea, vom analiza eforturile în curs de desfășurare care încearcă să abordeze această problemă importantă.

ISO 20022 este un standard global pentru schimbul de date între instituțiile financiare și acoperă domeniile plăților, schimbului valutar, cardurilor, finanțării comerțului și valorilor mobiliare. Standardul este complex, structurat și flexibil, ceea ce îl reprezintă un salt important față de standardele globale anterioare, ISO 15022 (formatul MT al SWIFT) și ISO 8583 (utilizat pentru plățile cu cardul și plățile între conturi).

În întreaga industrie s-au depus eforturi concertate pentru a stimula adoptarea standardului ISO 20022, deoarece beneficiile sunt cele mai evidente atunci când toată lumea îl utilizează. Ritmul acestei schimbări s-a accelerat pe măsură ce mai multe inițiative au făcut trecerea – multe case de compensare automată (ACH) din întreaga lume utilizând acum noul format pentru plăți de valoare mare și mică, precum și sistemul de plăți transfrontaliere SWIFT. Utilizarea sa nu este încă omniprezentă, unele sisteme acceptând formate vechi, în special pentru plăți în bloc; cu toate acestea, pentru sistemele locale de plăți în timp real, utilizarea standardului ISO 20022 este larg răspândită.

Domeniul de aplicare al standardului ISO 20022 se concentrează pe schimbul de informații, dar principalul beneficiu provine din utilizarea de către instituții a Dicționarului de date (se deschide într-o filă nouă) pentru a-și susține modelele de date interne, în esență, adoptând un limbaj comun. Aceasta înseamnă, de exemplu, că atributele care alcătuiesc o Parte (nume, adresă, data și locul nașterii etc.) sunt consecvente atunci când Partea este un Debitor într-o tranzacție transfrontalieră sau un Titular de Cont într-o Cerere de Schimbare a Contului.

ISO 20022, ca standard, este agnostic în ceea ce privește formatul, dar schemele de mesaje specifice sunt publicate oficial doar ca XSD-uri (XML Schema Definitions) și sunt disponibile din catalogul de mesaje (se deschide într-o filă nouă), ceea ce a dus la faptul că XML este formatul cel mai utilizat pentru schimbul de mesaje ISO 20022.

Pe măsură ce utilizarea standardului ISO 20022 crește, crește și cererea de noi cazuri de utilizare și noi modalități de schimb de date, un exemplu proeminent fiind API-urile, care sunt utilizate de instituțiile financiare pentru numeroase aplicații, cum ar fi permiterea accesului la informațiile contului, inițierea plăților, Open Banking sau integrări de sisteme interne.

Dezvoltatorii de API-uri, în special atunci când proiectează API-uri REST1, adoptă adesea o abordare minimalistă, prioritizând eficiența și transmițând doar datele esențiale necesare pentru o anumită solicitare și un răspuns. Informațiile schimbate prin API sunt de obicei trimise în JSON (JavaScript Object Notation), care este similar cu XML, dar prezintă unele mici incompatibilități.

Întrucât ISO 20022 nu publică scheme JSON și în prezent nu există reguli frecvent urmate pentru reprezentarea lor în acest format2, acest lucru poate prezenta provocări pentru dezvoltatorii de API care speră să utilizeze standardul.

ISO 20022 acceptă cazuri de utilizare a mesageriei financiare la nivel global, ceea ce înseamnă că fiecare mesaj va include mai multe elemente. Deși elementele cheie necesare pentru executarea unui anumit schimb de mesaje comerciale, de exemplu un transfer de credit, rămân destul de consecvente (numele debitorului, numele creditorului, suma, moneda etc.), există variații în modul în care sunt utilizate aceste elemente. De exemplu, în casele de compensare locale, un Agent Debitor (Banca Debitorului) în Germania este definit folosind un BIC (Cod de Identificare a Întreprinderii) sau un Bankleitzahl (BLZ – derivat din IBAN), dar în Australia este identificat folosind un Număr BSB (Sucursala Statului Bancii).

Pentru a ține cont de acest lucru, mesajele ISO 20022 sunt structurate astfel încât să permită furnizarea fie a uneia, fie a celeilalte variante, dar această flexibilitate duce la mesaje mai mari decât ar fi strict necesar pentru orice caz de utilizare dat.

Când dezvoltatorii proiectează API-uri, punând accent pe minimalism, aceștia vor include adesea doar elementele specifice cazului lor de utilizare; de exemplu, dacă se află în Regatul Unit, există puține motive pentru a include numărul BSB, deoarece toți agenții vor fi identificați cu un cod de sortare. În mod similar, dacă un agent poate fi identificat doar cu un cod de sortare, atunci de ce să includem o parte din structura unui mesaj ISO 20022 când numele elementului poate fi schimbat? Următorul exemplu evidențiază acest lucru:

Iată cum ar apărea un cod de sortare și un număr de cont din Marea Britanie într-o instanță ISO 20022 bazată pe 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> 

Codul „GBDSC” definește faptul că ID-ul membrului este un „cod de sortare intern din Marea Britanie”, iar ID-ul/Altul/ID-ul conține numărul de cont.

Comparativ, în continuare se prezintă modul în care aceleași date ar fi transmise prin intermediul API-urilor Open Banking din Regatul Unit, care au fost „proiectate folosind elementele și componentele mesajelor ISO 20022, acolo unde sunt disponibile”3, remarcând dimensiunea mai mică, dar și modificarea numelor, codurilor și structurii elementelor:

"Cont Creditor": {
"Nume schemă": "UK.OBIE.Cod de sortareNumăr cont",
„Identificare”: „08080021325698”
}

Această problemă nu este specifică Open Banking-ului din Marea Britanie și apare în întreaga industrie, API-urile bazate pe ISO 20022 fiind implementate fără îndrumări clare privind cele mai bune practici sau fără publicarea de scheme JSON oficiale. Riscul fragmentării abordării este ridicat, ceea ce duce la incompatibilitate între implementări și la neluarea în practică a unora dintre beneficiile pe care standardizarea și-a propus să le obțină. Industria a identificat acest risc, iar ISO 20022 a luat câteva măsuri pentru a-l atenua:

• Grupul de evaluare a standardelor (SEG) pentru API (se deschide într-o filă nouă) a fost înființat pentru a înregistra, dezvolta și întreține resursele API.
• ISO/TC 68/WG4 (Comitetul Tehnic 68/Grupul de Lucru 4), grupul responsabil pentru gestionarea/actualizarea standardului ISO 20022, a investigat modalitățile de modificare a standardului pentru a oficializa introducerea resurselor ISO 20022 bazate pe JSON, precum și introducerea unui șablon pentru a ajuta creatorii de modele care doresc să înregistreze diferite formate pentru ca standardul să fie publicat (de exemplu, Schema JSON).
• Grupul de asistență tehnică (TSG) ISO 20022 (se deschide într-o filă nouă) dorește să actualizeze și să revizuiască cartea albă privind cele mai bune practici JSON (la care se face referire în subsol) pentru a oferi îndrumări suplimentare privind modelarea JSON.

Pe măsură ce industria financiară continuă să evolueze, standardizarea și interoperabilitatea continue sunt cruciale. Adoptarea mesageriei bazate pe JSON este un factor cheie pentru inovare, dar prezintă și potențiale capcane de care industria trebuie să fie conștientă. Altfel, se confruntă cu riscul de a anula o mare parte din munca dificilă depusă anterior.

Mastercard este implicată activ în aceste inițiative și va continua să colaboreze cu industria pentru a contribui la un cadru care să permită adoptarea de noi formate, păstrând în același timp standardizarea și interoperabilitatea esențiale pentru inovația viitoare.