4. 监管科技行业认知与业务场景
监管科技数据工程岗位的面试，第一轮技术面往往不会直接考你写SQL，而是先确认一件事：你是否理解监管数据背后的业务链条。很多候选人能讲清楚Spark调优，却说不清“EAST报送”和“1104报表”的区别，也讲不出反洗钱可疑交易监测的数据链路。面试官由此判断：你进来后需要多久才能独立对接业务需求。本章帮你建立一张行业认知地图，把监管报送、反洗钱、风险监测、数据治理、合规科技五类场景串起来，并给出公司侧重点的判断方法。
一、核心原理：监管科技的“三层数据流”
监管科技的本质，是用数据工程能力把监管规则翻译成可计算、可追溯、可审计的数据产品。无论哪类场景，底层都遵循同一条数据流：
- 监管要求层：监管机构下发制度、办法、报送模板、校验规则，例如人民银行、金融监管总局、外汇局、证监会的各类文件。
- 数据加工层：数据工程团队负责采集、清洗、映射、汇总、校验、版本管理，把分散在核心系统、信贷、支付、理财等源系统的数据加工成监管口径。
- 报送与监测层：生成报送文件、跑批提交、接收回执、处理差错；同时把数据用于反洗钱监测、风险预警、合规分析。
理解这条链路后，你会发现五类场景并不是并列关系，而是同一套数据底座上的不同应用。监管报送是“对外交付”，反洗钱和风险监测是“对内风控”，数据治理是“底座质量”，合规科技是“工具与平台化”。面试时能讲出这层关系，比背概念更有说服力。
二、五类业务场景的岗位视角拆解
面试中，面试官会根据简历追问你熟悉哪类场景。下面这张清单帮你快速对齐每类场景的核心数据对象、典型任务和面试高频追问。
| 场景 | 核心数据对象 | 典型数据工程任务 | 高频追问 |
|---|---|---|---|
| 监管报送 | EAST、1104、客户风险、利率报备 | 口径映射、批量生成、校验回执、差错处理 | 报送时效如何保障？口径变更怎么管理？ |
| 反洗钱 | 客户、账户、交易、名单 | 规则引擎、可疑交易识别、名单匹配、案件线索 | 误报率怎么降？规则和模型如何配合？ |
| 风险监测 | 信贷、资金、市场、操作风险指标 | 指标计算、阈值预警、实时/准实时监测 | 指标口径一致性怎么保证？ |
| 数据治理 | 元数据、标准、质量规则、血缘 | 数据标准落地、质量检核、血缘追踪 | 如何推动业务部门认责？ |
| 合规科技 | 规则库、报送平台、监测平台 | 平台化、配置化、自动化、审计留痕 | 如何把一次性需求变成可复用能力？ |
三、公司侧重点判断：面试前的“画像四问”
不同公司对监管科技的定位差异很大：银行系偏报送与合规，支付机构偏反洗钱与交易监测，券商偏风险指标与净资本，监管科技厂商偏平台产品。面试前用四个问题快速画像：
- 客户是谁：服务自身合规部门，还是服务多家金融机构？前者重交付，后者重产品化。
- 监管压力来自哪：人民银行、金融监管总局、证监会、外汇局，不同监管方的数据口径和报送频率不同。
- 数据规模与时效：T+1批量报送，还是准实时监测？这决定技术栈是离线数仓还是流批一体。
- 团队定位：是成本中心式的合规支持，还是对外输出的科技产品？这影响你被考核的指标。
四、案例场景：一次EAST报送差错的复盘
假设你负责某银行EAST报送，某月监管回执显示“部分账户交易金额与核心系统不一致”。复盘路径如下：
1. 定位差异：比对报送文件与核心系统交易流水，发现跨月冲正交易被重复计入
2. 追溯口径：确认监管口径要求“按交易发生日归属”，而当前逻辑按“入账日”
3. 影响评估：涉及3张表、约1.2万条记录，需在整改期内重新报送
4. 修复方案：调整ETL映射逻辑，增加冲正标识过滤，补充口径文档
5. 防复发：在数据质量平台增加“冲正交易一致性”检核规则，纳入日常监控
这个案例在面试中非常实用。它同时体现了业务理解、数据排查、口径管理、质量闭环四项能力。讲述时用STAR结构：背景是监管回执差错，任务是定位并修复，行动是按上述五步推进，结果是按时整改并建立检核规则。
五、面试表达框架：业务场景题的“三句话结构”
当被问到“你了解反洗钱数据链路吗”这类开放题，用三句话结构组织回答：
- 第一句定场景：“反洗钱的核心是把客户、账户、交易、名单四类数据打通，支撑可疑交易识别和上报。”
- 第二句讲链路：“数据从核心、支付、信贷等系统采集，经过清洗和客户统一视图，进入规则引擎和名单匹配，输出可疑案例。”
- 第三句讲工程价值：“数据工程的关键是保证交易数据完整性和时效性，同时降低误报率，让合规人员把精力放在高价值线索上。”
这套结构同样适用于监管报送、风险监测和数据治理。它的好处是：先给业务全景，再给数据链路，最后落到工程价值，面试官能快速判断你的认知层次。