1. 必须分级脱敏，不能"一刀切掩码"

JR/T 0171 的分级是硬约束：

C3（鉴别信息）：银行卡磁道/芯片等效信息、卡片验证码、有效期、各类密码、生物识别信息 → 不应共享、转让、公开披露；除银行卡有效期外不应明文展示；必须加密存储

C2（身份与金融状况信息）：支付账号及其等效信息（含身份证、护照、手机号）、账户用户名、动态口令/短信验证码、财产信息、借贷信息、交易流水、证券委托、保险理赔、家庭住址

C1（内部信息）：开户时间、开户机构、支付标记等

通用行业做脱敏，往往是"手机号全掩码"就完事。金融不行——你得先建字段分级清单，再按级别定掩码规则。同一个手机号在客服场景可能只需后四位，在风控核查场景需要更多可见位，规则不一样。

2. 去标识化不能"只加密"——这是监管明文否掉的

JR/T 0171 对委托处理的原话是：采用去标识化（不应仅使用加密技术）等方式进行脱敏处理。

这句话杀伤力很大：加密只是把数据锁起来，密钥一解开还是明文；去标识化才真正改写字段值。

所以工作手机那种"前端显示 1385678、系统内可直拨、员工拿不到完整号码"的做法，在金融行业不是产品创意，而是标准落地形态——它同时满足"屏蔽展示"与"业务可用"两件事。

选型时可以直接拿这条去问厂商：你们的脱敏是加密存储，还是真正改写字段值？ 答"加密"的，不达标

3. C3 类信息根本不该进留痕库

这是最容易被忽略、也最致命的一条。

工作手机会全量留存通话与聊天内容。但卡片验证码、各类密码、生物识别信息属于 C3，除银行卡有效期外不应明文展示。

意味着：如果工作手机把客户在通话里报出的卡号、验证码、密码原样转写并存档——你以为在留痕合规，实际在系统里堆了一库 C3 明文，这是重大隐患。

金融场景必须要求：语音转写与聊天留存环节具备 C3 字段自动识别与屏蔽能力，且支持把这类内容排除在留痕库之外。

4. 境内存储，出境受限

JR/T 0171 对 C3、C2、C1  모두 要求：境内存储、处理、分析，向境外提供应符合有关规定。

这直接影响部署模式选择——金融机构用 SaaS 工作手机，服务器必须在境内，备份、日志、AI 分析链路也不能跑到境外。通用行业很少有人问这一条，金融必须问，且要写进合同。

5. 委托处理的限制比想象中严

这是金融最"要命"的一条，因为它直接约束厂商模式：

C3 以及 C2 类别中的用户鉴别辅助信息，不应委托给第三方机构处理；

委托行为不得超出客户授权同意的范围，并需准确记录和保存委托处理情况；

需对委托行为进行安全影响评估，确保受托方具备足够数据安全能力；

需对第三方进行监督——包括合同约束、定期外部信息安全评估与现场检查；

存储个人金融信息的数据库不得交由外部合作机构运维。

翻译成采购语言：金融机构上工作手机，优先选私有化部署或专属环境，而不是"把客户数据交给厂商统一运维的多租户 SaaS"。同时合同里必须写明受托方的数据安全义务、审计权与现场检查权。

6. 展示环节要"按角色动态脱敏"

银行业的标准实践是静态脱敏 + 动态脱敏组合：

静态脱敏：开发测试、数据出库到大数据平台时一次性脱敏，C3/C2 字段掩码或替换；

动态脱敏：生产场景（客服界面、柜员查询、报表展示）按角色实时遮蔽——柜员只看到掩码，授权岗验证后才能看明文。

套到工作手机上就是：客户经理默认只看掩码；因业务需要看完整号码时，走审批 + 留痕，而不是一个开关全放开。

通用行业通常不分这么细，管理员往往有全局明文权限——在金融，这属于权限过大，内审直接通不过。

7. 敏感个人信息需"单独同意"，且员工侧合规要求更重

金融账户信息属于个保法定义的敏感个人信息，处理此类信息除需明确同意外，还需单独取得同意，且需有更严格的安全保护措施。

同时，因为双罚制下个人可能面临终身禁业（前面提过的上海某支行案中，涉事客户经理因私售理财产品被终身禁止从事银行业工作），员工侧的合规宣导、告知书签署、培训留痕，在金融行业要比通用行业做得更实——这既是保护机构，也是保护员工。