一份名为《Fintech Engineering Handbook》的在线手册在 2026 年 6 月 26 日发布。它面向准备进入或已经身处金融科技领域的工程师，整理金额表示、账本、审计、事件溯源等工程模式。

有意思的地方不在“又多了一份技术资料”。而在它把金融系统最容易被低估的问题说得很直：难点不只是功能复杂，而是钱不能凭空出现，也不能在链路里消失。

普通系统里，状态错了还能补。金融系统里，余额错一分，后面跟着的是用户权益、财务解释和审计追问。

三条底线：不造数、不丢数、不信任

手册把金融工程压缩成三条原则：No invented data、No lost data、No trust。

中文说得更直白：不造数、不丢数、不信任。

原则工程含义常见落点
No invented data系统不能因为重复请求、错误更新、并发写入而“造钱”幂等、去重、对账、不可随意改余额
No lost data金钱变化必须完整留下，不能只保留当前状态全精度、不可变流水、审计轨迹
No trust不默认相信外部机构、内部组件或输入数据Webhook 校验、多源交叉验证、异常报警

这三条看起来朴素，但很容易被互联网后台经验冲掉。

很多业务系统习惯围绕“当前状态”建模。订单现在是什么状态，库存现在还剩多少，用户现在是什么等级。金融系统不太一样。它关心的是：这个当前值从哪里来，中间每一步能不能复算，出错后能不能定位。

我更在意的是第三条：No trust。

它不是说所有人都不可信，而是系统设计不能靠“应该没问题”。外部支付回调可能重复，内部任务可能重跑，人工配置可能误改。金融系统要把这些失败当作常态来处理，而不是当作小概率事故。

对刚进入 fintech 的工程师，这意味着不要只学支付接口怎么调。更要学幂等键、状态机、对账、补偿和审计字段为什么存在。

对技术负责人，这意味着评审时要少问一句“功能跑通了吗”，多问一句“钱能不能从原始流水复算回来”。

钱不是 float，余额也不是事实

手册对金额表示给了一条硬规则：不要用浮点数表示钱。

原因不复杂。浮点数会带来精度损失。这个损失一旦进入数据库、接口或报表，后面很难无损恢复。金融系统怕的不是多写几行代码，怕的是错得很小，却无法解释。

更麻烦的是，精度问题不是一个地方能解决的。存储、计算、序列化要分开看。

环节更稳妥的做法风险点
存储用最小货币单位的整数，或固定精度类型把金额存成 float/double
计算使用 BigDecimal 一类任意精度类型，并明确舍入规则中间计算偷偷丢精度
序列化用字符串或最小单位整数传输裸 JSON number 可能被解析成 IEEE-754 double

币种也不能省。

金额必须和币种绑定。系统应该禁止不同币种之间的隐式加减。100 USD 和 100 EUR 不是同一种“100”。把币种当备注字段，是很多问题的开端。

汇率也不能只存一个数字。它至少要有方向、时间和来源。

EUR/USD 不能简单等同于 USD/EUR 的倒数。买入价和卖出价可能不同。今天的汇率也不能替代交易发生时或估值日的汇率。

这就是金融系统和普通后台的分水岭。普通后台常把余额字段当事实，再补一份日志。金融系统更接近会计账簿：流水是事实，余额是结果。

手册强调复式记账思想，也是在说这件事。一笔钱总有来源和去向。外部支付机构也应有对应账户。余额可以缓存，但缓存只是性能优化，不是真相本身。

这对支付、账本、清结算团队很具体：

  • 新建账户体系时，先定义分录和账户，不要先设计一个可直接更新的 balance 字段。
  • 做多币种能力时，金额、币种、汇率方向、汇率时间、汇率来源要一起进入模型。
  • 做报表或月结时，优先验证余额能否由不可变流水推导，而不是只核对当前表里的数字。

一句老话很适合这里：账不怕细，怕断。金融系统里，断点比慢更危险。

审计不是补日志，事件溯源也不是万能药

手册对审计轨迹的要求很具体。每一次变化要回答四个问题：发生了什么，何时发生，谁或什么触发，为什么发生。

“为什么”尤其容易被省掉。

一次风控拦截如果只记录 blocked，后面很难解释当时依据了哪些规则、输入和判断。一次人工调整如果只留下新值，也很难判断它是修正错误、执行运营策略，还是越权操作。

手册还区分了 value time、booking time 和 settlement time。交易发生时间、系统入账时间、资金实际清算时间，经常不是同一个时间。

如果系统只留下一个 created_at，跨日报表、月结、追账和审计都会变得很难。不是查不到数据，而是说不清这笔钱到底应该算在哪一天。

这里也要加一个限制：事件溯源不是全系统都必须采用。

手册把它放在更克制的位置。它适合需要审计轨迹的地方，比如账本、关键资金状态变化、重要配置变更。周边域可以继续使用传统模型，再配可靠的变更日志。

原因很现实。事件溯源会带来投影、查询、版本演进和回放成本。把它当成架构潮流到处套，最后可能不是更可靠，而是更难维护。

真正该观察的，不是这份手册会不会变成行业标准。更实际的是，团队能不能拿它查出自己的系统缺口：

角色应该立刻检查什么不检查的代价
刚进入 fintech 的工程师金额类型、币种绑定、幂等键、审计字段写出能跑但说不清账的代码
支付/账本/清结算负责人余额能否从流水复算，汇率能否追源，人工操作是否留痕对账失败后只能靠人工猜
风控或财务系统负责人拦截原因、规则版本、触发主体、时间口径是否完整事后无法解释当时判断

目前能看到的价值，是它把很多团队零散踩过的坑，整理成一套共同语言。

但它也不能替团队做完设计。多机构对账失败怎么补偿，历史事件 schema 怎么演进，人工干预怎么授权和复核，这些仍要落到每个系统自己的边界里。

所以这份手册更像一把尺，不是一张施工图。它量的不是功能多不多，而是金钱数据能不能守恒、可追溯、可验证。