前面所有文章都假设一个前提：参与人交收时能拿出钱和券。这个前提每天都在被考验——结算备付金余额不足、托管的证券被司法冻结、参与人盘中出事下午就交不出券，都是真实发生过的场景。违约处置就是当这个前提垮掉时的标准动作：谁来垫付已经履约的一方、违约的头寸怎么处置、损失怎么算、钱怎么追。这套流程平时完全不显眼，一旦启动就是全市场瞩目，系统设计的好坏在这时候全部见真章。
处置流程的四个阶段
CCP 的违约处置可以拆成四个阶段，顺序有严格的依赖：
垫付（第一天）：处置的第一优先级不是惩罚违约方，而是保护已履约的守约方——保证交收的承诺必须在违约当天就兑现，否则 CCP 的信用背书就垮了。垫付的资金从违约处置的水池出（顺序见《保证交收与非保证交收款》）：先动违约方的保证金，不够再逐层上溯。垫付动作要快，通常以"日终发现不足、当日完成垫付"为目标。
头寸处置（随后数日）：垫付只是止血，违约方留下的净头寸还挂在 CCP 账上——可能是一个净买入 20 亿的股票篮子。CCP 要在市场上平仓这些头寸，把风险敞口归零。处置的原则是"尽快但不砸盘"：流动性好的品种直接市价平，持仓大的要分批、要用算法执行（TWAP/VWAP，参见交易系统篇），极端情况下组织其他参与人协议受让。处置期间的行情波动造成的损益，记进违约损失。
损失分摊（处置完成后）：平仓完毕算总账：垫付了多少、平仓亏了多少、追回了多少。净损失按水池分层规则分摊——先违约方保证金（已没收）、再 CCP 自有、再全体共同担保金。分摊的计算要逐笔记账、向全体参与人公告，这不是财务细节，是 CCP 信用体系的透明度来源。
追索（长期）：对违约方的法律追索可以持续数年，追回款项按原分摊顺序反向回填。系统和法务的接口在这里：分摊记录要保存完整，否则多年后追回的钱不知道怎么分。
系统在处置窗口内的底线
违约处置期间，受影响的绝不只是违约方一家——与违约方有未到期交易的参与人、共用同一结算路径的客户，都处于不确定状态。处置窗口内系统要守住三条底线：
一是守约方的交收不受影响。这是设计目标，落地时考验的是数据隔离：垫付逻辑只依赖违约方的保证金账户和处置水池，绝不能因为要动水池而在代码路径上阻塞其他参与人的正常交收——批量设计里这通常意味着垫付和正常交收是两个并行任务，只在总账层面汇合。
二是风险敞口的实时可见。违约当天的每一个时点，处置团队要能回答：当前敞口多大、已平多少、保证金覆盖率还剩多少。这要求清算系统对"处置视图"有一等公民支持——把违约方的持仓、保证金、在途交收从正常报表里单独切出来实时汇总，而不是处置时临时写 SQL。
三是处置动作本身全程留痕。冻结、强平、垫付、分摊，每个动作的时间、操作人、依据（触发了哪条规则）都要进不可篡改的审计日志（审计日志篇展开）。违约处置事后必然被监管调查，处置动作的法律效力直接取决于留痕的完整度。
为什么速度本身是风控
一个反直觉的事实：违约处置里最常见的损失来源不是违约本身，而是处置拖延。违约头寸挂在那里，市场价格每一天都在动——持仓 20 亿的股票篮子，指数跌 2%，敞口就扩大 4000 万。损失期望可以粗写成：
$$ E[\text{损失}] \approx \text{敞口} \times \sigma_{\text{日}} \times \sqrt{T_{\text{处置天数}}} $$
平方根项来自随机游走的扩散性质：拖得越久，不利波动的幅度按时间的平方根增长。这就是为什么处置预案要在平时就备好——违约方大持仓的清单定期生成、平仓路径和压力情景提前演练，而不是违约发生后第一周先开会讨论怎么办。系统的价值在这个阶段体现得最直白：平时看起来多余的"违约方敞口日报"，启动处置那天就是作战地图。