คู่มือผู้ซื้อแพลตฟอร์ม neobank แบบ white-label

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

มีห้าเรื่องที่ควรแยกแยะก่อนตัดสินใจ ได้แก่ core กับชั้นแอป ใบอนุญาตอยู่ที่ใด design system ลึกแค่ไหน การส่งมอบแบบ standalone หรือ embedded และการตัดสินใจสร้างเองหรือซื้อที่รองรับทุกเรื่อง เรามาดูตามลำดับ

เรื่องแรก: core กับชั้นแอป

เส้นแบ่งที่มีประโยชน์ที่สุดคือระหว่างส่วนที่ต้องถูกต้อง กับส่วนที่ต้องเป็นของคุณ Core คือส่วนที่พลาดแล้วแพง ได้แก่บัญชีแยกประเภทแบบ double-entry บัญชีและยอดคงเหลือ KYC และการ onboarding การออกบัตรและการประมวลผล ช่องทางคริปโตและ stablecoin และคอนโซลผู้ปฏิบัติการที่อยู่เบื้องหลังทั้งหมด ชั้นแอปคือสิ่งที่ลูกค้าสัมผัส ได้แก่แบรนด์ หน้าจอ สถาปัตยกรรมข้อมูล และชุดฟีเจอร์ที่เปิดใช้ แพลตฟอร์มที่คุ้มซื้อใช้ core เดียวร่วมกันทุกแบรนด์ และกำหนดค่าแอปแยกตาม tenant ประเมินสองส่วนนี้คนละเกณฑ์ core ดูที่ความถูกต้อง ว่าเป็น double-entry จริงไหม กระทบยอดได้จริงไหม ผู้ปฏิบัติการใช้งานได้จริงไหม ส่วนชั้นแอปดูที่ความยืดหยุ่น ว่าแบรนด์ต่างออกไปได้แค่ไหนก่อนต้อง fork

ใบอนุญาตอยู่ที่ใด และแยกออกได้หรือไม่

สิทธิ์ในการถือครองหรือเคลื่อนย้ายเงินเป็นเรื่องที่มีการกำกับดูแล และไม่ใช่การซื้อเดียวกับซอฟต์แวร์ จงถามตรงๆ ว่าแพลตฟอร์มรวมใบอนุญาตมาให้หรือคาดหวังให้คุณนำมาเอง และถ้ามีให้ เป็นใบอนุญาตของใคร ในประเทศใดบ้าง และคุณเป็นลูกค้าโดยตรงหรือเป็นตัวแทน ผู้ซื้อต้องใส่ใจเรื่องการแยกเป็นหลัก แพลตฟอร์มที่ผูกซอฟต์แวร์ไว้กับใบอนุญาตเดียวที่เปลี่ยนไม่ได้ ได้เลือกเขตอำนาจและพันธมิตรแทนคุณไปเงียบๆ แล้ว ส่วนแพลตฟอร์มที่มองใบอนุญาตเป็นราง (rail) ที่คุณนำมาเอง ให้คุณเลือกใบอนุญาตได้อิสระและเปลี่ยนภายหลังได้ ไม่มีแบบไหนผิด แต่คุณต้องรู้ว่ากำลังซื้อแบบไหน Protocore Pay (/products/pay) เป็นชั้นซอฟต์แวร์ล้วนๆ ทำงานบนรางที่ได้รับอนุญาตตามที่คุณนำมา และซอฟต์แวร์ไม่ใช่ใบอนุญาต แนวคิดที่คุณจะเจอในการหารือ ได้แก่ EMI, payment institution, agent, sponsor bank อธิบายไว้ใน /glossary

Design system ลึกแค่ไหน

คำมั่นของ white-label คือแอปดูเป็นของคุณ ไม่ใช่แค่เปลี่ยนสกินจากเดโมของผู้ขาย และคำมั่นนี้ลึกได้เท่ากับ design system ที่อยู่เบื้องหลังเท่านั้น ระบบที่ตื้นให้แค่เปลี่ยนโลโก้กับสีเน้น ระบบที่ลึกเปิดคำศัพท์จริงของการออกแบบ ทั้งสี ตัวอักษร ความโค้งของมุม ระยะห่าง ความหนาแน่น และการเคลื่อนไหว เป็น token ที่ทุกหน้าจออ่านค่า ทำให้แบรนด์เป็นชุดค่าที่ override ไม่ใช่ fork จงถามว่ามี token กี่ตัวและครอบคลุมอะไรบ้าง token ชุดเดียวกันส่งออกไปทั้งเว็บ native และเดสก์ท็อปหรือไม่ เพื่อให้สีหนึ่งหมายถึงสีเดียวกันทุกที่ และนักออกแบบปรับ tenant ให้ต่างจาก reference build ได้มากแค่ไหนโดยไม่แตะโค้ด design system ของ Protocore (/products/pds) เป็นคำตอบหนึ่งที่ส่งมอบแล้ว คือ 144 token และ 889 utility class แบบ dark-first ค่าเริ่มต้นมุมเป็นศูนย์ ส่งออกสำหรับเว็บ, .NET และ native แต่คำถามของผู้ซื้อเป็นคำถามทั่วไปว่า ชั้นดีไซน์เป็นระบบ token จริง หรือเป็นแค่สีที่ทาทับแอปที่ตายตัว

แอป standalone หรือชั้น embedded

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

การสร้างเองกับการซื้อ พูดกันตรงๆ

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

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

ห้าทิศทาง ไม่ใช่ห้าผลิตภัณฑ์

เมื่อขอตัวอย่างจากผู้ขาย คุณมักถูกโชว์แอปที่เสร็จแล้วหลายตัว จงอ่านให้ถูก ว่าเป็นทิศทางที่ core เดียวกันไปได้ ไม่ใช่เมนูที่เลือกได้แค่อย่างเดียว reference core ของแพลตฟอร์มหนึ่งรองรับได้ทั้งหน้าตาแบบ exchange ที่สะอาด (Halcyon เรียบๆ ให้การเทรดอยู่ข้างหน้า) super-app แบบแชตเป็นหลัก (Lumen เงินเคลื่อนที่ในบทสนทนา) แอปที่เน้นการโอน (Fern เริ่มที่การจ่ายเงินแบบแบตช์และการแปลงสกุลเงินตามกฎ) บิลด์ stablecoin โทนมืด (Volt มีตัวคัดแยกเงินเดือนและบัตรทีม) และบัญชีหลายสกุลเงิน (Meridian ยอด EUR คู่กับ USDC และบัญชี BTC ที่รางวัลจากบัตรเข้า) ห้าแบรนด์ ห้าสถาปัตยกรรมข้อมูล ห้าชุดฟีเจอร์ แต่ใต้ทุกตัวคือบัญชีแยกประเภทเดียว KYC เดียว และตัวประมวลผลบัตรเดียว ตัวเลขที่สำคัญไม่ใช่ห้า แต่คือจำนวน tenant ที่ core รองรับได้ ผู้ขายที่บอกว่าผลิตภัณฑ์คือห้าแอปเข้าใจผลิตภัณฑ์ของตัวเองผิด ส่วนผู้ขายที่โชว์ห้าตัวเพื่อพิสูจน์ว่าตัวที่หกทำได้ง่ายนิดเดียว เข้าใจดี

คำถามที่ใช้คัดกรองผู้ให้บริการ

คำถามสั้นๆ ไม่กี่ข้อก็ช่วยตัดข้อเสนอส่วนใหญ่ออกไปได้ แกนระบบเป็นระบบเดียวที่ใช้ร่วมกัน หรือแยก fork ให้ลูกค้าแต่ละราย — และเมื่อแก้บั๊ก การแก้ไขนั้นไปถึงทุก tenant พร้อมกันหรือไม่ เลเยอร์ดีไซน์เปิดให้ใช้ token จริง หรือมีแค่ช่องใส่โลโก้ แพลตฟอร์มรวมใบอนุญาตที่ถูกกำกับดูแลมาให้แล้ว หรือต้องหามาเอง — และเปลี่ยนภายหลังได้หรือไม่ แกนระบบเดียวกันส่งมอบได้ทั้งแอปแบบ standalone และเลเยอร์แบบ embedded ได้หรือไม่ ส่วนไหนที่ถือเป็นงานโครงสร้างพื้นฐาน และส่วนไหนที่คาดหวังให้เราสร้างเอง คำตอบเหล่านี้จะวางผู้ให้บริการลงบนแผนที่ที่คู่มือเล่มนี้วาดไว้ ได้แก่ แกนระบบร่วมหรือฟาร์ม fork, ระบบ token หรือแค่การทาสี, ซอฟต์แวร์บวกใบอนุญาตของเราเอง หรือชุดรวมที่เชื่อมติดกัน, รูปแบบการส่งมอบแบบเดียวหรือสองแบบ รายละเอียดฉบับเต็มของแกนระบบหนึ่งเดียวนี้ — ทั้งห้าทิศทาง แอปอ้างอิง และคอนโซลผู้ดูแลระบบที่อยู่เบื้องหลัง — อยู่ที่ /products/pay ส่วนดีไซน์ซิสเต็มที่เป็นรากฐานอยู่ที่ /products/pds และคำศัพท์ต่างๆ อยู่ใน /glossary