上一篇讲了年金账户的三层结构（《企业年金与职业年金的账户结构》篇），这一篇讲运营链条上的角色分工。年金制度的精妙和麻烦都在同一点上：没有一家机构能单独看到全图。委托人、受托人、账管人、投管人、托管人，五方各持一段数据和一份职责，链条靠对账关系缝合。理解这套分工，是理解"多方协作型金融系统"的典型案例。
四个运营角色各管什么
按《企业年金办法》的角色定义：
- 受托人：责任的枢纽。选投管人、定投资策略、监督各方履约。受托人不碰资产也不记账，但它要看到全部数据——各家投管人的估值、账管人的权益账、托管人的资产账，汇总成计划层面的全景，向委托人报告；
- 账管人：记权益账。建个人账户、记录每笔缴费的到账和分配、按组合收益率分摊投资收益、算待遇。账管人的系统输出是"每人有多少"；
- 投管人：管投资。按受托人定的投资政策在组合范围内投资，每日估值（管多个计划时，同一投资策略的组合常归集运作，按计划虚拟切分），输出组合收益率。投管人的系统输出是"组合赚了多少"；
- 托管人：保管资产。计划全部资产存在托管户，资金划付按受托人指令执行（投管人的交易指令经托管人复核后对外），独立估值复核（《托管行的估值复核》篇的机制在年金的完整应用）。托管人的系统输出是"账上实际有多少"。
职责切分的设计逻辑是执行与保管分离、记账与管钱分离：投管人管钱不管账，账管人管账不管钱，托管人管实物资产不对账，受托人管监督不执行。任何两方合谋才能挪用资产，单方无法完成——这是养老金这种超长期资金的信任基础，用结构成本换资金安全。
核心对账：权益账 vs 资产账
全部对账关系里最核心的一条：账管人记的个人权益合计 = 托管人记的计划资产净值。
$$ \sum_j E_j = V_{cust} $$
左边是个人权益明细的逐笔汇总（缴费 + 收益分摊 − 支付），右边是托管户的证券市值加现金（《估值表的勾稽关系》篇的恒等式在计划层的应用）。两边是完全独立的两套系统、两套数据：账管人没有持仓数据，托管人没有个人缴费数据，等式成立靠流程保证，每天都要验算。
差异的来源是结构性的，不是事故。典型项：
- 在途资金：缴费从企业账户划出到托管户到账有 1-2 个工作日的时间差，账管人按"企业划款指令日期"记缴费，托管人按"资金到账日期"记现金，两边日期口径错位产生暂记差异；
- 应收应付：投管人卖出证券的交收在途，托管人按交收后口径记，估值里已反映交易未反映资金；
- 分摊尾差：收益分摊到个人的四舍五入，个人合计与组合总收益之间有几分钱尾差，按规则挂公共账户或归个人后，两边口径必须同步这个规则。
对账的处理分两步：先把差异分类归因（在途、暂记、尾差、真差错），在途暂记类挂"未达账项"自动滚动次日核销，真差错走差异工单；再对未达账项设账龄监控，挂账超过 N 天的未达项升级处理——未达账项滚雪球是年金对账失真的典型前兆。
受托人：数据汇聚的中枢
受托人系统是全链条的数据汇聚点，它的数据源接口最多：账管人的权益数据（月度对账文件）、投管人的组合估值（每日）、托管人的资产明细（每日）。受托人不直接参与对账（那是账管与托管之间的事），但它要独立重算计划层面的关键指标：计划总权益、各投管人业绩、费用计提，用独立计算交叉验证各方的数。受托人系统的价值不在处理，在"交叉验证"——它自己不算明细账，但任何一方的数据异常都会在汇总层暴露。
待遇支付流程最能体现多方协同：职工退休申请 → 受托人审批 → 账管人核算待遇金额（按个人账户权益）→ 向投管人发变现指令 → 投管人卖出证券 → 托管人复核指令并划款。一笔支付串起五方系统，每一步的状态和金额要能对上，全靠流水号的贯穿设计（《全链路日志与问题定位》篇的 trace 思想在跨机构场景的对应——只是这里的"链路"跨了法人边界，没有统一的日志平台，对账文件就是唯一的 trace）。
养老金系统的架构启示可以推广到一切多法人协作场景：信任不靠任何一方的善意，靠结构性的互相验证——执行与保管分离制造验证点，独立对账暴露差异，账龄监控防止差异沉淀。单家机构内部的系统可以靠统一数据模型保证一致，跨法人的系统没有这份奢侈，对账就是一致性的全部载体。