คำถาม

Pain001 FAQ สำหรับบริหารเงิน ปฏิบัติการ วิศวกรรม และตรวจสอบ

คำตอบตรงไปตรงมาสำหรับผู้บริหารการเงิน ทีมปฏิบัติการชำระเงิน วิศวกร และผู้ตรวจสอบ เรียบเรียงตามวิธีที่ผู้คนถามกันจริง

คำตอบตรงไปตรงมาสำหรับผู้บริหารการเงิน ทีมปฏิบัติการชำระเงิน วิศวกร และผู้ตรวจสอบ คำถามเรียบเรียงตามวิธีที่ผู้คนถามกันจริง หากต้องการรายละเอียดทางเทคนิคเชิงลึก โปรดดูเอกสารอ้างอิงทางเทคนิค


สำหรับผู้นำด้านบริหารเงินและการเงิน#

pain.001 คือข้อความมาตรฐาน ISO 20022 ที่ลูกค้าส่งให้ธนาคารเพื่อสั่งโอนเงิน และเป็นรูปแบบ XML ที่สืบทอดจากรูปแบบเดิมอย่าง SWIFT MT101 และไฟล์แบบ flat file ภายในประเทศ ธนาคารของคุณจะตรวจไฟล์นั้นกับสกีมาและกฎเกณฑ์ของสกีมก่อนตอบรับ ส่วน Pain001 (ตัวซอฟต์แวร์) จะสร้างไฟล์เหล่านั้นจากข้อมูลที่คุณมีอยู่แล้ว และพิสูจน์ว่าไฟล์ถูกต้องก่อนที่คุณจะส่ง

ต่างกันที่ทิศทางของเงิน pain.001 ใช้สั่งโอนเงินออก คือคุณเป็นฝ่ายจ่าย ส่วน pain.008 ใช้สั่งหักบัญชีอัตโนมัติ คือคุณเป็นฝ่ายเรียกเก็บเงินที่ค้างชำระภายใต้หนังสือยินยอม Pain001 สร้างได้ทั้งสองแบบ ได้แก่ pain.001 จำนวนสิบเวอร์ชัน (.001.03 ถึง .001.12) และ pain.008.001.02

เร่งด่วน SWIFT ได้ยกเลิกข้อความ MT หมวด 1, 2 และ 9 สำหรับคำสั่งชำระเงินระหว่างธนาคารข้ามพรมแดนไปแล้วเมื่อพฤศจิกายน 2025 ส่วนช่องทางสำหรับลูกค้าองค์กรที่ยังรับ MT อยู่นั้น ขึ้นอยู่กับดุลยพินิจของแต่ละธนาคารและเหลือเวลาไม่มาก ตัวโหลด MT101 จะแปลงกระแสงาน MT101 ที่มีอยู่ให้เป็น pain.001 ที่ผ่านการตรวจสอบ โดยไม่ต้องคีย์ข้อมูลใหม่

Swift เคยวางแผนจะหยุดรับที่อยู่ทางไปรษณีย์ที่ไม่มีโครงสร้างเลยในการชำระเงินข้ามพรมแดนตาม CBPR+ ในเดือนพฤศจิกายน 2026 แต่เมื่อเดือนสิงหาคม 2026 ได้เลื่อนวันดังกล่าวออกไปและจะประกาศวันใหม่ภายในเดือนธันวาคม 2026 ทั้งนี้กฎยังไม่เปลี่ยน: ที่อยู่ต้องเป็นแบบมีโครงสร้างหรือแบบผสม โดยใช้องค์ประกอบแยกส่วน เช่น เมือง (<TwnNm>) และประเทศ (<Ctry>) แทนบรรทัดข้อความอิสระ หากข้อมูลหลักของคุณเก็บที่อยู่เป็นก้อนข้อความ งานที่ต้องทำอยู่ที่ข้อมูลของคุณ ไม่ใช่ที่การเชื่อมต่อกับธนาคาร จึงควรเริ่มจากตรงนั้น รายงานสรุปปี 2026 อธิบายไทม์ไลน์นี้อย่างละเอียด

ไม่มีค่าใช้จ่าย ส่วนหลักเผยแพร่ภายใต้สัญญาอนุญาตคู่ Apache-2.0 / MIT ส่วนแพ็กเกจเสริมใช้ Apache-2.0 อนุญาตให้ใช้ในเชิงพาณิชย์ แก้ไข และเผยแพร่ต่อได้ทั้งหมด เพื่อเทียบเคียงขนาดค่าใช้จ่าย เฉพาะ SDK สำหรับการแปลงข้อความของ SWIFT อย่างเดียวก็มีราคาปีละ €10,000–30,000


สำหรับฝ่ายปฏิบัติการชำระเงิน#

สาเหตุที่พบซ้ำสี่ประการ ได้แก่ การละเมิดสกีมา (ผิดองค์ประกอบ ผิดเวอร์ชัน ผิด namespace), รหัสระบุตัวตนไม่ถูกต้อง (IBAN ตรวจ checksum ไม่ผ่าน, BIC ผิดรูปแบบ), ยอดควบคุมไม่ตรงกัน (NbOfTxs / CtrlSum ไม่ตรงกับรายการธุรกรรม) และอักขระที่อยู่นอกชุดอักขระละตินของ ISO 20022 Pain001 ตรวจครบทั้งสี่ข้อตั้งแต่ก่อนที่ไฟล์จะเกิดขึ้น ได้แก่ การตรวจ JSON Schema รายระเบียน, การตรวจ IBAN ด้วย mod-97 และ BIC ตาม ISO 9362, การคำนวณยอดควบคุมขึ้นใหม่, การถอดอักษรให้อยู่ในชุดอักขระที่รองรับ และการตรวจ XML ที่สร้างขึ้นด้วย XSD เป็นขั้นสุดท้าย

ได้ ใช้ pain001 --dry-run (หรือคำสั่งย่อย validate หรือ POST /api/v1/validate) รหัสสถานะการออก 0 หมายถึงถูกต้อง ส่วน 1 หมายถึงการตรวจสอบไม่ผ่านพร้อมข้อผิดพลาดระดับฟิลด์ คุณสามารถผูกไว้กับ CI หรือรายการตรวจสอบก่อนส่งไฟล์ได้

มีกฎเกณฑ์ของสกีมมาพร้อมในตัวห้าชุด ได้แก่ SEPA Credit Transfer (sepa-sct), SEPA Instant (sepa-inst), SEPA Direct Debit Core (sepa-sdd), SEPA B2B (sepa-b2b) และการโอนเงินข้ามพรมแดน (xborder-ct) ใช้ --scheme <name> --explain เพื่อดูกฎทุกข้อที่ผ่านหรือไม่ผ่าน

Excel มักแปลงข้อความที่มีลักษณะคล้าย IBAN ให้กลายเป็นตัวเลขโดยไม่แจ้งเตือน ตัวโหลด Excel อ่านไฟล์ .xlsx/.xlsm ได้โดยตรง และจะหยุดทำงานทันทีหากคอลัมน์ IBAN มีเซลล์ที่เป็นตัวเลข ความเสียหายของข้อมูลจึงถูกจับได้ตั้งแต่ตอนโหลด ไม่ใช่ที่ธนาคาร

--streaming จะประมวลผลข้อมูลนำเข้าเป็นก้อนโดยจำกัดการใช้หน่วยความจำ (ค่าเริ่มต้น 1,000 รายการ) และส่งออกแต่ละก้อนเป็นไฟล์ XML ของตนเองพร้อมยอดควบคุมที่คำนวณขึ้นใหม่อย่างถูกต้อง ด้วยเหตุผลเดียวกัน REST API จึงมี POST /api/v1/generate/async พร้อมการตรวจสอบสถานะงาน


สำหรับวิศวกรและสถาปนิกระบบ#

ทั้งสามช่องทางเป็นช่องทางหลักเท่าเทียมกัน ได้แก่ Python API ที่กำหนดชนิดข้อมูลชัดเจน, CLI ที่ให้รหัสสถานะการออกซึ่งเหมาะกับ CI และไมโครเซอร์วิส FastAPI (pain001 serve) ที่มี endpoint แบบซิงโครนัส งานอะซิงโครนัส การตรวจสถานะระบบ และเมตริก Prometheus ทั้งหมดใช้ไปป์ไลน์การตรวจสอบชุดเดียวกัน ผลลัพธ์จึงไม่แตกต่างกันระหว่างช่องทาง

จำนวนเงินเป็น decimal.Decimal ตลอดทั้งกระบวนการสร้างไฟล์และการตรวจสอบตามกฎของสกีม โดยอ่านค่าเป็นทศนิยมที่แม่นยำ รวมยอดเป็นทศนิยมที่แม่นยำ และแสดงผลโดยไม่ผ่านรูปแบบเลขทศนิยมลอยตัว ส่วนยอดควบคุมจะคำนวณขึ้นใหม่จากระเบียนที่ผ่านการตรวจสอบ ไม่ใช้ค่าที่มากับข้อมูลนำเข้า

การอ่าน XML ทั้งหมดผ่าน defusedxml (ซึ่งสกัดการโจมตีแบบ XXE และการขยาย entity) และไม่มี lxml อยู่ในสายพึ่งพา ข้อมูลนำเข้าต้องผ่านตัวตรวจสอบการลัดเลาะเส้นทางไฟล์ อิมเมจ Docker ทำงานโดยไม่ใช้สิทธิ์ root มีการสร้าง SBOM รูปแบบ CycloneDX สำหรับการเผยแพร่ส่วนหลัก และสามารถปิดการค้นหาปลั๊กอินจากบุคคลที่สามได้ทั้งหมดด้วย PAIN001_DISABLE_PLUGINS=1

ส่วนหลักกำหนดเกณฑ์บังคับใน CI ให้ความครอบคลุมของโค้ดระดับบรรทัดและระดับสาขาเท่ากับ 100% (ตรวจสอบยืนยันได้: 3,828 บรรทัด, 926 สาขา ที่ระดับ 100%), ใช้ mypy แบบเข้มงวด, ความครอบคลุมของ docstring 100%, การตรวจความปลอดภัยด้วย Bandit และ pip-audit รวมถึงการสแกนด้วย CodeQL แพ็กเกจเสริมก็ยึดวินัยความครอบคลุม 100% เช่นเดียวกัน

ได้ ผ่านกลุ่ม entry point สำหรับปลั๊กอินสี่กลุ่ม (pain001.loaders, pain001.validators, pain001.schemes, pain001.writers) ตัวโหลด Excel เองก็เป็นปลั๊กอินที่ใช้โปรโตคอลสาธารณะนี้ จึงใช้เป็นตัวอย่างอ้างอิงในการพัฒนาได้ด้วย


สำหรับผู้ตรวจสอบและฝ่ายกำกับดูแล#

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

ไม่ ทุกองค์ประกอบ (CLI, ไลบรารี, REST API, เซิร์ฟเวอร์ MCP และ LSP) ทำงานภายในเครื่องทั้งหมด ไม่มีการเก็บข้อมูลการใช้งาน ไม่มีการเรียกกลับไปยังบริการ SaaS และไม่มีบริการตรวจสอบภายนอก เซิร์ฟเวอร์ MCP สื่อสารผ่าน stdio เท่านั้น และเครื่องมือทั้ง 17 รายการถูกกำกับไว้ว่าอ่านอย่างเดียวและให้ผลเหมือนเดิมทุกครั้งที่เรียกซ้ำ

Sebastien Rousseau ผู้นำด้านวิศวกรรมฟินเทคซึ่งประจำอยู่ที่ลอนดอน ร่วมกับผู้ร่วมพัฒนาจากชุมชน การพัฒนาเปิดเผยต่อสาธารณะบน GitHub เวอร์ชันที่เผยแพร่อยู่บน PyPI และมีการบันทึกการเปลี่ยนแปลงพร้อมระบุเวอร์ชันในทุกครั้งที่เผยแพร่