Заражённое устройство и банковское приложение: когда банк должен остановить операцию

Автоматическая реакция антифрода против прав добросовестного клиента: где искать баланс

Что нужно знать за 30 секунд

С 1 марта 2027 года российские банки обязаны выявлять вредоносное ПО на устройстве клиента до того, как деньги спишутся со счёта, и при обнаружении угрозы — отклонять операцию, объяснять причину и предлагать альтернативный способ платежа [7][8]. Это следует из поправок, внесённых Федеральным законом № 210-ФЗ от 26 июня 2026 года в статью 27 закона № 161-ФЗ «О национальной платёжной системе» [7]. Конкретные технические критерии заражения закон не определяет — их разрабатывает каждый банк самостоятельно вместе с поставщиком защитного модуля [13][16]. Это значит, что вся ответственность за баланс между безопасностью и удобством ложится на архитектуру антифрод-системы, скоринговую модель и процесс апелляции внутри конкретной организации.

Почему это стало отдельной проблемой именно сейчас

Новая обязанность банков с 1 марта 2027 года

До сих пор банки реагировали в основном на признаки самой операции: нетипичная сумма, необычное время, новый получатель, смена номера телефона незадолго до перевода [4]. С марта 2027 года список оснований для остановки платежа расширяется — в него добавляется состояние самого устройства, с которого совершается операция. По разъяснению Банка России, кредитные организации с согласия клиента обязаны перед проведением операции проверять устройство, на котором установлено банковское приложение, на наличие вредоносных программ, а при их обнаружении — отклонять операцию, уведомлять клиента и предлагать провести её с другого безопасного устройства или в отделении банка [3]. Глава профильного комитета Госдумы прямо охарактеризовал новую норму как обязанность банков и операторов связи реагировать на наличие вредоносного кода на устройствах пользователей [6].

Правило распространяется не только на переводы по СБП, но и на операции с картами и электронными денежными средствами [8]. Требование обязывает банки встроить в мобильные приложения и на сайты сертифицированные средства защиты информации, распознающие воздействие вредоносного ПО на этапе, предшествующем списанию средств [9].

Это дополняет уже действующий с января 2027 года расширенный перечень из 12 признаков операций, совершённых без добровольного согласия клиента [11], и работает параллельно с действующим с 2024 года механизмом приостановки переводов на счета из чёрного списка ЦБ на срок до 48 часов [1][2], а также с новым инструментом краткосрочной, до шести часов, задержки операции для повторного подтверждения клиентом [5].

Кого это касается

Тема напрямую касается банков и НФО как операторов по переводу денежных средств, команд разработки мобильного банкинга и антифрод-систем, а также подрядчиков, которые поставляют банкам защитные SDK и модули анализа устройства. Для инженера антифрод-системы это не абстрактное требование регулятора, а конкретная задача: спроектировать детектор угроз, встроить его как ещё один вход в общий скоринг, обеспечить неизменяемое логирование решений и путь апелляции клиента — и всё это без роста числа ложных отказов легитимным пользователям.

Какие сигналы указывают на заражённое устройство

Закон не описывает, что именно считать «вредоносным ПО» на устройстве, — эту работу он возлагает на сами банки в связке с поставщиком защитного модуля [13][16]. На практике индустрия уже накопила устойчивый набор технических сигналов.

Поведенческие признаки на уровне ОС

Классическая схема банковского трояна на Android строится вокруг злоупотребления системными сервисами специальных возможностей. После того как пользователя обманом заставляют включить AccessibilityService, вредоносное приложение получает возможность самостоятельно принимать запросы на разрешения и управлять интерфейсом без участия пользователя. Второй типичный вектор — оверлей-атака, при которой поддельное окно перекрывает интерфейс банковского приложения; для неё требуется разрешение SYSTEM_ALERT_WINDOW [15]. К этой же группе стоит отнести признаки, широко описанные в отраслевых отчётах о фишинговых приложениях-приманках, которые сейчас всё чаще маскируются не под банковские, а под приложения операторов связи, госуслуг и коммунальных сервисов [17]: активные инструменты удалённого доступа или демонстрации экрана в момент открытия банковского приложения, подозрительные комбинации выданных разрешений, признаки перехвата вводимых пользователем данных.

Сигналы целостности устройства

Отдельный класс сигналов — не поведение конкретного приложения, а состояние самого устройства. На Android для этого используется Play Integrity API: сервис сообщает приложению, не рутировано ли устройство, не изменено ли само приложение и работает ли оно в доверенной среде; ответ MEETS_STRONG_INTEGRITY дополнительно показывает, установлены ли актуальные обновления безопасности [24]. Именно на этом механизме (а до него — на SafetyNet Attestation) уже давно строится защита банковских приложений и Google Wallet, отказывающихся работать на рутованных устройствах [25]. На iOS аналогичную роль играют встроенные механизмы аттестации приложения и устройства. Важный технический нюанс для разработчиков антифрод-логики: сигнал целостности устройства не тождественен сигналу «на устройстве есть вредоносная программа» — устройство с root не обязательно заражено, а обычное устройство без root тоже может быть скомпрометировано через легитимно выданные разрешения.

Контекстные признаки операции

Признаки заражения имеет смысл рассматривать вместе с контекстом самой транзакции: нетипичная для клиента сумма, необычные время и периодичность операций, смена номера телефона в онлайн-банке менее чем за 48 часов до перевода, попытка перевода получателю, с которым ранее не было операций, перевод самому себе через СБП на сумму свыше 200 тысяч рублей при определённых условиях [4]. Сочетание технического сигнала о состоянии устройства с одним из этих контекстных признаков — куда более надёжное основание для реакции, чем каждый из них по отдельности.

Как оценивать достоверность сигнала

Почему один признак — не повод для блокировки

Аналитики уже указывают на риск избыточно широкого толкования понятия «вредоносное ПО»: формально под критерии подозрительности могут попасть VPN-сервисы, приложения для оптимизации работы смартфона и легитимные средства удалённого доступа, которыми пользуются, например, сотрудники поддержки или люди с ограниченными возможностями [13][14]. Использование VPN само по себе остаётся законным, но защитные и антифрод-системы исторически расценивают его как фактор риска, поскольку часть вредоносного трафика тоже маскируется через прокси и меняет геолокацию; при этом критерии опасности каждый банк задаёт себе сам в координации с поставщиком защитного модуля [16]. Если превратить единичный технический сигнал в жёсткое бинарное правило «есть сигнал — блокируем», банк рискует системно отказывать в обслуживании людям, которые пользуются обычными и законными инструментами.

Скоринг вместо бинарных правил

Зрелые антифрод-системы используют статические правила только для абсолютных, однозначных случаев — например, для операций с реквизитами из чёрного списка ЦБ. Всё, что связано с интерпретируемыми, вероятностными признаками — а состояние устройства как раз такой признак, — должно проходить через скоринговую модель: каждому признаку присваивается вес, баллы суммируются, решение принимается по пороговому значению, а не по факту наличия одного индикатора [28]. Классический пример из практики антифрод-аналитиков: сотрудник в командировке за границей, использующий российскую карту через VPN, формально даёт сразу несколько «рискованных» сигналов, но при этом остаётся легитимным клиентом — именно такие кейсы и должна корректно обрабатывать скоринговая, а не бинарная логика [28].

Когда предупреждать клиента, а когда блокировать операцию

Три уровня реакции

Разумная архитектура реакции строится по нарастающей: мягкое предупреждение и рекомендация проверить устройство при слабом единичном сигнале; запрос дополнительного подтверждения или кратковременная, до шести часов, задержка операции при среднем уровне риска [5]; и полный отказ в конкретной операции с предложением альтернативы при высоком уровне уверенности в компрометации устройства. Важно: закон говорит об отказе именно в конкретном переводе, а не о блокировке счёта или замораживании средств клиента в целом [8].

Что говорит закон о причине отказа и альтернативе

Ключевое требование новой нормы — банк обязан объяснить клиенту причину отказа и предложить способ всё же провести операцию: с другого устройства, на котором не выявлено вредоносное ПО, либо непосредственно в отделении банка [3][8]. Это отличает механизм от блокировок по 115-ФЗ, где банковская тайна и антиотмывочное законодательство часто ограничивают банк в возможности подробно раскрывать причины отказа [23].

Российская специфика: что меняется в регулировании

210-ФЗ и поправки в 161-ФЗ

Федеральный закон от 26 июня 2026 г. № 210-ФЗ вносит изменения в статью 27 закона от 27 июня 2011 г. № 161-ФЗ «О национальной платёжной системе» и вводит для кредитно-финансовых организаций обязанность использовать в мобильных приложениях и на официальных сайтах инструменты выявления вредоносного ПО на устройствах клиентов [7]. Норма вступает в силу 1 марта 2027 года и распространяется на переводы с банковских карт, операции с электронными денежными средствами и платежи через СБП [8].

Согласие клиента и обновление договоров

Проверка устройства возможна только с согласия клиента-физлица: банки обязаны до 1 сентября 2027 года внести в договоры с каждым клиентом пункт о праве согласиться на подключение средств защиты либо отказаться от них [10][12]. Это создаёт для банка развилку: клиент, отказавшийся от проверки, формально выпадает из-под действия нового механизма защиты, и здесь банкам предстоит проработать собственную политику — от информирования о рисках такого отказа до ограничения отдельных высокорисковых операций для таких клиентов в рамках уже существующих оснований 161-ФЗ.

Как это соотносится с уже действующими признаками мошеннических операций

Новая норма про вредоносное ПО — не отдельный изолированный механизм, а дополнение к уже работающей системе: действующему с 2024 года перечню признаков мошеннических операций [1], дополнительно расширенному перечню критериев с 1 января 2026 года [21], перечню из 12 признаков операций без добровольного согласия клиента с января 2027 года [11], давно применяемой двухдневной приостановке операций по счетам из базы ЦБ [2][19] и новому инструменту краткосрочной, до 6 часов, задержки [5]. Разработчикам антифрод-логики важно проектировать признак «заражённое устройство» именно как ещё один вход в общую скоринговую модель, а не как отдельный самостоятельный контур блокировки.

Как избежать массовых false positive

Отраслевые оценки показывают, что цена ошибки первого рода — необоснованного отказа добросовестному клиенту — часто выше цены пропущенного мошенничества: по оценке JPMorgan, реальный ущерб от собственно фрода составляет около 7% совокупных потерь, тогда как потери от ложных блокировок легитимных операций — около 19% [26]. При этом ложная блокировка честной операции означает не только упущенную выручку прямо сейчас, но и операционные издержки на разбор обращения, а также риск оттока клиента к конкуренту — по оценкам аналитиков, именно отток клиентов оказывается самой дорогой статьёй потерь от false positive [27].

Практические меры снижения false positive:

• считать заражение устройства вероятностным фактором риска, а не бинарным флагом, и включать его в общую скоринговую модель вместе с контекстом операции [28];
• вести отдельный учёт метрик false positive и false negative на рабочих порогах и явно формулировать бизнес-компромисс — «такой порог даёт X% ложных отказов и Y% пропущенного фрода», а не оптимизировать модель только под поимку мошенничества [27];
• исключать из автоматической блокировки категории легитимных инструментов, которые технически похожи на индикаторы риска — VPN-сервисы, ассистивные технологии, корпоративные MDM-решения — и работать с ними через более мягкие сценарии, а не через отказ [13][14];
• регулярно калибровать пороги и модели на основе фактических данных конкретного банка в рамках непрерывного цикла работы антифрод-центра, а не использовать статичный набор правил, скопированный у поставщика защитного модуля без адаптации [29];
• отслеживать долю ложных срабатываний в разрезе моделей устройств и версий ОС — кастомизированные прошивки ряда производителей по-разному реализуют системные разрешения и API целостности устройства, что может систематически повышать FP-долю на отдельных моделях.

Резервный канал подтверждения операции

Закон прямо требует предлагать клиенту альтернативу при отказе в операции — другое устройство без обнаруженного вредоносного ПО или обращение в отделение банка [3][8]. На практике набор резервных каналов подтверждения стоит проектировать шире:

• повторное инициирование операции с другого, ранее подтверждённого устройства клиента;
• совершение операции офлайн — в отделении банка или через банкомат по карте, без использования потенциально скомпрометированного приложения [3];
• подтверждение через отдельный, независимый от заражённого устройства канал связи — телефонный звонок в контакт-центр, отдельное веб-приложение с иным набором разрешений;
• временная, до шести часов, задержка с повторным запросом подтверждения — инструмент, прямо предусмотренный законодателем именно для операций, которые по ряду признаков выглядят потенциально опасными, но не критичными [5].

Ключевой архитектурный принцип: резервный канал не должен зависеть от того же скомпрометированного окружения, из-за которого сработал первичный отказ, иначе смысл проверки теряется.

Как хранить технические признаки решения

Любое автоматическое решение об отказе в операции по признаку «заражённое устройство» должно быть воспроизводимо: какие именно сигналы сработали, какой вес они получили, какой порог был превышен, какая версия модели и какая версия детектора устройства использовались. Это нужно не только для отладки, но и для защиты банка в споре с клиентом, регулятором или правоохранительными органами.

Формально эта задача укладывается в уже существующие требования к защите информации в кредитных организациях — Положения Банка России № 683-П и № 719-П, отсылающие к ГОСТ Р 57580.1 и ГОСТ Р 57580.2: банки обязаны вести учёт инцидентов защиты информации и проходить оценку соответствия ГОСТ 57580 не реже раза в два года с обязательным достижением не ниже четвёртого уровня соответствия [30]. Материалы такой оценки необходимо хранить не менее пяти лет, а сама организация обязана проводить ежегодный пентест [31]. Логичное решение — распространить эту же дисциплину логирования и хранения на решения антифрод-модуля по признаку вредоносного ПО: фиксировать входные сигналы, версию модели, итоговый скоринговый балл и принятое решение в отдельном неизменяемом журнале, доступном для последующего разбора инцидента и обоснования перед клиентом или регулятором.

Как организовать апелляцию клиента

Сам закон о вредоносном ПО отдельного механизма обжалования не описывает — банку предстоит выстраивать его самостоятельно, ориентируясь на уже действующую практику по смежным основаниям 161-ФЗ и 115-ФЗ. Общая логика такой практики: клиент вправе обратиться с заявлением в банк, где обслуживается счёт, либо направить обращение в Банк России [18][20]; если операция была приостановлена на основании базы данных ЦБ, для снятия ограничений также предусмотрено обращение с заявлением [19]. При отказе, вызванном подозрением в отмывании доходов по 115-ФЗ, банк может быть ограничен банковской тайной в объяснении подробностей, но обязан рассмотреть документы клиента и пересмотреть решение либо направить вопрос в межведомственную комиссию; при отказе банка и регулятора у клиента остаётся право обращения в суд [22][23].

Для отказов именно по признаку заражённого устройства банку стоит предусмотреть отдельный, максимально прозрачный процесс: понятное клиенту объяснение причины, чёткий путь предоставления альтернативы и — на основании журнала решений, описанного выше, — возможность оперативно вручную пересмотреть автоматический отказ, если клиент докажет, что устройство чисто (обновил ОС, удалил подозрительное приложение, прошёл повторную проверку целостности).

Как тестировать логику на разных версиях Android и iOS

Фрагментация экосистемы Android — разные производители, разные версии API, разная реализация системных разрешений и разная степень доверия к сигналам целостности устройства [24][25] — делает тестирование антифрод-логики отдельной инженерной задачей, а не разовой проверкой перед релизом. Практический подход для команды антифрод-разработки:

• строить матрицу тестовых устройств и версий ОС, отражающую реальное распределение устройств у клиентской базы банка, а не только флагманские модели;
• опираться на признанные международные методики тестирования безопасности мобильных приложений как основу для проверки устойчивости детектора к обходу — эмуляторам, модифицированным прошивкам, инструментам маскировки root-доступа;
• отдельно тестировать поведение на кастомизированных прошивках, которые по-разному обрабатывают AccessibilityService и системные разрешения [15], — именно здесь чаще всего возникают ложные срабатывания;
• проводить поэтапный (canary) выкат новых версий детектора на ограниченную долю трафика с мониторингом доли ложных отказов по моделям и версиям ОС до полного релиза;
• регулярно обновлять тестовые сценарии вслед за обновлениями API целостности устройства [24] и появлением новых техник обхода — синхронизируя это с ежегодным пентестом, уже требуемым положениями ЦБ [31].

Варианты реализации: готовый SDK, собственная разработка, гибрид

На практике у банка есть три пути. Первый — подключить готовый защитный SDK от специализированного поставщика антифрод-решений, который уже реализует детекцию популярных техник и предоставляет банку скоринговый балл риска устройства; критерии опасности при этом банк определяет для себя сам в координации с поставщиком модуля [16]. Второй — разрабатывать детектор внутри собственной команды, что даёт полный контроль над логикой и данными, но требует постоянных инвестиций в отслеживание новых угроз и способов обхода. Третий, наиболее распространённый в зрелых антифрод-системах, — гибрид: несколько независимых сигналов (собственная телеметрия, сторонний SDK, платформенные API целостности устройства) агрегируются в общую скоринговую модель банка [29], а не подключаются как отдельные, конкурирующие друг с другом источники решений.

Для задачи такого масштаба обычно требуется не точечная доработка, а архитектурная работа: согласование модели данных между мобильным приложением, антифрод-скорингом и системой хранения инцидентов, выстраивание процесса согласия клиента и обновления договоров, интеграция с существующей инфраструктурой логирования по ГОСТ 57580 [30]. Команда «Пятого фактора» может изучить действующий процесс обработки инцидентов и передачи данных между этими системами, оценить, где уже сейчас теряются признаки решений или нарушается требуемая полнота логирования, и помочь с архитектурой аудиторского следа для антифрод-решений — что особенно актуально, учитывая, что компания уже работает с задачами картирования потоков данных, интеграций и истории изменений в контуре компании для соответствия регуляторным требованиям [32].

Типичные ошибки и риски

• Бинарная блокировка по единичному техническому сигналу без учёта контекста операции — прямой путь к массовым false positive и оттоку клиентов [26][27].
• Отсутствие внятного объяснения причины отказа клиенту — формально это уже противоречит духу новой нормы, требующей объяснить причину и предложить альтернативу [3][8].
• Игнорирование легитимных сценариев использования «подозрительных» инструментов — VPN в командировке, ассистивные технологии, корпоративный MDM [13][14].
• Недостаточное логирование решений — если банк не может воспроизвести, почему сработал отказ, он не сможет ни защититься в споре с клиентом, ни доказать регулятору обоснованность своей политики [30][31].
• Тестирование только на флагманских устройствах без учёта фрагментации Android-экосистемы и реального распределения устройств клиентской базы.
• Отсутствие отдельного, понятного клиенту процесса апелляции именно по основанию «заражённое устройство», отличного от общих процедур по 161-ФЗ/115-ФЗ [22][23].

Вывод

Обязанность останавливать операцию при обнаружении вредоносного ПО на устройстве клиента — логичное продолжение уже выстроенной в России системы противодействия кибермошенничеству, но одновременно и новый источник операционного риска для самих банков — риска избыточных отказов добросовестным клиентам. Закон задаёт цель и общие рамки — согласие клиента, обязанность объяснить причину и предложить альтернативу, сертифицированные средства защиты, — но не даёт готового технического рецепта. Разработка такого рецепта — скоринговой модели, резервных каналов подтверждения, журнала решений и процесса апелляции — целиком ложится на банки и их технических партнёров, и именно качество этой инженерной работы определит, станет ли новая мера реальной защитой клиентов или источником новых жалоб и оттока.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] cbr.ru — Банк России определил шесть признаков мошеннических операций — https://cbr.ru/press/event/?id=18829

[2] cbr.ru — Методические рекомендации предпринимателю (161-ФЗ, 115-ФЗ) — https://cbr.ru/statichtml/file/155903/mrp.pdf

[3] garant.ru — Информация Банка России от 9 июня 2026 г. — https://www.garant.ru/products/ipo/prime/doc/414263743/

[4] xn----dtbeec7ak4ay9j.xn--p1ai — Банки будут блокировать переводы при наличии вредоносного ПО — https://xn----dtbeec7ak4ay9j.xn--p1ai/news/banki-nachnut-blokirovat-perevody-pri-obnaruzhenii-vredonosnogo-po/

[5] amic.ru — Эксперт объяснил, на какой период банки смогут задерживать операции клиентов — https://www.amic.ru/news/ekspert-obyasnil-na-kakoy-period-banki-smogut-zaderzhivat-operacii-klientov-585818

[6] klerk.ru — Банки заблокируют переводы при обнаружении на устройствах клиентов вредоносного ПО — https://www.klerk.ru/buh/news/703757/

[7] garant.ru — Банки откажут клиенту в переводе при выявлении вредоносного ПО на его устройстве — https://www.garant.ru/news/2200614/

[8] ixbt.com — Российские банки получат доступ ко всем файлам на смартфоне клиента? — https://www.ixbt.com/news/2026/08/08/427012-rossiiskie-banki-polucat-dostup-ko-vsem-failam-na-smartfone-klienta-s-1-marta-2027-goda-banki-budut-blokirovat-perevody-s-ustroistv-s-vredonosnym-po.html

[9] comss.ru — Банки смогут блокировать переводы при обнаружении вредоносного ПО на устройстве клиента — https://www.comss.ru/page.php?id=20890

[10] vm.ru — Что изменится в сфере денежных переводов с марта 2027 года — https://vm.ru/finance/1348155-kak-banki-budut-blokirovat-perevody-pri-obnaruzhenii-vredonosnogo-po-na-ustrojstvah-klientov

[11] kod.ru — Банки начнут останавливать переводы при обнаружении вредоносного ПО на устройстве клиента — https://kod.ru/banki-blokirovka-perevodov-vredonosnoe-po

[12] interfax.ru — Банки будут отказывать клиентам в переводе средств, заметив вредоносное ПО на их устройствах — https://www.interfax.ru/business/1095014

[13] sledstvie.info — Начиная с 2027 года, банки получат возможность приостанавливать переводы — https://sledstvie.info/news/110683-c_2027_goda_banki_smogut_blokirovatj_perevody_pri_obnaruhenii_vredonosnyh_programm_na_smartfone_klienta

[14] iguides.ru — Банки начнут блокировать переводы с заражённых смартфонов — https://www.iguides.ru/main/security/banki_nachnut_blokirovat_perevody_s_zarazhyennykh_smartfonov/

[15] nuancesprog.ru — Обнаружение банковских троянов на устройствах Android — https://nuancesprog.ru/p/21079/

[16] klerk.ru — Банки смогут блокировать переводы, если обнаружат на телефоне вредоносное ПО — https://www.klerk.ru/buh/articles/704433/

[17] habr.com (F.A.C.C.T.) — Заразное приложение: фейки под сотовых операторов, коммунальные платежи — https://habr.com/ru/companies/f_a_c_c_t/news/857550

[18] tbank.ru — Что такое закон 161-ФЗ о национальной платежной системе — https://www.tbank.ru/bank/help/general/161-fz/

[19] e-kontur.ru — Блокировка по 161-ФЗ: что делать предпринимателю — https://e-kontur.ru/enquiry/2660/blokirovka-po-161-fz

[20] allo.tochka.com — 161-ФЗ: что это такое, как снять блокировку — https://allo.tochka.com/161-fz

[21] kk.ru — Блокировка и ограничения по 161-ФЗ: что важно знать — https://kk.ru/articles/safety/blokirovka-i-ogranicheniya-po-161-fz-chto-vazhno-znat/

[22] harant.ru — Блокировка карты или перевода по 161-ФЗ и 115-ФЗ: как вернуть доступ к счету — https://harant.ru/blog/bankovskie-voprosy-finansy/bank-zablokiroval-kartu-perevod-ili-onlajn-bank-chto-delat-po-161-fz-i-115-fz/

[23] vseadvokaty.ru — Блокировка банковских карт по статье 161 Федерального закона — https://vseadvokaty.ru/questions/grazhdanskoe-pravo/vzyskanie-dolgov-neustoyki-i-ubytkov/58491

[24] support.google.com — Как использовать Play Integrity API для выявления опасных взаимодействий — https://support.google.com/googleplay/android-developer/answer/11395166?hl=ru

[25] myseldon.com — API Google Play Integrity позволяет блокировать приложения, установленные из сторонних источников — https://myseldon.com/ru/news/index/317661895

[26] setka.ru — Почему false positive опаснее, чем кажется — https://setka.ru/posts/019f4189-3cdc-73a1-a1d6-fb4de82ffb89

[27] codeby.net — Метрики антифрода: от Recall к Net Savings — https://codeby.net/threads/metriki-antifroda-kak-perestat-merit-tol-ko-po-dole-otklonennykh-operatsii.91613/

[28] codeby.net — Антифрод аналитика транзакций: паттерны и скоринг — https://codeby.net/threads/antifrod-analitika-tranzaktsii-frod-patterny-i-skoringovyye-pravila-na-praktike.94232/

[29] infosec.ru — Антифрод-системы для банков: как работает защита от мошенничества — https://www.infosec.ru/glavnye-temy/antifrod-sistemy-dlya-bankov-kak-rabotaet-zashchita-ot-moshennichestva-i-sistema-protivodeystviya-fr/

[30] rtmtech.ru — 719-П Положение ЦБ — https://rtmtech.ru/services/719-p/

[31] legal-bifit.ru — Разбор Положения Банка России № 683-П — https://legal-bifit.ru/683p_analytics

[32] 5factor.ru — сайт компании — https://5factor.ru/