供应链金融风控系统流程是怎样的

供应链金融风控系统流程是怎样的呢？依据我们供应链金融风控系统的开发经验，下面来为大家进行介绍。前期准备
拿到足够多的数据做支撑
做足够灵活的分析**去分析数据
产出风险**进行阻拦风险
量化风险拦截的价值和不断分析案例进行策略优化
风控技术评估研究
日志选择：以增量日志方式记录存储，hadoop或spark做分析，集群同步到客户端机器上，做同步策略，不同纬度的数据做统计加工计算。实时监控：监控在每一个环节的交易量和高风险操作，做阀值报警，以默认的规则做处理。dns防范：防止http对dns的拦截，手动纪录中断被拦截掉的交易流，转向存储中心系统做处理给予用户提示。报警提醒：在发生重大灾难的同时需要有一套完善的体系提醒风控人员近入作战，以短信或电话的形式发起通知给用户。数据灾难：数据的历史纪录应该有完整的备库纪录，这种操作不是必须的但是必要的，防止管理员因为误操作导致的数据灾难不容小视，启东应急方案进行恢复。日志选择：需要在原有基础上做集群数据分析后，统一有一个入口的分析**做汇总，对不同维度的计算规则做排重，这里我们可以使用elk的方式把数据清洗完成后，做相关的分析调研，实时读库的方式不可取，增量数据库只保留历史的数据，可以对时间做相关的约定，查询的**统一做相关的调控。方案的选择和实施
针对现在的数据规则，需要对现有的各方数据做分析指标，做数据仓库，从不同的数据中计算对应的需要风控形成各种渠道的报表数据。如何通过查询海量的历史数据来支撑规则的运算，从分析的角度来看，又是一个io密集型的应用；利用oltp（online transaction processing）和olap（online analytical processing）做相关的维度计算，主要针对用户、功能、数据片、存储空间、db设计来做维度计算和方案的优化调整。大到用hadoop做数据集群算法分析，也可以用spark、storm来做。简而言之就是分布式框架，那么什么是分布式框架？分布式计算框架实现了什么？简而言之，基于分布式计算框架的应用，就是一个分布式的应用；那么分布式的应用解决了什么问题？简而言之，就是将请求处理的业务逻辑和所需资源合理地分布到n台服务器上，这里就不在过多介绍。基于c/s**的原理，从client到server端的应用，采集需要的数据。server之间通讯是有开销的，只不过这个开销是ms级的。系统在定位也是基于百万级的应用。以分层的概念，针对每部的风控模块，需要在特定的时间做调整。缓存的应用：如果是历史级别的数据，可以采用red**、cache来做，防止减少对于i/o的读写操作，减少存储压力的开销。基于款时间的维度对应的风控系统计算，需要我们在处理的同时考虑数据的节点，分批次处理。对于变化多端的数据，建议利用高可用性能存储设计，基于db设计即可，数据结构要基于范式(nf)设计，不可有冗余免得频繁返工。数据分离的优先选择
数据库读写分离机制：在初期，风控系统一般都极为简单，此时侯一般通过数据库主从复制/读写分离/sharding（或sl**e进行）等机制来保证交易系统的数据库和风控系统数据的同步及读写分离。风控系统对所需要的客户/账户数据、交易数据一般都只进行读操作。缓存/内存数据库机制：不管是交易系统还是风控系统，高效的缓存系统是提升性能的大杀器，一般会把频繁使用的数据存放到red**等缓存系统中。例如对风控系统，包括诸如风控规则、风控案例库、中间结果集、黑白名单、预处理结果等数据；对交易系统而言，包括诸如交易参数、计费模板、清结算规则、分润规则、银行路由策略等。对一些高频交易中，基于性能考虑，会采用内存数据库（一般会结合ssd硬盘）。rpc/soa架构：要降低交易系统和风控系统的耦合度，在初期系统服务较少的情况下，一般直接采用rabbitmq/activemq之类的消息中间件或rpc方式来实现系统间服务的调用。如果系统服务较多，存在服务治理问题，会采用dubbo之类的soa中间件来实现系统服务调用，这个期间我们需要支持用异步消息完成rabbitmq的消息的push/pull处理机制来处理违规数据和异常数据提取。