AI风控实验室
锁机什么时候按下去：从30天到60天，一套能对上监管的分阶段配合
做手机分期和租赁的人，最后都会撞上同一个问题：锁机到底该在第几天按下去？
按早了，客户投诉、监管问责、口碑崩；按晚了，机器已经被刷机转卖，或者客户干脆不用了，锁也没意义。绝大多数团队的做法是”看自己数据调阈值”——跑一段时间，看回收率，再调松紧。这在没有监管的市场行得通，在有监管的市场，调来调去最后撞上的是法条。
2026 年这一轮，印度把这件事写成了硬时限。这篇文章不聊概念，只讲两件事：一条已经落地的法定时间线长什么样，以及为什么它其实给了一个很好用的分阶段框架。
先把法定那套摆出来
印度储备银行（RBI）2026 年 8 月 6 日发布《商业银行——负责任经营行为（第四次修订）指引》（Reserve Bank of India (Commercial Banks—Responsible Business Conduct) Fourth Amendment Directions, 2026），2027 年 1 月 1 日生效。适用对象包括商业银行（不含小型金融银行、支付银行、区域农村银行、本地银行、城市合作银行、农村合作银行）、全印金融机构、非银行金融公司（NBFC）和住房金融公司。
这套规则的核心是一句话：原则上禁止把设备锁作为催收工具，唯一的例外是这台设备本身是用这笔贷款买的。
例外不是自动成立的，要同时满足四个条件：
- 贷款合同里明确且无歧义地授权这一机制，并写清操作流程；
- 借款人收到关于欠款和拟采取措施的通知；
- 全面限制只能在贷款逾期满 60 天后才生效；
- 在可获得的前提下，取得设备制造商或操作系统平台的认证（这条主要针对厂商级方案）。
然后是时间线，这是最值得抄的部分：
- 逾期满 30 天（30 dpd）之前：一步都不能动。 早期催收阶段的设备限制统统不行。只能靠提醒、外呼、短信——常规手段。
- 满 30 天、且借款人收到通知后仍未付款：可以开始”逐步”限制。 注意是逐步，不是一次性停用。
- 满 60 天：合同授权的全部限制才能生效。 这里有一条硬约束——外呼功能在满 60 天之前不能被限制。也就是说，客户还得能往外打电话，包括打给你投诉。
- 任何阶段都不能动的：来电、短信、紧急 SOS 功能。不能影响借款人正常工作或就业相关活动。借款人有权查看自己设备当前被施加了哪些限制。
- 还清欠款后 1 小时内必须解除限制。 错了或者拖了，按每小时 ₹250 赔付，赔付上限是这笔贷款实发金额。
- 个人数据一律不能碰。 通讯录、短信、通话记录、照片、位置历史——用于催收或其他任何目的都禁止，外包给技术服务商也一样禁止。
- 全额还清后，必须及时放弃对设备限制技术的控制权；借款人要求卸载的，要提供操作说明。借款人保留随时部分或全额提前还款的权利。
政策落地时间是 2027 年 1 月 1 日，距离现在不到两个月。用这套规则的企业现在就得把系统改完。
有个细节值得注意：在草案阶段（2026 年年初的两版草案），RBI 提的门槛是”逾期 90 天”，还配了两段通知——60 天发第一份通知给 21 天补救期，之后再发第二份给 7 天。定稿把门槛降到了 30 天起限、60 天全限。 从 90 天到 60 天，方向是收紧，但把”逐步”这个动作正式写进了流程——这对做产品的人来说，反而给了明确的中间档。
所以这 30 天到 60 天，能切出几档
把监管的时间轴当成骨架，中间是可以自己填的。一个能跑的结构大致是这样：
第 0—7 天：只做提醒，不碰设备。
到期前推、到期当天推、逾期第 3 天推。渠道按成本排：App 内消息 → 短信 → Push → 外呼。这个阶段的动作重点不是催，是确认人还在——手机是否还在客户手上、SIM 是否还是原卡、设备是否被恢复出厂设置。这组数据决定后面要不要按锁。
第 8—30 天：软提醒 + 状态标黄。
这个阶段可以开始用”看得见的压力”，但不要用功能限制。能做的：
- 还款入口置顶、逾期费用明示；
- 设备端弹窗提示（不阻断使用）；
- 记录客户承诺还款日（PTP），到点自动核销；
- 对高风险行为（换 SIM、多次尝试卸载管理组件、恢复出厂）打标记并升优先级。
第 31—60 天：逐步限制，对应监管的”gradual approach”。
这是唯一有腾挪空间的窗口。能做的是从非核心功能开始：应用商店、后台数据同步、非必要后台服务、部分第三方 App 启动。来电、短信、SOS、外呼一律不动——这条在印度是硬规定，在其他市场也是投诉高发点，动了必挨罚。
这个阶段有个容易犯的错：把”逐步”理解成”按百分比调低性能”。实际上借款人感知最强的不是性能，是能不能用。所以逐步的正确切法应该按功能重要性走，而不是按资源占用走。
第 61 天以后：全部限制生效。
外呼在这一档才允许限制。同时这个阶段要把处置决策摆上台面：继续锁着等、走法律程序、还是核销认损。
回款瞬间：1 小时内解锁。
印度写的是 1 小时硬时限，错一次 ₹250/小时。其他市场没这么严，但这个 1 小时其实是给自己设的技术指标——很多投诉不是因为锁了，是因为”钱付了机器还锁着”。真正要做到 1 小时内解除，需要的是付款回调和解锁指令在同一条链路上，而不是”客服接到单再手动解”。
已经在跑的玩家怎么做的
看几个真实产品的做法，能看出分阶段这件事在实操里的差异。
M-KOPA（肯尼亚，CBK 持牌）走的是激活窗口制：手机内嵌软件的激活窗口按时续期，每笔按期付款续一次窗口，窗口过期设备停用。付满全款才永久解锁。这个机制下，”分阶段”其实是隐含的——停用的是窗口过期那一刻，不是”第几天”。它的解锁流程是：付款 → 账户到账 → 收到解锁码短信 → 在锁屏或配套 App 输入 → 必要时重启。三十天内没收到解锁码，基本可以判断是付款没入账（最常见原因是 M-PESA 上输入的账号和 M-KOPA 档案不一致），而不是设备问题。
顺带一个值得记的信息：M-KOPA 在 2026 年 3 月以约 800 万美元（约 10.4 亿肯尼亚先令）现金加股权，收购了芬兰软件公司 KilpiTek 100% 有表决权股份——就是给 M-KOPA 提供远程设备锁定技术的那家公司。把锁机技术供应商直接买下来，这说明头部玩家对这套能力的定位不是”外包催收工具”，是核心资产。
Safaricom 的 Lipa Mdogo Mdogo按公开条款，是逾期第 4 天锁机。这个节奏明显比 M-KOPA 激进，但它做的是低端 Android/KaiOS 设备，客单价低、单机风险敞口小，赔付容忍度完全不同。
PayJoy在南非的做法是 3 / 6 / 9 个月合约，支付间隔可选 7、14、21、30 天。它的机制是”付多少解锁多久”——付款金额决定设备解锁到下一个到期日之前。欠付即锁，付款后一般不需要人工介入就能恢复。它也明确表示即使严重逾期也不做物理回收。
还有一组可以拿来对标的底数：肯尼亚统计局（KNBS）2024 年 FinAccess 家庭调查显示，使用 Lipa polepole 类（先付后用）服务的人数从 2021 年的 579,242 人涨到 2024 年的 1,751,994 人，三年翻了三倍。这个市场的规模，已经撑得起把分阶段做精细化。
三个实操判断
第一，”锁”不是催收动作，是处置动作。
它的位置应该在催收之后、法律程序之前，作为一个中间档。如果把锁当成第三天就按的提醒工具，就变成了用设备当人质要钱——这正是印度这次要禁的东西。反过来，如果拖到九十天才锁，机器可能早被处理掉了。30 到 60 天这个区间，恰恰是设备还在、人还有还款意愿的窗口。
第二，软锁的成本比硬锁低一个数量级，效果差不了太多。
硬锁的代价是全部投诉风险，收益是”逼还款”。软锁（限商店、限部分 App、弹窗）的代价小得多，很多客户在这个阶段就付了。真正需要硬锁的是那批已经打算放弃设备的人，占比通常不高。所以合理的资源分配是：把钱花在识别”哪批人会走到硬锁”，而不是花在把硬锁做得更狠。
第三，解锁速度是品牌资产，不是运营成本。
印度用 ₹250/小时把它变成了财务成本，但即使没有这条规定，1 小时解锁和 24 小时解锁的差别，决定的是这个客户下次还借不借、还不还推荐给别人。系统设计上唯一要保证的是：付款回调和解锁指令不能断链。这一条做不到，前面所有分阶段设计都会被”钱付了还锁着”这一条投诉吃掉。
落地清单
如果现在要按这个框架改系统，最小改动集是：
- 在设备端把限制拆成功能级开关（而不是整机开关），至少分出：商店、后台服务、第三方 App、外呼、来电短信 SOS（最后这组永远是只读不可动）；
- 把 DPD 作为限制策略的唯一主键，30 天前策略表全部为空；
- 通知模板与 DPD 绑定：30 天档一份、60 天档一份，内容要写明”将要限制什么、什么时候开始、还清后多久解除”；
- 付款回调直连解锁指令，设 1 小时超时告警；
- 记录每次限制的施加与解除时间戳，保留期按当地要求（印度要求催收通话录音留存 6 个月，设备限制记录同理宜长不宜短）；
- 内部设一条独立申诉通道，专门处理”解锁”相关投诉——印度把它写成了强制机制，其他市场照做也没坏处。
最后一句：这套东西的价值不在”锁得住”，在”锁得可解释”。能把每一次限制讲清楚是哪天、因为什么、依据合同哪一条、什么时候解除，就够了。
