การทดสอบ KYB เป็นงานที่ต่างจากงานทดสอบทั่วไป เพราะสิ่งที่ถูกตรวจไม่ใช่บุคคลคนหนึ่งแต่เป็นองค์กรซึ่งมีโครงสร้างซ้อนกันได้หลายชั้น บทความนี้จะพาคุณดูว่าขั้นตอนนี้ต้องเก็บข้อมูลอะไร ทำไมสถานะการตรวจสอบจึงเป็นส่วนหนึ่งของงานออกแบบ และทีมควรเตรียมอะไรก่อนเริ่มทดสอบ
KYB คืออะไร และต่างจาก KYC ตรงไหน?
KYB ย่อมาจากการรู้จักธุรกิจของลูกค้า เป็นขั้นตอนที่สถาบันการเงินและผู้ให้บริการหลายประเภทใช้ทำความเข้าใจว่าลูกค้าที่เป็นองค์กรคือใคร ใครเป็นเจ้าของที่แท้จริง และธุรกิจที่ทำมีความเสี่ยงด้านใด ขั้นตอนนี้เป็นส่วนหนึ่งของแนวปฏิบัติด้านการป้องกันการฟอกเงินที่ใช้กันทั่วไป
ความต่างจาก KYC อยู่ที่หน่วยของสิ่งที่ถูกตรวจ KYC ตรวจเอกสารและตัวตนของบุคคลคนหนึ่ง ซึ่งมีจุดสิ้นสุดชัดเจนเมื่อยืนยันได้ว่าเป็นบุคคลจริงและตรงกับเอกสาร KYB ตรวจองค์กร ซึ่งไม่มีจุดสิ้นสุดง่าย ๆ เพราะเบื้องหลังองค์กรหนึ่งอาจมีบริษัทแม่อีกหลายชั้นและมีผู้ถือหุ้นที่กระจายอยู่หลายประเทศ
ด้วยเหตุนี้ ขั้นตอน KYB จึงมักใช้เวลานานกว่า และมีโอกาสที่คำตอบจะเป็นว่า ยังสรุปไม่ได้ มากกว่าขั้นตอนของบุคคล การออกแบบระบบจึงต้องรองรับสถานะกลางทางไว้ตั้งแต่ต้น ไม่ใช่คิดว่าเรื่องจะจบในครั้งเดียว
ข้อมูลและเอกสารที่มักถูกขอ
รายการที่ขอแตกต่างกันไปตามประเภทกิจการและข้อกำหนดที่เกี่ยวข้อง แต่ต่อไปนี้คือกลุ่มข้อมูลที่พบได้บ่อย
- หลักฐานการจดทะเบียนขององค์กร เช่น หนังสือรับรองการจดทะเบียน
- เลขทะเบียนบริษัทของประเทศที่จดทะเบียน
- เลขประจำตัวผู้เสียภาษีหรือเลข VAT ในกรณีที่มี
- หลักฐานที่ตั้งสำนักงานจดทะเบียน
- ข้อมูลผู้รับผลประโยชน์ที่แท้จริงหรือผู้มีอำนาจควบคุม
- ข้อมูลเกี่ยวกับลักษณะและที่มาของรายได้ของกิจการ
- ใบอนุญาตหรือคุณสมบัติเฉพาะสำหรับธุรกิจบางประเภท
จำนวนและรูปแบบของเอกสารไม่ได้เท่ากันในทุกกรณี และไม่ควรถือว่ารายการนี้เป็นข้อยุติ ระบบควรออกแบบให้เพิ่มประเภทเอกสารได้โดยไม่ต้องแก้โครงสร้างข้อมูลหลัก
ทำไมโครงสร้างผู้ถือหุ้นหลายชั้นทำให้งานยากขึ้น?
กรณีที่ตรงไปตรงมาที่สุดคือองค์กรที่มีบุคคลถือหุ้นทั้งหมดโดยตรง เราสามารถไล่ดูรายชื่อผู้ถือหุ้นแล้วระบุตัวผู้รับผลประโยชน์ที่แท้จริงได้ไม่ยาก แต่ในโลกจริงกลับมีโครงสร้างที่บริษัทหนึ่งถือหุ้นอีกบริษัทหนึ่ง ซึ่งถือหุ้นอีกบริษัทหนึ่งต่อไปเรื่อย ๆ การไล่ตามเส้นทางนี้ต้องอาศัยเอกสารจากหลายประเทศ และแต่ละประเทศมีเกณฑ์การเปิดเผยข้อมูลไม่เท่ากัน
ปัญหาที่ตามมาคือ เราไม่รู้ว่าเมื่อไรจึงควรหยุดไล่ บางเส้นทางไปสิ้นสุดที่นิติบุคคลซึ่งไม่เปิดเผยผู้ถือหุ้นต่อสาธารณะ และบางเส้นทางก็มีข้อมูลที่ขัดแย้งกันเองระหว่างเอกสารหลายฉบับ การมีเกณฑ์ที่เขียนไว้ชัดว่ากรณีใดต้องส่งต่อให้คนตรวจจะช่วยให้ทีมงานตัดสินใจได้สม่ำเสมอ
อีกปัญหาคือเอกสารมีอายุ หนังสือรับรองการจดทะเบียนที่ออกเมื่อหลายปีก่อนอาจไม่สะท้อนสถานะปัจจุบัน ระบบจึงควรเก็บวันที่ของเอกสารไว้ด้วย ไม่ใช่แค่ไฟล์ที่แนบมา เพื่อให้ทราบว่าข้อมูลที่ตรวจไปแล้วเก่าแค่ไหน
สถานะการตรวจสอบและเหตุผลที่ถูกปฏิเสธ
การตรวจสอบแบบนี้ไม่มีคำตอบแค่ผ่านหรือไม่ผ่าน ในทางปฏิบัติเราพบอย่างน้อยห้าสถานะที่ต้องแยกออกจากกัน ได้แก่ ยังไม่ส่งเรื่อง อยู่ระหว่างตรวจ ต้องขอข้อมูลเพิ่ม ผ่าน และถูกปฏิเสธ การรวมสถานะเหล่านี้เข้าด้วยกันจะทำให้ทั้งฝ่ายบริการและลูกค้าไม่รู้ว่าควรทำอะไรต่อ
เหตุผลที่ถูกปฏิเสธควรถูกเก็บเป็นรหัสที่อ้างอิงได้ ไม่ใช่ข้อความอิสระที่เจ้าหน้าที่พิมพ์เอง เพื่อให้วิเคราะห์ได้ว่ากรณีใดเกิดบ่อย และเพื่อให้ทีมบริการอธิบายให้ลูกค้าฟังได้ตรงประเด็นโดยไม่ต้องตีความข้อความของกันและกัน
สิ่งที่ควรออกแบบให้ดีคือเส้นทางกลับมาหลังถูกปฏิเสธ ลูกค้าจำนวนมากถูกปฏิเสธเพราะเอกสารไม่ครบหรืออ่านไม่ชัด ซึ่งแก้ไขได้ การเปิดให้ส่งใหม่โดยไม่ต้องเริ่มจากศูนย์ช่วยลดภาระทั้งสองฝ่าย และทำให้อัตราการผ่านดีขึ้นโดยไม่ต้องผ่อนเกณฑ์ใด ๆ
สิ่งที่ห้ามทำเด็ดขาดระหว่างทดสอบ
ข้อแรกคือห้ามใช้วัตถุประสงค์ของการทดสอบเป็นข้ออ้างปิดกลไกป้องกันความเสี่ยง การปิดการตรวจสอบชั่วคราวเพื่อให้แบบทดสอบผ่านเร็วขึ้นเป็นเรื่องที่อันตราย เพราะกลไกเหล่านั้นมักถูกลืมเปิดกลับคืน และกลายเป็นช่องโหว่ถาวร
ข้อที่สองคือห้ามใช้เอกสารของบริษัทจริงในการทดสอบ แม้จะได้รับอนุญาตจากเจ้าของข้อมูลก็ตาม เพราะข้อมูลเหล่านั้นจะไหลไปอยู่ในเครื่องของนักพัฒนาแต่ละคนและในบันทึกการรันอัตโนมัติ ซึ่งควบคุมได้ยากกว่าที่คิด
ข้อที่สามคือห้ามใช้ข้อมูลบริษัทสมมติไปยื่นเรื่องจริงกับหน่วยงานใด การใช้ข้อมูลสมมติมีที่ทางของมันในงานทดสอบเท่านั้น ขอบเขตโดยละเอียดของเรื่องนี้อยู่ในเส้นแบ่งของข้อมูลบริษัทสมมติ ซึ่งควรอ่านก่อนเริ่มงานทดสอบทุกครั้ง
สำหรับนักพัฒนา: เครื่องสถานะและการทดสอบซ้ำ
สถานะของเรื่องควรถูกจัดการเป็นเครื่องสถานะที่มีการเปลี่ยนสถานะได้เฉพาะเส้นทางที่อนุญาต เพื่อให้ทุกฝ่ายเห็นตรงกันว่าตอนนี้เรื่องอยู่ขั้นใด และขั้นถัดไปคืออะไร การเก็บเฉพาะธงว่าผ่านหรือไม่ผ่านทำให้ไม่สามารถตอบคำถามง่าย ๆ อย่างเรื่องนี้ค้างมากี่วันได้เลย
การเปลี่ยนสถานะทุกครั้งควรถูกบันทึกไว้พร้อมเวลา ผู้ที่ทำให้เปลี่ยน และเหตุผล ข้อมูลชุดนี้มีค่ามหาศาลเวลาตรวจสอบย้อนหลัง เพราะช่วยตอบได้ว่าเรื่องนี้ถูกส่งกลับเพราะอะไร และใครเป็นคนอนุมัติในรอบสุดท้าย
เรื่องการทดสอบซ้ำควรทำให้การส่งเรื่องเดิมซ้ำไม่สร้างเรื่องใหม่ขึ้นมาอีก และควรทดสอบกรณีที่เอกสารถูกส่งกลับมาแก้พร้อมกับมีเอกสารใหม่เข้ามาในเวลาเดียวกัน เพราะเป็นจังหวะที่ระบบมักสับสนว่าควรใช้เอกสารชุดใด
สุดท้ายคือการแยกสภาพแวดล้อม ชุดทดสอบควรเดินอยู่ในสภาพแวดล้อมที่ไม่เชื่อมกับหน่วยงานภายนอกจริง และมีเครื่องหมายชัดเจนว่าข้อมูลนี้เป็นของทดสอบ เพื่อไม่ให้มีทางที่เรื่องสมมติจะถูกส่งออกไปนอกระบบได้
เริ่มทดสอบด้วยข้อมูลบริษัทสมมติ
เริ่มจากการสร้างบริษัทสมมติหนึ่งรายที่มีข้อมูลครบทุกกลุ่ม แล้วเดินเรื่องตั้งแต่ต้นจนถึงสถานะสุดท้าย จากนั้นลองสร้างกรณีที่ข้อมูลไม่ครบและกรณีที่เอกสารเก่า เพื่อดูว่าเครื่องสถานะตอบสนองถูกต้องในทุกเส้นทางหรือไม่
คุณสามารถเปิดเครื่องมือสร้างข้อมูลบริษัทสำหรับทดสอบเพื่อสร้างนิติบุคคลสมมติพร้อมเลขทะเบียนและเลข VAT ของประเทศที่เลือกได้ทันที หากต้องการเข้าใจรหัสที่ใช้ระบุตัวนิติบุคคลในงานตรวจสอบ อ่านต่อที่รหัส LEI กับหมายเลข DUNS หรือดูตัวอย่างประเทศที่มีการเปิดเผยข้อมูลองค์กรค่อนข้างชัดเจนได้ที่หน้าประเทศสิงคโปร์
บทความนี้พูดถึงขั้นตอนการตรวจสอบในมุมของงานทดสอบระบบเท่านั้น ไม่ได้ให้คำแนะนำทางกฎหมาย และไม่ได้ชี้แนะวิธีหลีกเลี่ยงการตรวจสอบใด ๆ ผู้ที่ต้องปฏิบัติตามข้อกำหนดจริงควรปรึกษาผู้เชี่ยวชาญของหน่วยงานที่เกี่ยวข้อง