Accertify

这套系统只干两件事:机器先判一遍,判不准的派给人看,人看完的结论回流成下一轮规则的依据。下面分四部分——谁在操作、产品由哪些模块构成、评分卡怎么配怎么算、我方复刻还缺什么。

4条主操作流
12个产品模块
1,133条在跑的规则
2条执行通道

第一部分

操作流

四条流构成一个闭环:机器判 → 人补判 → 争议兜底 → 策略回调。

① 机器自动判 实时 / 批量两通道 自动通过 人工复核队列 自动拒绝 ② 坐席审单 认领 → 判定 → 结案 ③ 拒付争议 数周后回来 · 独立队列 数周后 ④ 策略岗调因子与分值 看报表 → 统计定分 → 审批上线 因子与分值回灌
关键是左下那条回流线:坐席的每次判定都是标签,报表把它变成下一轮的分值。
1.1

一笔交易进来,到出结论

系统
结果只有三种:放行、拒绝、交给人看。但不是所有规则都打分:评分卡只是流水线中间的一段。
  1. 数据进来 实时通道(下单时同步拦截)或批量通道(文件 / SFTP 事后跑)。
  2. 落到一张宽表 所有判断都基于这张表的字段,没有的字段就判不了。
  3. 加工数据 清洗格式,调外部服务补地理位置、设备指纹、邮箱画像等。不打分。
  4. 一票定案 白名单会员直接放行、命中制裁名单直接拒绝,不看分数。
  5. 评分卡加减分 其余因子逐个检查,命中加减分,也可能跳过或提前结束。
  6. 按分数线分三档 自动通过 / 人工复核 / 自动拒绝。
  7. 执行动作 派进队列、写黑名单、发邮件、出文书。进哪个队列由动作规则决定,分数只决定队列里谁排前面。

规则分五类,只有一类打分

类别打分?干什么
评分类打分命中加减分,组成评分卡(见第三部分)
一票定案类不打分命中直接出结论;自带测试 / 生产开关
数据加工类不打分打分前准备数据
动作类不打分派队列、写名单、发邮件、出文书、发起扣款
流程控制类不打分调用另一张评分卡、中途结算分数

跨客户共享的黑名单(ARID)被刻意限定为只能加分、不能一票定案:别家客户标记的数据,误判率不受自己控制。

两个实用做法 ① 外部服务按调用收费,先用免费条件筛,再对剩下的调付费服务。
② 新记录先进 OTHER 队列再分发,过了中午 OTHER 还有存量就说明出问题了,可直接借鉴。
1.2

审一单

风控坐席
坐席给机器判不准的单做最终裁决,一单同一时间只归一个人。
  1. 进队列 按收单方、卡组织等筛选,可存成常用视图。
  2. 点开即认领 不处理要手动还回队列,否则一直挂在自己名下。
  3. 看命中了什么 面板列出命中的因子和各自分数,加上订单、设备、名单信息。
  4. 下结论 接受 / 拒绝 / 转跟进,结论写回交易,用于统计误杀漏放。
  5. 结案后约 15 分钟才搜得到 后台异步处理。
影子因子 可以设成「后台照常记录、不给坐席看」:新因子先在生产静默跑,验证有效再正式启用。
1.3

处理一笔拒付(Chargeback)

拒付专员
拒付(Chargeback)是独立的一张表,有自己的队列和结案动作。时效第一:过了回复期限就没法申诉。
  1. 按到期日排序 先处理快到期的,点开即认领。
  2. 关联原始订单 自动关联;关不上就手工填订单号,或上传订单证明。
  3. 查关联争议 按卡号搜,同卡、拆单产生的多笔争议一眼可见,可批量处理。
  4. 备材料 上传证据、写说明、填真实争议原因。
  5. 结案三选一 认赔 / 应诉 / 已无法申诉。
  6. 自动出应诉材料 选应诉后,系统自动填好文档、组装成材料包,经传真、人工上传或 SFTP 发给收单方。
两个注意点 ① 银行给的争议理由和人工填的真实原因是两个字段,做报表要分开统计。
② 批量加文档、复制字段后即使取消结案也不会回滚。

对照我方:我们现在人工下载材料、去 Provider 端手动提交,等于 Accertify 三种投递方式中的「人工上传」,这一步不落后。差距在投递之前的自动填充与组装,这是最小增量的演进方向。

1.4

上线一个新因子

策略岗
改完不会直接生效,要经过验证 → 回溯 → 审批。
  1. 新建或复制一个改 官方推荐复制:「账单国 = 收货国」复制一份,改成「≠」。
  2. 用一笔真实交易验证 看是否按预期命中。
  3. 放进评分卡 配三样:顺序、分数、命中后怎么办。
  4. 回溯 拿历史交易跑一遍,看误杀和漏放。
  5. 提交审批 批准前线上版本不动,批准后整体切换。
  6. 上线后看报表 效果数据喂给下一轮,重新定分。
两个容易出事故的点 ① 停用因子不要直接设成停用,会让整张评分卡卡死;应从评分卡移除或把分数改成 0。
② 回溯历史数据时,频次因子的时间基准要从「导入时间」改成「订单时间」,否则结果全错。

第二部分

产品架构模块

十二个模块,分四层。前三层是业务链路,第四层横切支撑。

接入 数据接入 · 虚拟表 外部数据服务 名单与共享情报 判断 规则引擎 评分与阈值 策略直决 模型概率 作业 队列与分派 案件工作台 拒付管理 支撑 报表与度量 测试与回溯 治理与审批 层级与计费 支撑层横切前三层:任何一层的对象都受层级、权限、审批和计费约束,且都能被测试与度量。
业务链路是竖着走的:数据进来 → 判断 → 派给人做。支撑层不在链路上,但决定了这套系统能不能被一个团队长期维护——尤其是治理与回溯这两块,是自建时最容易漏掉的。
·

十二个模块

01 · 接入数据接入

把不同来源、不同格式的交易统一成一张可供判断的宽表。两条通道:实时同步返回、批量事后处理。

虚拟表 · 掩码 · 导入器
02 · 接入外部数据服务

补充本方没有的信息。地理位置校验、信用卡验证、设备指纹、邮箱画像、高危地址库。按调用计费。

Service 规则 · Billing Event
03 · 接入名单与共享情报

记住已知的坏人与好人。负面表拦截、正面表放行;另有跨客户共享的情报库,但只影响分数,不单独定生死。

负面表 · 正面表 · ARID 共享库
04 · 判断规则引擎

系统的心脏。三类能力平级存在:判断(比大小、查名单、算频次)、加工(补字段、拼派生列)、动作(派队列、写名单、发信、出文书、发起支付)。

规则 · 规则集
05 · 判断评分与阈值

把一堆命中结果压成一个可排序的数字,再切成三档:自动通过、人工复核、自动拒绝。

分值 · 阈值 · 建议
06 · 判断策略直决

某些结论不需要算分。白名单会员直接放、命中某条硬规则直接拒。命中即定案,绕过评分,且自带测试/生产开关。

Policy 规则 · Test/Production
07 · 判断模型概率

用跨商户的正负样本训练出的概率分,作为一列数据参与规则判断——模型不直接做决定,只提供输入。

Accertify Index · 模型概率
08 · 作业队列与分派

决定哪些单给谁看、按什么顺序。支持按业务维度分组、自定义筛选并保存视图、认领与归还、跟进队列。

队列 · 认领 · followup
09 · 作业案件工作台

坐席看单和下结论的地方。面板化组织,布局按团队可配——不同角色看到的字段可以不同。

交易详情 · Rules Tripped 面板
10 · 作业拒付管理

争议的全生命周期。独立的表与队列、与原始订单关联、批量处理关联争议、应诉文书自动填充与组装投递。

拒付表 · 原单关联 · 文书三件套
11 · 支撑报表与度量

每条规则命中了多少次、误杀多少、漏放多少。这是权重能被科学调整的前提。

规则命中报表 · 误杀/漏放
12 · 支撑测试 · 治理 · 层级

上线前用真实交易验、沙箱跑、历史数据回溯;改动要审批、留版本;所有对象挂在租户层级树上,决定作用范围、权限与计费。

沙箱 · 审批流 · 层级树
·

模块之间最该记住的三条关系

  1. 规则库和评分卡是两个东西 规则只定义「怎么判断」,分值配在评分卡里。同一条「高风险国家」规则,在信用卡业务的评分卡里可以值 5,000 分,在钱包充值的评分卡里值 2,000 分。调权重是改评分卡,不是改规则。
  2. 加工类规则和判断类规则平级 因为评分前数据必须先「建」出来。要比对账单地址和收货地址,得先调服务把两个地址补齐、格式化。所以规则引擎不只是判断器,也是数据加工管道。
  3. 动作也是规则 派队列、写名单、发邮件、生成文书、甚至发起扣款,都是规则类型。这意味着运营动作可以被配置,而不是写死在代码里。

第三部分

风控评分逻辑

打个比方:给一笔交易打「可疑分」,就像老师批卷子。因子是一道道题,评分卡是试卷,分数线决定放行、人工还是拒绝。

3.1

因子:要检查的一个个风险点

一个因子只回答一个问题:这笔交易有没有这个风险点?答案只有「有」或「没有」。因子本身不带分数,分数在评分卡上配。

因子分四类

类别问的是什么例子
比大小某个值是否越界金额 > $500;账单国 ≠ 收货国
查名单在不在黑 / 白名单里这个 IP 在黑名单里;这个会员在白名单里
算频次一段时间内发生了几次、累计多少同一张卡 24 小时刷了几次;同一 IP 一天换了几张卡
查表按取值落在哪一档国家属于哪个风险等级;金额落在哪个区间

「算频次」最值钱:单看一笔看不出问题,放到时间线上才露馅。比如同一个手机号注册了 5 个账户,每个账户单独看都正常。

名单的「置信度」

名单里每条记录都带一个 1–9 的置信度,表示有多确定它是坏的:人工确认的欺诈者标 9,系统自动拉黑、还没人核实的标低一点。置信度不参与乘法,每个档位算一个独立因子,各配各的分(例如「黑名单 · 置信度 9」+3,000,「黑名单 · 置信度 5」+1,000)。这样系统自己猜的和人确认过的,不会被同等对待。

3.2

评分卡:按因子配分,有先后顺序

评分卡 = 一张按顺序排好的因子清单,每个因子配上「命中加 / 减几分」和「命中后接着干什么」,从上往下逐个检查。
顺序因子命中加减分命中后
10白名单会员—直接放行,后面不再检查
20高风险国家+500继续
30IP 在黑名单(置信度 9)+3,000跳到第 60 项
40同卡 24 小时刷超 3 次+800继续
50老客户(注册超 2 年)−1,000继续
60结束——

顺序号按 10 递增,方便以后往中间插新因子。

顺序为什么重要

如果只是加减,先算后算结果一样。顺序起作用,是因为每一项可以决定后面还要不要继续检查:

  • 提前结束——白名单会员排第一,命中就放行,后面的加分项根本不会检查。
  • 跳过——命中某个重大风险后跳到结尾,省掉中间的检查。
  • 中途看分——跑到一半先结算一次,后面可以写「分数超过 40,000 才去调付费验证服务」,低风险的单就不花这笔钱。

为什么分数配在评分卡上,不跟着因子走

因为同一个风险点,在不同业务里严重程度不一样。「账单国 ≠ 收货国」在跨境电商里很常见,给 100 分就够;在本地钱包充值里就很可疑,该给 2,000 分。一个因子可以放进多张评分卡,每张配不同的分。调分数只动评分卡。

两条铁律 ① 只能往后跳,不能往回跳,往回跳整张评分卡当场停止。
② 别把评分卡里的因子设成停用,检查到它会整张卡死。要停用就把它从评分卡里拿掉,或把分数改成 0。
3.3

分数怎么算:命中的因子加减起来

总分 = 起步分 + 命中因子的分数加减。可疑因子加分,可信因子(老客户、白名单)减分,没命中的算 0。只加减,不相乘,没有封顶。

示例:一笔 $2,000 的交易

起步分35,000每笔都有。定得高,是为了减分再多也不会变负数
高风险国家+500固定分:命中就加这么多
IP 在黑名单+3,000固定分
同卡刷了很多次+2,766变量分:次数越多,分越高
金额档+3,000按档给分:$2,000 落在最高档
合计44,266→ 自动拒绝

分数拿来干什么

  1. 划分数线 低分自动放行,中间交人工,高分自动拒绝。
  2. 决定先看哪单 人手有限,分高的先审。这其实是分数最常用的地方。
  3. 控制成本 中途看分,只对高分单调用付费的外部验证。

想表达「两个因子同时出现才特别危险」(比如大额 + 高风险国家)?加减做不到相乘,只能把两个因子合成一个新因子 AU|大额 单独配分,或者写脚本。

3.4

例外:一票定案的因子

有些因子不用算分:VIP 白名单会员直接放行,命中制裁名单直接拒绝。一命中就出结论,跳过整个加减分。

好比「作弊直接零分」,卷面得多少分都不看。这类因子还带一个测试 / 生产开关:先在测试状态下观察,确认没问题再切到生产才真正生效。

所以系统里同时有三种判断方式:模型给概率、评分卡给分数、一票定案的因子直接给结论,各管各的场景。

3.5

能做什么,做不到什么

想做的事能不能做怎么做
单个因子配分直接能做国家 → 分数,查表即可
一段时间内的次数、金额直接能做频次因子,时间窗从分钟到天可配
金额分 10 档能,但麻烦每档算一个因子,要配 10 个
两个因子交叉能,但要绕先合成一个新因子,再配分
更复杂的组合逻辑要写代码写脚本(Groovy / SQL)
一键批量调所有分数不能每个因子在各自的评分卡里单独改
3.6

每个因子给多少分,是谁定的

不是凭经验拍的,是用历史数据统计出来的。拿大量已知好单和坏单,算出哪些因子真正和欺诈相关、相关程度多大,据此配分;分数线也是用历史数据跑出来的。

这也解释了为什么只做加减:统计模型算出来的本来就是「每个因子各占多少分」,和银行信贷的评分卡是同一个思路。

光能配因子不够 想让这套东西真正跑起来,还得有两样:①足够多已经确认好坏的历史交易,用来算分;②能拿历史交易把新配置重新跑一遍,看效果变好还是变坏。缺了这两样,分数只能拍脑袋。

第四部分

复刻评分卡:还缺什么

以 Accertify 为标尺对照我方:因子库和回溯验证已有,其余六块需要新建。

4.1

评分卡要完整跑起来,需要哪几块

#模块干什么我方现状
①因子库定义要检查的风险点✅ 已有,部分上线,后续补齐
②评分卡配置把因子组装成评分卡❌ 没有
③执行与分档算总分、按分数线出结果❌ 没有
④命中明细留痕每笔交易记下命中了什么、各几分❌ 没有
⑤好坏标签回流交易最终是好单还是坏单❌ 没有
⑥定分支持给策略同学算分值的数据和工具❌ 没有
⑦回溯验证改动上线前看效果✅ 已有,复用灰度平台
⑧变更治理版本、审批、回滚❌ 没有
4.2

各模块怎么实现

① · 已有因子库
  • 因子只输出命中 / 未命中,不在因子上挂分值
  • 新增因子按比大小、查名单、算频次、查表四类归类
  • 每个因子给唯一编号,供评分卡引用
② · P0评分卡配置
  • 新建评分卡对象:选因子、配分值
  • 分值可正可负;支持固定分、按档查表(带兜底分)
  • 配置起步分和两条分数线,切出通过 / 人工 / 拒绝
  • 支持多张评分卡,按收单机构或大客户挂载
  • 单独配置一票定案因子,命中直接出结论
③ · P0执行与分档
  • 先跑一票定案因子,命中直接返回结论
  • 未定案的逐个检查评分卡因子,命中分值累加
  • 总分对照分数线,输出通过 / 人工 / 拒绝
  • 人工档推送案件管理,按分数从高到低排序
  • 二期再支持顺序、跳过、提前结束、中途看分
④ · P0命中明细留痕
  • 每笔存:评分卡版本、命中因子、各自分值、总分、结果
  • 坐席审单页展示命中明细,说明为什么被拦
  • 支持影子因子:后台记录命中,但不计分、不给坐席看
  • 按交易 ID 可查,作为统计和回溯的数据源
⑤ · P1好坏标签回流
  • 拒付(Chargeback)结果按交易 ID 关联回来,标为坏单
  • 接入卡组织欺诈报告(TC40 / SAFE),按交易关联
  • 坐席审核结论写回交易,作为人工标签
  • 人工建单通道(如 LatPay)在 Build 建单时必填原交易 ID
  • 超过拒付期限仍无争议的交易,自动标为好单
⑥ · P2定分支持
  • 宽表自助导出:交易 + 每个因子命中 + 最终标签
  • 因子效果报表:命中量、坏单率、误杀率
  • 策略同学在配置页录入分值,走审批上线
  • 早期标签不足时先专家拍分,再用回溯校验
⑦ · 已有回溯验证
  • 评分卡接入灰度平台,新旧版本并行,只记录不生效
  • 输出新旧版本三档比例和误杀 / 漏放对比
  • 如做历史重放,频次因子须按交易当时的时间点重算
⑧ · P3变更治理
  • 每次修改生成新版本,可对比差异、一键回滚
  • 修改须提交审批,批准前线上版本不变
  • 改因子逻辑时,自动列出引用它的评分卡一并送审
  • 记录修改人、时间、原因,满足审计留痕
4.3

建议优先级

阶段做什么目标
P0② 评分卡配置、③ 执行与分档、④ 命中明细留痕先跑起来,用专家拍的分
P1⑤ 标签回流;评分卡接入 ⑦ 灰度平台能验证分值好不好
P2⑥ 定分支持分值从拍脑袋变成统计得出
P3⑧ 变更治理;③ 的二期能力规模化后的可维护性