介绍

作为一款基于市场、面向消费者的应用，Uber 在其平台上遇到了多种欺诈来源。最常见的欺诈案例之一是，不法分子使用各种方法试图绕过 Uber 乘车、Eats 订单和其他服务（如 Uber for Business）的付款。当这种情况发生时，可能会发生交易失败，从而造成损失，影响在 Uber 上运营的司机和企业。

为了应对支付欺诈造成的严重财务影响，Uber 将风险管理列为首要任务。我们的工程师根据整个科技行业的风险解决方案状况，开发了复杂的解决方案，以实现以下目标：

检测欺诈：实时欺诈检测由运行在Uber 规则引擎Mastermind上的业务规则系统驱动。此外，机器学习模型会生成预测分数，从而深入了解用户是欺诈者的可能性。缓解欺诈： Uber 采用了不同形式的欺诈缓解措施，以根据触发的规则和超阈值分数采取相应措施并予以解决。这些措施既包括手动策略，也包括自动策略，这也是风险挑战发挥作用的地方。风险挑战

风险挑战是指要求用户完成某项任务或流程的体验，通常是为了验证其身份或付款方式的合法性。您可能以前遇到过风险挑战，而且不仅仅是在 Uber 应用程序中。一种常见的情况是在进行信用卡交易时输入信用卡的 CVV。

风险挑战的主要预期结果之一是有效地抓住坏人。这一点是不言而喻的：与对照组相比，遇到风险挑战的群体的欺诈率应该较低。然而，防止欺诈并不像向每个人介绍风险挑战那么简单。风险挑战的性质是高度个性化的。鉴于 Uber 的用户、产品和地域范围广泛，Uber 上遇到的风险挑战因用户而异。Uber 对用户旅程的不同阶段应用不同的风险挑战，世界不同地区的用户可能会遇到不同的风险挑战。让我们只考虑 Uber 应用程序中实施的一项风险挑战：一分钱一滴验证。

一分钱一滴验证

假设 Uber 收到一位用户的乘车请求，而该用户似乎不是该应用上使用的借记卡或信用卡的所有者。根据此 Uber 帐户的行为和数据，该特定用户很可能盗用了一张他们声称拥有并计划用于乘车的卡。

过去，Uber 会检测出极有可能是欺诈者的用户，并立即采取某些严格的措施，阻止他们继续与应用进行互动。在上述场景中，Uber 会拒绝乘车请求，在某些情况下还会限制相关付款和/或用户。

从表面上看，这似乎可以有效避免支付欺诈。然而，尽管实施了这种严格行动的策略，但显然它对潜在的误报用户来说并不理想。被限制访问的 Uber 用户需要联系客户服务来解决他们的状态，这通常是一个资源密集型的过程。

优步应用程序引入了“一分钱验证”功能，这是一种用户友好的方法，让之前可能被限制使用该应用程序的个人有机会证明自己拥有支付方式。在这项挑战中，用户需要向优步确认两笔小额随机授权保留金额，否则将在给定时间范围内到期。 成功完成表示用户可能是合法持卡人，而不是欺诈者。

图 1：向潜在风险用户发起禁令行动与风险挑战

技术概述

实施一分钱验证挑战的目的是，为使用信用卡或借记卡作为付款方式的用户提供一种有效且直观的欺诈缓解方法。我们可以总结如何通过以下设计原则实现这一目标，这些原则不仅适用于一分钱验证挑战，也适用于任何其他良好的风险挑战：

尽量减少误报：信任好用户（而不是坏用户）。欺诈者不应该能够通过这一挑战，而善意的用户应该能够在失败时自行解决并恢复。创造无缝且富有同理心的用户体验，并保持适度的摩擦：这是必要的，因为风险挑战的频率和程度与用户满意度和流失率之间可能存在权衡。例如，如果用户面临他们认为太难或太长而无法完成的风险挑战，他们可能会完全停止使用该应用。应避免令人沮丧的用户体验，同时不影响欺诈缓解。

以下屏幕截图展示了合法用户面临新的一分钱验证挑战的顺利路径。

图 2：一分钱一掷验证风险挑战的顺利路径流程

如图所示，挑战以一种不会严重干扰用户预期的主要操作（在本例中为请求乘车）的方式融入到移动用户体验中，通过清晰的说明和简单的操作。同时，“跳过”挑战是不可能的，因为被抛出挑战的用户必须完成挑战。即使用户在用户界面中退出已发起的挑战，挑战的状态仍将处于活动状态，并且如果用户尝试恢复相关操作，系统将不断提示用户完成挑战。

触发流程

如上所述，某些风险挑战是针对 Uber 应用程序上的某些用户旅程流程而设计的。在两个主要流程中可能会显示 Penny Drop 验证挑战：

当用户请求乘车或送货订单时当用户添加付款方式时

每次发生这些流程时，不会对每个用户都提出质询。相反，在启动这两个流程之一的情况下，会调用下游服务来获取与用户相关的功能并运行Mastermind中的风险规则。规则结果可能表明需要进一步的风险评估，特别是验证用户是否是特定支付方式的所有者。如果发生这种情况，后端服务会向移动端发送错误代码，以便用户遇到负责启动 Penny Drop 验证质询的移动屏幕。

图 3：风险挑战由用户操作发起，例如请求乘车

用户同意

在触发流程中，当 Penny Drop 验证挑战被视为必需时，系统会显示一个模式，让用户选择验证他们选择的卡。在某些情况下，用户可能已经同意挑战，但在成功完成挑战之前退出，因此他们必须重新同意。

如果用户选择切换到其他付款方式，则可能不会要求他们进行进一步验证。这是因为提出风险挑战的行为取决于用户的具体付款方式。通常，Uber 用户会在其帐户中添加多张卡，他们可能是也可能不是其中任何一张卡的合法所有者。同一用户的不同付款资料可以具有不同的挑战状态。

一旦用户点击“验证卡”，后端进程就会检查各种条件，以确定在其余的挑战流程中向用户显示什么客户端屏幕。首先需要确认与所选付款方式相关的数据（如其 UUID 和 Penny Drop 验证挑战的状态）已保存在Uber 的后端数据库Docstore中。如果该卡是全新的，则有关该卡的相关数据将首次写入 Docstore。

图 4：当用户同意风险挑战时，检查挑战条件

发送授权

在提供更多有关风险挑战信息的屏幕上，系统会提示用户发送授权保留。在电子交易和支付的总体背景下，授权保留是对一定数额的资金的临时保留；它们通常用于确定用户是否有足够的钱来完成交易，从而确定 Uber 是否能够从该用户那里收取付款。

用户点击“发送授权保留”后，将使用授权保留协议向用户指定的银行账户发放两笔小额资金。为了启动此过程，内部支付操作服务会向专门的“支付授权”服务发出请求，以创建两笔不同的授权。这是通过提供两个随机生成的要保留的金额以及指定的无效期限来实现的。

支付授权服务与支付网关或处理器交互，后者联系用户的银行或发卡机构，正式请求在用户的支付账户上设置指定金额的临时授权保留。如果指定的无效期限已过且资金保留已解除，而用户尚未成功验证金额以完成质询，则用户必须重新发送授权保留。

图 5：授权保留必须作为 Penny Drop 挑战的一部分发送

金额验证

为了成功完成“一分钱掉落”挑战，用户需要查看银行对账单，并在 Uber 应用程序中准确输入授权保留的确切金额。然后，这些输入的金额将接受验证。

在此过程中，用户的质询状态会在 Uber 的后端数据库 Docstore 中更新。如果用户在一定次数内未能成功验证授权保留金额，则质询失败。在这种情况下，他们对 Uber 应用的访问将受到限制，因为我们有强烈迹象表明他们不是付款方式的所有者。相比之下，如果用户成功完成质询，他们可以无缝地继续执行在被质询之前发起的预期操作。

图 6：必须正确验证授权保留金额才能通过 Penny Drop 挑战

结论

我们不断优化一分钱验证挑战的用户体验，以有效降低风险，同时又不会对用户体验造成太大影响。通过分析成功率和流失率等指标，我们不断根据用户如何应对挑战的洞察采取行动。

一分钱验证只是 Uber 应用程序中集成的一种风险挑战。其他挑战涉及不同程度的难度。根据我们对特定用户及其意图的了解，一种挑战可能被认为比另一种更好。总体而言，风险挑战是我们不断努力增强 Uber 应用程序的安全性和用户体验不可或缺的一部分。它的实施不仅有效地防止了欺诈，而且还带来了更流畅的用户体验，从而加快了 Uber for Business 等专业产品的入职速度。

致谢

感谢 Spender Risk 团队在我实习期间分享了一系列与欺诈相关的有趣的工程挑战（包括风险挑战）的专业知识。

特别感谢 Diganta Sarkar、Qixiong Liu 和 Susie Peng 提供与本博客相关的见解，以及 Neel Mouleeswaran 和 You Xu 对我作为软件工程师的实习和成长的支持。

作者:

Stephanie Yen

Stephanie Yen was a Software Engineering Intern on the Spender Risk Team at Uber during Summer 2023. She is studying Computer Science and Urban Studies at Princeton University, and is interested in the applications of technology in the realms of cities, media, and security.

出处:https://www.uber.com/en-JP/blog/stopping-uber-fraudsters-through-risk-challenges/