作者简介:小明java问道之路,专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码,就职于大型金融公司后端高级工程师,擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
热衷分享,喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家
如果此文还不错的话,还请关注、点赞、收藏三连支持一下博主~
前言
一、 资损防控系统设计资损防控规范
二、常见业务产品分析资损风险
三、常见业务产品分析资损防控点
四、业务参数调整资损风险
1、常见的业务参数调整资损风险
2、常见业务参数调整资损防控
总结
业务产品分析资损防控规范21业务产品分析支付公司的大部分业务都涉及到资金 的流转,对于每一笔的资金业务,往往既涉及信息流的变化,也会涉及资金流的变化。在我们做业务的需求分析设计的时候,如果和业务方未能理解一致或者分析不全,将会从业务源头上产生资损风险
从系统架构层面整体来看,支付公司的系统可以抽象为如下结构:
一、对外部商户提供收单服务类的系统
二、连通支付公司与各金融渠道的网关类系统
三、支付公司的内部业务处理系统
四、消息、调度等中间件系统
五、数据库、缓存等存储平台
从系统架构与业务架构上来讲,各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。
1、资金流、信息流、业务流等和理解和业务产品方不一致。
2、只分析了信息流的处理,遗漏了资金的处理,或遗漏了某些阶段的资金处理。比如基金类商户的出款类交易迁移的时候没有考虑商户不需要直正的出款。
3、资金需求中,对资金结算模式等理解不一致。比如退款成功的理解不一致;是退到商户户还是退到个人户的理解不一致。
4、业务产品设计的时候,部分支付产品充退接口设计不完整,尤其资金流设计不完整。执行充退逻辑时异常考虑不完备会有资损。
5、系统业务设计未能遵守先借记后贷记的原则。
6、业务缺少资金平衡检查。
7、正反交易资金流不一致容易资损。
8、内部户的使用不当。比如挂销机制不合理。
9、内部作业人员操作界面未设置合理的限制条件。如营销平台的卡券发放等。
1、需求分析中对信息流、资金流的分析要完整全面。业务需求中要包括完整的信息流和资金流(业务系统还需要包括相关的物流等业务流),不但要包括正向的完整描述,也要包括反向的描述;不但包括正常情况的描述也要包括异常情况下的处理描述。
2、业务迁移过程中,要梳理出新旧业务全面的信息、资金流流向。验证过程中,要核对业务信息、支付信息、渠道信息、银行账户流水信息等。
3、新支付产品需求分析的时候,要对支付产品的信息流和资金流做完整分析。有其是反向资金流。尤其是内部业务系统包装的渠道,尤其注意冲退逻辑的实现是否完备。
4、资金结算模式的理解。需求分析过程中,要与业务方梳理出清晰完整的资金结算模式形成双方认可的资金结算的流向图,流转到具体的资金账户。
5、业务设计的时候遵从先借记后贷记原则。
6、要保证正反交易的资金流向一致。对于正方交易资金流向不一致的场景(如冲退转代发部分支付产品冲退退余额),设计与系分的时候要着重评审,并重点测试验证。
7、收单、渠道、支付等系统都需要设计相关的资金平衡检查。如渠道冲退的金额不能大于原交易流水的金额、收单商户退款的金额不能大于可退金额等。
8、内部账户的使用。必须由业务方和运营财务人员沟通后申请,技术人员不可自行配制;要有挂销机制;要有相关的业务和技术核对机制。
9、内部作业系统设置合理的业务条件限制。不允许有无限制条件的输入输出。
如OMS查询可以限制为一个月;营销平台的卡券发放一个人可以设置上限1000个等
1、商户参数调整。业务自行调整合同业务参数影响其他收单商户。
2、渠道参数调整。
3、结算规则调整。
4、通过数据修订等方式进行业务参数调整。
1、可以验证的业务参数,需要在测试环境等验证过进行调整。
2、风险较大的业务参数调整的时候,可以通过限流等措施在产线上逐步开放。
3、系统在设计的时候,要避免可能引起业务作业人员误解的配置,避免商户间的串用、滥用、误用。
4、业务类参数的调整要平台化,不要通过数据修改等方式进行参数调整。
业务产品分析资损防控规范21业务产品分析支付公司的大部分业务都涉及到资金 的流转,对于每一笔的资金业务,往往既涉及信息流的变化,也会涉及资金流的变化。在我们做业务的需求分析设计的时候,如果和业务方未能理解一致或者分析不全,将会从业务源头上产生资损风险。