คำถามที่พบบ่อยเกี่ยวกับ ISO 20022 คำถามที่พบบ่อยเกี่ยวกับ ISO 20022
Common questions about ISO 20022 pacs messages, how they work together, and how pacs008 helps teams implement them.
ทั่วไป ทั่วไป
ISO 20022 คืออะไร?
ISO 20022 เป็นมาตรฐานสากลสำหรับการส่งข้อความทางการเงิน กำหนดภาษาและโมเดลร่วมสำหรับข้อความการชำระเงินที่แลกเปลี่ยนระหว่างสถาบันการเงิน ต่างจากรูปแบบเก่าอย่าง SWIFT MT ตรงที่ ISO 20022 ใช้ XML และรองรับข้อมูลที่สมบูรณ์และมีโครงสร้างมากขึ้นสำหรับคู่สัญญา จำนวนเงิน และการอ้างอิง
ข้อความ pacs คืออะไร?
ตระกูลข้อความ pacs (payments clearing and settlement) ครอบคลุมคำสั่งการชำระเงินระหว่างธนาคาร รายงานสถานะ การคืนเงิน การกลับรายการ และการสอบถาม ประกอบด้วย pacs.002, pacs.003, pacs.004, pacs.007, pacs.008, pacs.009, pacs.010 และ pacs.028 แต่ละข้อความมีบทบาทเฉพาะในวงจรชีวิตการชำระเงิน
ข้อความ pacs แตกต่างจากข้อความ SWIFT MT อย่างไร?
SWIFT MT ใช้รูปแบบฟิลด์แท็กแบบแบน (เช่น MT103 สำหรับการโอนเครดิตลูกค้า) ข้อความ pacs ใช้ XML แบบลำดับชั้นที่มีโครงสร้างข้อมูลสมบูรณ์กว่า ความแตกต่างสำคัญ ได้แก่ รองรับหลายธุรกรรมต่อข้อความ การระบุตัวตนคู่สัญญาแบบมีโครงสร้าง (LEI, หลาย ID) ที่อยู่ไปรษณีย์แบบมีโครงสร้าง และข้อมูลการโอนแบบมีโครงสร้าง MT103 ตรงกับ pacs.008, MT202 ตรงกับ pacs.009 และข้อความสถานะ MT199 ถูกแทนที่ด้วย pacs.002
ความสัมพันธ์ระหว่างข้อความ pain และ pacs คืออะไร?
ข้อความ pain (payment initiation) เดินทางระหว่างลูกค้าและธนาคาร ข้อความ pacs เดินทางระหว่างธนาคาร คำสั่ง pain.001 เริ่มต้นการโอนเครดิตลูกค้าจากธนาคารผู้ชำระเงินกลายเป็นคำสั่ง pacs.008 ระหว่างธนาคาร ทั้งสองโดเมนใช้องค์ประกอบข้อมูลร่วมกันแต่ให้บริการส่วนต่างของสายการชำระเงิน
การเลือกข้อความ การเลือกข้อความ
ควรใช้ pacs.008 เมื่อใด?
ใช้ pacs.008 สำหรับคำสั่งโอนเครดิตลูกค้าระหว่างธนาคาร ข้อความนี้บรรจุข้อมูลคู่สัญญาผู้ชำระเงินและผู้รับเงิน จำนวนเงิน ข้อมูลการโอน และรายละเอียดการชำระบัญชี เป็นข้อความหลักสำหรับการส่งการชำระเงินลูกค้าผ่านเครือข่ายระหว่างธนาคาร ทั้งในประเทศ (SEPA) และข้ามพรมแดน (CBPR+)
ควรใช้ pacs.009 แทน pacs.008 เมื่อใด?
ใช้ pacs.009 สำหรับการโอนบัญชีของสถาบันเอง ขาเงินทุน และการชำระเงินคัฟเวอร์ ต่างจาก pacs.008 ที่บรรจุการชำระเงินลูกค้าในนามผู้ชำระเงิน pacs.009 ย้ายเงินทุนระหว่างธนาคารในนามของตนเอง ในกระแสคัฟเวอร์ pacs.009 บรรจุขาเงินทุน ขณะที่ pacs.008 บรรจุคำสั่งลูกค้าบนเส้นทางแยกต่างหาก
pacs.004 กับ pacs.007 ต่างกันอย่างไร?
pacs.004 คืนเงินที่ชำระบัญชีแล้วจากฝั่งผู้รับกลับผ่านสาย pacs.007 กลับรายการการชำระเงินจากฝั่งผู้สั่งเดิมไปข้างหน้าผ่านสาย ใช้ pacs.004 เมื่อธนาคารผู้รับเงินไม่สามารถเข้าบัญชีได้หลังการชำระบัญชี ใช้ pacs.007 เมื่อผู้ส่งค้นพบข้อผิดพลาด รายการซ้ำ หรือการฉ้อโกง
ควรใช้ pacs.028 แทนการรอ pacs.002 เมื่อใด?
ใช้ pacs.028 เมื่อต้องการร้องขอสถานะของการชำระเงินที่ไม่ได้รับการอัปเดต pacs.002 ตามกำหนดอย่างกระตือรือร้น pacs.002 ขับเคลื่อนด้วยเหตุการณ์ (ตัวแทนผู้รับส่งในเชิงรุก) ขณะที่ pacs.028 ขับเคลื่อนด้วยข้อยกเว้น (ตัวแทนผู้สั่งร้องขอ) ใช้ pacs.028 สำหรับการอัปเดตที่ล่าช้า ไม่ชัดเจน หรือขาดหายไป ไม่ใช่เป็นปริมาณงานปกติ
pacs.003 ใช้สำหรับอะไร?
pacs.003 ส่งคำสั่งเดบิตโดยตรงของลูกค้าระหว่างธนาคาร ตัวแทนเจ้าหนี้ส่งไปยังตัวแทนลูกหนี้เพื่อเรียกเก็บเงิน ต้องมีการอ้างอิงข้อตกลงที่ถูกต้องและรองรับรูปแบบเดบิตโดยตรง SEPA Core และ B2B ไม่ใช้สำหรับการโอนเครดิตหรือเดบิตโดยตรงระหว่างสถาบันในบัญชีของตนเอง
pacs.010 ใช้สำหรับอะไร?
pacs.010 จัดการเดบิตโดยตรงระหว่างสถาบันการเงินในบัญชีของตนเอง ใช้สำหรับการเรียกเก็บระหว่างธนาคาร เช่น ค่าธรรมเนียม margin call และภาระผูกพันที่คล้ายกันภายใต้ข้อตกลงทวิภาคี ไม่ใช้สำหรับเดบิตโดยตรงของลูกค้าหรือการโอนเครดิต
โครงสร้างข้อความ โครงสร้างข้อความ
Group Header (GrpHdr) คืออะไร?
Group Header ปรากฏหนึ่งครั้งต่อข้อความ pacs ประกอบด้วยตัวระบุข้อความ (MsgId) ประทับเวลาการสร้าง (CreDtTm) จำนวนธุรกรรม (NbOfTxs) ข้อมูลการชำระบัญชี (SttlmInf) และทางเลือกคือจำนวนเงินรวมการชำระบัญชีระหว่างธนาคารและข้อมูลประเภทการชำระเงิน ระบุซองข้อความ ไม่ใช่ธุรกรรมทางธุรกิจแต่ละรายการ
ตัวระบุการชำระเงินใน pacs.008 มีอะไรบ้าง?
pacs.008 ใช้ตัวระบุหลักสี่ตัว MsgId ระบุซองข้อความและเปลี่ยนที่แต่ละ hop InstrId เป็นการอ้างอิงจุดต่อจุดระหว่างตัวแทนที่อยู่ติดกันและอาจเปลี่ยนต่อ hop EndToEndId กำหนดโดยผู้ริเริ่มและต้องไม่ถูกเปลี่ยนแปลงโดยตัวแทนใดในสาย TxId กำหนดโดยตัวแทนผู้สั่งแรกและคงที่ในพื้นที่ระหว่างธนาคาร UETR เป็น UUID ที่ไม่เปลี่ยนแปลงในทุกขาเพื่อการติดตามจากต้นทางถึงปลายทาง
มีวิธีการชำระบัญชีอะไรบ้าง?
กำหนดวิธีการชำระบัญชีสี่แบบ CLRG ชำระบัญชีผ่านระบบเคลียริง เช่น TARGET2, EURO1 หรือ CHIPS INDA ชำระบัญชีในสมุดบัญชีของตัวแทนที่ถูกสั่งซึ่งตัวแทนลูกหนี้มีบัญชี INGA ชำระบัญชีในสมุดบัญชีของตัวแทนผู้สั่งซึ่งตัวแทนที่ถูกสั่งมีบัญชี COVE ชำระบัญชีผ่านการชำระเงินคัฟเวอร์แยกต่างหากที่บรรจุโดย pacs.009
รหัสผู้รับภาระค่าธรรมเนียมหมายความว่าอะไร?
DEBT หมายถึงค่าธรรมเนียมทั้งหมดเป็นภาระของผู้ชำระเงิน (เทียบเท่า MT103 OUR) CRED หมายถึงค่าธรรมเนียมทั้งหมดเป็นภาระของผู้รับเงิน (เทียบเท่า BEN) SHAR หมายถึงค่าธรรมเนียมแบ่งกันระหว่างตัวแทนผู้ชำระเงินและผู้รับเงิน (เทียบเท่า SHA) SLEV หมายถึงค่าธรรมเนียมเป็นไปตามกฎระดับบริการและบังคับสำหรับการโอนเครดิต SEPA
CBPR+ และการย้ายระบบ CBPR+ และการย้ายระบบ
CBPR+ คืออะไร?
CBPR+ (Cross-Border Payments and Reporting Plus) เป็นโปรแกรมของ SWIFT สำหรับนำ ISO 20022 มาใช้ในการส่งข้อความการชำระเงินข้ามพรมแดน เริ่มใช้งานในมีนาคม 2023 และแทนที่ข้อความ MT ด้วย pacs ที่เทียบเท่า CBPR+ กำหนดให้ใช้ pacs.002 สำหรับการสื่อสารสถานะทั้งหมด รองรับข้อมูลคู่สัญญาที่สมบูรณ์กว่าและที่อยู่แบบมีโครงสร้าง และใช้การติดตามด้วย UETR ผ่าน gpi
ช่วง MT/MX ร่วมเป็นอย่างไร?
ช่วงการอยู่ร่วมกันสำหรับคำสั่งการชำระเงินข้ามพรมแดนสิ้นสุดในพฤศจิกายน 2025 ตั้งแต่นั้นมา ข้อความ CBPR+ ต้องใช้รูปแบบ ISO 20022 (MX) บริการแปลที่แปลงระหว่าง MT กับ MX ในช่วงเปลี่ยนผ่านไม่มีให้บริการอีกต่อไปสำหรับกระแสใหม่ ธนาคารต้องส่งและรับข้อความ pacs ดั้งเดิม
เส้นตายที่อยู่แบบมีโครงสร้างพฤศจิกายน 2026 คืออะไร?
ตั้งแต่พฤศจิกายน 2026 SWIFT CBPR+ กำหนดให้ใช้ที่อยู่ไปรษณีย์แบบมีโครงสร้างในข้อความการชำระเงินข้ามพรมแดน บรรทัดที่อยู่แบบไม่มีโครงสร้าง (AdrLine เพียงอย่างเดียว) จะไม่ได้รับการยอมรับสำหรับฟิลด์คู่สัญญาหลักอีกต่อไป อย่างน้อยต้องมี TwnNm และ Ctry โดยแนะนำให้มี StrtNm และ BldgNb หรือ PstBx ช่วยปรับปรุงการคัดกรองการคว่ำบาตรและลดการแก้ไขด้วยมือ
pacs.008 แทนที่ MT103 อย่างไร?
pacs.008 แทนที่ MT103 และ MT103+ สำหรับการโอนเครดิตลูกค้า การแมปหลัก: ฟิลด์ 20 ของ MT103 แมปกับ MsgId หรือ InstrId; ฟิลด์ 32A แยกเป็น IntrBkSttlmDt และ IntrBkSttlmAmt; ฟิลด์ 50a แมปกับ Dbtr และ DbtrAcct; ฟิลด์ 59a แมปกับ Cdtr และ CdtrAcct; ฟิลด์ 70 แมปกับ RmtInf; ฟิลด์ 71A แมปกับ ChrgBr pacs.008 เพิ่ม UETR ข้อมูลการโอนแบบมีโครงสร้าง การระบุตัวตนด้วย LEI และรองรับหลายธุรกรรมต่อข้อความ
pacs.009 แทนที่ MT202 อย่างไร?
pacs.009 แทนที่ MT202 และ MT202COV สำหรับการโอนระหว่างสถาบัน ในกระแสคัฟเวอร์ MT202COV (ที่บรรจุทั้งเงินทุนและข้อมูลลูกค้าพื้นฐาน) แยกอย่างชัดเจน: pacs.009 บรรจุขาเงินทุน ขณะที่ pacs.008 บรรจุคำสั่งลูกค้าโดยตรง การแยกนี้ปรับปรุงคุณภาพข้อมูลและลดปัญหาการกระทบยอด
รายละเอียดทางเทคนิค รายละเอียดทางเทคนิค
ที่อยู่แบบมีโครงสร้างกับไม่มีโครงสร้างคืออะไร?
ที่อยู่แบบมีโครงสร้างใช้อิลิเมนต์ XML แยกสำหรับแต่ละส่วนประกอบ: StrtNm (ถนน), BldgNb (เลขที่อาคาร), PstCd (รหัสไปรษณีย์), TwnNm (เมือง), Ctry (ประเทศ) และอิลิเมนต์ที่เลือกได้เช่น Flr, Room และ DstrctNm ที่อยู่แบบไม่มีโครงสร้างใช้อิลิเมนต์ AdrLine ได้ถึงเจ็ดรายการพร้อมข้อความอิสระ ที่อยู่แบบไฮบริดรวมทั้งสองในช่วงเปลี่ยนผ่าน หลังพฤศจิกายน 2026 CBPR+ กำหนดให้ใช้รูปแบบมีโครงสร้าง
UETR คืออะไรและการติดตาม gpi ทำงานอย่างไร?
UETR (Unique End-to-End Transaction Reference) เป็น UUID v4 ที่สร้างโดยตัวแทนผู้ชำระเงินและบรรจุไม่เปลี่ยนแปลงในทุกขาของการชำระเงิน ปรากฏใน pacs.008, pacs.009, pacs.002, pacs.004, pacs.007 และ pacs.028 SWIFT gpi ใช้ UETR ในการติดตามการชำระเงินผ่านฐานข้อมูล Tracker บนคลาวด์ แต่ละตัวแทนยืนยันการรับและประมวลผล ทำให้มองเห็นได้จากต้นทางถึงปลายทางและติดตาม SLA
รหัสสถานะ pacs.002 ที่พบบ่อยมีอะไรบ้าง?
ACCP หมายถึงยอมรับหลังตรวจสอบโปรไฟล์ลูกค้า ACSP หมายถึงยอมรับและการชำระบัญชีกำลังดำเนินการ ACSC หมายถึงการชำระบัญชีในบัญชีลูกหนี้เสร็จสมบูรณ์ RJCT หมายถึงปฏิเสธ (พร้อมรหัสเหตุผลใน StsRsnInf) PDNG หมายถึงรอดำเนินการต่อ RCVD หมายถึงได้รับแต่ยังไม่ได้ประมวลผล แต่ละสถานะอาจมีรหัสเหตุผลแบบมีโครงสร้าง เช่น AC01 (เลขที่บัญชีไม่ถูกต้อง), AM04 (เงินไม่เพียงพอ) หรือ RC01 (BIC ไม่ถูกต้อง)
รหัสเหตุผลการคืนเงิน pacs.004 ที่พบบ่อยมีอะไรบ้าง?
รหัสเหตุผลการคืนเงินที่พบบ่อย ได้แก่ AC01 (เลขที่บัญชีไม่ถูกต้อง), AC04 (บัญชีปิด), AC06 (บัญชีถูกระงับ), AM04 (เงินไม่เพียงพอ), BE04 (ที่อยู่เจ้าหนี้ขาดหายไป), CUST (ลูกค้าร้องขอ), DUPL (การชำระเงินซ้ำ), FOCR (ตามคำขอยกเลิก) และ FR01 (การฉ้อโกง) รายการทั้งหมดกำหนดไว้ใน External Code Sets ของ ISO 20022
ข้อมูลการโอนแบบมีโครงสร้างคืออะไร?
ข้อมูลการโอนแบบมีโครงสร้างใน pacs.008 ใช้อิลิเมนต์ RmtInf/Strd เพื่อบรรจุการอ้างอิงเอกสาร (เลขที่ใบแจ้งหนี้ ใบลดหนี้) จำนวนเงิน (ครบกำหนด โอนแล้ว ภาษี ส่วนลด) และการอ้างอิงเจ้าหนี้ (การอ้างอิง RF ตาม ISO 11649) ช่วยให้จับคู่ใบแจ้งหนี้อัตโนมัติและกระทบยอดได้ รหัสประเภทเอกสารที่พบบ่อย ได้แก่ CINV (ใบแจ้งหนี้การค้า), CREN (ใบลดหนี้) และ SOAC (ใบแจ้งยอดบัญชี)
LEI คืออะไรและใช้เมื่อใด?
LEI (Legal Entity Identifier) เป็นรหัสตัวอักษรและตัวเลข 20 ตัวตาม ISO 17442 ระบุตัวตนนิติบุคคลที่เข้าร่วมธุรกรรมทางการเงินอย่างเฉพาะเจาะจง ในข้อความ pacs LEI ปรากฏใน OrgId/LEI สำหรับคู่สัญญาและ FinInstnId/LEI สำหรับตัวแทน CBPR+ สนับสนุนการใช้ LEI มากขึ้นสำหรับการระบุตัวตนคู่สัญญาและตัวแทน ช่วยแก้ปัญหาความกำกวมของนิติบุคคลและรองรับข้อกำหนดการรายงานด้านกฎระเบียบ
เกี่ยวกับชุดเครื่องมือ pacs008 เกี่ยวกับชุดเครื่องมือ pacs008
pacs008 ทำอะไร?
pacs008 เป็นชุดเครื่องมือ Python ที่สร้าง ตรวจสอบ และส่งข้อความการชำระเงิน ISO 20022 อ่านข้อมูลการชำระเงินจากแหล่ง CSV, JSON, JSONL, SQLite และ Parquet ตรวจสอบกับ JSON Schema และ XSD ตรวจสอบตัวระบุ IBAN และ BIC ทำความสะอาดข้อมูลให้สอดคล้องกับอักขระ SWIFT และสร้างไฟล์ XML ให้บริการ REST API, CLI และไลบรารี Python
pacs008 รองรับข้อความประเภทใด?
pacs008 รองรับแปดประเภทข้อความ: pacs.002.001.12 (รายงานสถานะ), pacs.003.001.09 (เดบิตโดยตรงลูกค้า), pacs.004.001.11 (การคืนเงิน), pacs.007.001.11 (การกลับรายการ), pacs.008.001.13 (การโอนเครดิตลูกค้า), pacs.009.001.10 (การโอนเครดิตสถาบันการเงิน), pacs.010.001.05 (เดบิตโดยตรงสถาบันการเงิน) และ pacs.028.001.05 (คำขอสถานะการชำระเงิน)
pacs008 ช่วยเรื่องเส้นตายที่อยู่แบบมีโครงสร้าง 2026 อย่างไร?
pacs008 ตรวจสอบฟิลด์ที่อยู่ไปรษณีย์แบบมีโครงสร้างและไฮบริดก่อนสร้าง XML แจ้งเตือนข้อมูลที่อยู่แบบไม่มีโครงสร้างที่จะไม่ผ่านหลังเส้นตายพฤศจิกายน 2026 รองรับรูปแบบไฮบริดก่อนเส้นตายและรูปแบบมีโครงสร้างอย่างเดียวหลังเส้นตาย และรวมการตรวจสอบคุณภาพที่อยู่เข้ากับ CI pipeline และกระบวนการตรวจสอบแบบแบตช์
pacs008 ตรวจสอบข้อมูลโดยไม่สร้าง XML ได้หรือไม่?
ได้ ใช้แฟล็ก CLI --dry-run หรือ endpoint API POST /validate เพื่อตรวจสอบข้อมูลการชำระเงินโดยไม่สร้าง XML ไปป์ไลน์การตรวจสอบจะตรวจ JSON Schema, รูปแบบและ checksum ของ IBAN, โครงสร้าง BIC และความสอดคล้องกับอักขระ SWIFT รหัสออกหรือการตอบกลับ API ระบุว่าการตรวจสอบผ่านหรือไม่ผ่าน