Responsible FinTech · WHITE FORCES KNOWLEDGE
สร้างผลิตภัณฑ์ FinTech อย่างรับผิดชอบ ต้องคิดอะไรก่อนฟีเจอร์
เผยแพร่ · ตรวจทานล่าสุด · อ่านประมาณ 5 นาทีเครื่องมือการเงินและการเทรดมีผลต่อการตัดสินใจจริง การออกแบบจึงต้องเริ่มจากความเสี่ยงควบคู่ประสบการณ์ผู้ใช้
ระบุสิ่งที่ทำและไม่ทำ
แยกเครื่องมือวิเคราะห์ automation, execution และคำแนะนำให้ชัด หลีกเลี่ยงภาษาที่ทำให้เข้าใจว่าผลตอบแทนแน่นอน
เส้นแบ่งนี้ไม่ใช่เรื่องสำนวน แต่กระทบทั้งความรับผิดและข้อกำกับ เครื่องมือที่คำนวณตัวเลขให้ผู้ใช้ตัดสินใจเอง กับระบบที่ส่งคำสั่งซื้อขายแทนผู้ใช้ อยู่คนละระดับความเสี่ยง และการให้คำแนะนำการลงทุนเป็นกิจกรรมที่มีข้อกำหนดเฉพาะ ผู้พัฒนาจึงต้องตอบให้ได้ตั้งแต่วันแรกว่าผลิตภัณฑ์ของตนอยู่ตรงไหน และสื่อสารให้ผู้ใช้เข้าใจตรงกัน
ทดสอบสถานการณ์ผิดปกติ
รวมข้อมูลผิด การเชื่อมต่อหลุด คำสั่งซ้ำ market gap และบริการภายนอกล่ม พร้อม safe state และ manual override
หลักออกแบบที่ควรยึดคือ fail-safe เมื่อระบบไม่แน่ใจหรือขาดข้อมูล ให้หยุดในสถานะที่ปลอดภัยแทนที่จะเดินต่อด้วยข้อมูลเก่า เช่น เมื่อราคาที่ได้รับหยุดอัปเดตผิดปกติ ระบบควรระงับการส่งคำสั่งใหม่และแจ้งเตือนทันที ไม่ใช่เทรดต่อบนราคาค้าง และผู้ใช้ต้องมีปุ่มหยุดฉุกเฉินที่ทำงานได้เสมอแม้ระบบหลักขัดข้อง
แสดงข้อจำกัดและเก็บหลักฐาน
บอกเวลาข้อมูล assumption และ risk เก็บ version ของกฎกับ audit log เครื่องมือไม่แทนคำแนะนำลงทุน และผลย้อนหลังไม่รับประกันอนาคต
audit log ที่ดีต้องตอบได้ว่า ณ เวลาหนึ่ง ระบบเห็นข้อมูลอะไร ใช้กฎเวอร์ชันไหน และตัดสินใจอะไรเพราะอะไร บันทึกเช่นนี้ปกป้องทั้งผู้ใช้และผู้พัฒนา เมื่อเกิดข้อพิพาทหรือผลไม่เป็นไปตามคาด จะแยกได้ว่าเป็นพฤติกรรมของตลาด ข้อผิดพลาดของระบบ หรือการตั้งค่าของผู้ใช้เอง แทนที่จะเดากันด้วยความทรงจำ
ตัวอย่างสถานการณ์ที่ต้องออกแบบเผื่อ
สมมติทีมหนึ่งพัฒนา EA หรือ bot เทรดให้ผู้ใช้นำไปรันเอง ความเสี่ยงที่พบบ่อยไม่ใช่ตัวกลยุทธ์ แต่คือความเข้าใจของผู้ใช้ เช่น ผู้ใช้เห็นผลทดสอบย้อนหลังที่สวยแล้วเข้าใจว่าเป็นการรับประกันผลในอนาคต จึงตั้งขนาดการเทรดเกินตัว ผู้พัฒนาที่รับผิดชอบต้องออกแบบการสื่อสารให้ชัดตั้งแต่หน้าขายจนถึงเอกสาร ว่าผลย้อนหลังคือข้อมูลประกอบ ไม่ใช่คำสัญญา พร้อมค่าเริ่มต้นที่ระมัดระวังและคำอธิบายความเสี่ยงของแต่ละพารามิเตอร์
อีกสถานการณ์คือวันที่ตลาดผันผวนแรงและโบรกเกอร์หรือแหล่งข้อมูลภายนอกตอบสนองช้า ระบบที่ไม่ได้ออกแบบเผื่อจะส่งคำสั่งซ้ำ ค้างสถานะ หรือทำงานบนข้อมูลเก่าโดยไม่รู้ตัว การซ้อมสถานการณ์เหล่านี้ในสภาพแวดล้อมทดสอบ รวมถึงการทดสอบตัดการเชื่อมต่อกลางคัน ควรเป็นส่วนหนึ่งของการพัฒนาปกติ ไม่ใช่สิ่งที่ทำครั้งเดียวก่อนเปิดตัว
ขั้นตอนพัฒนาอย่างรับผิดชอบ
กรอบนี้ใช้ได้ทั้งเครื่องมือวิเคราะห์ bot และระบบการเงินบนเว็บ
- นิยามขอบเขตผลิตภัณฑ์ระบุชัดว่าเป็นเครื่องมือวิเคราะห์ automation หรือ execution และอะไรอยู่นอกขอบเขต
- ตรวจข้อกำกับที่เกี่ยวข้องศึกษาข้อกำหนดของหน่วยงานกำกับในตลาดที่จะให้บริการ ก่อนออกแบบ ไม่ใช่หลังพัฒนาเสร็จ
- ออกแบบ fail-safe และ overrideกำหนดพฤติกรรมเมื่อข้อมูลผิด การเชื่อมต่อหลุด หรือบริการภายนอกล่ม พร้อมปุ่มหยุดฉุกเฉิน
- ทดสอบเคสปกติและเคสวิกฤตทดสอบทั้งสภาพตลาดปกติ ช่วงผันผวนแรง คำสั่งซ้ำ และการหลุดการเชื่อมต่อกลางคัน
- เขียนเอกสารและคำเตือนความเสี่ยงอธิบายข้อจำกัด สมมติฐาน และความเสี่ยง ด้วยภาษาที่ผู้ใช้ทั่วไปเข้าใจ
- เปิดตัวแบบจำกัดและติดตามเริ่มกับกลุ่มเล็ก เก็บ log และ feedback ปรับปรุงก่อนขยาย พร้อมช่องทางแจ้งปัญหาที่ตอบจริง
เช็กลิสต์ก่อนปล่อยผลิตภัณฑ์
- ผู้ใช้อ่านหน้าแรกแล้วเข้าใจถูกว่าผลิตภัณฑ์ทำอะไรและไม่ทำอะไร
- ไม่มีข้อความที่สื่อว่าผลตอบแทนแน่นอนหรือรับประกันกำไร
- มีคำเตือนความเสี่ยงที่ชัดเจน ไม่ซ่อนในตัวอักษรเล็ก
- ระบบมี safe state เมื่อข้อมูลผิดปกติหรือการเชื่อมต่อหลุด
- ผู้ใช้หยุดระบบเองได้เสมอ และรู้วิธีทำตั้งแต่ก่อนเริ่มใช้
- เก็บ audit log พร้อมเวอร์ชันของกฎที่ใช้ในแต่ละการตัดสินใจ
- ผ่านการทดสอบสถานการณ์ผิดปกติที่บันทึกผลไว้เป็นหลักฐาน
- ตรวจแล้วว่ารูปแบบบริการไม่เข้าข่ายกิจกรรมที่ต้องมีใบอนุญาต หรือได้ขอใบอนุญาตแล้ว
ระดับความเสี่ยงตามประเภทผลิตภัณฑ์
ยิ่งระบบตัดสินใจแทนผู้ใช้มาก ความรับผิดชอบในการออกแบบยิ่งสูง
| ประเภท | ความเสี่ยงหลัก | สิ่งที่ต้องมีเป็นอย่างน้อย |
|---|---|---|
| เครื่องมือวิเคราะห์และ indicator | ผู้ใช้ตีความผิดหรือเข้าใจว่าเป็นคำแนะนำ | คำอธิบายวิธีคำนวณ ข้อจำกัด และเวลาของข้อมูล |
| automation ที่ผู้ใช้ควบคุม | ตั้งค่าผิด ระบบทำงานต่อในสภาพตลาดที่ไม่เหมาะ | ค่าเริ่มต้นระมัดระวัง ปุ่มหยุด และแจ้งเตือนผิดปกติ |
| execution แทนผู้ใช้ | คำสั่งซ้ำ ข้อมูลค้าง ความเสียหายเกิดเร็วและจริง | fail-safe, idempotency, audit log และการซ้อมเหตุวิกฤต |
| คำแนะนำการลงทุน | เข้าข่ายกิจกรรมที่มีข้อกำหนดเฉพาะทางกฎหมาย | ตรวจสอบใบอนุญาตและข้อกำกับก่อนให้บริการ |
ข้อผิดพลาดที่พบบ่อย
- ใช้ผลทดสอบย้อนหลังเป็นเครื่องมือขายผล backtest ที่คัดช่วงเวลาสวยทำให้ผู้ใช้คาดหวังผิด และทำลายความน่าเชื่อถือระยะยาว
- ทดสอบเฉพาะตลาดปกติระบบที่ไม่เคยเจอช่วงผันผวนแรงในการทดสอบ มักแสดงพฤติกรรมคาดไม่ถึงเมื่อเจอของจริง
- ไม่มีปุ่มหยุดที่ทำงานได้จริงเมื่อระบบหลักค้าง ผู้ใช้ต้องหยุดความเสียหายได้ด้วยช่องทางอิสระจากระบบหลัก
- มองข้ามข้อกำกับเพราะเป็นทีมเล็กขนาดทีมไม่ใช่ข้อยกเว้นทางกฎหมาย ควรตรวจขอบเขตกิจกรรมกับหน่วยงานกำกับตั้งแต่ออกแบบ
- เก็บ log ไม่พอจะอธิบายเหตุการณ์เมื่อผู้ใช้ถามว่าทำไมระบบทำแบบนี้ การตอบไม่ได้คือความเสี่ยงทั้งทางธุรกิจและกฎหมาย
คำถามที่พบบ่อย
ทำเครื่องมือเทรดต้องมีใบอนุญาตไหม
ขึ้นกับรูปแบบบริการ การขายซอฟต์แวร์ให้ผู้ใช้รันเองกับการรับบริหารเงินหรือให้คำแนะนำการลงทุนมีสถานะทางกฎหมายต่างกัน ควรศึกษาข้อกำหนดของ ก.ล.ต. และหน่วยงานที่เกี่ยวข้องในตลาดเป้าหมาย หรือปรึกษาผู้เชี่ยวชาญทางกฎหมายโดยตรง บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย
แค่ไหนถึงเรียกว่าสื่อสารเกินจริง
หลักง่าย ๆ คือถ้าข้อความทำให้คนทั่วไปเข้าใจว่าผลตอบแทนแน่นอน ไม่มีทางขาดทุน หรือระบบฉลาดจนไม่ต้องเข้าใจความเสี่ยง ถือว่าเกินจริง การสื่อสารที่ดีบอกทั้งจุดแข็ง เงื่อนไข และสิ่งที่ระบบทำไม่ได้
ผลทดสอบย้อนหลังใช้ทำอะไรได้
ใช้เป็นข้อมูลประกอบการเข้าใจพฤติกรรมของกลยุทธ์ในอดีต เช่น ช่วงขาดทุนลึกสุดและความถี่ของการเทรด แต่ต้องแสดงเงื่อนไขการทดสอบ ค่าธรรมเนียม และ slippage ที่ใช้ และย้ำเสมอว่าอดีตไม่รับประกันอนาคต
ควรเปิดเผยอะไรให้ผู้ใช้บ้าง
อย่างน้อยคือขอบเขตของระบบ สมมติฐานสำคัญ ความเสี่ยงหลัก เวลาและแหล่งของข้อมูล เงื่อนไขที่ระบบจะหยุดทำงาน และช่องทางติดต่อเมื่อเกิดปัญหา ความโปร่งใสเหล่านี้คือสิ่งที่แยกผลิตภัณฑ์ที่รับผิดชอบออกจากผลิตภัณฑ์ที่ขายฝัน
แหล่งอ้างอิง
หน่วยงานกำกับและมาตรฐานที่ผู้พัฒนา FinTech ควรติดตาม