สร้างเองหรือซื้อ: ต้นทุนที่แท้จริงของระบบ core banking

ไม่ช้าก็เร็ว ผู้ก่อตั้งฟินเทคทุกคนต้องตีราคาการตัดสินใจเดียวกัน: สร้างระบบ core banking ขึ้นเองในองค์กร หรือขอสัญญาอนุญาตใช้ระบบสำเร็จแล้วนำมาตั้งค่า การเปรียบเทียบแบบง่ายเกินไป — ค่าสัญญาอนุญาตอยู่ฝั่งหนึ่ง เงินเดือนนักพัฒนาไม่กี่คนอยู่อีกฝั่ง — แทบจะผิดเสมอ เพราะสองคอลัมน์นั้นไม่ได้บรรจุสิ่งเดียวกัน

การเปรียบเทียบที่ตรงไปตรงมาคือต้นทุนรวมในการเป็นเจ้าของตลอดอายุของผลิตภัณฑ์: การสร้าง การบำรุงรักษาถาวร งานด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบที่ต้องทำต่อเนื่อง และรายได้ที่คุณไม่ได้รับระหว่างที่กำลังสร้าง เราสร้างซอฟต์แวร์ core banking จึงย่อมมีจุดยืนของตัวเอง — แต่การคำนวณด้านล่างคือสิ่งที่เราอยากเห็น หากเราเป็นฝ่ายซื้อเสียเอง

"ระบบ core banking" หมายถึงอะไรกันแน่

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

• แกนธุรกรรม: บัญชีแยกประเภทแบบ double-entry ที่คงสมดุลภายใต้โหลดพร้อมกัน โดยทุกยอดคงเหลือคำนวณมาจากบัญชีแยกประเภท และกระทบยอดรายวันกับผู้ให้บริการทุกราย
• ผลิตภัณฑ์ฝั่งลูกค้า: ตัวแอปธนาคารเอง การยืนยันตัวตนด้วยระดับ KYC และ KYB บัญชีหลายสกุลเงิน การโอนเงิน บัตร — และที่เพิ่มขึ้นเรื่อยๆ คือกระเป๋าเงินคริปโตที่มีการเก็บรักษากุญแจอย่างแท้จริงอยู่เบื้องหลัง
• ผลิตภัณฑ์ที่สองที่ไม่มีใครวางแผนไว้: ระบบหลังบ้านฝ่ายปฏิบัติการสำหรับคิวงานด้านการปฏิบัติตามกฎระเบียบ การเฝ้าระวังธุรกรรม การตั้งค่าค่าธรรมเนียม การรายงาน และบทบาทพนักงานแบบละเอียด
• เลเยอร์ที่มองไม่เห็น: บันทึกตรวจสอบแบบ append-only ขั้นตอนยืนยันสองชั้นที่มากกว่าแค่ตอนล็อกอิน rate limiting การระบุลายนิ้วมืออุปกรณ์ และการจัดการกุญแจที่เก็บซีเคร็ตไว้นอกโค้ดและฐานข้อมูล

เส้นทางสร้างเอง: งบประมาณบรรจุอะไรไว้จริงๆ

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

ในด้านกรอบเวลา รูปแบบมีความสม่ำเสมอ: หนึ่งถึงสองปีกว่าจะไปถึงจุดที่แพลตฟอร์มที่สมบูรณ์แล้วมีให้ตั้งแต่วันแรก เวลาไม่ได้หมดไปกับหน้าจอ แต่หมดไปกับความถูกต้องของบัญชีแยกประเภทภายใต้ภาวะพร้อมกัน การเชื่อมต่อผู้ให้บริการที่แต่ละรายมาพร้อมความจุกจิกของ sandbox และขั้นตอนการรับรองของตัวเอง การเสริมความแข็งแกร่งด้านความปลอดภัย และหางยาวของกรณีขอบที่ปรากฏก็ต่อเมื่อมีลูกค้าจริงและเงินจริงเท่านั้น

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

ต้นทุนที่ไม่เคยปรากฏในสเปรดชีต

• ต้นทุนค่าเสียโอกาส: ทุกเดือนที่ใช้สร้างบัญชีแยกประเภทคือเดือนที่ผลิตภัณฑ์ไม่ได้อยู่ในตลาด คู่แข่งที่ขอสัญญาอนุญาตใช้ core กำลังรับลูกค้าและปรับราคาไปเรื่อยๆ ขณะที่คุณยังเชื่อมต่อผู้ให้บริการอยู่
• ความเสี่ยงด้านการจ้างงาน: แผนการสร้างตั้งอยู่บนสมมติฐานว่าทีมที่เริ่มจะเป็นทีมที่สร้างเสร็จ การเสียวิศวกรหนึ่งในสองคนที่เข้าใจบัญชีแยกประเภทกลางคันคือเหตุการณ์เลื่อนกำหนดการที่วัดกันเป็นเดือน
• หางของความถูกต้อง: บัญชีแยกประเภทที่ถูกต้อง 99% ไม่ได้แปลว่าใกล้เสร็จ — มันคือเครื่องผลิตทิกเก็ตซัพพอร์ต ยอดกระทบไม่ตรง และเหตุการณ์ทางกฎระเบียบ 1% สุดท้ายแพงกว่า 99% แรก
• ความปลอดภัยในฐานะงานปฏิบัติการ: การทดสอบเจาะระบบ การหมุนเวียนกุญแจ การตอบสนองเหตุการณ์ การเฝ้าระวังและการแจ้งเตือน — ต้นทุนที่เกิดซ้ำและมีอยู่ไม่ว่าจะมีอะไรผิดพลาดหรือไม่ก็ตาม
• การดูแลการปฏิบัติตามกฎระเบียบ: เอกสาร KYC หมดอายุ กฎเกณฑ์สินทรัพย์คริปโตที่เปลี่ยนแปลง ภาระการรายงานใหม่ๆ งานเหล่านี้วนกลับมาทุกปีและเลื่อนออกไปไม่ได้
• ระบบหลังบ้าน: การสร้างภายในองค์กรมักปฏิบัติต่อเครื่องมือของพนักงานเป็นเรื่องรอง แล้วทีมปฏิบัติการก็ได้รับมรดกเป็นคอนโซล SQL หน่วยงานกำกับดูแลและผู้ตรวจสอบทุกรายที่เห็นสิ่งนั้นจะบังคับให้คุณสร้างใหม่อย่างถูกต้อง
• การแปลภาษา: การส่งมอบผลิตภัณฑ์หลายภาษาพร้อมการรองรับ right-to-left อย่างแท้จริงมีต้นทุนต่ำเมื่อออกแบบไว้ตั้งแต่วันแรก และแพงมากเมื่อต้องมาติดตั้งย้อนหลังหลังผลิตภัณฑ์สร้างเสร็จแล้ว

เส้นทางซื้อ: คุณจ่ายเพื่ออะไร และอะไรยังเป็นของคุณ

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

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

เมื่อไรที่การสร้างเองในองค์กรคือทางเลือกที่ถูกต้อง

สร้าง-หรือ-ซื้อไม่ใช่คำถามเชิงวาทศิลป์ที่มีคำตอบกำหนดไว้ล่วงหน้า การสร้างเองถูกต้องเมื่อเงื่อนไขอย่างน้อยหนึ่งข้อต่อไปนี้เป็นจริง:

• โครงสร้างพื้นฐานคือตัวผลิตภัณฑ์: คุณขายบัญชีแยกประเภท การเก็บรักษาสินทรัพย์ หรือขีดความสามารถ banking-as-a-service เอง ดังนั้นการเป็นเจ้าของมันคือตัวธุรกิจ
• ความแตกต่างของคุณอยู่ในข้อกำหนดที่ไม่มีผู้ขายรายใดครอบคลุม — ไม่ใช่ฟีเจอร์ที่ผู้ขายยังไม่มีในไตรมาสนี้ แต่เป็นขีดความสามารถที่อยู่นอกโครงสร้างของสิ่งที่แพลตฟอร์มทำโดยพื้นฐาน
• คุณมีทีมอาวุโสที่มีประสบการณ์ core banking ระดับโปรดักชันอยู่แล้ว และมีเงินทุนพอจะสนับสนุนพวกเขาหลายปีโดยไม่มีรายได้
• หน่วยงานกำกับดูแลหรือบริษัทแม่กำหนดให้ต้องควบคุมสแต็กภายในองค์กรทั้งหมด เป็นเงื่อนไขที่คุณต่อรองไม่ได้

กรอบคำถามห้าข้อ

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

Coreza อยู่ตรงไหนในการตัดสินใจนี้

Coreza คือคอลัมน์ฝั่งซื้อ ที่สร้างมาให้ผ่านเช็กลิสต์ข้างต้น: ลูกค้าแต่ละรายรันอินสแตนซ์เฉพาะบน AWS พร้อมฐานข้อมูลของตนเองและซีเคร็ตเข้ารหัสของตนเอง ทุกโมดูล — รวมทั้งเชน ภาษา และโทเคน — มีสัญญาอนุญาตแยกรายการเพื่อให้ราคาสะท้อนสิ่งที่คุณเปิดใช้ และการเชื่อมต่อผู้ให้บริการอยู่หลังเลเยอร์นามธรรมเพื่อให้สัญญาเชิงพาณิชย์ยังเป็นของคุณ

เวอร์ชันหนึ่งของ core นี้ทำงานในโปรดักชันที่ฟินเทคยุโรปภายใต้การกำกับดูแลมาตั้งแต่ปี 2024 และอินสแตนซ์ใหม่ติดตั้งได้ในไม่กี่สัปดาห์: แบรนด์ โมดูล ภาษา และเชน เป็นการตั้งค่า ไม่ใช่งานวิศวกรรม หากคุณกำลังคำนวณตัวเลขสร้าง-หรือ-ซื้ออยู่ นั่นคือการเปรียบเทียบที่เราเชิญให้คุณทำ — ต้นทุนสามปีต่อต้นทุนสามปี พร้อมคอลัมน์ที่ซ่อนอยู่ถูกกรอกให้ครบ