1 min read

支付风控:交易频次(Velocity)

Velocity 定义

Velocity(英/vəˈlɒsəti/,美/vəˈlɑːsəti/,ve–lo–ci–ty)重音在第二音节,即ve-LO-ci-ty;在支付风控场景中,Velocity指时间窗口内同一主体或要素的交易及行为次数、金额与变化速度,属于频率/速度类风控指标,对应的velocity rule/check/limit意为频率/速度规则、校验与限额,主要用于识别异常高频行为,应用场景包括卡片交易(如10分钟内刷卡笔数及金额)、设备操作(如1小时内绑卡及开户数)、账户行为(如24小时内登录、支付及修改密码次数)、IP操作(如5分钟内开户及支付请求数)等。

  1. 交易频率:10分钟内同一账户支付≥5笔→审核/验证;
  2. 金额速度:1小时内同一设备支付≥5000元且超历史均值3倍→提风险评分;
  3. 新增操作:1小时内同一账户绑新卡≥3张→阻断/复核;
  4. 跨要素频率:24小时内同一IP注册账户≥20个→拦截+灰名单;
  5. 行为异常:月均1笔小额消费用户,10分钟内10笔大额转账→判定异常。

一、早期纸质支付时代(19世纪前):无显式风控需求的技术背景

19世纪前,全球支付体系以现金、汇票、本票等纸质工具为核心,支付模式与当时的技术水平、社会结构深度绑定。工业革命前,商品贸易以区域化为主,跨地域交易频率低、金额有限,运输方式以马车、帆船为主,交易周期长达数周甚至数月。18世纪欧洲跨国贸易中,一张汇票从签发到清算需经过商人、银行家、代理人等多重环节,人工核验流程贯穿始终,天然限制交易频率。

社会结构层面,当时银行多为区域性机构,服务对象以本地商户、贵族为主,熟人社会特征明显。银行职员通过长期接触了解客户的交易习惯、信用状况,票据审核依赖签名比对、印章验证等人工手段,风险控制重点为票据真伪与信用违约,而非高频交易欺诈。纸质支付的低效率,使得短时间内集中作案缺乏技术可行性。

这一阶段风控缺失显式velocity概念,主要因技术条件与风险形态匹配:既无支撑高频交易的技术工具,也无相应欺诈场景,风险主要来自清算延迟、战争导致的票据失效等系统性问题。

二、银行卡与电子支付时代(20世纪中后期):技术创新催生初代velocity规则

20世纪中期,磁条技术发明(1950年代)、POS终端普及(1970年代)与信用卡产业崛起,改变了支付生态。磁条卡的可复制性、POS机的即时交易特性,使盗刷风险成为现实。1960年代美国信用卡盗刷案件呈增长趋势,盗卡者常通过复制磁条信息,在短时间内连续刷卡消费后逃逸。

技术层面,电子支付系统的自动化处理能力突破人工审核效率限制,单张银行卡日均交易次数提升,传统人工核验模式难以应对。监管层面,各国开始出台支付行业规范,如美国1970年《银行保密法》要求金融机构记录大额交易,但缺乏针对高频小额交易的监管工具,推动银行自主探索风控手段。

初代velocity规则在此背景下诞生:1974年,美国运通(American Express)首次推出一段时间内累计交易金额上限规则,随后花旗银行跟进设置短时高频异地交易拦截规则。这些规则未明确使用velocity术语,但已具备时间窗口+行为频率的核心逻辑,是对电子支付技术带来的风险形态变革的应对。

三、网络支付与电商时代(1990s-2000s):场景扩张推动velocity体系化

1990年代互联网商业化普及,催生电商、跨境支付等新场景,支付行为从线下转移至线上,风险形态呈现多元化。卡不在场交易(CNP)成为主流,盗刷者无需持有实体卡片,仅通过获取卡号、有效期等信息即可完成支付,使异地高频盗刷更隐蔽。2000年全球在线支付欺诈损失中,70%来自短时间内的高频小额交易。

技术支撑方面,大数据存储与实时计算技术发展(如Hadoop分布式系统诞生),使银行能够同时监测海量用户的多维度行为数据(卡号、IP、设备等)。支付机构开始构建专门的欺诈监测系统,将velocity指标从单一的交易次数/金额,扩展至登录频率、绑卡频率、退款频率等多维度。1998年PayPal推出的风控系统,首次将IP+账户组合velocity作为核心监测指标,拦截大量撞库盗号引发的欺诈交易。

监管环境随之升级,欧盟2007年《支付服务指令》(PSD1)要求支付机构建立实时风险监测机制,明确将异常交易频率列为重点监测内容。这一政策推动velocity规则从行业自发实践上升为合规要求,成为支付机构的常规风控维度。

四、实时支付时代(2010s至今):技术升级与监管加压下的velocity迭代

21世纪10年代后,实时支付系统(FPS)在全球快速推广,核心特征为资金瞬时到账、7×24小时不间断服务,技术支撑源于实时清算系统与移动互联网普及。实时支付的技术革新,使欺诈风险呈现不可逆转性,资金一旦转账成功,追索难度较大,传统事后审核模式及时性不足。

风险形态变化推动监管政策收紧:2015年欧盟《支付服务指令修订版》(PSD2)要求支付机构实施强客户认证(SCA),并将velocity监测作为实时拦截的重要手段;中国人行2019年发布的《关于进一步加强支付结算管理防范电信网络新型违法犯罪有关事项的通知》,明确要求支付机构设置单日转账次数上限、新账户短时交易限额等velocity类规则。

行业实践中,velocity指标应用场景进一步扩展:反洗钱领域,通过监测同一账户短时间内向多个陌生账户转账的velocity特征,识别拆分交易、结构化洗钱行为;盗用风险控制中,利用同一IP短时间内发起海量支付请求的velocity数据,防范系统攻击引发的批量请求。

五、智能风控时代(2018年至今):技术迭代驱动velocity类模型

近年来,机器学习、图网络等技术成熟,推动支付风控从规则驱动转向模型驱动,velocity指标也从单一规则演进为多维度特征及模型。这一变革的技术基础是大数据处理能力提升,支付机构能够整合用户近年的行为数据,通过算法挖掘隐藏的风险模式,无需依赖人工预设的规则阈值。

单一维度velocity特征难以满足复杂欺诈场景需求,组合维度、相对变化速度、群体维度的velocity特征逐步应用:组合维度如卡号+设备的交叉监测,可识别盗刷者使用多卡在同一设备作案的行为;相对变化速度通过对比用户历史行为均值与群体均值,捕捉正常用户突然高频交易的异常信号;群体维度利用图网络技术,监测羊毛党、刷单团伙。

单一维度Velocity的识别盲区可通过多维度组合优化,结合用户行为画像、交易场景特征等补充判断,提升风控策略的精准度,是支付风控策略的重要工具。

六、Velocity加工与策略落地注意事项

Velocity指标的数据加工、代码实现、策略上线,是风控落地的关键环节。加工不规范会导致指标失效、策略误拦/漏拦。结合支付风控实操,核心注意事项如下:

1. 时间窗口定义严谨,区分Velocity与其他间隔类指标计算逻辑

  • Velocity采用滚动时间窗(如近10分钟、近1小时),统计窗口内累计行为次数/金额,属于连续频率指标;

  • 需明确区分Velocity与其他间隔类指标的计算逻辑,避免策略逻辑错位。

2. 数据清洗:剔除无效数据,保证样本纯净

  • 加工前需剔除测试交易、冲正交易、待核销数据、异常调试数据,未剔除无效数据会导致Velocity统计结果失真;长周期Velocity(如日级、周级、月级)需额外排除近期短窗口内的交易数据,因近期短窗口内可能存在集中欺诈交易,纳入统计会污染长周期指标,无法反映用户正常长期行为;

  • 同一主体的重复请求、失败请求需去重,避免虚增交易频率。

3. 核心注意点:避免信息穿越

  • Velocity计算仅能使用交易发生前的历史数据,应避免调用未来时间戳的数据、未生效的交易结果;
  • 代码编写时需严格校验时间逻辑,多次复核数据调用范围,信息穿越会导致指标失效,需重点规避这类问题。

4. 维度聚合逻辑统一,避免重复统计

  • 单一维度(账户/设备/IP/卡号)聚合需锁定唯一标识,组合维度(账户+设备、IP+卡号)需明确交叉规则;
  • 跨系统数据拼接时,需保证主体ID一致性,防止重复计数导致Velocity阈值误触发。

5. 离线加工与在线计算逻辑保持一致

  • 离线训练、调试的Velocity计算逻辑,需与在线实时计算的代码、参数、窗口保持一致;

  • 逻辑不一致会导致离线效果达标、线上策略失效,是策略落地的常见问题。

6. 阈值校准贴合业务,避免统一标准

  • 结合用户分层(新户/老户/白名单)、业务场景(消费/转账/绑卡)、时段(高峰/低谷)设置差异化阈值;
  • 结合多维度特征协同校准,避免单一Velocity阈值过严导致客诉、过松导致漏防。

7. 加工过程可回溯,留存校验日志

  • Velocity计算的窗口、数据范围、聚合结果需留痕存档,便于问题排查、策略复盘;
  • 关键代码变更需评审,多人复核后再上线,降低人为操作失误风险。

结语

从纸质支付时代的无显式风控,到数字支付时代的velocity模型,velocity风控的演进与支付技术、风险形态、监管政策的发展密切相关。技术革新提供监测高频行为的工具,风险形态变化催生风控需求,监管政策规范其应用。

实操层面,Velocity的数据加工规范性影响风控效果,把握时间窗口、数据清洗、信息穿越等核心规则,能让Velocity更好发挥支付风控作用。