合规问数

证券行业合规工作需要持续监控客户交易行为，及时发现异常交易、大额资金流动、关联交易等风险信号。监管机构对证券公司有定期报送要求（如反洗钱数据、适当性管理数据、风险预警数据），但这些数据的统计口径在不同部门有不同理解，导致报送数据与业务系统原始数据经常出现差异，每次监管检查都要反复核实。

智能问数平台将风控系统的预警数据与交易系统账户数据统一建模：账户本体包含客户号、账户类型、开户时间、所属营业部等属性；预警本体记录预警编号、触发时间、触发规则、账户、预警等级、处理状态；触发规则本体则详细记录每条预警规则的逻辑（哪些条件触发、阈值是多少）。合规总监可以随时提问："本月触发预警的客户账户数量较上月变化"，系统自动计算同比/环比，并按预警类型（异常交易预警、大额资金预警、反洗钱预警等）做分类统计，数据可直接用于监管报告。

技术团队构建了合规域核心本体。账户本体覆盖客户账户、机构账户、和产品户，记录账户ID、客户号、账户类型、开户日期、销户日期、当前状态；预警本体记录每次预警事件，包括预警ID、触发时间、关联账户、预警类型（异常交易/大额资金/反洗钱/适当性等）、预警等级（红/黄/蓝）、处理状态（待处理/处理中/已关闭）；触发规则本体记录预警规则的定义，包括规则ID、规则名称、触发条件、阈值参数、适用账户范围。本体层定义了账户与预警之间的"触发"关系，预警与触发规则之间的"依据"关系。关键设计：触发规则在本体中仅记录触发条件和阈值参数，不暴露规则核心逻辑（如"连续3笔超过500万的委托"这类具体数值），以保护合规规则的敏感信息。

"本月触发预警的客户账户数量较上月变化"这句话，系统解析出：时间范围A（本月）、时间范围B（上月）、主体（触发预警的客户账户，去重）、指标（数量）、语义（变化=（本月数量-上月数量）/上月数量*100%，即环比变化率）。语义映射层将"客户账户"映射为账户本体的账户ID字段（去重），"触发预警"映射为预警本体的触发时间在目标月份内的记录，"环比变化"映射为统计本月和上月去重账户数后计算差值百分比。系统还支持追问："哪些预警类型的增长最明显？""本月新增预警账户中，有多少已转成案件？"

查询执行需要对接风控系统（预警记录）和交易系统（账户信息）。风控系统提供预警明细，交易系统提供账户基础信息，两边通过账户ID关联。由于合规数据敏感性，所有查询在合规部权限范围内执行，非合规人员无法访问。查询结果支持导出为监管报送格式，减少手工整理工作量。系统还提供数据血缘追溯：每个数据点都可以追溯到原始记录，方便监管检查时提供证据链。

风控预警规则是公司核心资产，规则的具体参数（如"单日超过500万的大额资金转入"中的500万阈值）属于敏感信息，不能在问数平台中直接暴露。但合规总监需要了解哪些规则触发了预警、触发了多少次，以便评估合规状态。技术团队在本体层对触发规则做了两层抽象：规则层（仅记录规则名称和触发类型，如"大额资金预警规则"，不暴露具体阈值）和参数层（仅合规总监级别可见，包含具体参数值）。问数结果中，预警次数按类型展示，但不暴露规则具体参数；若合规总监追问具体参数，系统提示"此信息需要额外权限申请"。

"触发预警的客户账户数"在不同口径下有不同的计算方式：人行报送要求"月内去重客户数"（同一客户当月多次触发只计一次），但公司内部风控口径可能按"预警笔数"统计（同一客户多次触发计多次）。口径不一致会导致报送数据与业务数据存在差异，监管检查时难以解释。技术团队在本体层为每个指标定义了两个口径：内部合规口径和监管报送口径。当合规总监提问"本月触发预警的客户账户数"时，系统默认返回"内部合规口径（按预警笔数）"，同时支持用户明确指定"人行口径"，返回去重后的客户数。两个口径并列展示，差异一目了然。

合规数据涉及客户交易行为、预警记录等高度敏感信息，必须严格控制访问范围。系统基于本体层的权限语义实现行级数据隔离：合规总监可查看全部预警数据，合规专员只能查看自己处理的预警，普通业务人员只能看到与自己业务相关的客户预警。查询日志全程记录，包括查询人、查询时间、查询内容、返回结果的数据量，确保数据访问可审计。此外，对于涉及监管报送的敏感数据，系统设置"防导出"标记——用户可以看到汇总数据，但无法导出明细，防止数据泄露。