ISO 20022 และ JSON: การสร้างสมดุลระหว่างมาตรฐานและความยืดหยุ่นใน API

การนำมาตรฐาน ISO 20022 มาใช้เพิ่มมากขึ้น และความต้องการใช้งาน API ที่เพิ่มขึ้น ส่งผลให้เกิดนวัตกรรมมากมายในอุตสาหกรรมการเงิน อย่างไรก็ตาม มาตรฐานข้อมูลที่ซับซ้อนของ ISO 20022 อาจขัดแย้งกับความเรียบง่ายและมินิมอลที่ JSON ซึ่งเป็นรูปแบบข้อมูลมาตรฐานที่ใช้ใน API ส่งเสริม ปัญหาดังกล่าวอาจเป็นอุปสรรคต่อภาคอุตสาหกรรมในการได้รับประโยชน์อย่างเต็มที่จากมาตรฐาน ISO 20022

ในบทความนี้ เราจะสำรวจประเด็นปัญหาที่นักพัฒนาและอุตสาหกรรมต้องเผชิญเมื่อพยายามผสานความยืดหยุ่นและความเรียบง่ายของ JSON เข้ากับความสมบูรณ์ของข้อมูลตามมาตรฐาน ISO 20022 นอกจากนี้ เราจะมาดูความพยายามที่กำลังดำเนินอยู่เพื่อแก้ไขปัญหาสำคัญนี้ด้วย

ISO 20022 เป็นมาตรฐานสากลสำหรับการแลกเปลี่ยนข้อมูลระหว่างสถาบันการเงิน และครอบคลุมด้านการชำระเงิน การแลกเปลี่ยนเงินตราต่างประเทศ บัตร การเงินเพื่อการค้า และหลักทรัพย์ มาตรฐานนี้มีเนื้อหาที่ครบถ้วน มีโครงสร้างที่ชัดเจน และมีความยืดหยุ่น ทำให้เป็นก้าวสำคัญที่เหนือกว่ามาตรฐานสากลก่อนหน้านี้อย่าง ISO 15022 (รูปแบบ MT ของ SWIFT) และ ISO 8583 (ที่ใช้สำหรับการชำระเงินด้วยบัตรและการชำระเงินระหว่างบัญชี)

มีการพยายามอย่างพร้อมเพรียงกันทั่วทั้งอุตสาหกรรมเพื่อผลักดันให้มีการนำมาตรฐาน ISO 20022 มาใช้ เนื่องจากผลประโยชน์จะเห็นได้ชัดเจนที่สุดเมื่อทุกคนนำไปใช้ การเปลี่ยนแปลงนี้เกิดขึ้นอย่างรวดเร็วเนื่องจากมีโครงการริเริ่มจำนวนมากขึ้นที่เปลี่ยนมาใช้ระบบใหม่ โดยปัจจุบันศูนย์การหักบัญชีอัตโนมัติ (ACH) ทั่วโลกจำนวนมากใช้รูปแบบใหม่นี้สำหรับการชำระเงินทั้งมูลค่าสูงและต่ำ รวมถึงระบบการชำระเงินข้ามพรมแดนของ SWIFT ด้วย ปัจจุบันการใช้งานยังไม่แพร่หลาย โดยบางระบบยังคงรองรับรูปแบบดั้งเดิม โดยเฉพาะอย่างยิ่งสำหรับการชำระเงินจำนวนมาก อย่างไรก็ตาม สำหรับระบบการชำระเงินแบบเรียลไทม์ในระดับท้องถิ่น การใช้งาน ISO 20022 นั้นแพร่หลายมาก

ขอบเขตของ ISO 20022 มุ่งเน้นไปที่การแลกเปลี่ยนข้อมูล แต่ประโยชน์หลักมาจากการที่สถาบันต่างๆ ใช้ พจนานุกรมข้อมูล (Data Dictionary) เพื่อสนับสนุนแบบจำลองข้อมูลภายในของตน ซึ่งโดยพื้นฐานแล้วคือการใช้ภาษาเดียวกัน นี่หมายความว่า ตัวอย่างเช่น คุณลักษณะที่ประกอบขึ้นเป็นคู่สัญญา (ชื่อ ที่อยู่ วันเดือนปีเกิด และสถานที่เกิด ฯลฯ) จะมีความสอดคล้องกันไม่ว่าคู่สัญญานั้นจะเป็นลูกหนี้ในธุรกรรมข้ามพรมแดน หรือเป็นเจ้าของบัญชีในคำขอเปลี่ยนบัญชีก็ตาม

มาตรฐาน ISO 20022 นั้นไม่ขึ้นกับรูปแบบข้อความ แต่โครงสร้างข้อความเฉพาะจะได้รับการเผยแพร่อย่างเป็นทางการในรูปแบบ XSD (XML Schema Definitions) และสามารถดูได้จาก แคตตาล็อกข้อความ [เปิดในแท็บใหม่] ซึ่งส่งผลให้ XML เป็นรูปแบบที่ใช้กันอย่างแพร่หลายที่สุดในการแลกเปลี่ยนข้อความ ISO 20022

เมื่อการใช้งาน ISO 20022 เพิ่มขึ้น ความต้องการกรณีการใช้งานใหม่ๆ และวิธีการแลกเปลี่ยนข้อมูลแบบใหม่ๆ ก็เพิ่มขึ้นเช่นกัน ตัวอย่างที่โดดเด่นคือ API ซึ่งสถาบันการเงินใช้สำหรับแอปพลิเคชันต่างๆ มากมาย เช่น การอนุญาตให้ Access ข้อมูลบัญชี การเริ่มต้นการชำระเงิน Open Banking หรือการบูรณาการระบบภายใน

นักพัฒนา API โดยเฉพาะอย่างยิ่งเมื่อออกแบบ REST API มักจะใช้แนวทางที่เรียบง่าย โดยให้ความสำคัญกับประสิทธิภาพและส่งเฉพาะข้อมูลที่จำเป็นสำหรับคำขอและการตอบกลับที่เฉพาะเจาะจงเท่านั้น ข้อมูลที่แลกเปลี่ยนผ่าน API มักถูกส่งในรูปแบบ JSON (JavaScript Object Notation) ซึ่งคล้ายกับ XML แต่มีข้อแตกต่างเล็กน้อย

เนื่องจากมาตรฐาน ISO 20022 ไม่ได้เผยแพร่ JSON Schema และปัจจุบันยังไม่มีกฎเกณฑ์ที่ใช้กันทั่วไปในการแสดง JSON ในรูปแบบนี้2 จึงอาจก่อให้เกิดความท้าทายสำหรับนักพัฒนา API ที่หวังจะใช้มาตรฐานนี้

มาตรฐาน ISO 20022 รองรับกรณีการใช้งานการส่งข้อความทางการเงินทั่วโลก ซึ่งหมายความว่าแต่ละข้อความจะประกอบด้วยองค์ประกอบหลายอย่าง แม้ว่าองค์ประกอบหลักที่จำเป็นต่อการดำเนินการแลกเปลี่ยนข้อความทางธุรกิจเฉพาะอย่าง เช่น การโอนเงิน จะยังคงค่อนข้างสม่ำเสมอ (ชื่อลูกหนี้ ชื่อเจ้าหนี้ จำนวนเงิน สกุลเงิน ฯลฯ) แต่ก็มีความแตกต่างกันในวิธีการใช้งานองค์ประกอบเหล่านั้น ตัวอย่างเช่น ในสำนักหักบัญชีท้องถิ่นในเยอรมนี ตัวแทนลูกหนี้ (ธนาคารของลูกหนี้) จะถูกกำหนดโดยใช้ BIC (รหัสระบุธุรกิจ) หรือ Bankleitzahl (BLZ – ซึ่งได้มาจาก IBAN) แต่ในออสเตรเลียจะระบุโดยใช้หมายเลข BSB (หมายเลขสาขาธนาคารประจำรัฐ)

เพื่อรองรับสิ่งนี้ ข้อความตามมาตรฐาน ISO 20022 จึงถูกจัดโครงสร้างในลักษณะที่อนุญาตให้คุณระบุอย่างใดอย่างหนึ่งได้ แต่ความยืดหยุ่นนี้ทำให้ข้อความมีขนาดใหญ่กว่าที่จำเป็นอย่างเคร่งครัดสำหรับกรณีการใช้งานใดๆ ก็ตาม

เมื่อนักพัฒนาออกแบบ API โดยเน้นความเรียบง่าย พวกเขามักจะใส่เฉพาะองค์ประกอบที่เกี่ยวข้องกับกรณีการใช้งานของตนเท่านั้น ตัวอย่างเช่น หากอยู่ในสหราชอาณาจักร ก็ไม่จำเป็นต้องใส่หมายเลข BSB เนื่องจากเอเจนต์ทั้งหมดจะถูกระบุด้วยรหัส Sort Code อยู่แล้ว ในทำนองเดียวกัน หากตัวแทน (Agent) สามารถระบุได้ด้วยรหัสเรียงลำดับ (Sort Code) เท่านั้น แล้วทำไมจึงต้องรวมโครงสร้างบางส่วนของข้อความ ISO 20022 ในเมื่อสามารถเปลี่ยนแปลงชื่อองค์ประกอบได้ ตัวอย่างต่อไปนี้แสดงให้เห็นถึงประเด็นนี้:

นี่คือตัวอย่างวิธีแสดงรหัส Sort Code และหมายเลขบัญชีของสหราชอาณาจักรในรูปแบบ XML ตามมาตรฐาน ISO 20022:

</CdtrAcct>

    <CdtrAgt> 

        <FinInstnId> <รหัสสถาบันการเงิน> 

            <ClrSysMmbId> 

                <ClrSysId> 

                    <Cd>GBDSC</Cd> 

                </ClrSysId> 

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

    </CdtrAgt> 

    <CdtrAcct> <บัญชี CDTR> 

        <Id> <รหัส> 

            <Othr> <อื่นๆ> 

                <Id>21325698</Id> 

            </Othr> </อื่นๆ> 

        </Id> 

    </CdtrAcct> 

รหัส “GBDSC” กำหนดว่ารหัสสมาชิกคือ “รหัสธนาคารภายในประเทศของสหราชอาณาจักร” โดยที่ Id/Other/Id ประกอบด้วยหมายเลขบัญชี

เมื่อเปรียบเทียบกันแล้ว ข้อมูลชุดเดียวกันจะถูกส่งผ่าน API Open Banking ของสหราชอาณาจักรดังนี้ ซึ่ง 'ได้รับการออกแบบโดยใช้ส่วนประกอบและองค์ประกอบข้อความ ISO 20022 ที่มีอยู่'3 โปรดสังเกตขนาดที่เล็กลง แต่ยังรวมถึงการเปลี่ยนแปลงชื่อองค์ประกอบ รหัส และโครงสร้างด้วย:

"บัญชีเจ้าหนี้": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
รหัสประจำตัว: "08080021325698"
}

ปัญหานี้ไม่ได้จำเพาะเจาะจงเฉพาะ Open Banking ของสหราชอาณาจักร แต่เกิดขึ้นทั่วทั้งอุตสาหกรรม โดยมีการนำ API ที่อิงตาม ISO 20022 มาใช้โดยไม่มีแนวทางปฏิบัติที่ดีที่สุดที่ชัดเจน หรือไม่มีการเผยแพร่ JSON Schema อย่างเป็นทางการ ความเสี่ยงที่จะเกิดความแตกแยกในแนวทางปฏิบัติมีสูง ส่งผลให้เกิดความไม่เข้ากันระหว่างการนำไปใช้ และทำให้ไม่ได้รับประโยชน์บางประการที่การกำหนดมาตรฐานตั้งใจจะบรรลุ ภาคอุตสาหกรรมได้ตระหนักถึงความเสี่ยงนี้แล้ว และมาตรฐาน ISO 20022 ได้ดำเนินการบางประการเพื่อลดความเสี่ยงดังกล่าว:

• กลุ่มประเมินมาตรฐาน API (API SEG) เปิดในแท็บใหม่ ก่อตั้งขึ้นเพื่อลงทะเบียน พัฒนา และบำรุงรักษาทรัพยากร API
• ISO/TC 68/WG4 (คณะกรรมการทางเทคนิค 68/กลุ่มงานที่ 4) ซึ่งเป็นกลุ่มที่รับผิดชอบในการจัดการ/ปรับปรุงมาตรฐาน ISO 20022 ได้ทำการตรวจสอบวิธีการเปลี่ยนแปลงมาตรฐานเพื่อให้การนำทรัพยากร ISO 20022 ที่ใช้ JSON มาใช้เป็นไปอย่างเป็นทางการมากขึ้น รวมถึงการแนะนำเทมเพลตเพื่อช่วยเหลือนักออกแบบโมเดลที่ต้องการลงทะเบียนรูปแบบต่างๆ สำหรับการเผยแพร่มาตรฐาน (เช่น (JSON Schema)
• กลุ่มสนับสนุนทางเทคนิค ISO 20022 (TSG) กำลังดำเนินการปรับปรุงและแก้ไขเอกสารแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับ JSON (อ้างอิงในส่วนท้าย) เพื่อให้คำแนะนำเพิ่มเติมเกี่ยวกับการสร้างแบบจำลอง JSON

เนื่องจากอุตสาหกรรมการเงินยังคงพัฒนาอย่างต่อเนื่อง การสร้างมาตรฐานและความสามารถในการทำงานร่วมกันจึงมีความสำคัญอย่างยิ่ง การนำระบบส่งข้อความแบบ JSON มาใช้ถือเป็นปัจจัยสำคัญที่ช่วยขับเคลื่อนนวัตกรรม แต่ก็มีข้อเสียที่อาจเกิดขึ้นได้เช่นกัน ซึ่งอุตสาหกรรมจำเป็นต้องตระหนักถึงเรื่องนี้ มิเช่นนั้น ก็อาจเสี่ยงที่จะทำให้ความพยายามอย่างหนักที่ผ่านมาต้องสูญเปล่าไปเป็นจำนวนมาก

Mastercard มีส่วนร่วมอย่างแข็งขันในโครงการริเริ่มเหล่านี้ และจะยังคงร่วมมือกับอุตสาหกรรมต่อไปเพื่อผลักดันไปสู่กรอบการทำงานที่เอื้อต่อการนำรูปแบบใหม่มาใช้ ในขณะเดียวกันก็รักษามาตรฐานและความสามารถในการทำงานร่วมกัน ซึ่งเป็นสิ่งสำคัญสำหรับนวัตกรรมในอนาคต