ISO 20022 და JSON, დაბალანსებელი სტანდარტიზაცია და მოქნილობა API— ებში

ISO 20022-ის მზარდმა მიღებამ და API-ებზე გაზრდილმა მოთხოვნამ გამოიწვია ბევრი ინოვაცია ფინანსურ ინდუსტრიაში. ამასთან, ISO 20022-ის მდიდარი მონაცემთა სტანდარტები შეიძლება ეწინააღმდეგებოდეს სიმარტივეს და მინიმალიზმს, რომელსაც JSON, API— ებში გამოყენებული დე ფაქტო მონაცემ ამ საკითხს აქვს პოტენციალი, შეაფერხოს ინდუსტრიას იმ სარგებლის განხორციელებაში, რაც ISO 20022— ს შეუძლია

ამ სტატიაში ჩვენ ვიკვლევთ პრობლემებს, რომლებსაც დეველოპერები და ინდუსტრია აწყდებიან, როდესაც ვცდილობთ შეერგოთ JSON-ის მოქნილობა და სიმარტივე ISO ჩვენ ასევე გადავხედავთ ამ მნიშვნელოვანი საკითხის მოგვარების მიმდინარე ძალისხმევას.

ISO 20022 არის ფინანსურ ინსტიტუტებს შორის მონაცემთა გაცვლის გლობალური სტანდარტი და მოიცავს გადახდების, სავალუტო ვალუტის, ბარათების, სავაჭრო ფინ სტანდარტი მდიდარი, სტრუქტურირებული და მოქნილია, რაც მას დიდი ნახტომი წარმოადგენს წინა გლობალურ სტანდარტებთან შედარებით, ISO 15022 (SWIFT-ის MT ფორმატი) და ISO 8583 (გამოიყენება ბარათით გადახდებისთვის და ანგარიშიდან ანგარიშზე გადახდებისთვის).

მთელ ინდუსტრიაში ჩატარდა ერთიანი ძალისხმევა ISO 20022-ის მიღების მიზნით, რადგან სარგებელი ყველაზე აშკარაა, როდესაც მას ყველა იყენებს. ამ ცვლილების ტემპი დაჩქარდა, რადგან უფრო მეტი ინიციატივა შეიტანა - მრავალი ავტომატიზირებული კლირინგის სახლი (ACH) მთელს მსოფლიოში ახლა იყენებს ახალ ფორმატს მაღალი და დაბალი ღირებულების გადახდებისთვის, ასევე SWIFT-ის სასაზღვრო გადახდის სისტემას მისი გამოყენება ჯერ კიდევ ყველგან არ არის გავრცელებული, ზოგიერთი სისტემა მხარს უჭერს მემკვიდრეობის ფორმატებს, განსაკუთრებით ნაყოფიერი გადახდებისთვის, თუმცა ადგილობრივი რეალურ დროში გადახდის სისტემებისთვის ISO 200

ISO 20022-ის ფარგლები ფოკუსირებულია ინფორმაციის გაცვლაზე, მაგრამ ძირითადი სარგებელი მოდის ინსტიტუტებიდან, რომლებიც ახა ლ ჩანართში იყენებენ მონაცემთა ლექსიკონარ იას მათი შიდა მონაცემთა მოდელების მხარდასაჭერად, არსებითად, საერთო ენის გამოყენებისთვის ეს ნიშნავს, მაგალითად, რომ მხარეს შექმნელი ატრიბუტები (სახელი, მისამართი, დაბადების თარიღი და ადგილი და ა. შ.) თანმიმდევრულია, როდესაც მხარე არის მოვალე საზღვარგარე ტრანზაქციაში ან ანგარიშის მფლობელი ანგარიშის შეცვლის მოთხოვნაში.

ISO 20022, როგორც სტანდარტი, არის აგნოსტიკური ფორმატის, მაგრამ კონკრეტული შეტყობინებების სქემები მხოლოდ ოფიციალურად გამოქვეყნებულია როგორც XSDs (XML Schema Definitions) და ხელმისაწვდომია შეტყობინებ ების კატალოგიდან, რაც გამოიწვია XML ყველაზე ფართოდ გამოყენებული ფორმატი ISO 20022 შეტყობინებების გაცვლისთვის.

ISO 20022-ის გამოყენებასთან ერთად იზრდება მოთხოვნა ახალი გამოყენების შემთხვევებზე და მონაცემთა გაცვლის ახალ გზებზე, რომელთა გამორჩეული მაგალითია API, რომლებსაც ფინანსური ინსტიტუტები იყენებენ მრავალი პროგრამისთვის, როგორიცაა ანგარიშზე წვდომა, გადახდების დაწყება, ღია ბანკინგი ან შიდა სისტემების ინტეგრაცია.

API დეველოპერები, განსაკუთრებით REST APIS1-ის შემუშავებისას, ხშირად იყენებენ მინიმალისტურ მიდგომას, პრიორიტეტულობას ანიჭებენ ეფექტურობას და გადასცემენ მხოლოდ კონკრეტული მოთხოვნისა API— ის საშუალებით გაცვლილი ინფორმაცია ჩვეულებრივ იგზავნება JSON-ში (JavaScript Object Notation), რომელიც XML-ს ჰგავს, მაგრამ აქვს მცირე შეუთავსებლობა.

ვინაიდან ISO 20022 არ აქვეყნებს JSON სქემებს და ამჟამად არ არსებობს ჩვეულებრივ დაცული წესები იმის შესახებ, თუ როგორ უნდა წარმოადგინოთ იგი ამ ფორმატში 2, ამან შეიძლება გამოწვევები წარმოადგენს API დეველოპერებს, რომლებიც იმედოვნებენ

ISO 20022 მხარს უჭერს ფინანსური შეტყობინებების გამოყენების შემთხვევებს გლობალურად, რაც იმას ნიშნავს, რომ თით მიუხედავად იმისა, რომ კონკრეტული ბიზნეს შეტყობინებების გაცვლისთვის აუცილებელი ძირითადი ელემენტები, მაგალითად საკრედიტო გადარიცხვა, საკმაოდ თანმიმდევრული რჩება (მოვალის სახელი, კრედიტორის სახელი, თანხა, ვალუტა და ა. მაგალითად, ადგილობრივ კლირინგულ სახლებში გერმანიაში მოვალე აგენტი (მოვალე ბანკი) განისაზღვრება BIC (ბიზნესის იდენტიფიკატორის კოდი) ან Bankleitzahl (BLZ - IBAN) გამოყენებით, მაგრამ ავსტრალიაში იგი იდენტიფიცირებულია BSB ნომრის გამოყენებით (ბანკის სახელმწიფო ფილიალი).

ამის დასაკმაყოფილებლად, ISO 20022 შეტყობინებები სტრუქტურირებულია ისე, რომ საშუალებას გაძლევთ მიაწოდოთ ერთი ან მეორე, მაგრამ ეს მოქნილობა იწვევს უფრო დიდ შეტყობინებებს, ვიდრე მკაცრად საჭირო იქნება ნებისმიერი მოცემული გამოყენების შემთხვევისთვის.

როდესაც დეველოპერები აპროექტებენ API-ებს, მინიმალიზმზე აქცენტით, ისინი ხშირად შეიცავენ მხოლოდ მათი გამოყენების შემთხვევისთვის სპეციფიკურ ელემენტებს, მაგალითად, თუ ისინი გაერთიანებულ სამეფოში არიან, მცირე მიზეზი არსებობს BSB ნომრის ჩართვისთვის, რადგან ყველა აგენტი იდენტიფიცირდება დალაგების კოდით. ანალოგიურად, თუ აგენტის იდენტიფიცირება შესაძლებელია მხოლოდ დახარისხების კოდით, მაშინ რატომ შეიტანოთ ISO 20022 შეტყობინების ზოგიერთი სტრუქტურა, როდესაც ელემენტის სახელის შეცვლა შესაძლებელია, შემდეგი მაგალითი ხაზს უსვამს

ასე გამოჩნდება დიდი ბრიტანეთის დალაგების კოდი და ანგარიშის ნომერი XML— ზე დაფუძნებული ISO 20022 ინსტანციაში:

</CdtrAcct>

    <CdtrAgt> < კდტრაგტი > 

        <FinInstnId> < ფინინსტნიდი > 

            <ClrSysMmbId> < კლრსისმმბიდ > 

                <ClrSysId> < კლრსისიდ > 

                    <Cd>< სდ > გბდსკ < /სდ ></Cd> 

                </ClrSysId> < /კლრსისიდ > 

                <MmbId>< მმბიდი > 080800 < /მმბიდი ></MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> < /ფინისტნიდი > 

    </CdtrAgt> < /ცდტრაგტ > 

    <CdtrAcct> 

        <Id> < იდი > 

            <Othr> < ოტრი > 

                <Id>< იდი > 21325698 < /იდი ></Id> 

            </Othr> < /ოთრ > 

        </Id> < /იდი > 

    </CdtrAcct> 

კოდი „GBDSC“ განსაზღვრავს, რომ წევრის ID არის „დიდი ბრიტანეთის საშინაო დახარისხების კოდი“, ID /სხვა/ID შეიცავს ანგარიშის ნომერს.

შედარებით, ქვემოთ მოცემულია, თუ როგორ გადაეცემა იგივე მონაცემები დიდი ბრიტანეთის ღია ბანკინგის API— ების საშუალებით, რომლებიც „შექმნილია ISO 20022 შეტყობინების ელემენტებისა და კომპონენტების გამოყენებით, სადაც ხელმისაწვდომია“ 3, გაითვალისწინეთ მცირე ზომა, ასევე ელემენტების სახელების, კოდების და სტრუქტურის

" კრედიტორის ანგარიში ": {
" სქემენაიმ ": " UK.obie.sortcodeAccountNumber ",
" საიდენტიფიკაციო ": " 08080021325698 "
}

ეს საკითხი არ არის სპეციფიკური დიდი ბრიტანეთის ღია ბანკინგისთვის და ხდება მთელ ინდუსტრიაში, ხოლო ISO 20022-ზე დაფუძნებული API ხორციელდება საუკეთესო პრაქტიკის ან ოფიციალური JSON სქემების მკაფიო მიდგომის ფრაგმენტაციის რისკი მაღალია, რაც იწვევს განხორციელებებს შორის შეუთავსებლობას და ზოგიერთი სარგებელი, რომლის მიღწევას სტანდარტიზაცია აპირებდა. ინდუსტრიამ გამოავლინა ეს რისკი და ISO 20022-მა გადადგა რამდენიმე ნაბიჯი მის შესამცირებლად:

• API SEG (სტანდარტების შეფასების ჯგუფი) იხსნება ახალ ჩანართში, რომელიც შეიქმნა API რესურსების რეგისტრაციისთვის, განვითარებისა და
• ISO/TC 68/WG4 (ტექნიკური კომიტეტი 68/სამუშაო ჯგუფი 4), ჯგუფი, რომელიც პასუხისმგებელია ISO 20022 სტანდარტის მართვას/განახლებაზე, იკვლევდა, თუ როგორ უნდა შეცვალოს სტანდარტი JSON-ზე დაფუძნებული ISO 20022 რესურსების დანერგვის ფორმირების მიზნით. JSON სქემა).
• ISO 20022 ტექნიკური მხარდაჭერის ჯგუფი (TSG) იხსნება ახალ ჩანართში ცდილობს განაახლოს და გადახედოს მათ JSON საუკეთესო პრაქტიკას Whitepaper (მითითებულია ქვედა კოლონტიტულში), რათა უზრუნველყოს შემდგომი მითითებები JSON-ის მოდელირების შესახებ.

რადგან ფინანსური ინდუსტრია განაგრძობს განვითარებას, გადამწყვეტი სტანდარტიზაცია და ურთიერთ JSON-ზე დაფუძნებული შეტყობინებების მიღება ინოვაციების მთავარი ხელშემწყობია, მაგრამ ის ასევე ქმნის პოტენციურ ხაფანგებს, რომელთა შესახებაც ინდუსტრიამ უნდა იცოდეს. წინააღმდეგ შემთხვევაში, მას წინაშე დგას ბევრი რთული სამუშაოს გაუქმების რისკი, რომელიც ადრე გახდა.

Mastercard აქტიურად არის ჩართული ამ ინიციატივებში და გააგრძელებს თანამშრომლობას ინდუსტრიასთან, რათა მიაღწიოს ჩარჩოს მიღებას, რომელიც საშუალებას იძლევა მიიღოს ახალი ფორმატები და თანამშრომლობა შენარჩუნებს, რაც აუცილებელია მომავალი ინ