DOPA e-KYC และ Digital ID กับระบบ ERP

e-KYC คืออะไร? ทำไมองค์กรต้องสนใจ

KYC (Know Your Customer) คือกระบวนการรู้จักตัวตนของผู้ใช้บริการหรือคู่ค้า ซึ่งเดิมทีต้องทำแบบ Manual — ใช้สำเนาบัตรประชาชน เซ็นรับรองสำเนา แล้วส่งให้เจ้าหน้าที่ตรวจสอบ ส่วน e-KYC (Electronic Know Your Customer) คือการนำกระบวนการเดียวกันนี้มาทำในรูปแบบดิจิทัล — ยืนยันตัวตนผ่านระบบอิเล็กทรอนิกส์แทนการใช้กระดาษ

ในประเทศไทย e-KYC มีกฎหมายและมาตรฐานรองรับหลายฉบับ:

• พ.ร.บ. การพิสูจน์และยืนยันตัวตนทางดิจิทัล พ.ศ. 2565 — กำหนดกรอบมาตรฐานการพิสูจน์ตัวตนทางดิจิทัลสำหรับหน่วยงานรัฐและเอกชน
• พ.ร.บ. ป้องกันและปราบปรามการฟอกเงิน — กำหนดให้สถาบันการเงินและหน่วยงานที่เกี่ยวข้องต้องมีกระบวนการ KYC
• PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล) — กำกับดูแลการเก็บ ใช้ และเปิดเผยข้อมูลส่วนบุคคลที่เกิดขึ้นในกระบวนการ e-KYC

รายการ	KYC แบบเดิม (กระดาษ)	e-KYC (ดิจิทัล)
ขั้นตอน	ถ่ายสำเนาบัตร → เซ็นรับรอง → ส่งเจ้าหน้าที่ → ตรวจสอบด้วยตา	สแกนบัตร/ใบหน้า → API ตรวจสอบอัตโนมัติ → ได้ผลทันที
เวลาดำเนินการ	1-5 วันทำการ	ไม่เกิน 30 วินาที
ค่าใช้จ่าย	ค่ากระดาษ + ค่าแรงเจ้าหน้าที่ + ค่าจัดเก็บเอกสาร	ค่า API ต่อ transaction (ต่ำกว่ามาก)
ความแม่นยำ	ขึ้นอยู่กับเจ้าหน้าที่ — อาจผิดพลาดจากการตรวจสอบด้วยตา	สูงมาก — ตรวจสอบกับฐานข้อมูลทะเบียนราษฎรโดยตรง
ความเสี่ยงปลอมแปลง	สูง — สำเนาบัตรปลอมได้ง่าย	ต่ำมาก — ใช้ biometric + ฐานข้อมูลจริง
การจัดเก็บ	ต้องเก็บเอกสารตัวจริง ใช้พื้นที่มาก	บันทึกเป็น digital log — ค้นหาง่าย ไม่เปลืองพื้นที่

DOPA API — ระบบยืนยันตัวตนของกรมการปกครอง

DOPA (Department of Provincial Administration) หรือ กรมการปกครอง กระทรวงมหาดไทย เป็นผู้ดูแล ฐานข้อมูลทะเบียนราษฎร ของคนไทยทั้งประเทศ — ข้อมูลบัตรประชาชน รูปถ่ายใบหน้า ลายนิ้วมือ ทั้งหมดอยู่ที่ DOPA

DOPA เปิดให้หน่วยงานภาครัฐและเอกชนที่ได้รับอนุญาตสามารถเชื่อมต่อผ่าน DOPA API เพื่อตรวจสอบตัวตนของบุคคลได้ โดยแบ่งบริการเป็น 3 ระดับ:

ระดับบริการ	วิธีการตรวจสอบ	ระดับความน่าเชื่อถือ (IAL)	เหมาะกับ
ระดับ 1: Card Verification	ส่งเลขบัตร + ชื่อ-นามสกุล → DOPA ตรวจว่าข้อมูลตรงกับทะเบียนราษฎรหรือไม่	IAL 1.3	ตรวจสอบข้อมูลเบื้องต้น, ลงทะเบียน Vendor
ระดับ 2: Face Verification	ถ่ายรูปใบหน้า → DOPA เปรียบเทียบกับรูปในฐานทะเบียนราษฎร	IAL 2.2	เปิดบัญชี, ยืนยันตัวตนพนักงาน, e-Signature
ระดับ 3: ThaiD Authentication	ยืนยันตัวตนผ่านแอป ThaiD + Face Verification + ข้อมูลชิปบัตร	IAL 2.3	Login ระบบสำคัญ, อนุมัติธุรกรรมการเงิน, ลงนามสัญญา

มาตรฐาน IAL/AAL — ระดับความน่าเชื่อถือของ Digital ID

เมื่อพูดถึง e-KYC จะเจอคำว่า IAL และ AAL อยู่เสมอ — ทั้งสองเป็นมาตรฐานที่ใช้วัดระดับความน่าเชื่อถือของการพิสูจน์และยืนยันตัวตน โดยอ้างอิงจาก NIST SP 800-63 (Digital Identity Guidelines) ของสหรัฐอเมริกา และ ETDA (สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์) ได้นำมาปรับใช้เป็นมาตรฐานของประเทศไทย

IAL (Identity Assurance Level) — ระดับความน่าเชื่อถือของการพิสูจน์ตัวตน

วัดว่า "คุณพิสูจน์ได้แค่ไหนว่าคนนี้เป็นใคร":

ระดับ	วิธีพิสูจน์	ตัวอย่างการใช้งาน
IAL 1	Self-claim — ผู้ใช้กรอกข้อมูลเอง ไม่มีการตรวจสอบ	สมัครสมาชิกเว็บทั่วไป, สมัครรับข่าวสาร
IAL 2	ตรวจสอบเอกสารยืนยันตัวตน (Remote หรือ In-person) + อาจมี biometric	เปิดบัญชีธนาคาร, ลงทะเบียน Vendor ใน ERP, HR Onboarding
IAL 3	ตรวจสอบเอกสาร + biometric + เจ้าหน้าที่ยืนยัน In-person	ออกหนังสือเดินทาง, ทำนิติกรรมมูลค่าสูง, ลงนามสัญญาภาครัฐ

AAL (Authenticator Assurance Level) — ระดับความน่าเชื่อถือของการยืนยันตัวตน

วัดว่า "คุณมั่นใจแค่ไหนว่าคนที่กำลัง Login คือคนคนเดียวกับที่ลงทะเบียน":

ระดับ	วิธียืนยัน	ตัวอย่าง
AAL 1	Single-factor — ใช้ Password อย่างเดียว	Login เว็บทั่วไป
AAL 2	Multi-factor — Password + OTP/2FA หรือ ThaiD	Login ระบบ ERP, Internet Banking, ระบบ อนุมัติเบิกจ่าย
AAL 3	Hardware token + biometric — Phishing-resistant	ระบบความมั่นคงแห่งชาติ, ระบบการเงินมูลค่าสูงมาก

5+ Use Cases: e-KYC กับระบบ ERP

e-KYC ไม่ได้มีประโยชน์แค่ตอน Login เท่านั้น แต่สามารถประยุกต์ใช้กับหลายจุดในระบบ ERP ที่ต้องพิสูจน์ตัวตน:

1. ยืนยันตัวตน Vendor ใหม่ (ป้องกัน Vendor ปลอม)

เมื่อ ระบบจัดซื้อจัดจ้าง รับลงทะเบียน Vendor ใหม่ สามารถใช้ DOPA API ระดับ 1 หรือ 2 ตรวจสอบว่าบุคคลที่แจ้งว่าเป็นกรรมการบริษัทมีตัวตนจริง — ป้องกันการสร้าง Vendor ผีเพื่อเบิกจ่ายเงินให้ตัวเอง

2. e-Signature อนุมัติเบิกจ่าย

การ อนุมัติเบิกจ่าย มูลค่าสูง สามารถผูกกับ e-KYC ระดับ 2 (Face Verification) เพื่อยืนยันว่าผู้อนุมัติเป็นตัวจริง — ไม่ใช่แค่คนที่รู้ Password

3. HR Onboarding — ยืนยันตัวตนพนักงานใหม่

ระบบ HR สามารถใช้ e-KYC ตรวจสอบข้อมูลพนักงานใหม่กับฐานทะเบียนราษฎรได้ทันที — ไม่ต้องรอสำเนาบัตรประชาชน ไม่ต้องเสียเวลาตรวจสอบด้วยตา

4. ป้องกัน Ghost Employee (พนักงานผี)

ปัญหา "พนักงานผี" ที่มีชื่อในระบบแต่ไม่มีตัวตนจริง สามารถป้องกันได้ด้วย Face Verification ประจำเดือนหรือประจำปี — ยืนยันว่าพนักงานทุกคนในระบบ HR ยังมีตัวตนจริง

5. ตรวจสอบผู้มีอำนาจลงนามสัญญา

ก่อนลงนามสัญญา e-Signature มูลค่าสูง สามารถใช้ ThaiD (ระดับ 3) ยืนยันว่าผู้ลงนามเป็นบุคคลที่มีอำนาจจริงตามหนังสือรับรองบริษัท

Use Case	ปัญหาที่แก้	ระดับ IAL ที่ต้องการ	โมดูล ERP ที่เกี่ยวข้อง
ยืนยัน Vendor ใหม่	Vendor ปลอม / นอมินี	IAL 1-2	จัดซื้อจัดจ้าง
e-Signature อนุมัติเบิกจ่าย	ผู้อนุมัติไม่ใช่ตัวจริง	IAL 2-3	อนุมัติเบิกจ่าย, บัญชี
HR Onboarding	ข้อมูลพนักงานไม่ตรง	IAL 2	HR
ป้องกัน Ghost Employee	พนักงานผีในระบบ	IAL 2	HR
ลงนามสัญญา	ผู้ลงนามไม่มีอำนาจ	IAL 3	e-Signature, จัดซื้อ
Login ระบบ ERP	ถูก Phishing / ขโมย Password	AAL 2	ทุกโมดูล (ThaiD Login)

DOPA API Flow — เชื่อมต่ออย่างไร (Technical)

สำหรับทีม IT ที่ต้องการเข้าใจ Technical Flow ของการเชื่อมต่อ DOPA API กับระบบ ERP มีขั้นตอนดังนี้:

OAuth 2.0 Flow

DOPA API ใช้มาตรฐาน OAuth 2.0 ในการ Authentication — ระบบ ERP ต้องลงทะเบียนเป็น Relying Party (RP) กับ DOPA ก่อน จึงจะได้ Client ID และ Client Secret สำหรับเรียกใช้ API

Sequence ของการทำงาน

1. ผู้ใช้ ขอทำธุรกรรมที่ต้องยืนยันตัวตนในระบบ ERP (เช่น อนุมัติเบิกจ่าย)
2. ERP ส่ง request ไปยัง DOPA API พร้อม token และข้อมูลที่ต้องตรวจสอบ
3. DOPA API ตรวจสอบข้อมูลกับ ฐานทะเบียนราษฎร
4. DOPA API ส่ง result กลับมา (match / not match / error)
5. ERP บันทึก consent log + ผลการตรวจสอบ + ดำเนินธุรกรรมต่อ (หรือปฏิเสธ)
6. ผู้ใช้ ได้รับแจ้งผลการยืนยันตัวตน

ข้อกำหนดสำคัญ

• ลงทะเบียนกับ DOPA — ต้องยื่นคำขอและได้รับอนุญาตก่อนใช้งาน API
• SSL/TLS บังคับ — การเชื่อมต่อต้องเข้ารหัสทั้งหมด (HTTPS only)
• Consent Log — ต้องเก็บบันทึกความยินยอมของผู้ใช้ทุกครั้งที่ส่งข้อมูลไปตรวจสอบ (ตาม PDPA)
• Rate Limiting — DOPA API มีข้อจำกัดจำนวน request ต่อวัน
• IP Whitelist — ต้องแจ้ง IP ของเซิร์ฟเวอร์ ERP ให้ DOPA ล่วงหน้า

ความเสี่ยงและข้อควรระวัง

แม้ e-KYC จะช่วยเพิ่มความปลอดภัยและลดขั้นตอน แต่ก็มีความเสี่ยงที่ต้องจัดการ:

ความเสี่ยง	รายละเอียด	วิธีจัดการ
PDPA Compliance	ส่งข้อมูลส่วนบุคคลไป DOPA โดยไม่ได้ consent	ขอ consent ก่อนทุกครั้ง + เก็บ consent log + แจ้งวัตถุประสงค์ชัดเจน
Data Minimization	ดึงข้อมูลจาก DOPA มากเกินจำเป็น	ขอเฉพาะข้อมูลที่จำเป็น — เช่น ถ้าแค่ยืนยันตัวตน ไม่ต้องขอที่อยู่
API Downtime	DOPA API ล่ม ทำให้ไม่สามารถยืนยันตัวตนได้	มี Fallback mechanism — เช่น ใช้ OTP แทนชั่วคราว + retry queue
False Rejection	Face Verification ปฏิเสธคนจริง (เช่น ใบหน้าเปลี่ยนจากอายุ)	มี Manual override process โดยเจ้าหน้าที่ระดับสูง + บันทึก Audit log
Data Breach	ข้อมูลที่ส่ง/รับจาก DOPA ถูกดักจับ	บังคับใช้ TLS 1.3 + ไม่เก็บ biometric data ฝั่ง ERP + encrypt at rest

เปรียบเทียบ: DOPA e-KYC vs NDID vs Private ID

ในประเทศไทยมีระบบยืนยันตัวตนดิจิทัลหลายตัว — แต่ละตัวมีจุดเด่นต่างกัน:

รายการ	DOPA e-KYC	NDID	Private ID (เอกชน)
ผู้ให้บริการ	กรมการปกครอง (ภาครัฐ)	บริษัท เนชั่นแนลดิจิทัลไอดี (กึ่งรัฐ)	บริษัทเอกชน (เช่น LINE, TrueMoney)
ฐานข้อมูล	ทะเบียนราษฎร (ครบทุกคน)	เชื่อมกับหลายฐาน (ธนาคาร, โทรคมนาคม)	ฐานลูกค้าของตัวเอง
ค่าใช้จ่าย	ต่ำ (ราคาภาครัฐ)	ปานกลาง	แตกต่างกันไป
ระดับ IAL สูงสุด	IAL 2.3 (ผ่าน ThaiD)	IAL 2.3	IAL 1-2 (แล้วแต่ผู้ให้บริการ)
เหมาะกับ	หน่วยงานรัฐ, ระบบ ERP ภาครัฐ	สถาบันการเงิน, ประกันภัย	แอปเอกชน, e-Commerce
รองรับ Face Verification	รองรับ	รองรับ (ผ่าน IdP)	บางรายรองรับ
จุดเด่น	เชื่อมตรงกับทะเบียนราษฎร ครอบคลุมคนไทยทุกคน	Federated Identity — ใช้ตัวตนจากหลายแหล่ง	ง่าย รวดเร็ว ไม่ต้องขออนุญาตภาครัฐ

Saeree ERP + e-KYC

e-KYC ไม่ใช่แค่เรื่องของ Login — แต่เป็นรากฐานของความน่าเชื่อถือในทุกธุรกรรมดิจิทัลขององค์กร ตั้งแต่การลงทะเบียน Vendor ไปจนถึงการอนุมัติเบิกจ่ายและลงนามสัญญา

- ไพฑูรย์ บุตรี, ผู้เชี่ยวชาญด้านระบบเน็ตเวิร์คและระบบความปลอดภัยเซิร์ฟเวอร์ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด

สรุป — e-KYC คือโครงสร้างพื้นฐานของ ERP ยุคดิจิทัล

ประเด็น	สรุป
e-KYC คืออะไร	การยืนยันตัวตนแบบดิจิทัล — แทนการใช้สำเนาบัตรประชาชน
DOPA API	ระบบตรวจสอบตัวตนของกรมการปกครอง 3 ระดับ (Card / Face / ThaiD)
IAL / AAL	มาตรฐานวัดความน่าเชื่อถือของการพิสูจน์ (IAL) และยืนยันตัวตน (AAL)
Use Cases ใน ERP	ยืนยัน Vendor, e-Signature, HR Onboarding, ป้องกัน Ghost Employee, ลงนามสัญญา
Saeree ERP	รองรับ ThaiD Login + กำลังพัฒนา e-KYC Integration เพิ่มเติม
ข้อควรระวัง	ต้องขอ consent (PDPA), ใช้ Data Minimization, มี Fallback เมื่อ API ล่ม

หากองค์กรของคุณต้องการระบบ ERP ที่รองรับ Digital ID และ e-KYC ครบวงจร — ตั้งแต่ ThaiD Login ไปจนถึงการยืนยัน Vendor และ e-Signature สามารถนัดหมาย Demo หรือติดต่อทีมที่ปรึกษา Saeree ERP ได้เลย — อ่านเพิ่มเติมเกี่ยวกับ ระบบรักษาความปลอดภัยของ Saeree ERP และ ระบบ 2FA ได้ที่นี่

แหล่งอ้างอิง

• กรมการปกครอง — กระทรวงมหาดไทย (DOPA)
• สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA)
• NIST SP 800-63 — Digital Identity Guidelines
• ราชกิจจานุเบกษา — พ.ร.บ. การพิสูจน์และยืนยันตัวตนทางดิจิทัล พ.ศ. 2565
• สำนักงานพัฒนารัฐบาลดิจิทัล (DGA)