FinBus金融防控系统技术方案


  • administrators

    摘要:

    证券交易系统是证券公司的核心业务系统,为经纪、资管、自营等业务部门提供核心的交易通道服务。目前国内证券公司大多外购第三方厂商的大交易柜台系统作为主要的交易平台,此外为满足专业机构客户对交易速度的要求,通常会外购或自建极速内存交易系统。接入这些交易系统的客户端形如手机App、普通或专业PC应用程序、Web页面等等。投资者通过各类交易客户端下发交易指令,交易指令隐含了投资者的所有交易行为。通过分析这种隐含的投资者交易行为可以协助券商、交易所捕捉异常、恶意、不合规的交易请求,起到精细化交易管理的作用。然而市场上能满足这类需求的产品不多,原因有三:一、交易系统、交易终端多种多样,交易指令协议不统一无法轻易从中提取交易行为;二、交易是核心系统,交易链路上提取交易行为通常会影响交易指令传达,加大延迟甚至造成交易中断 三、交易行为没有固定形式,不断变化发展,满足这种动态变化且不对交易造成影响的交易管理产品不易设计。本文介绍我们在实践中总结出的满足这类需求的技术方案。

    关键词

    总线、流水线插件化模型、协议、低延迟、交易行为捕捉、实时、多维度防控、运营、开放插件化、旁路降级。

    引言

    2015年3月13日中国证券业协会下发了修订后的《证券公司网上证券信息系统技术指引》,其中第五十四条指出,证券公司不得向第三方运营的客户端提供网上证券服务端与证券交易相关的接口。证券交易指令必须在证券公司自主控制的系统内全程处理。同年,上交所更新发布了《上海证券交易所会员客户证券交易行为管理实施细则》,细则规定券商应切实履行对客户交易行为的管理职责,规范、约束客户的异常交易行为。监管对客户交易行为管理的态度很明确,接下来就是系统改造实施的问题了。目前券商交易系统大多采购第三方厂商的系统,这些系统缺失对投资者交易行为的跟踪,想升级改造这些系统来支持规范管理客户交易行为从成本和难度上都是巨大的。随着金融创新的发展,投资者客户端(X)、交易所交易平台(Y)、券商交易系统(Z)会随之不断增长,如图1所示的交易链路也会越来越复杂,但监管的态势不会放松,交易管理逐渐成为券商的命脉。本文从交易终端与交易系统解耦、流水线插件框架、低延迟、交易行为捕捉多个方面讲述我们的技术方案。

    0_1535683201791_2.jpg

    解耦

    计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。中间层起到一个很好的解耦作用,面对不断增长变化的交易客户端和交易系统,在他们之间加入一个稳定的中间层能够降低系统的复杂度增强系统的稳定性。总线很适合作为中间层,各类异构的交易终端和交易系统无差别的连到总线上,总线提供消息路由的作用如图2。我们使用的总线支持的“发布-订阅”机制,这种策略下,发布者与订阅者不需要相互知道,只要按照订阅的主题进行发布,订阅者就能收到消息。总线解耦后,已有的系统和新增的系统都可以轻易地接入总线。

    0_1535686081867_03.jpg

    流水线插件框架

    第三方厂商的异构交易终端和交易系统采用的协议通常无法兼容。为了便于统一的客户交易行为采集和分析,多协议的兼容和转换无法避免。转换为统一格式的协议后,对交易消息的处理需求灵活多变。为了满足这些需求,我们设计了流水线插件框架。交易指令从交易终端到达总线后,由交易管理核心处理,交易管理核心是流水线插件结构的。流水线由串行的stage组成,stage由串行或并行的step组成,step是最小的逻辑执行单位,如图3。

    通过组合复用不同的step可以拼凑不同的流水线处理结构。有两个特殊的step:source和sink。他们定义交易请求的来源和去向。交易请求来自不同的交易客户端,他们采用的协议不同,兼容各类协议只需要实现几个轻量的step。收集到投资者的异常交易行为,需要采取一些应对措施、如流控、黑名单等,这种业务处理逻辑也实现为step。在我们的流水线框架中step是所有业务处理逻辑的抽象接口,它接收来源消息,进行处理,发出消息给后续step继续处理。我们的框架把step实现成插件化的方式,通过定义yaml来定义流水线的接口,实现step定义的接口并编译成动态库,插件框架加载动态库、读取yaml定义文件就可以生成流水线。

    0_1535687453479_14.jpg

    低延迟-旁路降级

    在交易链路上加上的交易管理核心服务便于收集投资者交易指令中隐藏的交易行为,但大家肯定问质疑这种做法是否会造成交易中断,当交易管理核心挂掉;是否会增加交易延迟,毕竟多了一跳。我们在交易管理核心服务中实现了故障自动旁路的功能,当检测到自身服务故障时不会对交易请求进行处理,交易请求重新切换回原有的交易路径,保障交易可用为最高优先级。为了最大程度降低延迟的增加,我们的流水线插件框架中step的执行采用直接函数调用的方式,基本0消息传输,最大限度的减少了处理的延迟;在消息总线方面,我们借鉴使用low latency computing技术,如mTCP/DPDK来减少tcp协议栈的多次内存拷贝导致的延迟。

    交易行为捕捉

    我们将交易请求指令通过异步的方式发送到kafka,采用spark分布式并行计算技术对收集到的交易流水数据进行统计分析,对诸如单一客户单只证券进行大额申报、大额成交、大额撤单、频繁撤单这里交易行为很容易捕捉。