客户持有的基金想换个产品，常规路径是赎回 A、等钱到账、再申购 B，资金在路上要停 T+3 以上，还要交两笔费用。基金转换（Fund Switch）把这两步合成一笔；转托管（Transfer of Custody）解决的是另一个问题——份额本身不动产品，但要在不同销售机构甚至不同 TA 之间搬家。两个功能都是"客户少等几天"，但系统实现完全是两个物种：转换是账务组合，转托管是数据迁移。
基金转换：赎回与申购的原子化
转换的业务本质是：按 T 日净值同时做一笔 A 的赎回和一笔 B 的申购，金额首尾相接：
$$ M_{\text{净}} = q_A \times N_A^{(T)} - F_{\text{赎回}}(q_A) $$ $$ q_B = \frac{M_{\text{净}} - F_{\text{申购}}(M_{\text{净}})}{N_B^{(T)}} $$
客户感知的差异在两点。一是时间：赎回款不用出产品账户再进来，资金在产品内部轧掉，T+1 确认后直接是 B 的份额，省掉 T+2 到 T+3 的在途。二是费用：赎回 A 的赎回费照收，但申购 B 的申购费通常给"补差"优惠——只收两只基金申购费率的差额部分，老式做法甚至直接免申购费（后来销售新规对费率优惠的合规口径收紧了，各家合同写法不同，系统按档取数就行）。
系统实现的关键是原子性。转换在 TA 批处理里必须作为一笔复合流水处理：赎回确认和申购确认同生共死，不允许出现"A 赎回了 B 没申上"的中间态——那等于客户的钱消失在系统里。做法是把转换单挂在统一流水号下，确认结果分四个状态：转换成功、转出成功转入失败（转入失败按失败处理，转出资金退回客户账户，这条路径要和直销/代销渠道约定清楚）、转出失败、全部拒绝。后两种天然安全，第一种要退钱，第二种最麻烦，是客诉高发区，必须能在确认文件里区分表达。
还有一个隐蔽约束：同一家 TA。转换只能发生在份额登记在同一个 TA 的产品之间（同一基金管理人旗下的基金，自建 TA 内部互转）。跨管理人的"转换"实际是超级转换——先赎回到客户资金账户再申购，资金真的要在路上停几天，系统上就是普通赎回 + 普通申购的组合单，只是前端打包展示。做渠道对接时这两种"转换"的字段定义完全不同，别混。
转托管：份额的物理迁移
转托管解决的是客户想换销售渠道（比如从银行渠道换到券商渠道）但不想卖出基金的场景。份额从转出机构的 TA 记录迁到转入机构名下。按迁移范围分两档：
系统内转托管（同一 TA 下换销售机构，也叫"转销售"）：最轻量，TA 内部把份额明细的"交易账号"从转出机构改为转入机构，当日批量即可完成，资金不动，持有期连续计算。本质是 UPDATE 一条明细的渠道归属，但要保留转托管流水，因为费率分成（《直销与代销》篇的客户维护费）要按转入机构重新归属，历史分成不清算、未来分成重挂。
跨 TA 转托管（比如从中登 TA 转到基金公司自建 TA，或反过来）：真正的数据迁移。流程是转出 TA 冻结份额、生成转托管明细文件发往转入 TA，转入 TA 按文件登记新份额。难点全在时点：
- 转出 TA 在收到申请当日做份额冻结（防止转出在途期间被赎回）；
- T+1 或 T+2 转出 TA 出文件，文件在途期间份额处于冻结状态——客户这期间看到"可用份额减少"，要会解释；
- 转入 TA 登记成功回传确认，转出 TA 做份额划出销记。任一端失败，走退回路径，份额解冻回到原机构。
跨 TA 转托管的字段对齐是暗坑高发区：两只 TA 对"份额类别、分红方式、持有期起算日"的口径要逐字段核对。持有期起算日必须以原始取得日迁移，不能按转托管日重算——否则客户转个托管，惩罚性赎回费的持有期门槛被重置，这是客诉和合规双重事故。
为什么这两个功能值得单独做
从客户视角它们是体验优化，从管理人视角是存量份额的护城河：转换功能把"想换产品"的客户留在自家产品线内，转托管成本越低、客户越敢在任意渠道买。所以行业里的趋势是系统内转托管当日达、跨 TA 转托管 T+1 达，文件接口标准化（中登主导的标准报文格式）。TA 系统厂商的转托管模块成熟度，是基金公司选型时的硬指标之一。
把转换和转托管放在一起看，能看清 TA 系统"账务严谨"和"数据迁移"两种截然不同的工程能力：前者考验流水设计的原子性，后者考验跨系统文件协议的鲁棒性。客户感知都只是"快了一点"，但对账工作量是加倍的——每一笔迁移都要在转出方、转入方、TA 总账三处同时平账。