业务监测与风险预警系统的制作方法

本发明涉及银行业技术领域，更具体地说，涉及一种供商业银行使用的业务监测与风险预警系统。

背景技术：

为满足人民银行及银监会监管要求，增强各法人行及联盟自身风险控制能力，使联盟核心、电子渠道等业务具备事中和事后的风险监测、识别和处理的全流程管理能力，在不降低客户体验满意度的前提下，快速、动态和全面控制业务风险。根据《山东城商行联盟科技发展战略规划(2015年-2019年)修订稿》要求，联盟建立了t+1的数据平台，可以对前一天的数据进行有效的采集和监管。

然而，上述的t+1数据平台，仅仅是针对每个法人行，受每个法人行自身的操作，对于多个法人行组成的联合体，缺乏信息的有效整合和整体监管，因此，目前迫切需要t+0实时、准实时数据分析体系的支持。

技术实现要素：

针对以上缺点，本发明提出了业务监测与风险预警系统，填补联盟交易事中、事后风险管控工作的空白，通过实时、准实时、批量导入等方式，获取全渠道各类信息，建立起涵盖风险“识别、监控、处置、报告”在内的全流程风险监测管控体系。

本发明实施例提供了一种业务监测与风险预警系统，所述的系统包括：

数据采集模块，包括实时采集模块，用于采集电子交易报文进行处理后发送至数据库或规则引擎；非实时采集模块，用于采集t+1数据文件，清洗和加工后发送至规则引擎；

规则引擎，利用数据采集模块发送过来的数据生成预警信息；

前端应用模块，用于设置并管理规则引擎的配置文件；

数据库，用于存储上述数据采集模块、规则引擎、前端应用模块运行过程中产生的数据。

进一步的，所述的电子交易报文包括电子银行的交易流水、外围系统的问题、核心系统的交易报文。

进一步的，所述的实时采集模块处理电子交易报文时，选取以下模块中的一个或多个进行处理：

mq采集模块，通过消息队列的方式采集数据获取模块中的电子交易报文；

第一交易解析模块，将采集到的16进制的定长报文，根据固定字段的长度截取，解析成xml报文；

第二交易解析模块，根据预设的获取规则，从xml报文中获取所需要的报文字段并重新拼装；

交易分派模块，将核心的报文数据进行复制，分发到不同的功能模块；

交易过滤模块，用于保留失败交易数据，以及在监控列表下的交易数据。

进一步的，所述的规则引擎包括：

规则加载模块，用于将配置的规则信息以map的形式加载到共享内存中，待匹配规则信息时使用；

交易接收模块，用于接收传输过来的报文信息，然后放到共享内存a中；

报文准备模块，用于从共享内存a中获取交易报文数据，然后做数据准备，报文重组，放入共享内存b；

规则匹配模块，用于从共享内存b中获取交易报文数据，根据支行号、交易码获取规则相关的交易信息，调用规则引擎的预警分析处理方法，循环处理此交易码的每一条子规则信息，将预警信息或组装后的交易报文放入共享内存c；

预警生成模块，用于从共享内存c获取预警报文，进行预警处理，从明细表取出要展示的字段存入预警明细表中。

进一步的，所述的前端应用模块包括：

规则管理模块，用于实现基础字段、统计字段、报文准备、数据准备、规则维护、交易码对照、明细表映射、交易入库、动态建表、解析字段、下发版本管理和法人行规则维护。

进一步的，所述的前端应用还包括：

系统管理模块，用于设置机构、用户及角色的信息及权限。

进一步的，所述的系统还包括：

预警处理模块，用于实现预警信息的查询、手动处理和自动处理。

进一步的，所述的预警处理模块包括：

预警查询模块，用于实现对于预警信息的查询；

预警单生成模块，按照设定的条件，自动的生成预警单，而手动处理需手动生成预警单；

案件处理模块，通过对预警单中预警信息进行复核，直至案件状态为结束为止。

发明内容中提供的效果仅仅是实施例的效果，而不是发明所有的全部效果，上述技术方案中的一个技术方案具有如下优点或有益效果：

核心、电子银行和外围系统(网银、前端、esb、xbus等)通过mq队列的方式传递交易数据实现了数据采集的实时性，保证了实时交易数据的实时监控、识别和处置的基础。

风险预警系统支持规则的灵活配置、分层管理，运行引擎根据规则类别，完成交易触发分析和批量数据定时分析。对于产生的预警信息，可根据预先设计的流程，完成预警信息的处理。

系统的实施部署完成一次实施部署可支持多法人行的使用，方便快捷。

系统的建设，具备实时风险监控的能力，具备智能化、可定制的风险计量规则模型，从而有利于城商联盟、及其各法人行的交易操作类风险管理水平的全面提升。有利于提高风险监控的实效性和范围，加大风险防范力度，以降低经营成本、确保银行业务的安全运营。同时对系统发现的风险进行风险评估，生成的风险评估报告，为控制经营风险、进行科学决策提供依据。

附图说明

图1是本发明实施例的整体系统原理图；

图2是本发明实施例中预警处理的流程图；

图3是本发明实施例中规则维护的流程图；

图4是本发明实施例应用在现实中的架构原理图。

具体实施方式

为能清楚说明本方案的技术特点，下面通过具体实施方式，并结合其附图，对本发明进行详细阐述。下文的公开提供了许多不同的实施例或例子用来实现本发明的不同结构。为了简化本发明的公开，下文中对特定例子的部件和设置进行描述。此外，本发明可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。应当注意，在附图中所图示的部件不一定按比例绘制。本发明省略了对公知组件和处理技术及工艺的描述以避免不必要地限制本发明。

实施例

如图1所示，本发明实施例提供了一种业务监测与风险预警系统，所述的系统包括数据采集模块、规则引擎、前端应用模块、预警处理模块、数据库。

所述的数据采集模块，用于从数据来源采集数据，系统数据来源包含核心、电子银行、外围系统和数整平台,外围系统(告警监控)是指山东城商行联盟生产环境中的所有应用系统。核心业务系统是指金融行业的银行核心业务系统。数整平台是指山东城商行联盟数整系统，主要是做数据下档和数据分析整理等内容。数据推送方式有mq、ftp两种。电子银行、外围系统、核心系统分别将交易信息或者系统告警信息组装成xml报文，并分别放置在mq队列1、mq队列2、mq队列3中，业务监测与风险预警系统从上述的mq中获取。t+1数据文件由业务监测与风险预警系统每天定时从数整平台通过数据分发的方式获取。

上文中的mq，全称为messagequeue(消息队列)，是一种应用程序对应用程序的通信方法。

数据分发的定义为：使用ftp，ftp(filetransferprotocol,文件传输协议)是tcp/ip协议组中的协议之一，其任务是从一台计算机将文件传送到另一台计算机。

电子银行的数据通过cdc的实时镜像同步，将电子银行的交易明细数据、客户数据等数据库内的数据实时同步到cdc数据库内，然后cdc将电子银行的交易流水实时推送到mq队列1中，待业务监测与风险预警系统获取。

外围系统(告警监控)数据源，联盟的所有系统都可以将系统内的问题组装成xml报文推送到mq队列2中，待业务监测与风险预警系统获取。

核心业务系统实时将交易报文推送到mq队列3中，待业务监测与风险预警系统获取。

数整平台将下档的核心业务系统表数据放到指定的目录下，业务监测与风险预警系统通过ftp方式去获取。

所述的数据采集模块，包括实时采集模块和非实时采集模块。

实时采集模块用于采集电子交易报文进行处理后发送至数据库或规则引擎。所述的实时采集模块处理电子交易报文时，选取以下模块中的一个或多个进行处理：

1)mq采集模块，通过消息队列的方式采集数据获取模块中的电子交易报文。

2)第一交易解析模块，将采集到的16进制的定长报文，根据固定字段的长度截取，解析成xml报文。

3)第二交易解析模块，根据预设的获取规则，从xml报文中获取所需要的报文字段并重新拼装成xml报文。

4)交易分派模块，将核心的报文数据进行复制，分发到不同的功能模块。

5)交易过滤模块，用于保留失败交易数据，以及在监控列表下的交易数据。

例如，如图1所示，mq队列1的数据仅仅需要经过mq采集模块即可发送至规则引擎，mq队列2的数据需要依次经过mq采集模块、第二交易解析模块即可发送至规则引擎，mq队列3的数据需要依次经过mq采集模块、第一交易解析模块、交易分派模块、交易过滤模块、第二交易解析模块才能发送至规则引擎。

需要注意的是，mq队列3的数据，在完成交易分派模块的处理后，即可统计入库，存入数据库内。

非实时采集模块将数整平台的t+1数据文件通过ftp方式下发到指定目录，再读取数据后进行数据清洗、加工，然后推送到规则引擎的交易接收进程中。

非实时采集模块中的数据清洗，指的是从数整平台获取交易明细表、客户信息表等表的数据文件，并存入到数据库。

非实时采集模块中的数据加工，指的是通过程序脚本对t+1的数据进行加工整理。

所述的规则引擎，利用数据采集模块发送过来的数据生成预警信息，所述的规则引擎包括：

规则加载模块，用于将配置的规则信息以map的形式加载到共享内存中，待匹配规则信息时使用。

交易接收模块，用于接收传输过来的报文信息，然后放到共享内存a中。

报文准备模块，用于从共享内存a中获取交易报文数据，然后做数据准备，报文重组，放入共享内存b。

报文准备的具体实现原理为：

第一步：根据交易码在cdc镜像库获取交易码需要数据，本系统中称为外部字段；第二步：把交易内容存入交易码对应的交易类交易明细表；第三步：将外部字段重新拼装到交易报文，放入共享内存b。

规则匹配模块，用于从共享内存b中获取交易报文数据，根据支行号、交易码获取规则相关的交易信息，调用规则引擎的预警分析处理方法，循环处理此交易码的每一条子规则信息，将预警信息或组装后的交易报文放入共享内存c。

规则匹配的具体实现原理为：

第一步：首先判断交易报文内容是否符合统计范式(先决条件)，如果符合进入下二步，如果不符合跳出循环；第二步：判断交易报文内容是否符合表达式，如果符合进入第三步，如果不符合跳出循环；第三步：从中间表获取同一主规则下的其他子规则的预警情况，判断是否符合主规则表达式(子规则关系)，如果符合进入第四步，如果不符合，跳出循环；第四步：判断是否是电子银行的规则，如果是则在报文最后拼接end结束标志，供生成预警信息计算分值时使用，如果不是则不进行特殊处理，将组装后的交易报文放入共享内存c。

预警生成模块，用于从共享内存c获取预警报文，进行预警处理，从明细表取出要展示的字段存入预警明细表中。

预警生成的具体原理为：

第一步：首先判断从共享内存c获取的交易报文是否有end结束标志，如果有就进入第二步，如果没有就进入第三步；第二步：开始处理电子银行规则预警，进行风险分值的计算，生成预警信息和预警明细信息，然后入库；第三步：开始处理会计规则预警，生成预警信息和预警明细信息，然后入库，进行预警信息的自动发核查和自动发处理。

通过规则引擎和规则生成的预警信息，这些预警信息可以给客户展示，也可以向其他的渠道或系统推送。而向客户展示的预警信息，客户可以在客户端通过预警处理模块进行预警信息的处理。

所述的预警处理模块包括：预警查询模块，用于实现对于预警信息的查询；预警单生成模块，按照设定的条件，自动的生成预警单，而手动处理需手动生成预警单；案件处理模块，通过对预警单中预警信息进行复核，直至案件状态为结束为止。

如图2，预警信息可根据预警的规则风险值是否满足自动合并阀值的条件分为自动处理和手动处理两种，自动处理会按照设定的条件自动的生成预警单，而手动处理需手动生成预警单，然后通过电话或短信的方式核实，调查该预警为正常—>结束、级别高成为案件—>待审批—>待调查，然后撤销或者归档—>结案—>结束。

所述的前端应用模块包括规则管理模块，用于实现基础字段、统计字段、报文准备、数据准备、规则维护、交易码对照、明细表映射、交易入库、动态建表、解析字段、下发版本管理和法人行规则维护。

规则管理模块中每个模块的具体功能为：

(1)基础字段：根据核心交易字段文档，配置所有监控交易报文的所有基础字段及系统中规则引擎配置预警规则需要使用的字段。

(2)统计字段：根据规则需求，对所有需进行累计、累加的字段进行配置。

(3)数据准备：可在页面上向规中使用的各明细表、外部表、中间表表导入数据。

(4)交易码对照：前后台交易码对照关系配置及对应的交易类型和名称。

(5)明细表映射：根据交易类型，设置各交易类型入库所对应的明细表。

(6)交易入库：交易里的字段与入到库里明细表中的哪个字段建立的对应关系。

(7)报文准备：为每一个需要外部数据支撑或加工处理的后台交易配置新的报文字段准备。

(8)动态建表：创建规则需使用的各明细表、外部表、中间表，建立的表在明细表映射中配置。

(9)规则维护：配置规则，如图3，之前的功能模块都是为配置规则服务的，如图1的统计字段和基础字段等。一条主规则可以有多条子规则和子规则关系组成，而一条子规则在创建的时候需明确对应交易类型、统计字段、关联字段和时间类型，同时配置对应的表达式、统计范式、输出数据、关联表和子规则明细配置；子规则关系是指设置各个子规则结果(如输出数据、预警结果和发生时间)之间的关系。

表达式配置：根据统计字段做累加/累次/报文值/执行sql语句的计算。

统计范式配置：按基础字段做条件的过滤。

输出数据配置：按基础字段或表达式语句字段输出值。

关联表配置：设置交易产生预警时，去哪张交易明细表里拿交易明细，以及时间限制。

子规则明细配置：把源表中的某字段存入目标表中哪个字段的配置。

(10)解析字段：配置所有监控交易输入流的所有报文字段。

(11)下发版本管理：把规则下发到联盟或各个法人行。

(12)法人行规则维护：维护下发到各个法人行的规则。

所述的前端应用还包括系统管理模块，用于设置机构、用户及角色的信息及权限。

所述的数据库，用于存储整个系统运行过程中产生的数据。

业务监测与风险预警系统基于城商行联盟的核心镜像库cdc(changedatacapture：变更数据捕获，用于对表数据的更新进行跟踪)和核心、外围系统等推送mq数据和数整平台t+1供数为数据来源，充分利用规则引擎的强大能力，对数据进行解析重组，完成数据的清洗加工，然后进行数据的分析和处理，实现实时交易数据和批量数据的监控、识别和处置，有效的识别风险，避免风险和损失，同时全面满足银监会、人民银行和公检法对于风险防控的监管要求和内控合规的风险监测要求。

在实际应用中，图4是系统的部署架构，其中数据处理服务器、数据分析服务器、告警分析服务器、应用服务器、数据库服务器组成了业务监测与风险预警系统的物理架构。

电子银行将数据同步给cdc，然后由cdc推送mq给本系统；核心系统通过mq直接将数据推送过来；外围系统等通过mq推送交易数据给联盟esb，然后由联盟esb给本系统推数；数整平台使用ftp推送t+1数据。

各法人行、联盟生产网等通过http/https访问前端应用。

图1的数据采集(实时、非实时)、规则引擎两块逻辑处理程序部署在图4的数据处理服务器、数据分析服务器、告警分析服务器；图1的前端应用程序部署在应用服务器；图1的风险预警数据库程序部署在数据库服务器。各服务器部署程序及处理如下：

1)数据处理服务器：安装数据处理应用程序，以便接收核心mq交易数据，并对数据分析加工处理，为数据分析提供数据基础。

2)数据分析服务器：安装数据分析应用程序(规则引擎)，对实时交易数据进行分析预警。

3)告警分析服务器：安装数据处理应用程序和数据分析应用程序(规则引擎)，对告警数据进行加工处理，及分析预警。

4)数据库服务器：用于储存基础信息、核心及告警mq数据、以及预警处理相关数据。

5)应用服务器：安装web端应用，用于展示预警信息及预警处理流程信息。

尽管说明书及附图和实施例对本发明创造已进行了详细的说明，但是，本领域技术人员应当理解，仍然可以对本发明创造进行修改或者等同替换；而一切不脱离本发明创造的精神和范围的技术方案及其改进，其均涵盖在本发明创造专利的保护范围当中。