一篇有关创建内部解决方案的文章，该解决方案用于检测和防止在tar斯坦的一家小型但非常自豪的银行的互联网银行中进行的欺诈交易。 您将从这篇文章中学习有关为什么以及谁需要反欺诈的知识，为什么内部开发比购买现成的解决方案便宜，以及在新年之前会产生几行代码。
关于您自己的几句话-一家IT公司的信息安全专家，偶然（或可能不是这样）竟然是反欺诈解决方案开发团队的产品负责人。 这家IT公司本身从事互联网银行软件的开发。
这一切是怎么开始的？
对于银行本身，这一切都始于俄罗斯联邦中央银行上载了第382-P号法规的修正案和增补草案，该草案称该银行应在未经客户同意的情况下阻止资金转移。 此外，根据俄罗斯银行2831-U的命令 ，该银行有义务向中央银行报告所有事件，包括欺诈者的行为。
对我而言，这个故事始于一个请求，该请求旨在帮助功能需求的形成以及与现有远程银行服务（以下简称RBS）集成的研究。 走开...
输入数据
在开发之前，有必要研究主题，研究现成的开发 耙子 浏览市场。
在研究期间，结果是：
- 从苏格兰皇家银行偷钱的最常见方法-社会工程和网络钓鱼
- 利用社会工程学，他们要么侵入银行系统，要么强迫客户自愿转移资金
- 欺诈者一年中偷走的金额不是很大，银行花在调查和赔偿上的金额约为该金额的10％
- 现成的反欺诈解决方案的成本超过参与欺诈的金额的5-10倍（关于整合语音的成本尚未消失...）
- 有必要向FinCERT报告，请确保
- 您可以突出几个非常常见和重要的案例
在分析反欺诈主题时， codezombie文章对我有很大帮助。 四年前，他撰写了有关电子商务中使用反欺诈的文章，并介绍了他的经验。 就我而言，具体情况有所不同，但这些信息非常有价值。
根据这些条件，决定将项目交给从事集成和解决其他团队问题的开发团队，因为该团队包括最有经验和最出色的开发人员。 不幸的是，随着时间的推移，在由3个开发人员组成的团队中，只剩下2个。 我参与了积压工作，需求的形成，文档的组织和会议的组织（我们在Scrum上工作，但还有其他方法）。 碰巧的是，团队中有4人编写了代码，而3位负责人解决了问题。
发生过的案件
不要以为银行没打过 与邪恶 与骗子。 用负担得起的手段战斗。 但是，存在与入侵RBS相关的事件数量开始增加的趋势。 2018年的一个流行计划是在Avito开放空间中离婚-欺诈者使用社交工程方法识别卡号，并在对话中识别SMS进入RB。 因此，他们获得了特定客户的Internet银行的完全访问权限。 在2019年，诈骗者开始代表银行的安全服务部门给客户打电话，扬言要赔掉所有钱，发现登录详细信息，或敦促他们将所有资金转移到“安全帐户”。
开发团队的主要目标是创建一种机制，以识别新的客户设备并停止可疑的金融交易。 为什么要使用新设备？ 分析表明，大多数情况下，他们通过智能手机访问远程银行，以便通过PUSH通知而不是SMS消息接收确认代码。
此外，FinCERT开始发送与欺诈操作有关的详细信息列表，即必须将其阻止。
反欺诈的开发与整合
我们有2位出色的.NET程序员，RBS的微服务体系结构，REST API，十多个各种形状的黑名单以及各种类型和颜色的大量集成，而且没有测试人员或开发人员工程师。 并不是说它是保护免受所有骗子攻击的必要储备。 但是，如果您仍然需要这样做，那么您将不会停止。 唯一引起我担忧的是误报。 反欺诈运营商在5分钟之内飞了20张票，这无非是无奈，不负责任和被宠坏了。 我知道我们迟早会遇到这种情况。
通常，集成没有错。 SLA设置了3秒的限制来响应请求。 目前，平均响应时间为0.3秒。 通过添加三行将请求发送到反欺诈微服务，微服务体系结构使其易于与现有解决方案集成。 在通过SMS或PUSH通知确认之前进行验证。
解决方案体系结构的示意图：
在开发的第一阶段，设定了目标-检查两个重要条件。 首先，尝试进行交易的设备对于客户端来说是新设备还是受信任的设备。 其次，道具是否不在黑名单中。 这两个条件足以阻止70％的事件发生，其余情况则需要更多信息，例如，是否通过登录名/密码或卡号登录，您从哪个国家/地区进入苏格兰皇家银行等。
要应用验证，您不需要太多数据-客户端的唯一标识符，其设备的标识符（在客户端本身上创建-网站上的移动应用程序和JS库），传输量，传输详细信息。 根据这些数据，做出允许或阻止该操作的决定。 一旦整个系统在工业运行中正常运行，团队便进入了下一个阶段。 有白名单和来自FinCERT的列表的自动加载。 目前，通过API将事件报告发送到FinCERT本身已调试（这是一个单独的故事）。
目前，在反欺诈系统中已验证了以下付款方式：按卡号进行P2P付款，补充电话号码，按明细转账，补充电子钱包。 欺诈者通常会向电话号码或钱包转入2,000-3,000卢布。 对于卡，通常金额接近客户所有可用资金的总和。 除了检查外，还为Antifraud操作员创建了一个页面，这不可能使系统完全自治-需要一个人来监视事件，调查事件，阻止/解除阻止，创建系统报告。 一个团队中有两个后端开发人员时，很难建立站点。 但是，学习永远不会太晚（当T型专家加入团队时，这太酷了！）。
最初，在进行规划和分析时，有很多关于在RBS客户端中引入机器学习，动态规则和防病毒的想法。 但是，从供应商和其他银行的经验来看，可以通过应用静态规则来解决一半以上的案件。 所有其他方法都需要大量资源，效果不佳。 因此，由两个开发人员和一个分析师（我认为自己是）组成的团队足以实施最低限度的保护措施和监管机构的要求。
痛
反欺诈发展的基本原则-无害。 任何更改和新方法都应首先在测试中进行测试，然后在监视模式下的战斗中进行测试，以确保没有问题。 在最坏的情况下，错误可能导致财务损失和客户忠诚度损失。 在我们的案例中，该错误导致操作员研究和管理反欺诈系统。
在除夕夜。 该系统不仅对移动设备进行验证，还对客户端浏览器进行验证。 使用EverCookie 。 开发人员包括了该功能，但未对其进行测试，因为该库未在前端引入。 仅在2019年的最后一个工作日，前端程序员才决定将分支倒入产品中（好吧，明年不要留下相同的东西！）。 因此，在新年周末期间，反欺诈操作员以系统误报的形式堆积了大量工作。 不能说这很关键，但是，操作员对此感到有点遗憾...毕竟，这项工作比更改之前多了5倍。
总结
在不到一年的时间内，一个很小的团队就为互联网银行实施了反欺诈系统。 不幸的是，仍然有很多工作要做。 在Antifraud Russia论坛上与银行和供应商的代表进行了交谈之后，很明显，骗子每年都会想出新的方法，这方面您不能放松。
如果有兴趣，我将写更多有关软件解决方案，市场分析以及如何以3人为一组的团队实施Scrum的文章。