资金风控之间的那点事-延迟结算单
资金风控之间的那点事-延迟结算单
奔向蔚蓝的深坑 发表于5个月前
资金风控之间的那点事-延迟结算单
  • 发表于 5个月前
  • 阅读 70
  • 收藏 0
  • 点赞 0
  • 评论 0

标题:腾讯云 新注册用户域名抢购1元起>>>   

        出于种种原因,延迟结算、交易冻结……状态存储在了“资金系统”。从此便开始了一段资金与风控间博弈的趣事。
        某日某人提出要把节假日的风险识别批处理,作出挽损操作。其中就提出了要对日终风险商户进行延迟结算单。因为处罚中心神一样的存在,这点需求看上去根本不叫个事。不就是发现风险商户通过“处罚中心”调用一下资金接口么。soeasy。如果这样想,那你是真的没有喝过深水井的水啊。那叫一个甜!
        在支付这个行业为了创造GMV,我们将结算开发出了多种不同的业务。T+0、假日付、秒到…… 目的很明显,因为我们需要利润。只要受众在使用产品时候方便放心,我们的利润就来了。然而就在利润的背后也充斥着 贷记卡拒付、磁条卡盗刷、黑产与商户勾结等令人不齿的违法犯罪行为。这也是我们为什么一定要及时发现风险后,迅速进行风控的原因。也是这一次升级优化的推手。
资金系统因为其业务特性,结算任务采用定时批处理的方式来进行。在正式结算出款之前,其会根据用户的结算产品、风控,决定是否生成结算单。
        所以能够影响资金结算的条件有两个方面,1商户自身属性、2风控情况;也就是在这个时候业务上的耦合就出现了。
        风控的日终风险商户是每天进行全量商户批处理。按照理想化的剧情发展,我发现风险必然要上报“处罚中心”,再由“处罚中心”依规则对应的处罚信息。执行处罚措施。假如此时配置了“延迟结算单”,那么按照剧情的需要,处罚中心必然要去调用资金的相关接口。也就是这个时候问题就暴露出来了。问题如下。
        1. 假设处于假日期间,资金会根据其结算业务特性,对普通商户不予结算。根本没有结算单,如果此时风险商户被捕获,是无法进行有效控制。
        2. 强行调用。会出现“处罚中心”调用资金某接口失败。最后会因为处罚中心自检机制,而入接口调用失败监控队列。(在没有专人跟进的情况下等同于,任其自由)
        3. 如果风控妥协,在日终风险批次上与“结算”进行适配,那么无疑“结算”强势侵入的风控系统。待其调整结算产品,风控则需要一并升级。手拉手一起跳井了。从服务化划分的角度来看,此事这么做也甚是不妥。完全打破了垂直划分解耦的初衷、限制了系统扩展的能力、断送了迭代的基础。反之,如结算妥协亦然。
        通过上述,归纳影响功能升级的点有两个:1、业务特性不同导致“处罚”无法妥善的处理。2、简单暴力处理造成系统耦合。

处罚中心异常监控队列
        此时需要冷静下来,解决这个问题。根据业务特性,决定采用异步处理,但要保证最终一致性、及时性(发生在结算验证风控环节)、性能、扩展、迭代……
        码字好辛苦……上图!
技术设计示意
        从上图的设计上来看,风控90%摆脱结算的侵入。结算的功能也变得更加聚合。从而双方友好的进行了解耦。
        同时因为永久代的缓冲区(数据量不过1000/日),也为结算带来了性能上的提升。避免了在跑批时频繁调用风控验证的情况。
        也避免了风控开放平台负载峰值过高。
        缺陷在于风控的日终批处理要赶在结算批处理之前完成。某种程度上也算是耦合。

        虽然最后因为 时间、成本……等问题,采用暴力解决的方式进行实施。但我觉得还是有必要记录下。毕竟在技术设计的环节上废了不少心思。唯有“用心”不可辜负!

第一篇博客,写了写工作中遇到的小事。如时间允许,我会尽量多酝酿些技术方面东西。 分享自己,利己利人!

 

 

 

 

 

共有 人打赏支持
粉丝 0
博文 2
码字总数 2232
×
奔向蔚蓝的深坑
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: