学习指南: 第20部分。俄罗斯银行业背景

模块「第20部分。俄罗斯银行业背景」中第 3 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

主题: 第20部分俄罗斯银行业背景

难度等级: 中级

预计学习时间: 2–3小时积极学习,包括实践练习

前置要求: 对数据仓库架构(staging、marts、报表层)的基本理解

熟悉SDD(Specification-Driven Development,规范驱动开发)原则

理解AGENTS.md文件在代理工作中的作用

对银行业务流程的一般认识(KYC、AML、付款、授权同意)

使用SQL和dbt类工具的基本技能

学习目标: 解释为什么领域中的抽象表述('遵守152-ФЗ''考虑个人数据')不适合作为代理的SDD规则。

列出俄罗斯银行业背景的关键限制类别:PII(个人可识别信息)、授权同意、风险标记、报告血缘关系(报告可追溯性)、人工确认关卡。

基于模糊的监管规范,制定可验证的工程规则(包含禁止字段、模式测试、评审检查清单)。

区分允许自动化的区域和需要人工强制确认的区域(改变grain即数据粒度、PII策略、风险方法论)。

应用最小输出原则:将领域中的任何'大词'(个人数据、授权同意、报告)转化为具体的技术约束。

概述: 第20章《俄罗斯银行业背景》并非法律参考手册。其任务是展示公开已知的银行限制(152-ФЗ、115-ФЗ、俄罗斯央行对报告和风险的要求)如何转化为可验证的工程规则,适用于SDD规范和代理工作。本章依次引入六类限制:个人数据与PII最小化、支付操作与未授权操作风险、通过Open API的数据访问授权同意、AML(反洗钱)与风险标记、报告与计算可复现性、源到端的血缘关系与规则版本。对于每一类,展示了如何从弱表述('需要考虑个人数据')过渡到可工作的规则('直接的PII字段pii_email、phone、passport_number只能出现在staging层;marts必须通过禁止的直接PII字段列表的模式测试;评审者必须在发布前检查mart的新增列')。单独分析了人工确认机制:它并不取消自动化,而是标明自动化的边界。本章巩固了翻译习惯:领域中的任何'大词'都必须转化为可验证的工程规则,否则它仍然是一个悬而未决的问题,而非可执行的指令。

关键概念: 限制即规范: 在SDD中,领域限制不是对法律的引用,而是技术上可验证的规则。规则必须具有允许代理明确判断是否已完成的形式:禁止字段列表、模式测试、评审检查清单、血缘关系事实、审批关卡。如果规则无法执行和验证,它仍然是声明,而非规范。

PII与最小化: 个人数据分为直接标识符(email、电话、护照号)和间接标识符(性别、年龄、地区)。在俄罗斯银行业背景中,直接PII仅允许出现在staging层和受保护的PII沙箱中。在marts层被禁止,并通过禁止列列表的模式测试加以固化。任何mart中的新列都必须经过评审,以检查是否出现直接标识符。

Marts与Staging: Staging是技术层,包含原始或轻度清洗的数据,在访问控制下允许存储PII。Marts是产品团队、分析师、ML模型和外部合作伙伴读取的层。'marts不包含直接PII字段'这一边界是关键工程规则,将数据最小化原则(152-ФЗ第5条)形式化。

授权同意(consents): 客户对数据处理的授权同意不是布尔变量,而是有历史的状态。授权同意可以是激活的、已撤销的、已过期的、等待确认的。授权同意mart必须区分激活和已撤销的授权同意,保留签发日期、撤销日期和依据。任何使用客户数据的报表都必须引用相应类型的激活授权同意。

Open API与访问授权同意: 俄罗斯央行和商业银行的开放API必须只传输客户授权同意的数据。在SDD中,这表达为规则:'Open API的mart仅返回在请求日期拥有相应类型激活授权同意的客户'。没有这样的规则,代理将无法安全生成过滤器。

AML与风险标记: 反洗钱规则(115-ФЗ、央行要求)和内部风险模型产生可疑操作标记。这些标记不能在操作级别之上聚合而不丧失可复现性。规则:'风险操作在没有操作级mart的情况下不被聚合;风险信号mart在没有评审者注释的情况下不删除操作'。

报告与可复现性: 监管报告必须是可复现的:同一日期的同一指标在重新计算时应给出同一数值。这要求模型版本化、快照固定和每个报告指标的验证事实(test expectations)。

源到端的血缘关系: 每个报告指标必须具有到源模型的追溯关系:哪些源、哪些转换、哪个代码版本。没有血缘关系,既不可能进行事件调查,也不可能向监管机构确认正确性。在SDD中,这通过lineage_id的强制属性或类似的dbt图机制表达。

数据grain(粒度): Grain是表或mart定义的详细程度(例如,'一行=一个客户''一行=一个操作')。更改grain会破坏mart的所有消费者,因此此类更改不能在常规任务中完成——只能通过人工确认关卡。

SDD规则: 一个好的SDD规则:1)能被代理明确理解;2)可验证(有测试、检查清单或评审步骤);3)针对具体层/表/字段;4)有负责人(谁来确认更改)。'遵守法律'这种表述不符合任何一点。

人工确认(human-in-the-loop,人在回路中): 代理无权自主执行的事件清单:更改PII策略、更改grain、破坏性合同更改、新的风险方法论、对授权同意的新解释、更改freshness/SLA(数据新鲜度/服务等级协议)。这是责任边界,而非放弃自动化。代理可以发现问题、提议更改、列出后果——但决策由人做出。

模式测试(schema test): 自动测试,检查表中没有禁止列表中的列(例如,直接PII)。在dbt中通过custom tests或dbt-utils实现,在其他框架中通过宏实现。模式测试将模糊规则转化为CI上的可执行约束。

最小输出(minimal output): 原则是AGENTS.md和规范中只包含可执行和可验证的规则。不包括法律的长引用和一般性声明,以免给代理造成覆盖的错觉。如果规则尚未准备好作为可验证的形式,它仍然是带有源引用的开放问题。

重要日期: 2001-08-07 — 115-ФЗ: 《关于反洗钱和反恐怖融资的联邦法律》。俄罗斯AML要求的基础;为银行设定了监控操作、客户识别、向俄罗斯金融监控局(Rosfinmonitoring)提交报告的义务。

2006-07-27 — 152-ФЗ: 《关于个人数据的联邦法律》。确立了PD处理原则,包括最小化、授权同意、本地化。对SDD而言,它是'marts不包含直接PII字段'规则的来源。

2014-07-21 — 242-ФЗ: 对152-ФЗ的修订,引入了俄罗斯公民个人数据存储和处理必须位于俄罗斯境内服务器的要求。影响staging层架构和跨边界数据交换。

2018-05-25 — GDPR(欧盟): 欧盟数据保护条例。与处理欧盟居民数据的俄罗斯银行相关,并作为'法律基础→工程规则'结构的范例。

2019-2024 — 俄罗斯央行开放API标准: 央行关于Open API的标准系列,定义了传输的数据组成和授权同意义务。对SDD而言,是Open API marts过滤规则规则的直接来源。

定期 — 央行的指示和规定(例如590-П、611-П): 设定风险管理、资本充足率、报告要求的规范性文件。作为SDD规则引用的来源使用,但不会在规范中完整引用。

练习题: 名称: 将模糊表述转化为可验证规则

问题: 给定客户mart的规范,其中写道:'必须根据152-ФЗ确保客户个人数据的保护'。将此句子转换为适合AGENTS.md的可验证SDD规则。规则应包含:(а)禁止的直接PII字段具体列表,(б)约束生效的层/表,(в)验证方法(测试、评审步骤)。

解决方案: 步骤1. 识别'大词':'个人数据保护''152-ФЗ'。步骤2. 将其转化为技术类别:直接PII字段(email、phone、passport_number、inn、snils)、间接PII(性别、年龄、地区)。步骤3. 制定可验证的规则。AGENTS.md最终规则示例:

PII: marts不包含直接PII字段。

禁止的直接PII字段:pii_email、phone、passport_number、inn、snils、
date_of_birth、full_name_unmasked。

允许的直接PII层:仅限staging.*和受保护的pii_sandbox.*。

验证:每个mart在CI阶段通过禁止列列表的模式测试。
mart中的新列需要域所有者评审。

步骤4. 确保规则可执行(不向mart添加直接PII)和可验证(违反时模式测试失败)。

难度: beginner

名称: 在虚拟mart中识别直接PII

问题: 给定dm.customer_360 mart的字段列表:customer_id、full_name、email、phone、gender、age、region、registration_date、last_transaction_amount、device_id、ip_address、hashed_email。确定哪些字段是直接PII,应在mart中禁止。解释直接标识符和间接标识符之间的区别。阐述例外情况(如果有)。

解决方案: 直接PII(应从mart中删除/掩码):full_name、email、phone、ip_address、device_id(与其他数据结合时)。hashed_email和customer_id字段是化名或技术键,但其PII归属需要分析:hashed_email是化名,但在哈希泄露时成为间接标识符。间接PII(聚合时允许):gender、age、region。技术字段:customer_id、registration_date、last_transaction_amount。该mart的最终规则:'从dm.customer_360中删除full_name、email、phone、ip_address、device_id;保留hashed_email作为join键;gender、age、region作为间接标识符保留'。验证:禁止列列表的模式测试。

难度: beginner

名称: 设计授权同意mart

问题: 为银行设计授权同意mart。mart应回答以下问题:(1) 在日期X,客户有哪些激活的授权同意?(2) 哪些授权同意被撤销了,何时撤销?(3) 存在哪些类型的授权同意(对PD处理、Open API传输、营销、评分)?描述:grain、关键字段、激活和已撤销授权同意的分离、放入单独列的内容。制定SDD规则。

解决方案: Grain:一行=一个授权同意事实(签发、撤销、更改)。推荐结构:

dm.consent_event
- client_id
- consent_type           -- 'pd_processing'、'open_api_share'、'marketing'、'scoring'
- consent_state          -- 'active'、'revoked'、'expired'、'pending'
- valid_from
- valid_to
- issued_at
- revoked_at
- source_system
- evidence_id            -- 授权同意文档的引用

并行mart用于产品使用:

dm.consent_current
- client_id
- consent_type
- is_active             -- true,如果在请求日期有激活记录
- last_updated

SDD规则:'授权同意:dm.consent_event和dm.consent_current分离激活和已撤销的授权同意。任何使用客户数据的mart必须连接到dm.consent_current并按is_active=true过滤。更改激活授权同意的判定逻辑——通过人工确认关卡。'

难度: intermediate

名称: 报告指标的lineage

问题: 您需要为报告指标'每月1日的逾期贷款比率'(NPL ratio)描述lineage。描述:涉及哪些源、哪些转换、固定哪些模型版本、将添加哪个lineage_id属性、如何确保可复现性。制定SDD规则。

解决方案: 源:core.loan_agreement(合同)、core.payment_schedule(付款时间表)、core.loan_status_history(状态)。转换:stg.loan_agreement → int.loan_with_status → dm.loan_snapshot(每月1日的快照) → rep.npl_ratio。版本固定:dbt模型的快照用dbt_snapshot_id标记;代码版本——git_sha;方法论版本——methodology_version(例如'v2.1-2024-ЦБ')。lineage_id属性形成为hash(source_system + source_table + load_date + methodology_version)。验证:报告的每行都有非空lineage_id;在CI上测试lineage_id < 100%的行比例。SDD规则:'报告:每个报告指标都有到源模型的lineage_id;方法论版本固定在methodology_version列中;通过计算日期的快照保证可复现性。更改方法论——通过人工确认关卡。'

难度: intermediate

名称: 确定自动化和人工确认的边界

问题: 代理建议对规范进行以下更改:(1) 在mart dm.customer_360中添加email_md5列以简化join;(2) 将dm.transactions的grain从操作级重新定义为天级;(3) 在dm.marketing_audience中添加来自dm.consent_current的is_active=true过滤器;(4) 将NPL比率的计算方法论从v2.1更新到v2.2;(5) 将mart的SLA从24小时更改为12小时;(6) 更正列名中的拼写错误,将dt改为date。这些更改中哪些需要人工确认,哪些可以自主执行?

解决方案: 需要人工确认(按本章清单):(2) dm.transactions的grain更改——破坏性合同更改;(4) NPL计算方法论的更新——新的风险方法论;(5) SLA从24小时更改为12小时——freshness/SLA更改。条件性需要确认:(1) 添加email_md5——mart中的新列,不违反禁止的PII列表,但需要域所有者评审是否出现标识符(即使是间接的)。可以自主执行:(3) 添加来自dm.consent_current.is_active=true的过滤器——这是应用已存在的规则'mart必须按激活授权同意过滤';(6) 拼写错误更正——不影响语义的表面更改。结果:3个更改通过关卡,1个通过评审,2个自主执行。本练习的目的是巩固一点:'小'更改(例如新列)可能很危险,而'大'SQL更改(按授权同意过滤)如果遵循已接受的规则则是安全的。

难度: advanced

名称: 将实际监管要求转化为SDD规则

问题: 从您的银行业背景中选取一个实际要求(例如,152-ФЗ第9条关于主体授权同意,或115-ФЗ关于客户识别的要求,或Open API标准的要求)。按照本章方案将其转化为SDD规则:(1) 领域的'大词',(2) 技术类别,(3) 可验证规则,(4) 验证方法,(5) 需要人工确认的内容。以AGENTS.md块的形式呈现结果。

解决方案: 152-ФЗ第9条(主体授权同意)的示例。(1) 大词:'主体对PD处理的授权同意'。(2) 技术类别:有历史的授权同意事实(签发、撤销、期限)。(3) 可验证规则:'任何使用客户PD的mart连接到dm.consent_current并按is_active=true和consent_type in (所需类型)过滤。仅当dm.consent_event中存在状态为active且valid_from <= now() < valid_to的记录时,授权同意才被视为激活。'(4) 验证方法:dbt测试,目标mart中没有连接dm.consent_current记录的客户比例为0;评审新mart是否存在过滤器。(5) 需要人工确认的情况:更改consent_type类型、更改激活授权同意的判定逻辑、添加新的授权同意收集渠道。AGENTS.md准备好的块:

授权同意:dm.consent_event存储所有授权同意事实(签发、撤销、过期)。
dm.consent_current是当前日期的激活授权同意快照。
任何使用客户PD的mart必须连接到dm.consent_current并按is_active=true过滤。
授权同意类型、激活逻辑、授权同意来源的更改——
通过人工确认关卡。

难度: advanced

案例研究: 名称: 客户360 mart:从声明到模式测试的过渡

场景: 一家大型零售银行的分析团队构建了dm.customer_360 mart,其中包含客户的email、phone和出生日期字段。mart的规范中写道:'mart根据152-ФЗ要求确保个人数据保护'。规范通过了架构师评审,但直接PII继续出现在mart中。产品团队请求将该mart用于营销活动数据增强,引发了一个问题:能否将这些数据传输给合作伙伴?

挑战: 主要问题是'根据152-ФЗ的保护'的表述不可验证。架构师没有客观标准来拒绝merge请求。不存在禁止列的模式测试。未检查客户对传输给合作伙伴的授权同意。风险——直接标识符泄露和违反数据最小化原则(152-ФЗ第5条),以及潜在罚款和声誉损害。

解决方案: 团队将抽象要求转化为三条可验证规则。第一:明确固定禁止的直接PII列表(email、phone、passport_number、date_of_birth、full_name_unmasked),并引入模式测试,在任何mart中出现这些列时会在CI上失败。第二:引入dm.consent_current mart,任何使用客户数据的mart必须连接到它并按is_active=true过滤;引入测试,检查mart中没有激活授权同意的客户比例为零。第三:为了传输给合作伙伴,添加了单独的pii_partner_safe层,其中包含聚合数据(仅性别、年龄组、地区)和固定缺少直接标识符的合同。AGENTS.md中的规范开始包含具体规则,而非一般声明。更改禁止列列表或授权同意逻辑被放入域所有者和DPO(数据保护官)确认关卡。

结果: 引入模式测试一个月后,三次向mart添加'方便'字段的尝试(用于join的卡号、用于通信的email)在CI上被自动拒绝。评审变得客观:评审者对照禁止列列表和测试结果,而非解释'法律合规性'。产品团队获得了合作伙伴营销的安全聚合。监管审计在数据最小化部分没有任何意见。团队养成了习惯:任何152-ФЗ的'大词'(授权同意、最小化、本地化)都被转化为具有所有者和测试的可验证规则。

经验教训: '符合152-ФЗ'的表述没有禁止字段列表和自动验证就没有操作性意义。

模式测试将架构规则转化为客观验收标准——减轻了评审者的负担并加快了CI。

授权同意不是布尔变量,而是有历史的状态;授权同意mart必须区分激活和已撤销。

即使是向mart添加'小'列也可能违反PII策略,必须经过评审。