拉新补贴是代驾平台增长最快也最烧钱的模块，同时是黑产最集中的入口。三马代驾在补贴风控上迭代了三个版本，第一版只靠手机号黑名单，被薅到怀疑人生；现在跑的这版把设备、行为、资金三层闸门串起来，把绝大多数刷单挡在发钱之前。这篇把核心逻辑和代码摆出来。

所有规则都来自三马代驾线上在跑的风控服务。

对不上形态，规则写再多也没用：

三种形态在数据上的特征完全不同：自刷看"关系图"，团伙刷看"设备与轨迹"，串通刷看"资金流"。所以规则必须分层，指望一个模型通吃必然漏。

二、第一道闸：注册环节的设备指纹

三马代驾在注册和首单时采集设备特征，生成设备指纹：

public String buildDeviceFingerprint(DeviceInfo info) {
    String raw = StringUtils.join("|",
            info.getImei(), info.getAndroidId(),
            info.getScreenW() + "x" + info.getScreenH(),
            info.getDensity(), info.getSensorSignature(),
            info.isEmulator() ? "emu" : "real");
    return DigestUtil.md5Hex(raw);
}

（传感器特征向量）成本低但很难伪造，是识别模拟器和改机工具的主力。指纹落库后立刻做两件事：

// 1. 同设备账号数超限直接拒绝
long cnt = deviceAccountMapper.countByFingerprint(fp);
if (cnt >= MAX_ACCOUNT_PER_DEVICE) {
    throw new RiskedException("设备异常");
}
// 2. 新注册设备打标，首周补贴额度单独收紧
riskFlagService.mark(fp, "NEW_DEVICE", 7, TimeUnit.DAYS);

一个设备最多几个账号、新设备首周额度上限

，这两条朴素规则就拦掉了大部分设备农场。

三、第二道闸：行程真实性校验

补贴发放前对行程做体检，三个维度：

public boolean tripLooksFake(OrderTrip trip) {
    // 1. 速度异常：平均速度超过城市上限，必是假轨迹
    if (trip.getAvgSpeed() > CITY_SPEED_LIMIT) return true;
    // 2. 轨迹与路网匹配度过低：没有沿着真实道路走
    if (trip.getRoadMatchRate() < 0.85) return true;
    // 3. 起终点高度重合的短单，特征类似自刷
    Distance d = DistanceUtils.between(trip.getStart(), trip.getEnd());
    if (d.getMeters() < 500 && trip.getDuration() < 60) return true;
    return false;
}

路网匹配用的是离线地图数据算的匹配率，不是简单直线距离。假轨迹常见两种画法：直线匀速（速度异常抓得住）和沿主干道来回折返（路网匹配率抓得住），两者互补。

，转人工或二次校验，避免误伤正常用户。

四、第三道闸：行为序列与关系图

单笔行程都正常、但整体模式异常的，靠序列规则兜底：

-- 同一设备/同一路线短期内高频领券
SELECT route_hash, COUNT(*) AS c, COUNT(DISTINCT driver_id) AS d
FROM order_trip
WHERE create_time > NOW() - INTERVAL 1 DAY
GROUP BY route_hash
HAVING c > 20 AND d <= 3;

同一段"起终点组合"一天出现 20 次以上、且只来自 3 个以内的司机，基本就是固定演员在跑循环单。

司机与乘客的绑定关系也进图：

一个乘客 ID 近 30 天只坐过同一个司机的车

，正常业务里概率极低，这种边在图里会被标灰，双方补贴额度一起降级。

五、发钱前的最后一道：补贴限额与延迟到账

规则算完还要落到钱上，三马代驾的策略是"限额 + 延迟"：

BigDecimal calcSubsidy(RiskContext ctx) {
    BigDecimal base = ruleEngine.calc(ctx);
    // 风险分越高，系数越低
    double factor = ctx.getRiskScore() >= 80 ? 0.0
                  : ctx.getRiskScore() >= 60 ? 0.3 : 1.0;
    BigDecimal amount = base.multiply(BigDecimal.valueOf(factor));
    // 单司机单日补贴封顶
    BigDecimal todayGot = subsidyFlowService.todaySum(ctx.getDriverId());
    amount = amount.min(DAILY_CAP.subtract(todayGot)).max(BigDecimal.ZERO);
    // 高风险补贴延迟 48 小时到账，给风控留复核窗口
    if (ctx.getRiskScore() >= 60) {
        subsidyService.delayPay(ctx, amount, 48, TimeUnit.HOURS);
    }
    return amount;
}

三个动作各自解决一类问题：系数压低让刷子的边际收益趋近于零；日封顶控制单点损失上限；延迟 48 小时给人工复核留窗口，确认没问题再放款，有问题直接冻结，钱还没出去。

六、命中之后：名单沉淀与申诉回流

风控不是一锤子买卖，命中结果要回流：

第三条最容易被忽略。早期三马代驾只封不放，误伤一个真司机就是一条差评，申诉回流上线后客诉量降了一大截——

风控的体验成本和漏过成本必须一起算

补贴风控本质是把"发钱"这个动作拆成注册、行程、行为、资金四层检查，每层只解决自己擅长的那类作弊，再用限额和延迟把残余风险的损失锁死。规则会过时，但分层闸门的骨架可以一直用。

三马代驾实战（四）：补贴风控三道闸，设备指纹、行程体检与限额延迟到账

补贴是代驾平台被黑产盯得最紧的入口，本文拆解三马代驾的三道风控闸门：注册环节的设备指纹限号、发钱前的行程真实性体检、以及风险分联动的限额与延迟到账，附线上规则实现。

安全

后端

架构设计

三马代驾补贴风控实战：通过设备指纹、轨迹校验、行为序列三层闸门识别自刷、团伙刷、串通刷，配合限额与延迟到账策略拦截黑产，并沉淀黑名单、白名单回流机制，兼顾风控与体验，有效降低客诉。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

三马代驾实战（四）：补贴风控三道闸，设备指纹、行程体检与限额延迟到账

三马代驾实战（四）：补贴风控三道闸，设备指纹、行程体检与限额延迟到账

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐