押金收 30% 能扛住几期损失:一个覆盖率的算法
先给结论:押金 30% 大约能覆盖 2.9 期的租金损失,但这个数字只在设备能收回来的前提下成立。一旦设备收不回,押金覆盖率会从 100% 掉到 43.5% 左右。原因是押金覆盖的是「租金损失」,不是「本金损失」,这两者的量级差得很远,混着算会让风控敞口被严重低估。
先把覆盖率的定义定死
押金覆盖率等于押金除以出险时的净损失。关键是分母怎么定。多数人算的是「押金能顶几期租金」,分母取的是单期租金;但真实出险时分母是「采购价减去已收租金再减去能追回的东西」,这两个分母不是一回事。

用一笔具体账铺开。一台采购价 6000 元的机器,押金 30% 即 1800 元,租期 12 期,每期 620 元。客户在第 4 期出险——也就是前 3 期正常还了,第 4 期开始失联。
情形一:设备能收回来
先算乐观情形。设备通过管控手段收回,此时已收租金 3 期共 1860 元,设备残值按 3000 元计,回收处置成本(物流、验机、翻新)按 200 元计。
净损失等于采购价 6000 减已收 1860 减残值 3000 加处置成本 200,等于 1340 元。押金 1800 元,覆盖率 134%,押金不仅能覆盖,还有富余。这个情形下的结论是:只要设备能收回,30% 押金是够的。
这两种情形要分开记账,不能混成一个数。星皓易租的出险记录按设备是否收回分了两类,季末做敞口复算的时候,用两类各自的实际占比加权,比拍一个统一的覆盖率准得多。
情形二:设备收不回来
再算悲观情形,这也是实际风险敞口所在。设备收不回,残值 3000 元拿不到,处置成本也省了(但没有东西可处置)。
净损失等于 6000 减 1860 等于 4140 元。押金 1800 元,覆盖率等于 1800 除以 4140 等于 43.5%。剩下的 2340 元是净敞口,要靠催收、司法途径或者坏账计提消化。
这两种情形的覆盖率差了 90 个百分点,全部取决于设备能不能收回来——更准确地说,取决于设备在被管控、可定位的前提下能追回到什么程度。这就是为什么「押金能顶几期」这个算法危险:它默认了设备能收回。
「能顶几期」这个算法错在哪
用 1800 除以 620 得到 2.9 期,这个算式本身没错,错在它的含义被误读了。它算的是「押金相当于几期租金」,不是「押金能扛几期违约」。
底层逻辑是这样的:押金这道防线覆盖的是「租金损失」,不是「本金损失」。之所以这两个不能混为一谈,是因为租金是逐期流入的现金流,而损失是一次性暴露的本金缺口,两者量级差一个数量级。
区别在于:客户违约时你损失的不是后续的租金,而是设备本金减去已经收回的部分。租期越长,这个差额越大。所以租期越长,同样的押金比例覆盖率越低,而「能顶几期」这个算法完全体现不出这一点。
一个更贴近实际的算法
建议按出险期次分档算覆盖率,每档给一个敞口数字。以 12 期、押金 1800 元、设备收不回为前提:
第 1 期出险:已收 0 元,净损失 6000 元,覆盖率 30.0%
第 4 期出险:已收 1860 元,净损失 4140 元,覆盖率 43.5%
第 8 期出险:已收 4340 元,净损失 1660 元,覆盖率 108.4%
第 12 期出险:已收 6820 元,净损失为负,押金全额可退
这张表说明一件事:风险集中在前 6 期。第 8 期之后押金已经基本能覆盖,第 4 期前后是最脆弱的区间——客户已经过了最初的新鲜期,而本金还剩一大半没收回来。
所以风控资源应该往前压,而不是平均分配。前 6 期的提醒密度、行为信号监控频率,都应该是后半程的两倍以上。
三个常见误区
误区一:用「押金能顶几期」作为风控依据。它算的是租金换算,不是损失覆盖,两者在设备收不回时差 90 个百分点。
误区二:认为覆盖率是固定的。它随出险期次大幅变化,第 1 期 30%、第 8 期 108%,用一个平均值没有意义。
误区三:把免押当成少收押金。免押不是押金为零,是把押金换成了另一种担保形式,风险敞口的计算方式要跟着换。
两条边界
边界一:以上按设备收不回的极端情形算敞口,实际业务中回收率不会是零。用自己历史的实际回收率替换这个假设,算出来的覆盖率会更接近真实值。
边界二:押金比例受业务定位和客群结构影响明显,30% 是常见参考值不是标准值。免押产品的敞口要用信用担保的实际代偿率来算,不能套用押金的算式。
落地时按这五条做
把覆盖率算进日常风控,按这五步走:
按出险期次分档算覆盖率,至少分前中后三段,不要只算一个平均值
分别按「设备收回」和「设备收不回」两种情形各算一套,以后者作为敞口上限
找出覆盖率最低的那一档,把风控资源集中压在那里
每季度用实际回收率更新一次假设,覆盖率会随回收能力改善而上移
押金比例调整时,把新的覆盖率表同步给定价和进件两个环节,不要只改一个数
星皓易租的进件记录把押金金额、设备采购价、期次结构三项放在同一条记录里,就是为了能在进件那一刻就把各期覆盖率算出来,而不是等出险之后再倒推。敞口这种东西,事前算和事后算,意义完全不一样。
