上一篇讲确认引擎的流水线，其中校验环节埋了一个没展开的钩子：赎回申请要做"巨额赎回预检"。这一篇专讲这个分支。它是开放式基金合同里最硬的一条保护条款，也是 TA 批量里少数会改变当日全局确认结果的逻辑——不是逐笔判定的规则，是先算总账再回头改明细的规则。
10% 红线是怎么定义的
《公开募集证券投资基金运作管理办法》的口径：单个开放日净赎回申请超过基金总份额的 10%，即巨额赎回。注意是净赎回申请：
$$ \text{净赎回} = \text{赎回申请总额} - \text{申购申请总额} - \text{转换转出总额} + \text{转换转入总额} $$
四者都是申请口径、当日的、跨销售机构汇总。触发判定用的是上一开放日（T-1 日）确认后的基金总份额作分母：
$$ \text{巨额赎回} \iff \frac{\text{T 日净赎回}}{\text{T-1 日基金总份额}} > 10\% $$
为什么是净额而不是赎回总额？防误伤：末日里有大买有大卖，真实的流动性压力是轧差之后的缺口。系统实现上这要求确认批量先汇总再判定——所有渠道的赎回申请都要到齐、全部申购转出数据都入账之后才能下结论，这和确认流水"边算边出"的直觉相反，巨型批量里这是一个天然的全局栅栏点。
管理人手里的两个选择
合同里巨额赎回触发后，管理人可以二选一（也有合同写死顺延的）：
顺延兑付：T 日受理的赎回申请全部有效，但当日只兑付不超过总份额 10% 的部分（扣除当日申购抵充后），剩余部分顺延到下一个开放日兑付，依此类推直到兑付完。顺延部分按实际兑付日的净值计算赎回金额——客户承担了延期期间的净值波动，这是顺延的本质：赎回价格风险从管理人转移回客户。
比例确认：对 T 日的全部赎回申请按同一比例确认，未确认部分不延顺、视为撤销：
$$ \text{确认比例} = \frac{\text{可兑付上限} - \text{T 日申购抵充}}{\text{T 日赎回申请总额}} $$
每个赎回申请按确认比例打折出确认金额。比例确认对客户更"快"，但波动大的时候单日只能拿回一部分现金；顺延保留全部赎回权利，代价是价格不确定。系统层面两种模式的共同点是：确认结果在 T 日晚上批量之前是不可知的，销售机构白天受理时只能告诉客户"已受理"，绝不能承诺当日可兑付金额——这决定了销售渠道的页面文案和客服话术。
顺延的排期实现
顺延是批量里比较tricky的一块。顺延单不是简单的"塞到明天"：T 日顺延到 T+1 的赎回，和 T+1 新到的赎回申请同池竞争 T+1 的兑付额度，且按监管要求通常顺延部分优先。实现上一般给每笔赎回申请挂一个"顺延序号"和"顺延标记"：
- T 日序号按受理时间排；
- 顺延进入 T+1 时继承原序号，排在 T+1 当日新申请之前；
- 每日批量先消耗顺延队列，再按序号过新申请，直到当日额度耗尽，余下继续顺延。
伪代码就是一个游标推进：
quota = total_shares * 0.10 + today_purchases # 当日可兑付上限
for req in sorted(pending, key=lambda r: r.seq):
if req.shares <= quota:
confirm(req, today_nav) # 按今日净值兑付
quota -= req.shares
else:
defer(req, seq=req.seq, to=next_open_day) # 顺延，序号不变
还有一个费率细节：顺延兑付按实际兑付日净值算金额，但赎回费的持有期从原始申请日起算——客户不因为顺延被多收惩罚性费率。这两个日期在数据结构里要分开存，混成一个字段就会在费率档判断上出错。我在评审里见过把"申请日"覆盖成"兑付日"的实现，持有不足 7 天的客户被多收 1.5%，客诉查了一个月。
对流动性和销售端的影响
巨额赎回条款保护的是剩余持有人：基金被迫折价变现资产时，先跑的人把冲击成本留给了留下的人。10% 上限把单日冲击封顶，顺带把"挤兑"从 T 日阻止。但它给系统加了一个全局状态：某只基金进入顺延状态后，确认文件里要带顺延标记和预计兑付日期，销售机构的客服系统要能解释"为什么只到账一半"。
实务里还有个不成文的惯例：债券基金在信用事件后的连续巨额赎回，管理人会直接启动侧袋机制或暂停申购——暂停申购是另一个分支（额度控制直接清零），和巨额赎回是两个独立开关，系统里不要耦合在一起。
巨额赎回这条规则教给系统设计者一件事：有些业务分支的正确性依赖于全局聚合之后再回头修改明细。把它当成逐笔规则写，批量怎么并行化都会错；承认它是栅栏点，围绕它设计"先总后分"的两阶段批量，才是对的实现。