支付-支付风控

阅读目录

1. 领域模型
2. ER图

 

---

风控系统架构

外部系统直接通过接口调用得到实时的风险等级标识(通过、阻塞、 拒绝)，然后业务系统根据风险等级标识采取相应的措施，比如验证码或者阻塞拒绝。接口需要传入模型名称(登录风控模型、交易风控模型)，每个风控模型都有一组策略(当前实现是一个模型对应一个策略，后续可扩展)、每个策略对应一组规则，每个规则都对应一组特征。风控系统的核心就是规则引擎，规则引擎这里使用的是 Expr 表达式来实现，便于快速响应需求变化(通过表达式修改风控逻辑，动态调整风控阈值)。

风控系统流程

func check() {
        // 获取模型
	m, ok := e.modelManager.GetModelByGuid(modelUid)
  	if !ok {
		return ErrModelNotExists
	}
  	
  	// 验证参数
  	if err := e.validateProperties(ctx); err != nil {
		return err
	}
  
  	// 数据预处理
  	if err := e.executePrepares(ctx); err != nil {
		return err
	}
  
  	// 特征值计算
  	if err := e.executeAbstractions(ctx, modelId); err != nil {
		return err
	}
  
  	// 规则匹配打分
  	if err := e.executeActivation(ctx, modelId); err != nil {
		return err
	}
  
  	return nil
}

ER 图

回到顶部

领域模型

回到顶部

ER图

技术栈

编程语言：使用 Go 语言
数据存储：使用 MySQL + ClickHouse，MySQL 用来存储元数据，ClickHouse 用来实时分析统计数据
规则匹配：使用 expr, github地址: github.com/antonmedv/expr

不足

• 只有静态规则和统计规则，不支持多维度信息关联，比如用户修改密码后立即进行转账操作

• 规则阈值和风险等级的设定没有客观评价指标(需要人工风控经验，对各种场景的风控阈值和评分设置，需要长期不断的调整)

• 不支持对不同客户或不同业务线指定独立的规则集

• 实时性不够高,只能做事后风控(需要支持ms级的响应，及时给用户挽回损失，当前是事后告警(事前、事中、事后))

• 缺乏与AI风控技术的集成

• 缺乏分析系统(风控命中率、误判率)来衡量风控系统的表现

改进空间

• 需要使用实时计算框架，比如 Flink 等，提高实时统计分析的效率
• 需要利用并发机制提高规则匹配的效率
• 需要建立分析系统，衡量风控系统的表现，动态调整风控阈值
• 需要建立响应的 BI 看板