银行业务专栏 on 追风笔记

支付清算全流程拆解

Tue, 10 Feb 2026 00:00:00 +0000

普通人眼里的「转账」是一个瞬间动作：输金额、点确认、余额变了。但背后的资金流动要经过支付、清分、结算三个阶段，跨过多个系统，才可能真正「钱到了」。理解这套链路，是做银行支付系统的前提，也是排查「钱怎么少了」「为什么还没到账」的地图。

一笔转账背后发生了什么

当你在 App 上给朋友转 1000 元，这笔指令从你的银行出发，要穿越自己的核心系统、跨行清算通道、对方银行的核心系统，最后落到对方账户。中间任何一环的状态错位，都会让这笔钱「卡在半路」。所以支付系统设计的第一个原则，是把每个阶段的状态显式建模，而不是用一个「已转账」含糊带过。

支付系统最危险的 bug，不是算错金额，而是状态机说不清一笔钱现在到底在哪：是已扣、已发、已清算、已结算，还是已退回。

三个阶段：支付、清分、结算

这是整条链路的主干，三者的边界必须划清。

支付：机构内部的记账

付款方银行收到指令后，先校验账户状态、余额、限额、风控，然后在自己的核心账本上记一笔「待清算」的借贷。这一步完全发生在单个机构内部，还没有任何人把钱真正挪动。

清分：轧差与净额

清分是交易双方机构把彼此的借贷指令汇总、计算净额的过程。它有两种模式：

全额清分：每一笔借贷都单独计算，资金流与业务流一一对应，安全但占用流动性。
净额清分（轧差）：把一段时间内的多笔借贷相互抵扣，只交差额。比如 A 欠 B 100 万、B 欠 A 80 万，净额就是 A 再付 B 20 万。

结算：资金的真实位移

结算是资金在央行或清算机构的账户上真正转移，借贷最终平衡。只有结算完成，这笔钱才算「落地」。在此之前，它只是账面上的债权。

阶段	发生位置	是否动真实资金	关键产物
支付	付款方银行内部	否（仅记账）	支付流水、待清算挂账
清分	清算机构/双方对账	否（算差额）	净额头寸、清分文件
结算	央行/清算账户	是	准备金账户余额变动

清分算的是「谁欠谁多少」，结算做的是「把钱真正挪过去」。只清不分或只分不结，都会让账面悬空。

大小额与网银清算系统

中国人民银行的大小额支付系统，是跨行资金流动的主动脉。不同系统对应不同的金额、时效与成本取舍。

系统	处理方式	金额与时效	适用场景
大额支付系统（HVPS）	逐笔实时全额	大额、实时、营业时间	对公大额、同业头寸调拨
小额支付系统（BEPS）	批量净额轧差	小额、定时撮合	日常零售、代收付
网上支付跨行清算	逐笔/批量	7x24、准实时	网银、手机银行跨行

大额走全额是为了安全和实时，小额走净额是为了降低流动性占用和通道成本。设计路由时，按金额和时效要求分流，而不是一刀切全走大额。

计息与限额：算得清才能管得住

Mon, 22 Jun 2026 00:00:00 +0000

银行系统里最容易「看起来很简单、做起来全是坑」的两件事：计息和限额。它们一个决定「钱怎么生钱」，一个决定「钱不能出什么事」。两者共同的特点是：规则必须可被验证，结果必须可被复核。

计息：口径比公式重要

公式 本金 × 利率 × 天数 / 基数 人人会写，难的是口径统一。

计息基数：是每日余额、还是日均余额？贷款多用实际天数，存款各有约定。
闰年与节假日：一年按 365 还是 360？结息日遇节假日顺延还是提前？
利率变动：固定利率、浮动利率重定价日如何衔接，分段计息怎么切。

BigDecimal interest = dailyBalance
 .multiply(rate)
 .multiply(BigDecimal.valueOf(days))
 .divide(BigDecimal.valueOf(360), 6, RoundingMode.HALF_UP);

计息 bug 最可怕的结局，不是算错一笔，而是「每天错一点点，半年后对不上，却找不到从哪天开始错」。所以计息必须有可复现的逐日明细。

限额：控制点要前置

限额分好几类：单笔、日累计、月累计、余额上限、渠道限额。关键不在「存一个上限数字」，而在控制点必须前置到交易校验环节，而不是事后统计。

限额类型	控制点	典型场景
单笔限额	交易发起前	防单笔大额盗刷
日累计	交易前累计判断	渠道风控
余额上限	入账后校验	产品合规约束

限额规则要可配置，且变更留痕、可追溯生效时间。
累计类限额必须考虑并发：用原子计数或数据库约束，别靠「先查后扣」。
超限处理要明确：拒绝、转人工、还是降级，不能悄悄放行。

if (dailyUsed.add(amount).compareTo(dayLimit) > 0) {
 throw new LimitExceededException(cardNo, dailyUsed, dayLimit);
}

限额系统宁可「误杀一笔正常交易」，也不能「放过一笔该拦的」。前者是体验问题，后者是风险事件。

AML/KYC：合规不是绊脚石

Tue, 14 Jul 2026 00:00:00 +0000

一提 AML/KYC，业务侧往往皱眉：开户变慢、交易被拦。但合规不是外挂的「麻烦」，而是银行必须内建的能力。把它当系统一等公民来设计，风控和体验才能双赢。

KYC：先搞清楚你是谁

KYC 是起点，不是收集证件复印件，而是建立持续可验证的客户画像。

身份核验：证件真实性、活体、工商比对。
风险分级：按行业、地域、业务性质定级。
受益所有人：穿透到最终自然人，防借壳。

customer_risk:
 level: high
 factors: [virtual_asset, high_risk_region, pep: true]

AML：盯着钱往哪走

反洗钱看交易行为与资金路径，而非单次金额大小：名单监控、交易监测（规则+模型打分）、可疑报告（STR）走调查上报流程。

维度	信号	处置
频率	短期多笔等额进出	触发复核
对手方	命中制裁名单	阻断上报
金额	拆分规避限额	合并评估

真正的反洗钱是「识别不合理模式」：规整发工资的小额账户突然集中收款，比一笔大额更可疑。

工程落地要点

名单更新要准实时且对存量重跑；规则先求可解释、可回测；误报率持续度量；告警工单化、可审计。合规做扎实，业务国际化反而少踩坑。

一文理清 ECIF：客户信息为什么要「集中」

Mon, 10 Aug 2026 00:00:00 +0000

在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。

ECIF 解决什么

ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供唯一客户视图。

唯一标识：用客户号（Party ID）统一自然人/机构，而非证件号。
主次关系：支持一人多户、一户多卡，但主数据唯一。
服务化：其他系统通过接口查询，不再各自落库。

技术上的关键取舍

读写分离：主数据写入强一致，查询可走缓存/只读副本。
变更可溯源：客户信息变更需要留痕，满足监管审计。

ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。