金融数据分类分级完整指南：三大痛点、六份监管文件、四组件方法论

金融数据分类分级

痛点、需求与体系构建

前两期我们谈了行业层面的两个普遍现象——伪 AI 工具的盛行，以及准确率指标的水分。这两期都是「行业批判」视角的内容，更多是为采购方提供识别工具的方法。

这一期我们换个视角。

作为整个「AiDClass 观察」系列的核心一期，我们要正面回答一组金融客户、潜在客户、投资人都在问的问题——

金融行业在分类分级这件事上,真实的痛点是什么?要建一套真正能运营的体系,需要哪些组件?银行、保险、券商、金控这四类机构,各自的特殊性如何处理?一套完整的金融分类分级方法论应该长什么样?

这一期会比较长。但如果你只读「AiDClass 观察」系列里的一篇，我们希望是这一篇。

一、为什么金融是分类分级的「高地」

在中国，全行业都在做分类分级——医疗、电信、政务、能源、教育、交通……每一个行业都有自己的细则。但金融业有三个特点让它成为这件事的「高地」：

特点一:监管密度最高

没有任何一个其他行业，能像金融业一样在分类分级领域有六份并存生效的监管文件。这不是制度上的冗余——是因为金融业本身被三个不同监管口径覆盖：人民银行口径、金融监管总局口径、证监会口径，每个口径都有自己的分类分级体系。

一家综合金融集团，往往同时受三个口径监管，需要同时满足三套（甚至更多）分类分级标准。

特点二:字段规模最大

一家大型银行的核心系统群字段数通常在 5-10 万；一家头部保险公司的全业务库（含车险、寿险、健康险、再保险、精算）字段数可以达到 20 万以上；一家金控集团的全集团数据资产，可能涉及数十万到上百万字段。

这种字段规模意味着：分类分级这件事不能靠人工，必须靠自动化；自动化的准确率每提升一个百分点，背后都是数千到上万次正确判断。

特点三:执法压力最实

2026 年金融监管总局推动的「四个一批」专项行动——发现一批、整改一批、通报一批、处罚一批——是中国数据安全监管历史上第一次有明确执法链条的合规要求。

这三个特点叠加之下，金融业的分类分级，已经从「制度上的要求」变成了「运营上的能力」——做不到位的机构会被通报甚至处罚。

金融业是中国数据分类分级最复杂、最紧迫、最有标杆意义的行业。把金融做透,其他行业就有了参照系。

二、金融机构在分类分级上的三大真实痛点

我们在过去几年与几十家金融机构交流的过程中，反复听到三个痛点。它们不是「技术不够先进」「投入不够多」这种空泛的问题，而是非常具体的运营困境。

痛点一:字段规模带来的工程量

以一家中型保险公司为例：投保系统、核保系统、理赔系统、再保险系统、精算系统、客户系统、运营系统……合起来约 50-80 个业务系统，5-10 万张表，15-25 万个字段。

要给这 15-25 万字段做分类分级，传统做法是——业务部门提需求、数据治理团队整理字段、合规部门审核标签、技术部门落地标记。这个流程的现实表现是：

1. 一次完整的分类分级项目周期通常 6-12 个月;

2. 需要协调业务、数据、合规、技术四个部门，跨部门会议数十次;

3. 结果是一份「快照」——发布时是最新的，三个月后已经过期。

这种「一次性、慢速、易过期」的工作模式，根本无法支撑金办发 93 号文要求的「能运营的能力」——监管要求的是「动态更新的数据资产目录」，而不是一份每半年生产一次的合规文档。

痛点二:多套标准并存的对齐难题

前面提过，金融机构往往同时受多个监管口径覆盖。一家综合金融集团：旗下银行受金规 24 号、金办发 93 号管，旗下保险也受 24 号 / 93 号管但保险业有专属节点要求，旗下证券受 JR/T 0158 / JR/T 0250 管，集团反洗钱业务受人行令 3 号管。

加上 JR/T 0197 作为全金融业的底层标准——一共需要同时对齐 6 份文件。

这 6 份文件之间不是简单的并列关系：JR/T 0197 是行业推荐标准、人行令 3 号和金规 24 号是部门规章（法律效力更高）、JR/T 0158 / 0250 是证券业专属、金办发 93 号是 24 号文的执行细则。

机构内部要做的事情包括：

1. 每个业务字段对应到多套标准中各自的分类节点;

2. 跨标准的差异要解释清楚——比如同一份数据,在 0197 里是 4 级,在 24 号文里属于「重要数据」,在 0250 里是 3 级,如何报送如何说清楚;

3. 当某一份标准更新(每年都有新文件),整套映射要随之刷新。

绝大多数现有工具只对齐了 JR/T 0197——这只能解决「入门级合规」。真正满足金融机构需求的工具，必须同时对齐这 6 份文件，并维护它们之间的关系。

痛点三:四类机构各自的业务特殊性

金融业不是一个同质化的行业，银行、保险、券商、金控四类机构在业务结构、字段命名、数据流转上有非常显著的差异——这些差异决定了一个「金融通用」的分类工具往往无法精准服务任何一类。

银行的特殊性

1. **业务条线最多：**对公、零售、信用卡、金融市场、同业、国际业务、托管,每条线有完全不同的数据结构;

2. **敏感数据密度最高：**存款、贷款、信用卡是高敏感数据集中地,字段级敏感度判断需要极细的颗粒度;

3. **实时性要求最强：**支付清算、反洗钱、风控涉及秒级数据流动,分类分级标签必须在数据创建时即被打上。

保险的特殊性

1. **业务对象复杂：**投保人、被保险人、受益人、车辆/标的、医疗记录、维修信息——一份保单背后往往涉及十几个不同主体的数据;

2. **健康数据极敏感：**健康险、长期险涉及大量个人医疗数据,既受金融监管又受医疗数据保护要求;

3. **208 个专属节点：**保险业相对独有的分类节点(理赔损失评估、再保险分出、精算储备、保险中介数据等)需要单独的知识库支撑。

券商期货的特殊性

1. **投资策略数据：**持仓、报价、研究观点等内部数据是行业核心资产,既要保护又要支撑投研协作;

2. **客户分类细致：**专业投资者、合格投资者、普通投资者各有不同的数据保护要求;

3. **适用标准不同：**证券业以 JR/T 0158 / 0250 为主,而不是 24 号文,工具必须能切换适用框架。

金控集团的特殊性

1. **多标准叠加：**旗下牌照可能同时涉及银行、保险、证券、信托、基金、租赁,每张牌照独立报送但集团又要有统一视图;

2. **数据隔离要求：**防火墙是合规底线,跨子公司数据流动要被分类分级标签实时控制;

3. **集团报送压力：**对监管的报送需要把多个子公司的数据资产目录合并成集团视图,同时保留法人维度。

这四类机构的差异化处理能力，是一个真正成熟的金融分类分级工具的「金线」——能不能同时服务四类机构、能不能在同一套引擎上为四类机构生成不同的标准体系，这件事直接决定了工具的天花板。

三、金融机构对分类分级工具的三层需求

如果说三大痛点是「症状」，那么金融机构对工具的需求可以分成三层「层级越高、价值越大」：

第一层:合规底线

最基础的层次——能交付一份满足监管要求的数据资产目录。具体包括：

1. 覆盖全行字段,识别率和准确率达到一定水准;

2. 能输出符合监管报送格式的目录;

3. 能在监管现场检查时给出可追溯的分类依据;

4. 能对接重要数据目录上报流程。

这一层是「不可缺少」——做不到合规底线，工具的存在没有意义。但仅停留在这一层的工具，本质上还是一份昂贵的合规文档。

第二层:运营落地

第二层是「能运营的能力」——金办发 93 号文反复强调的概念。具体包括：

1. **动态更新：**新增系统、新增字段、新增业务,工具能自动识别新增内容并打上分类标签,不需要人工重新跑一次;

2. **标准变化响应：**新发布的监管文件、行内调整的分类标准,工具能在天级时间内引用新规则,而不是等待版本升级;

3. **异常发现：**分类结果与历史结果偏差较大时,工具能主动提示「这个字段的分类有变化,请确认」;

4. **可解释性：**对每一个分类结果,合规官能追问「为什么」,工具能给出推理依据。

这一层是「能用还是不能用」的分水岭。绝大多数现有工具停留在第一层，做出来的目录三个月后就开始失效，无法支撑运营要求。

第三层:风险驱动

最高层次，也是分类分级真正的价值所在——分类分级标签成为整个数据安全体系的「统一识别层」。具体包括：

1. **驱动加密策略：**L4 字段强制存储级加密,L3 字段查询级脱敏,L2 字段日志审计,L1 字段无限制——加密策略由分类标签自动配置;

2. **驱动访问控制：**不同岗位对不同级别数据的权限,由分类标签 + 角色矩阵自动生成;

3. **驱动数据流动：**跨域、跨境、出口、向量库、AI 训练等数据外流场景,由分类标签触发不同的审批和管控策略;

4. **驱动存储分布：**核心数据放专有云、敏感数据按地域隔离、一般数据进通用存储——存储架构由分类标签驱动;

5. **驱动生命周期：**不同级别数据的归档、保留、销毁策略,由分类标签确定。

第三层是分类分级的真正价值——它不是一份合规目录，而是数据安全的「DNA」，贯穿整个数据安全策略。

80% 的分类分级项目止步于第一层,15% 做到第二层,真正进入第三层的不到 5%。

但 2026 年之后，金融业的领先机构会逐渐向第三层迈进——因为只有第三层才能支撑 AI 时代日益复杂的数据流动场景。

四、体系构建:一套完整的金融分类分级方法论

讲完痛点和需求，进入这篇文章最重要的部分——如何真正构建一套完整的金融分类分级体系。

这套体系不是一个单一工具的能力清单，而是四个相互依赖的组件构成的方法论。

4.1 行业知识库:金融语义底座

一套金融分类分级体系的根基，是行业知识库。这不是一本「金融术语词典」，而是一套结构化的金融业务知识：

业务概念体系

从客户、账户、交易、产品四个基础对象出发，向下展开数千个业务概念。例如「保单」这个概念下，包含承保信息、被保险人、险种构成、保费、生效条件、批改记录、续保规则……每个概念都有明确的业务定义、典型字段、所属业务流程。

命名习惯库

收集每家金融机构常见的字段命名模式——英文缩写、拼音首字母、业务编号、跨行表关联命名——形成一套「命名习惯到业务概念」的映射网络。这套网络不是静态字典，而是一套能持续吸收新命名模式的活体系。

监管映射库

把每个业务概念映射到 6 份监管标准的对应节点——例如「客户健康告知」这个概念，在 JR/T 0197 中是 4 级，在金规 24 号文中属于「重要数据」，在保险业 208 节点中位于「健康险-投保-健康问询」节点。映射关系是多对多的，需要专业知识构建。

行业差异层

银行、保险、券商、金控各自有一层差异化知识——保险有 208 个专属节点，证券有买卖盘和投资策略数据，银行有信贷风控特有概念。这一层是「金融通用底座 + 行业专属层」的双层结构。

一个「拿着公开标准从零开始训练模型」的厂商，永远做不出这套知识库——这是过去十几年扎根金融业务积累的护城河，而不是大模型参数堆出来的能力。

4.2 多标准对齐机制:六份文件的统一视图

有了行业知识库，下一步是建立六份监管文件之间的对齐关系。下面这张表是金融分类分级最完整的监管视图：

对齐机制需要解决三个具体问题：

1. **节点映射：**每个业务字段在多份标准中分别对应哪个节点;

2. **等级换算：**0197 的 5 级 vs 人行令 3 号的 3 级 vs 24 号文的 3 级（核心/重要/一般）之间的对应关系;

3. **差异化报送：**面向人行报送、面向金融监管总局报送、面向证监会报送时,同一份数据资产目录如何切换为不同视图。

绝大多数现有工具只解决了「JR/T 0197 节点映射」这一件事——这是入门级能力。真正可用的工具，必须维护一套六份文件的完整映射网络，并能在三种报送视图之间自由切换。

4.3 银行、保险、券商、金控的差异化处理

基于统一的行业知识库和监管对齐机制，工具需要为四类机构提供差异化的能力：

对银行的差异化:多业务条线的并行支持

一家中大型银行通常有十几条业务条线，每条线的数据结构、敏感度、合规要求都不同。工具需要支持「按业务条线生成独立分类树」——对公条线一套，零售条线一套，信用卡条线一套，金融市场条线一套——彼此独立但可在集团层做统一视图。

对保险的差异化:208 个专属节点 + 健康数据双重保护

保险业的分类树深度通常是金融业最深的——投保、核保、出单、批改、保全、续保、理赔、再保、精算……每一环都有专属字段。工具需要内置完整的 208 节点知识库，并对健康数据这种「金融 + 医疗」双重敏感数据进行特殊处理。

对券商的差异化:适用框架切换

券商主要适用 JR/T 0158 / 0250 而非 24 号文。工具需要支持「适用框架切换」——对一家券商客户，主框架是 0158 的四级体系，而不是 24 号文的三级体系。这种切换不是简单的菜单选项，而是底层映射规则的差异。

对金控的差异化:多法人维度 + 集团视图

金控集团需要的是「集团层统一标准 + 子公司层独立配置」的双层架构。每个子公司可以根据自己的业务需要调整分类节点，但集团层维护一份合并视图供报送和管理使用。这是一种类似数仓中「维度建模」的能力，要求工具有「多租户 + 标签可继承」的底层设计。

4.4 与现有数据治理体系的对接

分类分级不是孤立的系统——它需要与机构现有的数据治理体系深度对接。具体包括四个集成点：

与元数据管理系统对接

机构现有的元数据管理系统（DataHub、Atlas、Apache Atlas、行内自研）维护着字段的技术元数据。分类分级工具需要能从这些系统读取字段信息（不需要重新采集），并把分类分级标签作为业务元数据回写回去，让全行的数据资产视图自动获得分类标签。

与数据血缘系统对接

数据血缘系统维护着字段在系统间的流转关系。分类分级标签需要沿着血缘传播——如果上游字段是 L4，下游字段（即使经过加工）默认也应该是 L4，除非经过明确的脱敏处理。这种「分级标签的血缘传播」是数据治理领域的最新能力之一。

与权限管理系统对接

机构现有的统一身份认证、4A 系统、IAM 平台维护着「人」的视图。分类分级标签需要与权限系统对接，让权限模型从「角色 × 表」升级为「角色 × 分类标签」——大幅简化权限模型，提高合规可追溯性。

与安全策略引擎对接

这是「第三层需求」的落地——分类分级标签需要驱动加密、脱敏、DLP、跨域审批、向量库访问控制、AI 训练数据筛选等下游策略。要做到这一点，工具必须提供标准化的标签 API，让安全策略引擎能实时查询「这个字段的分类等级是什么」。

这四个集成点合起来，才让分类分级从「一个独立工具」升级为「数据治理体系的识别层」。

五、落地的四个关键节点

讲完方法论，最后讲一下落地。一个金融机构从「立项做分类分级」到「真正运营起来」，会经过四个关键节点。我们看到的失败项目，大都在某一个节点上没走到位。

节点一:范围界定与优先级排序

一上来不要追求「全行字段一次性梳理完」——这种宏大目标在 95% 的机构里都会项目失败。正确做法是按风险优先级分批切入：

1. **第一批：**对公核心 + 零售核心 + 客户主数据(银行)/承保系统 + 理赔系统(保险);

2. **第二批：**信用卡、风控、报送相关系统;

3. **第三批：**运营、报表、数仓;

4. **第四批：**历史归档、非结构化资产。

每批 2-3 个月完成，整体 9-12 个月走完一轮，比一次性 18 个月项目的成功率高得多。

节点二:工具选型与 PoC

这一节点决定了整个项目的天花板。参考上一期讲过的 PoC 七项测试清单——拼音字段、行内特殊、历史遗留、训练外类别、可解释性、新监管响应、非结构化覆盖——这七项缺一不可。

特别强调：PoC 的测试集必须由客户从生产环境抽取，必须包含拼音字段、行内特殊命名、历史遗留系统这三类「难题」，不能让厂商提供测试集。

节点三:试点与扩展

PoC 通过后不要立即铺到全行——选一个有代表性的业务系统（建议：客户主数据 + 一个核心业务系统）做正式试点，3 个月时间内：

1. 验证全字段识别率;

2. 验证持续更新能力(新增字段是否自动识别);

3. 验证下游集成(标签是否能被加密、脱敏、权限引用);

4. 验证人工复核效率(合规团队工作量是否可控)。

试点结果通过后再分批扩展到全行——失败的项目往往跳过这一步，PoC 完直接铺全行，问题在落地阶段大爆发。

节点四:制度化与持续运营

最后一个节点是「让分类分级真正成为常态化运营」。这一节点不是技术问题，是组织问题：

1. **明确归属：**分类分级的运营责任归数据治理部门(而不是分散在各业务部门);

2. **建立流程：**新系统上线必须先做分类分级、新字段必须在创建时打标签、监管文件更新必须 30 天内引入对齐;

3. **纳入考核：**数据治理部门的 KPI 中包含「分类分级覆盖率」「准确率」「时效性」三个指标;

4. **对接审计：**内审、外审、监管检查时,工具能一键导出审计所需视图。

做到这一步，分类分级才真正从「项目」变成「能力」。

写在最后

这一期我们走完了金融分类分级的完整图景——从三大痛点、三层需求、到四组件方法论、再到四节点落地。

回到开头那组问题:金融机构在分类分级这件事上,真实的痛点是什么?需要哪些组件?四类机构的特殊性如何处理?一套完整的方法论应该长什么样?

如果用一句话来概括这一期的核心观点——

金融分类分级不是一个工具能解决的事,是一套体系工程。这套体系工程的核心,是把分类分级从合规文档,提升为数据安全的统一识别层。

做到第一层(合规底线)的机构,会被监管认可;做到第二层(运营能力)的机构,会减少长期运营成本;做到第三层(风险驱动)的机构,会建立数据资产管理的代际优势。

金融业是中国分类分级的高地——把金融做透，就为其他行业铺好了路径。下一期我们会跳出金融业，看看分类分级在中国整个产业层面的全景图——从《数据安全法》第 21 条出发，每个行业各自的细则、每个行业各自的痛点、以及为什么「跨行业的分类分级能力」会成为数据安全工具的下一个分水岭。

—— AiDClass 团队 · 模界数智