第三方支付风控系统架构设计.docVIP

第三方支付风控系统是如何运作的？如何搭建？系统架构如何？ 第三方电子支付是一个高风险的行业，这就意味着第三方电子支付公司必然要与各种不确定性相伴。从风险受益的角度来看，第三方电子支付公司存在的价值不在于其能消灭不确定性，消灭风险，而在于其能在对风险有较深入认识的基础上控制和管理风险，将风险配置到愿意并能承担风险的主体，并使其获得收益。风险控制系统目标是实现对各个业务部门、渠道和产品线和相关人员监测，通过对运营业务交易的实时分析、事中和事后分析、跟踪和处理的方法实现欺诈风险预警的自动化。通过对交易的监测，可以识别那些是高风险交易，以及早发现其欺诈的可能性，并及时采取各种防范措施，由此来降低交易带来的损失。 一个新产品需要重点考虑业务风险控制。关于风险控制系统整体的技术方案。此方案尽管能够满足业务需求，但对于海量交易数据分析、风险事件的实时处理、大量的风险规则处理上，在实时性、性能、架构的可扩展性上都不是很理想，有必要重新从架构上考虑一下实现方案。 一般而言，风险控制系统标准的软件架构如下： 1、风控系统实现的几种方案 1)、数据库方案：将风险规则、交易数据等都采用关系数据库存放。正如 支付系统风控系统建设思考 所提到的方案，交易库和风险库一般分别部署在不同的服务器上，在事件触发上可以采用数据库触发器、消息队列事件等方案。此种方案技术实现相对简单，但在进行海量交易数据查询以及大量风险规则处理时候，数据库系统查询性能及扩展性成为一个较大的瓶颈。很难满足风险事件实时分析的要求。 2)、内存数据库方案：由于对海量交易数据的查询、分析极其消耗数据库资源，可以采用内存数据库方案来替代关系数据库，保证风险事件实时处理的性能。 但目前开源的内存数据中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大规模的业务场合应用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase价格太高。 3)、分布式缓存方案：采用Memcached等NOSQL的分布式缓存来缓存交易数据、风险规则等，但由于NOSQL解决方案并不擅长数据间的关系逻辑处理，需要在程序中大量维护业务处理逻辑，远不如关系数据库或内存数据库方案方便。 以上方案，都可以通过规则引擎（例如drools）来完成风险规则的管理和维护，避免了风险规则维护的繁琐及规则间复杂关系处理。 Complex Event Processing (复杂事件处理)是一种新兴的基于事件流的技术，它将系统数据看作不同类型的事件，通过分析事件间的关系，建立不同的事件关系序列库，利用过滤、关联、聚合等技术，最终由简单事件产生高级事件或商业流程。CEP适合的场景包括实时风险管理、实时交易分析、网络诈欺、网络攻击、市场趋势分析等等。 CEP的几大特点： 基于数据流 时间序列 实时 复杂 支付系统风控系统建设思考 1. 管理框架 第三方电子支付风险管理解决方案由风险战略，组织架构和管理流程组成。其中，风险战略的确定是欺诈风险管理业务体制和运作机制设计的基础；组织架构确立风险管理运作机制和相应的组织管理模式，明确相关部门、人员、关键岗位分工和职责；管理流程则是一个完整的风险管理过程所包含的各个环节。各种风险管理的机制和体制需要通过统一的管理平台来实现。统一的欺诈风险管理平台包括监测模块、分析模块和案件管理模块。构建风险管理 平台的关键技术是以合理规范的数据模型，建立整合的风险数据平台；以及针对内部程序、人员和外部事件，实施有效的业务运营监测。 统一的风险控制系统包括三大模块：监测模块、分析模块和案件管理模块。 监测模块对支付平台的运营作业进行全面监测，将可疑行为信息和相关信息发送到分析模块进行分析确认，当发现异常行为时发出警报，将警报和与警报相关的信息都发送到分析模块和案件管理模块。 分析模块能对各种数据源进行集成，对各种历史数据进行学习分析，通过数据挖掘建模定义出典型的行为特征，建立行为模式、场景，并制定欺诈风险监测规则。 案件管理模块最终将案件处理的数据反馈到监测模块，从而增强监测模块对风险的监测和识别能力。 1. 监测模块 交易监控系统要及时对交易进行处理，在最短的时间内对可能存在的交易风险进行判别，准确的报告欺诈等高风险交易，在第一时间提供详尽的信息以协助工作人员对可疑交易进行识别、处理。为保证这种效能，交易监控系统需要采用准实时、分布式的模式进行交易处理。在部署上交易监控系统和交易系统应当支持分布式部署，在不同的主机系统上部署，系统间通过可靠的消息中间件进行信息的传递，降低系统间的耦合度，保证交易系统的高性能，同时也可以通过前置机方式来降低交易系统对信息处理的负荷