ต้นแบบบล็อคเชนพื้นฐานสามารถแสดงให้เห็นว่า fintech สามารถเชื่อมต่อเครือข่ายและโอนเงินได้ แต่ไม่ได้หมายความว่าพร้อมสำหรับการใช้งานจริง ในสภาพแวดล้อมจริง ธุรกรรมจะต้องคงความปลอดภัย ติดตามได้ และปรับยอดได้ แม้ว่าเครือข่ายจะพัฒนา เกิดข้อยกเว้น มีการควบคุม และระบบการเงินประมวลผลผลลัพธ์ Fintechs ที่ไม่ต้องการควบคุมเฉพาะในแต่ละชั้นสามารถนำซอฟต์แวร์เฉพาะมาใช้เพื่อลดโครงสร้างพื้นฐานที่ต้องจัดการภายในองค์กร
เมื่อ fintech ใช้ Blockchain SaaS ก็สามารถรักษาอินเทอร์เฟซลูกค้า การตั้งค่าสิทธิ์ กฎการกำหนดราคา และบัญชีแยกประเภทภายในของตนเองได้ แพลตฟอร์มผู้เชี่ยวชาญจะดูแลฟังก์ชันบล็อคเชนที่เลือกผ่าน APIs, SDKs และ webhooks ขอบเขตระหว่างบริการสามารถกำหนดได้ในหลายระดับ หมายความว่าการใช้ SaaS ไม่ได้บังคับให้ fintech ต้องมอบสแต็กบล็อคเชนทั้งหมดของตน
ฟังก์ชันที่มักถูกรวมผ่าน SaaS ได้แก่:
- งานกระเป๋าเงินและคีย์ ตั้งแต่การสร้างที่อยู่ไปจนถึงการลงนามธุรกรรม
- ดำเนินการธุรกรรมบนเครือข่ายที่รองรับ พร้อมการยืนยันและการจัดการค่าธรรมเนียม
- การโอนเงิน ครอบคลุมการแปลง การชำระด้วย stablecoin การจ่ายเงิน และกระบวนการสภาพคล่อง
- มาตรการความเสี่ยง เช่น การติดตามธุรกรรมและการคัดกรองที่อยู่
- ผลลัพธ์ทางการเงินสำหรับรายงาน รายการบัญชีแยกประเภท และการปรับยอด
การบำรุงรักษาการรองรับหลายบล็อคเชนสร้างภาระการบำรุงรักษาอย่างต่อเนื่อง ทุกเครือข่ายมีกฎการกำหนดที่อยู่ รูปแบบการยืนยัน โครงสร้างค่าธรรมเนียม มาตรฐานโทเค็น และรอบการอัปเดตของตัวเอง ทีมงานต้องเตรียมพร้อมสำหรับ forks, downtime, การอัปเกรดโปรโตคอล และเหตุการณ์ด้านความปลอดภัย
โมเดล SaaS ที่หลากหลายจัดการกับส่วนต่างๆ ของสแต็กบล็อคเชน Circle ใช้แนวทางที่เน้นกระเป๋าเงินเป็นศูนย์กลาง แอปพลิเคชันเข้าถึงฟังก์ชันกระเป๋าเงินและธุรกรรมผ่าน APIs หรือ SDKs ในขณะที่การกระจายเสียงเครือข่าย การจัดทำดัชนี และข้อมูลสำหรับเชนที่รองรับยังคงอยู่ในสภาพแวดล้อมที่จัดการโดย Circle
Fireblocks จัดการกับเลเยอร์การดำเนินงานของสถาบันในวงกว้างขึ้น แพลตฟอร์มของบริษัทนำเทคโนโลยีกระเป๋าเงิน การควบคุมการดูแล กระบวนการ treasury การจัดการนโยบาย APIs และการเชื่อมต่อข้ามหลายเชนมารวมกัน สิ่งนี้เหมาะกับ fintechs ที่ต้องการการตั้งค่าการควบคุมสินทรัพย์ดิจิทัลที่กว้างขึ้นโดยไม่ต้องสร้างสแต็กกระเป๋าเงินและเครือข่ายทั้งหมดภายใน
BVNK มุ่งเน้นไปที่การชำระด้วย Stablecoin เป็นหลัก โครงสร้างพื้นฐานของบริษัทเชื่อมโยงการชำระเงิน กระเป๋าเงิน และสภาพคล่องผ่านเลเยอร์ API ทำให้เหมาะสมกับผลิตภัณฑ์ที่สร้างขึ้นรอบการชำระด้วย Stablecoin และสภาพคล่อง
Coinspaid เสนอทางเลือกการปรับใช้สองแบบ Coinspaid Enterprise ให้แนวทางที่สมบูรณ์ยิ่งขึ้น โดยรวมโครงสร้างพื้นฐานธุรกรรมและการแลกเปลี่ยนเข้ากับการดำเนินงานของร้านค้า การชำระ สภาพคล่อง การปรับยอด และการปฏิบัติตามข้อกำหนด Coinspaid Console เป็นแบบโมดูลาร์ มีส่วนประกอบสำหรับ Treasury Management, Core Custody, Core Exchange และ Compliance สิ่งนี้ช่วยให้ fintechs เลือกแพลตฟอร์มที่ครอบคลุมหรือรวมชิ้นส่วนโครงสร้างพื้นฐานเฉพาะ
สถาปัตยกรรมที่เลือกควรสะท้อนว่าส่วนใดของสแต็กที่ fintech ต้องเป็นเจ้าของและส่วนใดที่สามารถมาจากภายนอก การคงเลเยอร์ไว้ภายในทำให้ทีมวิศวกรรมควบคุมได้มากขึ้น แต่ก็หมายความว่าบริษัทต้องดำเนินการ รักษาความปลอดภัย ติดตาม และอัปเดตเลเยอร์นั้นเมื่อเวลาผ่านไป แนวทางนี้สามารถใช้ได้กับสถาบันที่มีทรัพยากร blockchain, DevOps และความปลอดภัยโดยเฉพาะ โดยเฉพาะอย่างยิ่งเมื่อตรรกะการลงนามหรือนโยบายธุรกรรมเป็นแกนหลักของผลิตภัณฑ์
SaaS ช่วยลดการพัฒนาในระดับต่ำและสามารถเร่งเวลาในการออกสู่ตลาด โดยระดับการควบคุมขึ้นอยู่กับสถาปัตยกรรมของผู้ให้บริการ การตั้งค่าแบบไฮบริดแบ่งความรับผิดชอบข้ามเลเยอร์ที่เลือก Fintech สามารถรักษาสภาพแวดล้อมการลงนามและตรรกะความเสี่ยงของตนในขณะที่ได้รับการเชื่อมต่อเครือข่าย การจัดเตรียมกระเป๋าเงิน การแลกเปลี่ยน หรือการปรับยอดจากแหล่งภายนอก
โมเดลนี้ยังใช้กับการชำระเงินอีกด้วย เกตเวย์การชำระเงิน SaaS สามารถทำให้ฟังก์ชันการชำระเงินพร้อมใช้งานผ่านอินเทอร์เฟซซอฟต์แวร์ ในขณะที่ fintech ยังคงควบคุมประสบการณ์ลูกค้าและกระบวนการภายในของตน
การทบทวนการผลิตต้องกำหนดว่าความรับผิดชอบอยู่ที่ใดหลังจากการปรับใช้ และผู้ให้บริการจัดการกับความล้มเหลวของธุรกรรม การเปลี่ยนแปลงเครือข่าย หรือความจำเป็นในการย้ายบันทึกไปยังระบบการเงินอย่างไร การนับฟีเจอร์เพียงอย่างเดียวไม่สามารถแก้ไขปัญหาเหล่านี้ได้ ดังนั้นทีมเทคนิค ความปลอดภัย การปฏิบัติตามข้อกำหนด และการเงินจึงต้องมีรายการตรวจสอบร่วมกัน
- โมเดลการควบคุม: กำหนดอำนาจการลงนาม การจัดเก็บคีย์หรือส่วนแบ่งคีย์ การควบคุมการถอน และส่วนโครงสร้างพื้นฐานใดที่ยังอยู่ภายใต้การควบคุมของ fintech
- ความยืดหยุ่นของเครือข่าย: ตรวจสอบเชนและสินทรัพย์ที่รองรับ รูปแบบการยืนยัน ขั้นตอนการอัปเกรด และความจุสำหรับปริมาณธุรกรรมที่คาดการณ์
- ข้อมูลและการปรับยอด: ตรวจสอบว่าสถานะธุรกรรม ค่าธรรมเนียม และเหตุการณ์บล็อคเชนไหลเข้าสู่ระบบการเงินภายในอย่างไร
- พฤติกรรมการรวมระบบ: ทดสอบ REST APIs, SDKs, webhooks, ตรรกะการลองซ้ำ สถานะธุรกรรม และการจัดการข้อผิดพลาด
- การเชื่อมต่อการปฏิบัติตามข้อกำหนด: ทบทวนว่าเครื่องมือ Know Your Transaction (KYT), การวิเคราะห์บล็อคเชน, การคัดกรองที่อยู่ และกฎการอนุมัติภายในรวมเข้ากับกระบวนการธุรกรรมอย่างไร
- ความสามารถในการพกพา: ระบุว่ากระเป๋าเงิน บันทึก และข้อมูลการดำเนินงานใดที่สามารถส่งออกหรือย้ายได้ในกรณีที่เปลี่ยนผู้ให้บริการ
การทบทวนควรจัดสรรความรับผิดชอบสำหรับการควบคุมลูกค้า การบัญชีภายใน ความเสี่ยงผลิตภัณฑ์ และหน้าที่ด้านกฎระเบียบที่ยังคงอยู่กับ fintech
ยกตัวอย่าง fintech ในสหรัฐฯ ที่ต้องการเพิ่มการจ่าย USDC ให้กับข้อเสนอบัญชีธุรกิจปัจจุบัน การ onboarding ลูกค้า สิทธิ์ผู้ใช้ การกำหนดราคา และบัญชีแยกประเภทภายในสามารถคงอยู่ในแอปพลิเคชันของ fintech ในขณะที่การดำเนินการบล็อคเชนเชื่อมต่อผ่านผู้ให้บริการโครงสร้างพื้นฐาน
เมื่อผู้ใช้ที่ได้รับอนุญาตเริ่มการจ่ายเงิน ระบบแบ็คเอนด์ของ fintech จะส่งคำสั่งธุรกรรมผ่าน API ของผู้ให้บริการ เลเยอร์โครงสร้างพื้นฐานจัดการเวิร์กโฟลว์บล็อคเชนที่รองรับ ใช้การควบคุมธุรกรรมที่กำหนด และส่งกลับการอัปเดตสถานะผ่าน webhooks จากนั้น fintech สามารถอัปเดตบัญชีแยกประเภทและอินเทอร์เฟซลูกค้าได้โดยไม่ต้องแสดงขั้นตอนเฉพาะของบล็อคเชนให้ผู้ใช้เห็น
Treasury ยังคงเป็นปัจจัยในการออกแบบ Fintech ต้องตัดสินใจว่ากระเป๋าเงินปฏิบัติการได้รับเงินทุนอย่างไร เครือข่ายใดที่การจ่ายเงินทำงาน และธุรกรรมที่สมบูรณ์ถูกจับคู่กับบันทึกภายในอย่างไร การทดสอบการผลิตควรตรวจสอบว่าสถานะการจ่ายเงิน การเปลี่ยนแปลง treasury และรายการบัญชีแยกประเภทสามารถติดตามผ่านบันทึกธุรกรรมเดียวกันได้