Simplexity

监管科技（1） - 数据采集

Posted on Edited on In
Symbols count in article: 4.2k Reading time ≈ 14 mins.

一．监管采集系统

BIS的Financial Stability Institute团队在2020年的监管科技创新报告里指出监管数据采集的过程：

“First, financial institutions collect data from their business operations (ie their operational data, such as detailed data on mortgage loans extended to customers). Second, they map their operational data to the “input data”, which are the data elements needed to populate regulatory reports (eg outstanding loan amount, number of days past due, etc). 14 Third, they transform the input data to the required reporting data based on reporting instructions provided by financial authorities. Finally, required reporting data is transmitted to the financial authority.”

1. Austrian central bank (OeNB) 奥地利央行的多维数据立方

在2018年7家银行联合组建了Austrian Reporting Services GmbH (AuRep) 公司，作为被监管银行和OeNB间的数据缓冲与整合平台。AuRep的数据层次划分类似于上图提到的方式，数据领域的多维分析概念，定义Basic Cube数据立方的数据结构（上图的Input Data）。被监管银行从各自的IT系统抽取信息，以原始的细粒度数据映射成定义的数据格式并报送到AuRep, AuRep把数据存在Basic Cube内（被监管机构负有保证数据质量的责任）。然后AuRep根据OeNB的分类报送需要，设计定义具体类别的数据Smart Cubes（上图的Required reporting data）, 从Basic Cube的数据通过钻取/切片等数据处理方式计算出Smart Cubes并生成具体的报送文件/数据发送到OeNB。

此方案减轻了被监管机构的工作，只需要维护原始数据的报送质量和按Basis Cube的需要增删改字段报送到AuRep。而OeNB所需的报送文件（Smart Cubes）可能会频繁变化，则此汇总/转换/生成结果等工作完全交由AuRep统一完成，保证计算口径的一致。除开周期性的生成结果文件主动报送外，OeNB可能也会进行实时查询，同理此查询也只需访问AuRep的Basic Cube即可。整个方案兼具效率和灵活性，同时长期看也降低了成本。

2. European Central Bank (ECB) 的IReF报送框架

ECB遇到的主要问题是欧元区内各个主权国家的数据系统异构，数据模型不同，数据交换方式，交换频率，并且上报到ECB以及本国央行NCB的数据有交叉与差异。所以ECB提出了IReF(Integrated Reporting Framework)，将各种报送要求整合成统一的数据采集方式。同时Banks’ Integrated Reporting Dictionary (BIRD)定义了数据字典及规则，提供了转换方法论，将银行的原始数据映射成监管上报数据。与OeNB类似，被监管机构只需要按照BIRD定义的数据字典将原始数据报送到BIRD输入层，保证数据质量；后续的汇总等责任移到NCB和ECB，基于这份基础数据，相应的产出不同监管机构所需的数据报表。目前此方案还在设计和测试中，预计2024-2027年实现。

思考

  1. 监管数据采集有几个关注点：准确的数据，及时的获取，安全的传输通道。
  2. 方案分包含数据报送字典的定义及映射，数据转换/计算，数据传输方式三个阶段。对被监管方而言，只需要按照数据字典做细粒度的映射等最小化操作，后续的清洗/汇总等都由被监管方或者中间层进行（aggregate efforts shifted from financial institutes to financial authorities）。某种意义上，减轻了被监管机构的数据处理转换的负担，避免被监管机构在后续数据过程出错导致的数据质量问题，但是需要被监管方从源头上保证原始数据内容的正确性。
  3. 关注数据采集的法律责任。OeNB的方案里提到AuRep缓冲层的作用是No direct access to commercially sensitive raw data。
  4. 大多数央行/监管机构在指定方案/数据字典时，会与被监管机构进行多轮的咨询意见和建议，有些会由监管方，被监管方，业界专家组成讨论小组共同商定方案。甚至有些央行会与商业机构合作委托或者共同开发监管采集系统（ECB的文档里介绍其实施路径及方法论）。

二. 数据采集传输方式

International Bank for Reconstruction and Development / The World Bank 团队在2021年的”The Next Wave of Suptech Innovation”报告里指出，当前典型的监管数据采集有以下三种：

1. 前置数仓模式

卢旺达国家银行（The National Bank of Rwanda , BNR）在2017年起与商业公司Sunodia合作，设计了电子数仓（Electronic Data Warehouse , EDW）解决方案。被监管方在其各自的IT系统内部署前置数仓中间件，并使用统一的数据模型。由于数据模型统一，监管方就可以使用统一的API从被监管方拉取数据，然后在监管侧本地存储，管理，计算分析。

其中被监管侧的具体步骤为：

  • 数据抽取(Data Acquisition)。被监管方的数据库选型及数据模型存在异构性，需要根据自身情况，开发脚本程序从各自的数据库里抽取原始数据。保证数据质量及数据及时性。
  • 数据转换(Data Conversion)。根据自身数据库设计数据转换协议，将各自数据类型映射转换成统一数据模型存入被监管机构侧的前置数仓中间件（与被监管机构的核心系统隔离）。通常还包含业务逻辑的校验等。
  • 数据整合(Data Integration)。在前置中间件加上必要的数据校验，数据整合等，例如元数据管理，保证入库数据与原始数据一致等。

  • 数据提交(Data Submission)。监管方可以通过VPN和加密的方式从前值中间件拉取数据。也可以由被监管机构主动提交。

    此方案有以下特点：

  1. 数仓中间件作为数据缓冲层，避免了监管方直接访问到被监管方的核心系统和数据库，从而降低侵入性，减小对业务的影响。
  2. 数据存储在被监管方的前置数仓中间件，作为监管方可以按需不定时的从中间件拉取数据。
  3. （可能）由于前置中间件使用了统一建模并本地存储，因此监管方甚至可以直接使用数据分析工具和可视化工具访问，将计算下发被监管机构，获取粗粒度的汇总结果数据，也可以拉取细粒度的数据集中到监管方自建数据集市统一存储，管理，计算分析。

2. API提交方式

Bangko Sentral ng Pilipinas (BSP) 在2018年开始采用API数据采集方式。可大致拆分成以下四个阶段：

  • 数据抽取及API传输。由被监管机构实现从其各自的核心数据库里完成原始数据抽取，生成加密的XML文件，最后通过API的方式提交到监管机构。通常被监管机构平均每间隔10s提交一次，这样BSP就能获得近实时的数据用于进行统计分析。采集和提交原始数据，使得监管侧后续数据的数据使用更加灵活。
  • 数据预处理/校验。监管方定义数据校验规则库，接收到数据后进行规则检验，并将校验结果反馈给被监管方。这里的校验规则既包含通常意义上的数据质量规则，也包含一定的业务/合规等校验逻辑。
  • 数据入仓，统一存储。
  • 数据应用。

3. 数据文件报送方式

定期间隔的提交XBRL, CVS, or XML等格式的数据文件，可以是人工手动上传的，也可以是机器间的传输。方案简单，但是数据粒度及实时性等受限，数据模型变更的开发上线时间过长，适用IT能力较弱的监管体系。

思考

报告里将前置数仓和API提交分别定为以为most sophiscated和moderate sophicated。其中，前置数仓模式功能最为强大，特别适用于存在多个监管方，同一份数据需要多次整合发送的场景。建立统一前置数仓，能最大程度的保证数据一致性等数据质量，也可以消除在监管报送方面的重复建设。另外由于前置使用了统一建模并在被监管方本地存储，因此监管方甚至可以直接使用数据分析工具和可视化工具访问，将计算下发被监管机构，获取粗粒度的汇总结果数据，也可以拉取细粒度的数据集中到监管方自建数据集市统一存储，管理，计算分析。但同时前置对整个监管/被监管的体系的IT技术能力要求也最高，建设周期也最长。

  1. 需要机构在核心系统外建立和维护前置数仓。需要有完整的数据存储，数据管理和数据计算等能力，也就是专属的一套数仓环境用于满足监管需要。另外需要建立开放API接口体系，赋能监管机构下发计算进行数据分析，数据可视化，甚至于风控规则等等。
  2. 统一的数据建模难度。由于统一建模需要有效且相对稳定的数据模型设计，因此需要在对整个货币运行以及监管体系深度了解前提下进行顶层设计。
  3. 整个监管体系参与方的观念及方式更新转变。

API提交是相对折衷方案。相对于当前的数据报送方案T+1的时间间隔，能提升实时性，同时由于是直接抽取数据库，API接口灵活，也能比较容易的根据业务发展需要升级API接口版本和扩展数据维度。而相对于前置数仓的方式，被监管方的系统改造较小，建设周期短，适合作为短中期的方案。其中，譬如被监管方的数据库原始数据的数据抽取，数据转换等，也可视为长期方案的技术探索及积累。实际上，前置数仓PULL模式，也是需要通过API进行交互。另外，监管侧的数据平台具备数据校验，存储，管理，计算能力，与API传输的数据采集方式整合难度低。需要说明的是，虽然定义为API提交方案，但实际的技术方案应考虑到实际情况，充分利用各技术的特性，例如API，消息队列等，对于原始数据的抽取与转换也应该充分考虑各被监管机构的数据库异构性，以及采用数据转换预处理方案时的优缺点。