Summary

  • Twilio 的 Fraud Guard Promise 针对本应拦下却放行的短信泵流量，可能抵扣相应 Verify 与短信费用。客户须持续启用 Max Protection Mode，在发送月份结束后 30 天内提交工单，并通过 Twilio 审核。
  • 条款要求受影响号码没有启用 Verify Geo Permissions、Safe List 或 RiskCheck 参数。这些设置又是运营人员处理误拦的工具；真正决定抵扣资格的是当时的号码配置。

救一个验证码，动一张索赔单

短信验证码是登录入口，也是攻击者可以反复拉动的计费拉杆。短信泵流量把请求送往会产生费用的号码。Twilio 的 Fraud Guard 试图拦住这种流量；其 Promise 在系统漏拦本该识别的欺诈短信时，提供 Verify 和短信费用抵扣。钱不会因为仪表盘显示“节省”就自动回来。Twilio 要审核具体消息，并决定哪些费用符合条件。

保护档位是第一道门。官方文档把 Standard 列为默认档位，而抵扣条款要求 Fraud Guard 始终处于 Max Protection Mode。Max 拦得更积极；Twilio 同时说明，这一档偶尔会误拦正常用户。企业若为转化率降低拦截强度，便也离开了承诺要求的设置。产品团队与财务团队常在不同会议上做这两个决定，账单却只有一张。

第二道门更有意思。正常用户收不到验证码，运营人员可以把已知号码放进 Safe List，使 Fraud Guard 和 Geo 权限都不再阻挡它。可是 Promise 把 Safe List、Verify Geo Permissions 和 RiskCheck 参数列为受影响号码不能启用的“防误报功能”。给一个号码开白名单，并非宣告账户所有索赔都失效；条款看的是遭泵流量影响的号码。正因为范围具体，配置记录才不能只写“已开启 Fraud Guard”。

最后是日历。客户须在欺诈消息发送月份结束后 30 天内开支持工单，提供所需材料及 Twilio 追加要求的信息。Twilio 还要确认这些消息属于短信泵流量，且 Max 档本应拦截。替其他主体发送流量的账户、自定义验证码，也有额外条件。条款把这一抵扣设为 Promise 下的唯一救济。公开资料没有给出成功索赔比例或某客户损失。

真实争议还缺两样东西：受影响号码当时的设置和 Twilio 对消息的审核结论。企业现在能做的，是把保护档位、号码例外、单次请求覆盖、发送月份与工单时间放在同一份可追溯记录里。安全开关不应该只留在值班员的记忆中。

Sources