คำตอบตรงไปตรงมาสำหรับผู้บริหารการเงิน ทีมปฏิบัติการชำระเงิน วิศวกร และผู้ตรวจสอบ คำถามเรียบเรียงตามวิธีที่ผู้คนถามกันจริง หากต้องการรายละเอียดทางเทคนิคเชิงลึก โปรดดูเอกสารอ้างอิงทางเทคนิค
สำหรับผู้นำด้านบริหารเงินและการเงิน#
pain.001 คืออะไร อธิบายในย่อหน้าเดียว
pain.001 คือข้อความมาตรฐาน ISO 20022 ที่ลูกค้าส่งให้ธนาคารเพื่อสั่งโอนเงิน — เป็นรูปแบบ XML ที่สืบทอดจากรูปแบบเดิมอย่าง SWIFT MT101 และไฟล์แบบ flat file ภายในประเทศ ธนาคารของคุณจะตรวจไฟล์นั้นกับสกีมาและกฎเกณฑ์ของสกีมก่อนตอบรับ ส่วน Pain001 (ตัวซอฟต์แวร์) จะสร้างไฟล์เหล่านั้นจากข้อมูลที่คุณมีอยู่แล้ว และพิสูจน์ว่าไฟล์ถูกต้องก่อนที่คุณจะส่ง
pain.001 กับ pain.008 ต่างกันอย่างไร
ต่างกันที่ทิศทางของเงิน pain.001 ใช้สั่งโอนเงินออก — คุณเป็นฝ่ายจ่าย ส่วน pain.008 ใช้สั่งหักบัญชีอัตโนมัติ — คุณเป็นฝ่ายเรียกเก็บเงินที่ค้างชำระภายใต้หนังสือยินยอม Pain001 สร้างได้ทั้งสองแบบ ได้แก่ pain.001 จำนวนสิบเวอร์ชัน (.001.03 ถึง .001.12) และ pain.008.001.02
เรายังส่งไฟล์ MT101 อยู่ การย้ายระบบเร่งด่วนเพียงใด
เร่งด่วน SWIFT ได้ยกเลิกข้อความ MT หมวด 1, 2 และ 9 สำหรับคำสั่งชำระเงินระหว่างธนาคารข้ามพรมแดนไปแล้วเมื่อพฤศจิกายน 2025 ส่วนช่องทางสำหรับลูกค้าองค์กรที่ยังรับ MT อยู่นั้น ขึ้นอยู่กับดุลยพินิจของแต่ละธนาคารและเหลือเวลาไม่มาก ตัวโหลด MT101 จะแปลงกระแสงาน MT101 ที่มีอยู่ให้เป็น pain.001 ที่ผ่านการตรวจสอบ โดยไม่ต้องคีย์ข้อมูลใหม่
กำหนดเส้นตายเรื่องที่อยู่แบบมีโครงสร้างในเดือนพฤศจิกายน 2026 มีผลกับเราอย่างไร
ตั้งแต่ปลายเดือนพฤศจิกายน 2026 เป็นต้นไป การชำระเงินข้ามพรมแดนตาม CBPR+ จะไม่รับที่อยู่ทางไปรษณีย์ที่ไม่มีโครงสร้างเลยอีกต่อไป ที่อยู่ต้องเป็นแบบมีโครงสร้างหรือแบบผสม — ใช้องค์ประกอบแยกส่วน เช่น เมือง (
Pain001 มีค่าใช้จ่ายเท่าใด
ไม่มีค่าใช้จ่าย ส่วนหลักเผยแพร่ภายใต้สัญญาอนุญาตคู่ 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 ชุดใดบ้าง
มีกฎเกณฑ์ของสกีมมาพร้อมในตัวห้าชุด ได้แก่ SEPA Credit Transfer (sepa-sct), SEPA Instant (sepa-inst), SEPA Direct Debit Core (sepa-sdd), SEPA B2B (sepa-b2b) และการโอนเงินข้ามพรมแดน (xborder-ct) ใช้ --scheme เพื่อดูกฎทุกข้อที่ผ่านหรือไม่ผ่าน
ข้อมูลของเราอยู่ใน Excel มีข้อควรระวังอะไรบ้าง
Excel มักแปลงข้อความที่มีลักษณะคล้าย IBAN ให้กลายเป็นตัวเลขโดยไม่แจ้งเตือน ตัวโหลด Excel อ่านไฟล์ .xlsx/.xlsm ได้โดยตรง และจะหยุดทำงานทันทีหากคอลัมน์ IBAN มีเซลล์ที่เป็นตัวเลข — ความเสียหายของข้อมูลจึงถูกจับได้ตั้งแต่ตอนโหลด ไม่ใช่ที่ธนาคาร
รองรับชุดข้อมูล 500,000 แถวได้อย่างไร
--streaming จะประมวลผลข้อมูลนำเข้าเป็นก้อนโดยจำกัดการใช้หน่วยความจำ (ค่าเริ่มต้น 1,000 รายการ) และส่งออกแต่ละก้อนเป็นไฟล์ XML ของตนเองพร้อมยอดควบคุมที่คำนวณขึ้นใหม่อย่างถูกต้อง ด้วยเหตุผลเดียวกัน REST API จึงมี POST /api/v1/generate/async พร้อมการตรวจสอบสถานะงาน
สำหรับวิศวกรและสถาปนิกระบบ#
ควรผสานระบบอย่างไร — ไลบรารี CLI หรือ API
ทั้งสามช่องทางเป็นช่องทางหลักเท่าเทียมกัน ได้แก่ Python API ที่กำหนดชนิดข้อมูลชัดเจน, CLI ที่ให้รหัสสถานะการออกซึ่งเหมาะกับ CI และไมโครเซอร์วิส FastAPI (pain001 serve) ที่มี endpoint แบบซิงโครนัส งานอะซิงโครนัส การตรวจสถานะระบบ และเมตริก Prometheus ทั้งหมดใช้ไปป์ไลน์การตรวจสอบชุดเดียวกัน ผลลัพธ์จึงไม่แตกต่างกันระหว่างช่องทาง
การสร้าง XML ปลอดภัยจากการปัดเศษของเลขทศนิยมจริงหรือไม่
จำนวนเงินเป็น 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 รายการถูกกำกับไว้ว่าอ่านอย่างเดียวและให้ผลเหมือนเดิมทุกครั้งที่เรียกซ้ำ
ใครเป็นผู้ดูแล Pain001
Sebastien Rousseau ผู้นำด้านวิศวกรรมฟินเทคซึ่งประจำอยู่ที่ลอนดอน ร่วมกับผู้ร่วมพัฒนาจากชุมชน การพัฒนาเปิดเผยต่อสาธารณะบน GitHub เวอร์ชันที่เผยแพร่อยู่บน PyPI และมีการบันทึกการเปลี่ยนแปลงพร้อมระบุเวอร์ชันในทุกครั้งที่เผยแพร่