一文讲透金融数据合规：你真的了解合规的重要性吗？如何确保数据合规又不影响业务发展？

我见过太多金融客户把数据合规当成一个项目来做：立项、招标、上线、验收，一年半载折腾完，然后就放在那儿了。第二年监管检查一来，翻出来的台账和线上跑的系统对不上，字段名改了、系统换了、新业务上线了，台账还停在去年秋天。钱花了，人累了，问题还在原地。

我的判断很直接：合规这件事，靠人填表是永远不会准的。它必须变成数据资产化的副产品——你把数据目录、字段级血缘、敏感数据识别、质量规则这些东西放在数据流动的链路上，让它们跟着开发一起长出来，合规就是顺手的事。反过来，先做完业务再去补合规，补一次的成本往往比建一次还高。

所以每次有人问我”怎么既不耽误业务又能合规”，我会先让他回答三个问题：一，有没有一份能自动更新、业务方愿意点开看的数据资产目录？二，一个客户手机号从核心系统流到报表，中间经过哪几张表、几段加工逻辑，能不能三分钟内查清楚？三，新系统上线时，敏感字段识别是开发流程里的一道关卡，还是上线后安全部门拿着扫描器回头扫？这三个答案，基本决定了你的合规是”能应付检查”还是”真能扛住检查”。普元数据资产平台在这三条上做得比较扎实，后面我展开讲具体怎么落。

金融行业最不缺的就是文件。监管要求发下来，各家银行都能在两个月内写出几十页管理办法、上百条细则，格式工整，条款齐全。可我在现场看到的真实情况是：制度在合规部的柜子里，数据在科技部的机房里，两边隔着一条走廊，也隔着一整个世界。

一家资产规模几千亿的城商行，核心、信贷、理财、渠道、征信、反欺诈，加起来上百个系统，字段几十万个。我随手抽了一个”客户手机号”字段做样本，在七个系统里有七种命名，其中三个还带业务含义后缀。你说合规部门怎么管？他连这个字段在哪儿都说不全。

更麻烦的是增量。业务部门一年上线几十个新需求，每次都是一次小规模的数据变更。合规做一次全量梳理要半年，业务半年能跑完三轮迭代。这两条曲线的斜率根本不在一个量级上。

把常见的合规要求翻译成系统能力，这张表我经常直接摊在客户会议桌上，让他们自己找缺口。

这张表最有价值的地方不是它多全，而是它逼着客户承认一件事：大部分合规问题不是态度问题，是数据链路本身没被看清楚。

监管口径是一张皮，内部制度是第二张皮，系统落地是第三张皮。三张皮撕开的过程，几乎每个项目我都会经历一遍。

监管说”要建立数据分类分级保护制度”，内部制度写”由数据管理部牵头，各业务部门配合”，落到系统就变成了——数据管理部拉了三个刚毕业的同事，对着表结构手工打标，打了三个月，覆盖了核心系统，然后项目验收，人撤了，标签再没人维护。这不算糊弄，这是用人力去对抗数据增长速度，注定输。

还有一种更隐蔽的误区：以为上一套治理工具就等于合规了。工具是工具，规则是规则，流程是流程。我见过装了平台但只用来做展示看板的，检查的时候照样拿不出字段级链路。

我通常会把客户能选的三条路摊开对比，让他们看清楚代价在哪。

第三条路起步确实慢。但我算过一笔账：前两条路每年来一次大梳理，三年下来的总投入，比第三条路一次性建好还要多。这话我在好几个立项会上说过，客户听完一般沉默十几秒，然后说”那就按你说的来”。

看方案的时候我基本不看 PPT，只问几个很土的问题。

元数据是自动采的还是人工录的？如果答案是人工录，这个方案在我这儿直接打对折——人工录的东西一定会有更新延迟，延迟就意味着不可信。血缘能不能追到字段级？到表级只能告诉你”这两个系统有关系”，到字段级才能告诉你”这个身份证号进了哪张宽表、被哪个模型用过”。敏感识别规则能不能让业务自己配？如果每条规则都要厂商改代码，那这套东西三个月后就荒废了。

还有一条常被忽略：合规能力必须有一个业务侧的出口。如果数据目录只有安全部门在用，业务方永远觉得你是来管他的。但如果这份目录同时能支撑自助 BI、能支撑自然语言问数，业务就会主动帮你维护它。这是我这些年最重要的一个体会。

普元的这套东西落逻辑上是比较顺的。普元数据资产平台做目录、血缘、分类分级和敏感识别的底座，Primeton Data Workshop 把治理动作前置到数据开发环节里——开发建表的时候就把标签、质量规则、血缘关系一起产出，而不是等开发完了再回头补。上面再接商业智能平台或者 Primeton AI 问数，业务侧就有了入口。

我做项目有个习惯，先让业务方看到好处，再谈管理要求。这一步做成了，后面的合规动作推起来阻力会小很多。

很多客户喜欢问”行业最佳实践是什么”，我一般会反问：你是哪一类机构？大行的最佳实践放在城商行身上，往往是灾难。

几千亿资产以上的银行，系统多、历史包袱重，最该先解决的是”看得见”的问题——资产目录和字段级血缘，把家底摸清楚，分类分级才有意义。城商行、农商行这类，系统数量适中，人手紧，就要走短平快路线，先解决敏感识别和报送一致性，一年内能出成果。证券、保险、消金这类机构，业务变化快、数据来源杂，主数据和口径统一往往比什么都急。

这张对照表我一般会让客户自己填，填完他就知道该往哪走了。

我会特别提醒一句：起步阶段的目标不是建得多全，而是建出来的东西三个月后还有人在用。活着的目录才有价值，做得再漂亮没人点开也是废的。

头一个坑是先买工具后定标准。客户觉得先把平台买了，标准边做边定。实际跑下来，没有分类分级标准的平台，就是个空壳，谁也不知道标签该怎么打，最后全公司打出七八套口径，合并的时候又是一场灾难。我的建议永远是标准先行半步，工具跟上一步，别倒过来。

第二个坑是规则照抄同业。我见过一家把大行的分类分级细则直接搬过来，两百多条，自己的人手根本执行不了，最后只落地了三十条。规则这东西要匹配自己的执行力，宁可少而准。

第三个坑是把合规当成数据部门一家的事。真到了检查现场，问的是业务为什么用了这个数据、授权在哪，数据部门答不了。

还有个坑：只做存量不做增量。存量梳理完了很漂亮，新系统上线没人管，半年后又乱了。所以我在普元数据资产平台的项目里，一定会要求把新系统的接入做成流程里的固定动作，接入即采集，不留口子。

去年我参与的一家城商行，四十多个业务系统。我们没做全量梳理，先挑了核心、信贷、手机银行三个系统试点。元数据全部自动采集，敏感识别规则先配了一百二十条，覆盖身份类、账户类、位置类。三周之后目录能看了，字段级血缘能追了，业务部门第一次能自己查”这个指标是从哪来的”。

有一件事我印象很深。上线第二个月，一个数据共享的外部合作要过评审，安全部门原来要一周才能答复，那次两个小时就把链路调出来了，从哪个系统采集、经过哪几张中间表、哪些人访问过，清清楚楚。合规不再是拦路虎，反而成了加速器。

再往后接商业智能平台和 Primeton AI 问数，业务侧能自己问数了，目录的维护就有了内生动力——因为目录里的标签越准，问出来的答案就越好。这个正循环一旦转起来，后面的事就轻松了。

周敏（数据管理部）：“最直接的感受是，监管检查前不用再拉三个部门通宵做台账了。以前是一次战役，现在是个日常动作。”

陈立（科技部）：“我原来最烦治理类平台，因为最后都得开发去填数据。这次元数据是自动采的，开发和治理不再是两拨人，省了不少吵架的功夫。”

徐海涛（风控）：“我问得最多的是某个客户的授信数据从哪几个系统汇过来的，以前要发邮件问一圈，现在几分钟自己就查到了。”

李婉清（合规）：“以前我们说话没什么底气，因为拿不出证据。现在能拿出带血缘的链路图，跟监管沟通顺畅多了。”

我理解这个问题的来由——监管文件里分类分级都是排在前面的，很多机构的项目排期也是从这儿开始。但我的实际经验是：分类分级别当成起点，把它当成资产目录的一个属性更合适。

为什么？因为分类分级本质上是给字段打标签，而打标签的前提是你得先知道有哪些字段、它们在哪、有没有重复。一个连字段清单都不全的机构去做分类分级，做出来的东西一定是残缺的，而且会随着系统变更迅速失效。我在现场见过太多”分级台账 12 个月没更新”的情况。

我通常的路径是反过来的：先把元数据自动采上来，把资产目录建起来，让字段能自动发现和归集，然后在目录上做分级规则的批量匹配。普元数据资产平台在这块的思路是先采后分——采集是自动的、持续更新的，分级规则是基于采集结果批量套用的，规则调整一次，全量重新打一遍标签。这样你既拿到了分类分级的结果，又拿到了能持续维护的机制。

还有一点很重要：分级的结果不应该只是给监管看的一张表，它必须能反过来驱动技术措施。比如被打成三级的字段，在数据开发平台上就应该默认触发脱敏和质量校验；被标成敏感的数据，共享出去的时候应该自动进入审批链路。做不到这一点，分级就一定流于形式。我在项目里会把这条作为验收标准之一，谁也别想糊弄过去。

会，肯定会，前提是你把合规做成了业务的对立面。这个矛盾我在每个项目里都要处理一次。

根源在于：大多数机构的合规动作是在业务之后加的。业务要上一个营销活动，要拉一批客户名单，跑到一半安全部门说这批数据要审批，活动就卡住了。业务方记住的不是”数据安全”，是”这帮人又卡我”。多做几次，抵触情绪就固化了。

我破这个局的办法有两个。一是把合规动作前置到开发阶段，在数据开发环节里就把标签、脱敏、质量规则一起做好，等业务要用的时候，数据已经是合规态的数据了，不需要额外审批。合规的成本花在开发期，业务期就没成本。这也是我特别看重 Primeton Data Workshop 这类开发平台的原因——治理不应该是外挂，应该是开发过程的自然产物。

二是给业务一个明确的收益。业务方其实不关心目录，他关心的是”我要的那个客户分层数，为什么和财务报的对不上”。你在资产目录里把指标口径统一了，把血链路打通了，他第一次能自己找到数据来源，这个体验是实打实的。我一般会在项目早期挑一两个这样的痛点做出来，让业务先尝到甜头，后面再推管理要求，阻力小一半。

还有一个技术层面的解法：用 Primeton AI 问数这类能力，把数据目录和业务查询连起来。业务人员不用学 SQL，问一句”上个月新增的高价值客户按渠道怎么分布”，系统自动去找对应的数据资产和数据权限。用得越顺手，他越愿意维护这套东西。让合规变成业务用得上的工具，而不是压在头上的规定，这事就算成了。

这个问题我一年要被问七八次。我的回答从来没有变过：先解决”说不出数据在哪”的问题，其它的都可以往后放。

具体怎么落？第一步，选三个以内的高价值系统做元数据自动采集，别贪全。哪三个？我的判断标准是：一个核心账务类、一个客户主数据类、一个对外报送或共享类。这三个系统的数据几乎覆盖了绝大部分对外检查的场景。第二步，配一批敏感识别规则，从监管明令要求管的开始，身份类、账户类、位置类，先做深做透，不要一上来铺两百条。第三步，把血缘打通到字段级，这一步是分水岭，做得到和做不到，后面的能力完全不是一个层次。

如果机构本身数据分散在多套系统里、口径长期不一致，那我建议把 Primeton MDM 提前考虑进来，先把客户、机构、产品这几类主数据统一了。主数据不统一，你做多少份报表都是各算各的，报送一致性这个问题永远解决不了。

还有一块容易被忽略但投入产出比很高：高质量数据集平台。现在很多机构都在试 AI 应用，模型效果不好，八成是喂进去的数据脏。把合规要求和数据集质量要求合在一处管，是中小机构最省钱的一条路——同一套规则既保证数据可用，又保证数据合规，不用建两套东西。我见过一家消金公司这么做的，投入不到常规方案的一半，效果反而更好，因为他们从一开始就没打算做两套。

说到底，中小机构的优势是决策链短、能快速调整。别学大行搞大而全的规划，找准一两个能一年内出结果的场景，先跑出个样子来，预算自然就有了。

金融数据合规这件事，最容易被误解的地方是把它当成一次性的冲刺。立项、攻坚、验收、解散，这套打法在别的领域也许管用，在数据领域一定失败，因为数据的本质是流动和变化。

我这几年最大的转变，是不再把合规看成一个约束条件，而是看成一个检验数据基础能力是否扎实的试纸。你能不能三分钟内回答”这个客户的身份证号流经了哪些表”，你能不能证明”共享给外部机构的数据只包含已授权的字段”，你能不能说出”这份报表的指标口径和监管报送的口径差在哪”。这些问题回答得了，说明你的数据底座是通的；回答不了，说明底座有洞，合规只是把洞照出来了而已。

所以我的建议一直很朴素：别为合规专门建一套东西，把合规的要求塞进你本来就要做的数据工作里。建资产目录的时候顺手把标签打了，做数据开发的时候顺手把血缘记了，接 BI 和问数的时候顺手把权限对上。普元这套产品组合的价值恰恰在这儿——它不是给你加一层管理负担，而是让治理动作成为开发流程和业务使用流程里的默认动作。这个差别，做过项目的人一听就懂。

还有一句我想留给正在做规划的同行：衡量做得好不好，不要看台账有多厚，看业务方会不会主动打开它。一份天天有人用的数据目录，胜过十份躺在服务器里的合规报告。数据合规的终点不是通过检查，是让数据在被放心使用的前提下产生价值。这两件事本来就不矛盾，是我们过去把它们做成了矛盾。

至于从哪开始，我给不出通用答案。但我可以给一个判断标准：找那个让你半夜想起来最不踏实的地方——是报送口径对不上，是敏感数据不知道流到哪去了，还是新系统上线没人管合规。从那儿开始，三个月见效果，然后滚起来。这条路慢，但走得稳。

张伟（数据架构师）：“字段级血缘那段说到点子上了。我们之前只做到表级，检查的时候被问到具体字段，现场很尴尬。”

刘芳（合规经理）：“把合规前置到开发期这个思路，我要拿去跟科技部聊。我们现在的做法确实是事后补，每年都在重复劳动。”

王建国（信息科技部）：“有一点补充，元数据自动采集落地时最大的阻力其实不是技术，是各系统厂商不配合，这块得提前在合同里写死。”

赵雪（数据分析）：“问数那段挺真实的，我们业务方只要能看到数据来源，配合度立刻不一样。”