支付结算与账户 — 一笔转账的旅程
一句话总结
银行系统分为渠道系统、核心账务系统、信息系统三层，一笔转账要经过这些层和支付清算网络才能记入分户账——这段旅程未必完整，所以才有日终处理和对账。
为什么分成三层
刚进银行时，会听到“那是核心账务系统的事”“应该在渠道端拦住”“去信息系统里取数”之类的话。这三者既是组织的名称，也是系统的名称。
| 系统 | 作用 |
|---|---|
| 渠道系统 | 与客户接触的地方。手机银行、网上银行、ATM、柜面终端、开放银行 API。 |
| 核心账务系统 | 持有账户和分户账的核心。是唯一能改变余额的地方，运营最为保守。 |
| 信息系统 | 复制核心账务系统，用于分析、报告和营销。它不是原件，而是副本。 |
这样划分是为了隔离负载和风险。渠道每天要承受数千万次查询，但不改变余额。核心账务系统会改变余额，但受到保护，不承受查询负载。信息系统即使运行繁重的汇总，也不会拖慢核心账务系统。代价也随之而来——层与层之间产生了往来的报文（消息），而这些往返并不总是完整的。
一笔转账的旅程
客户在手机银行中点击跨行转账时，大致会发生以下事情。
- 渠道系统确认认证和限额，向核心账务系统发送取款请求报文。
- 核心账务系统确认付款账户余额，并在分户账中记录取款。
- 银行通过金融结算院的共同网络向收款银行发送入账请求。
- 收款银行把钱存入收款人账户并作出应答。对客户来说，到这里只需几秒。
- 银行之间实际的资金转移并不逐笔进行。而是汇总一天的交易计算差额，通过韩国银行金融网络，在各银行于韩国银行开设的往来账户之间结算。这就是差额结算，实际上在下一个营业日的规定时刻进行。
这个结构中有一个重要事实：存在一段收款人已经收到钱、而银行间结算尚未完成的时间。如果在此期间有一家银行倒闭会怎样，这就是结算风险，因此韩国银行要管理担保和限额。
分户账、日终处理与一致性
核心账务系统的分户账是按时间顺序累积交易的记录，余额是它的合计。出于性能考虑，每个账户都有余额字段，但那只是副本。一天结束时运行日终处理，确认当天的交易并切换会计日期。日终之后不能再以当天日期记入交易，所以截止时刻之后的交易记入下一个营业日。
日终处理的核心程序是对账。渠道应答成功的交易与记入分户账的交易、我方分户账与对方机构的清算文件、余额字段与分户账合计——要确认这些组合是否一致。不一致的形态只有固定的几种。
| 不一致 | 发生了什么 |
|---|---|
| 只在渠道中存在 | 应答已经发出，但记入分户账失败。客户以为已经成功。 |
| 只在分户账中存在 | 已记入分户账，但应答迟到，渠道记录为超时。客户以为失败而再次点击 → 重复交易。 |
| 金额不同 | 报文解析、位数、币种单位问题。少见，但存留时间最长。 |
| 只有余额不同 | 不经过分户账直接修改了余额字段。这不是更正，而是事故。 |
更正也有规则。不修改也不删除分户账中的行。遗漏的交易以更正交易补记，错误的交易以反方向交易冲销。发生过的事情必须按顺序保留下来，才能回应客户投诉和审计。
在处理资金的系统中，系统工程师实际会遇到的事
在金融领域，开发人员最先感到吃惊的不是业务规则，而是对时间和顺序的要求。
一天并不在午夜结束。 营业日与日历日不同，截止时刻之后的交易会转到下一个营业日。所以“今天”这个概念不能直接取系统时间，必须另有管理业务日期的地方。漏掉这一点，日终前后几分钟内的交易属于哪一天，就会各说各话。
日终处理期间不能动分户账。 在确定余额时如果有新交易进来，合计就对不上。所以在日终窗口（window）期间要么禁止写入，要么把这期间进来的交易先放进队列，日终之后再记入。如果服务必须 24 小时运行，就会形成核心账务系统做日终、只有渠道保持在线的结构。
对账（reconciliation）的主体是异常处理。 这是把我方分户账与对方机构的记录对齐的工作，大部分会自动对上，问题在于对不上的那几笔。要把金额不同的、只在我方存在的、只在对方存在的区分开，并且必须确定每一类由谁、在什么期限内处理。没有这个流程，对不上的交易就会越积越多，终有一天变成很大的数字。
撤销不是删除。 删除错误的交易，审计轨迹就会中断。要再建立一笔反方向的交易进行冲销，并把两笔交易相互关联。分户账必须是只能追加的账本，这样才能重新计算任意时点的余额。
金额绝不能用浮点数处理。 0.1 + 0.2 不等于 0.3，这在以韩元为单位时也是问题。要用整数（最小货币单位）或十进制类型存储，并把币种和小数位数与数值一起带着走。
时间存储时用 UTC，判断时用营业日。 两者一旦混用，午夜附近的交易必然出错。
实际工作中真正重要的事
第一，超时不是失败。 它表示渠道没有收到应答，而不是核心账务系统没有处理。渠道在超时后必须查询结果进行确认，并向客户显示“处理中”。如果显示“失败”，就会产生重复交易。
第二，重试需要幂等键。 要让同一请求即使来两次也只记入一次，核心账务系统必须记住渠道生成的唯一参考号。对账找出重复交易是事后措施，幂等键是事前措施。
第三，余额字段不是真相。 不一致时以分户账为准。用 UPDATE 修改余额的痕迹本身就是审计发现的问题。
在下一个实验中，你将亲自对渠道日志和分户账进行对账，找出上述四种不一致，并用更正交易加以纠正。