2. 金融数据基础
在金融数据校验的实战中，第一步不是写规则，而是看清“被校验的对象”。金融数据并非单一形态，它横跨交易流水、行情快照、客户档案、风控指标、监管报送等多个领域，来源分散、格式各异、更新频率差异巨大。只有先建立对数据类型、来源、格式和质量维度的系统认知，后续的完整性、准确性、一致性校验才有明确的靶点。
一、金融数据的四种常见类型
从业务语义出发，金融数据通常可分为四类，它们的校验重点各不相同：
- 交易类数据：订单、成交、支付、清算记录，强调金额、时间、账户、方向的一致性，任何字段错位都可能引发资金差错。
- 行情类数据：买卖盘、最新价、成交量、涨跌幅，具有高频、时序、易缺失的特点，校验重点是时间戳连续性与价格合理性。
- 参考类数据：证券代码、汇率、利率、客户主数据，变化慢但影响面广，校验重点是唯一性、有效区间和映射关系。
- 指标类数据：风险敞口、净值、收益率、监管指标，多为聚合计算结果，校验重点是口径一致与可回溯。
二、数据来源与常见格式
金融数据的来源决定了它的“先天质量”。常见来源包括核心交易系统、行情网关、第三方数据商、人工录入表单、监管报送接口以及日志与埋点。不同来源对应不同格式：
| 格式 | 典型场景 | 校验关注点 |
|---|---|---|
| CSV | 批量对账、报表导出 | 分隔符、编码、空值、列顺序 |
| JSON | API 返回、行情推送 | 字段缺失、类型漂移、嵌套层级 |
| XML | 监管报送、老系统交互 | 标签闭合、命名空间、Schema 约束 |
| 数据库表 | 核心系统落库 | 主键唯一、外键关联、约束与默认值 |
以 JSON 行情为例，一条典型的推送数据如下：
{
"symbol": "600519.SH",
"timestamp": "2024-06-11T09:30:00.123+08:00",
"last": 1680.50,
"volume": 12000,
"bid": 1680.40,
"ask": 1680.60
}校验时需关注：timestamp 是否单调递增、last 是否落在当日涨跌停区间、bid 是否小于等于 ask、volume 是否为非负整数。这些判断直接对应后文的质量维度。
三、数据质量维度：校验规则的“坐标系”
金融数据质量通常从六个维度衡量，它们也是校验规则设计的分类框架：
- 完整性：必填字段是否缺失，记录条数是否与上游一致。
- 准确性：数值是否在合理范围，金额精度是否符合币种要求。
- 一致性：同一实体在不同系统中的编码、名称、余额是否一致。
- 及时性：数据到达时间是否满足业务时效，时间戳是否滞后。
- 唯一性：主键、业务键是否重复，是否存在一码多物。
- 有效性：枚举值、日期格式、正则模式是否符合约定。
建议将每个质量维度映射为可执行的校验规则模板，例如“完整性 → 非空检查”“准确性 → 区间检查”“一致性 → 跨表比对”，这样规则库可以按维度分类管理，便于复用和审计。
四、案例与常见误区
某基金公司曾出现净值报送偏差：CSV 导出时金额字段被 Excel 自动转为科学计数法，导致 1234567.89 变成 1.23E+06。表面看是格式问题，实质是准确性维度失守。复盘发现，校验规则只检查了“字段非空”，没有检查“数值可解析且精度符合两位小数”。
常见误区有三：一是把格式正确等同于数据正确，忽略业务语义；二是只校验单表，不做跨源一致性比对；三是规则写死在脚本里，缺乏维度分类和版本管理，导致问题重复发生。
正确的做法是：先按来源和格式建立数据画像，再按质量维度设计规则，最后用样本数据回归验证。下图展示了从数据源到质量维度的映射关系，帮助你在实战中快速定位校验切入点。
掌握这张映射关系后，你在面对任何一批金融数据时，都可以先问三个问题：它来自哪里？以什么格式承载？需要从哪些质量维度切入校验？这三个问题的答案，就是后续完整性、准确性、一致性校验实战的起点。