金融科技工程手册

原文 ↗ Hacker News 讨论 ↗

手册的总体反馈

  • 许多有金融科技经验的读者表示，这些建议符合真实世界的实践，对新人很有帮助。
  • 也有人觉得某些地方比较浅，或者遗漏了重要的注意事项（外汇、账本、合规）。
  • 一些人对 AI 署名持怀疑态度；作者澄清说，大部分内容来自自身经验，只是在编辑上借助了一些 AI。
  • 还有几位强调，任何通用手册都无法取代由律师和合规要求塑造的、公司特定的指导。

幂等性、重试、审计轨迹和 Webhook

  • 大家普遍认同幂等键、谨慎的重试语义以及有序事件至关重要，尤其是在支付和 Webhook 场景中。
  • 良好的审计轨迹被描述为既是调试工具，也是核心合规后盾；一些工程师甚至把“只有审计轨迹”作为主要数据源。
  • Webhook 在支付中被广泛使用（例如确认交易状态），但并非所有行业都通用。

如何表示金钱：整数、十进制、浮点数、字符串

  • 基于 int 的“最小单位”表示法（例如分）被辩护为许多领域的行业标准（HFT、支付、消费银行）。
  • 批评者认为，在以下情况下，采用“最小单位 + 整数”会变得脆弱：
    • 不同货币的小数位数不同，
    • 稳定币/加密货币具有不同精度，
    • 伙伴系统会默认假设不同的指数而不显式说明。
  • 讨论的替代方案包括：
    • 任意精度十进制，或语言原生的 decimal 类型。
    • 基于字符串的 JSON 表示，以避免浮点解析问题。
    • 整数尾数 + 整数指数（十进制浮点）。
    • 定点方案（例如按 10^n 缩放）。
  • 一个强势少数派观点认为，只要你：
    • 尊重精度限制，
    • 在每次操作后保持一致地四舍五入，
    • 使用专门的会计数学，
      那么 double 是可以接受且很常见的。
  • 其他人坚持认为，浮点数绝不应用于托管/记账余额；近似值只适用于建模/量化语境。
  • 大家一致认为，无论采用哪种表示法，明确的舍入规则和对账都至关重要。

账本、不可变性、事件溯源和数据建模

  • 大家同意核心货币状态应该是不可变的，并且应由变动推导而来，但：
    • 一些人更偏好完整的事件溯源；
    • 另一些人则倾向更简单的仅追加审计日志，以避免复杂的状态回放。
  • 关于“余额永远不存储”是否可行存在争议；有些人认为这几乎是糟糕建议。
  • 有人指出，外汇和复杂金融工具需要比手册给出的更细致的处理（汇率、舍入策略、法律上的精度规则）。
  • 数据血缘以及外部/供应商数据的版本管理被强调为缺失但重要的话题。

合规、PII 和组织约束

  • 一种观点支持将 PII 与金融记录分离，以便在保留所需金融历史的同时支持删除。
  • 另一种观点警告说，这可能与 KYC/AML 以及调查要求冲突；他们强调应遵循内部、按司法辖区制定的政策，而不是泛泛而谈的建议。
  • 有人认为，受监管公司的工程师大多应该遵循既有的内部标准，而不是在网上“找模式”；也有人反驳说，为了现代化遗留实践，需要借鉴外部思路。

“金融科技”的范围与领域特定权衡

  • 多位评论者指出，“金融科技”涵盖了非常不同的子领域：
    • HFT 和低延迟交易，
    • 消费者支付和银行，
    • 加密钱包和区块链，
    • 风险/量化建模。
  • 什么是“正确”的做法（整数 vs 十进制、事件溯源的深度、精度水平）会因子领域以及性能/合规约束而有很大不同。
  • 几位评论者强调，学习会计和账本原理，以及数据库基础知识，比任何特定技术选择都更重要。

其他实用说明和资源

  • ACH/Plaid 的余额检查并不能保证资金安全；在结算前，资金可能会消失。
  • 透支处理以及“提交后才知道是否成功”的语义都被承认为现实存在。
  • 提到的进一步学习资源包括面向开发者的会计指南、账本扩展文章、数据密集型系统书籍，以及资本市场和固定收益的标准读物。