自建还是采购：核心银行系统的真实成本

每一位金融科技创始人迟早都要为同一个决策算账：是自建核心银行系统，还是获得一套现成系统的授权并加以配置。天真的比较方式——一边是授权费，另一边是几名开发人员的工资——几乎总是错的，因为这两栏里装的根本不是同样的东西。

诚实的比较是产品整个生命周期内的总拥有成本：建设本身、永久性的维护、安全与合规的持续投入，以及在建设期间未能赚到的收入。我们做的就是核心银行软件，所以立场自然有——但下面这份算法，正是如果我们自己是买方时希望看到的那一份。

“核心银行系统”究竟意味着什么

大多数自建对采购的估算在写下第一个数字之前就已经跑偏，因为范围被低估了。您的客户看到的银行应用只是系统的可见部分。一套达到生产级的核心系统，实际上是四个产品合而为一：

• 交易核心：一套在并发负载下始终保持平衡的复式记账账本，每个余额都从账本推导而来，并每日与每一家服务商对账。
• 客户产品：银行应用本身、带 KYC 和 KYB 分级的开户流程、多币种账户、转账、银行卡——以及日益重要的、背后有真正密钥托管能力的加密钱包。
• 没人列入预算的第二个产品：运营后台，覆盖合规队列、交易监控、手续费配置、报表以及细粒度的员工角色。
• 看不见的一层：仅可追加的审计日志、登录之外的双因素验证流程、限流、设备指纹，以及让密钥材料远离代码和数据库的密钥管理。

自建之路：预算里到底装着什么

一次现实的自建需要具备金融系统经验的资深后端工程师、前端工程师、DevOps 与安全、QA，以及懂合规的产品协调。能达到生产质量的团队很少低于六到十名资深成员——而其中的稀缺画像，即已经在生产环境运营过账本和托管系统的工程师，恰恰是最难招到、也最难留住的。

在时间线上，规律非常一致：需要一到两年才能达到成熟平台第一天就能提供的水平。时间不是花在界面上，而是花在并发下账本的正确性、每家都带着自己 sandbox 怪癖和认证步骤的服务商对接、安全加固，以及只有真实客户和真实资金到来后才会暴露的长尾边缘情况上。

而且支出不会在上线时结束。服务商更换 API，区块链网络升级，监管持续变化，依赖库逐渐腐化。自建核心不是一个会结束的项目，而是一支您承诺在产品存续期间持续供养的常设团队。

那些从不出现在预算表里的成本

• 机会成本：花在自建账本上的每一个月，都是产品缺席市场的一个月。采购了核心系统的竞争对手正在接入客户、迭代定价，而您还在对接服务商。
• 招聘风险：自建计划假设开工的团队就是完工的团队。在项目中途失去两名理解账本的工程师之一，是一个以月为单位计量的进度事故。
• 正确性的长尾：一套 99% 正确的账本并不是接近完工——它是客服工单、对账断裂和监管事故的生成器。最后的 1% 比前面的 99% 更昂贵。
• 作为日常运营的安全：渗透测试、密钥轮换、事故响应、监控与告警——无论是否出事都持续存在的经常性成本。
• 合规的持续维护：KYC 文件到期、不断演进的加密资产规则、新的报送义务。这些工作每年重复，无法推迟。
• 运营后台：自建项目几乎总是把员工工具当作事后补充，运营团队最后继承的是一个 SQL 控制台。任何看到这一幕的监管机构或审计师，都会要求您把它正经重建一遍。
• 本地化：从第一天就设计好的多语言与真正的 RTL 支持成本很低，而在产品建成之后再补装则非常昂贵。

采购之路：您付的是什么，留在手里的是什么

在采购这一侧，技术成本是明码标价的：平台的授权或租赁——严肃的供应商会对模块、链和语言逐项定价，让账单跟随您实际启用的内容——再加上实例运行所需的基础设施。采购不能替您免除的：您的监管牌照或合作机构安排、您与服务商的商业协议、您的运营人员、您的分销渠道。这些成本无论走哪条路都属于运营方——采购移走的是工程这座大山，而不是生意本身。

采购的真实代价呈依赖形态：路线图不完全掌握在您手里，而平台的水准取决于它最差的那个模块。缓解手段在签约之前都可以核实：独立专属实例，配自己的数据库和自己的加密密钥材料，让离开供应商是一次迁移而不是一场人质谈判；服务商集成置于抽象层之后，协议归您所有、服务商可以更换；模块化授权，只为启用的部分付费；以及平台处理过真实客户与真实资金的证据。

什么情况下自建才是正确选择

自建还是采购并不是一个答案早已注定的修辞性问题。当以下条件至少满足一条时，自建才是对的：

• 基础设施本身就是产品：您卖的就是账本、托管或 banking-as-a-service 能力本身，因此拥有它就是生意。
• 您的差异化在于任何供应商都不覆盖的需求——不是某家供应商这个季度还缺的功能，而是结构性地超出平台能力范围的东西。
• 您已经拥有一支具备生产级核心银行经验的资深团队，以及在数年无收入的情况下持续供养他们的资金。
• 监管机构或母公司把技术栈的完全自主控制作为不可谈判的条件强加给您。

一个五问框架

• 差异化：会有客户因为您的账本是自己写的而选择您吗？如果您的优势在产品、分销或定价，核心系统就是管道——不可或缺，但轮不到您重新发明。
• 时间线：在一个不会等人的市场里，业务能否承受核心系统建设期间一到两年的零收入？
• 团队：您是否拥有、或能否现实地招到并留住在生产环境运营过资金流转系统的工程师？
• 三年成本：把建设成本加上常设维护团队，与授权费加上已启用模块放在三年周期上比较——绝不要拿上线成本比上线成本。
• 退出：在每条路径上离开是什么样子？自建时，风险是关键人员带着知识离开。选择供应商时，要求独立实例、自己的数据库和自己的密钥，那样退出就只是一次迁移。

Coreza 在这个决策中的位置

Coreza 属于采购这一栏，并且是按照能通过上述清单的标准构建的：每位客户在 AWS 上运行独立专属实例，拥有自己的数据库和自己的加密密钥材料；每个模块——包括链、语言和代币——都单独授权，让价格跟随您启用的内容；服务商集成位于抽象层之后，商业协议始终归您所有。

这套核心的一个版本自 2024 年起在一家受监管的欧洲金融科技公司的生产环境中运行，而部署一个新实例只需数周：品牌、模块、语言和链都是配置，而不是工程。如果您正在核算自建还是采购，这正是我们邀请您进行的比较——三年成本对三年成本，并把那一栏隐藏成本补齐。