Управление рисками и противодействие мошенничеству при доступе к заработанной зарплате (EWA)

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

> Примечание: Статья предлагает справочную управленческую и техническую основу. Пороги сигналов тревоги, лимиты, сроки временной блокировки, порядок расследования и распределение ответственности между сторонами должны быть согласованы компанией, поставщиком услуги доступа к заработанной зарплате, платёжным партнёром, юридическим отделом и службой информационной безопасности — с учётом фактической модели внедрения.

> Пояснение терминов: доступ к заработанной зарплате (EWA) · HRIS (кадровая информационная система) · payroll (расчёт заработной платы) · ERP (планирование ресурсов предприятия) · MFA (многофакторная аутентификация) · risk-based auth (аутентификация с учётом уровня риска) · idempotency (защита от повторных транзакций) · callback/webhook (автоматическое уведомление между системами) · timeout (истечение времени ожидания) · false positive (ложное срабатывание/ошибочная блокировка) · social engineering (социальная инженерия) · go-live (ввод в промышленную эксплуатацию) · NIST CSF / OWASP ASVS (стандарты и концепции информационной безопасности).

Чем риск доступа к заработанной зарплате отличается от риска обычного займа?

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

Например:

• аккаунт работника взломан, а номер счёта получателя изменён;

• неутверждённые данные учёта рабочего времени учтены при расчёте лимита;

• запрос отправлен повторно после истечения времени ожидания, что привело к двойной выплате;

• сотрудник уволился, но статус в HRIS не обновлён;

• один и тот же человек имеет право и редактировать рабочее время, и утверждать транзакции;

• транзакция прошла успешно в банке, но не отражена в системе расчёта зарплаты;

• реальный работник ошибочно заблокирован из-за слишком чувствительной модели сигналов тревоги.

Таким образом, управление рисками при доступе к заработанной зарплате должно одновременно защищать четыре свойства:

1. Верный человек: транзакцию совершает законный владелец аккаунта.

2. Верная сумма: сумма рассчитана на основе утверждённых данных и действующей политики.

3. Верный получатель: средства переводятся на проверенный счёт.

4. Верная однократность: каждый корректный запрос создаёт только один результат платежа и полностью проходит сверку.

1. Различие между ошибкой, злоупотреблением и мошенничеством

Не каждое расхождение является мошенничеством. Если операционная команда делает поспешные выводы, компания рискует несправедливо наказать работника или упустить системную ошибку, которую необходимо устранить.

Хорошая система должна фиксировать событие как аномалию, требующую проверки, прежде чем появятся достаточные доказательства для вывода о мошенничестве.

2. Карта рисков по жизненному циклу транзакции доступа к заработанной зарплате

flowchart TD
    A["Идентификация и активация"] --> B["Получение данных о времени и зарплате"]
    B --> C["Расчёт лимита"]
    C --> D["Создание запроса"]
    D --> E["Перевод средств"]
    E --> F["Сверка и расчёт"]
    F --> G["Мониторинг, жалобы, возвраты"]

На каждом этапе — своя группа рисков:

3. Формирование реестра рисков доступа к заработанной зарплате

Реестр рисков превращает общие опасения в конкретную ответственность и действия. Каждый риск должен включать:

• код и описание сценария;

• затронутый актив или процесс;

• причину и условия возникновения;

• вероятность и степень воздействия;

• меры предотвращения, выявления и устранения;

• отслеживаемые данные или показатели;

• владельца риска;

• остаточный риск после применения контроля;

• лицо, уполномоченное принимать остаточный риск;

• дату следующего пересмотра.

Пример матрицы рисков

Не следует копировать оценки вероятности у других компаний. Показатели должны основываться на численности персонала, частоте транзакций, уровне автоматизации, качестве данных и истории инцидентов именно этой программы.

4. Контроль идентификации и защита от захвата аккаунтов

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

Контроль при активации

• сверка кода сотрудника с утверждённым источником HRIS;

• проверка того, что контактный канал принадлежит работнику;

• отказ от опоры на легко узнаваемые данные, такие как дата рождения или код сотрудника;

• ограничение числа попыток и выявление множества аккаунтов с одного устройства;

• уведомление об активации через зарегистрированный канал;

• сохранение доказательств версии условий и момента их принятия.

Контроль при входе в систему и транзакциях

• аутентификация, соответствующая уровню риска;

• повторная аутентификация перед транзакцией или чувствительным изменением;

• выявление новых устройств, аномальных сессий и множественных неудачных попыток;

• аннулирование старых сессий после смены пароля или сообщения об утере устройства;

• немедленное уведомление при новом входе или создании транзакции;

• предоставление пользователю доступного канала для сообщения «это был не я».

Восстановление аккаунта должно быть таким же надёжным, как вход в систему

Если сотрудник поддержки может восстановить аккаунт всего по нескольким легко угадываемым вопросам, все предыдущие меры контроля входа теряют смысл. Процедура восстановления должна требовать нескольких видов подтверждения, ограничивать полномочия сотрудника поддержки, полностью протоколироваться и предусматривать дополнительное утверждение для случаев высокого риска.

5. Контроль изменения счёта получателя

Смена получателя средств — это операция, способная превратить захваченный аккаунт в реальный финансовый ущерб.

Рекомендуемые меры контроля:

1. повторная аутентификация пользователя;

2. проверка нового счёта утверждённым способом;

3. уведомление об изменении через прежний и новый каналы, когда это уместно;

4. применение периода ожидания или усиленных ограничений в зависимости от риска;

5. блокировка транзакции, если изменение сопровождается новым устройством или другими признаками аномалии;

6. недопущение ситуации, когда один и тот же сотрудник поддержки и вносит изменение, и утверждает его;

7. сохранение истории с замаскированным старым и новым значением, исполнителем и причиной;

8. включение транзакций, совершённых сразу после изменения, в отдельный поток мониторинга.

Не следует публично раскрывать конкретные пороги или сроки ожидания, если эта информация может помочь злоумышленникам скорректировать поведение и обойти контроль.

6. Обеспечение достоверности данных о рабочем времени и статусе занятости

Лимит доступа к заработанной зарплате напрямую зависит от исходных данных. Контроль против мошенничества должен начинаться ещё до того, как данные попадут на платформу (см. Что такое утверждённое рабочее время? и Интеграция доступа к заработанной зарплате с учётом рабочего времени, расчётом зарплаты и ERP).

Данные о сотрудниках

• использование уникального кода сотрудника без повторного применения;

• своевременное обновление дат вступления в силу при приёме, отпуске и увольнении;

• проверка расхождений между HRIS, системой расчёта зарплаты и системой доступа к заработанной зарплате;

• приостановка права на транзакции при неясном статусе;

• проверка активных аккаунтов доступа к заработанной зарплате у уволенных сотрудников.

Данные учёта рабочего времени

• учёт только статуса, утверждённого компанией;

• сохранение утвердившего лица, времени утверждения и версии записи;

• оповещение о добавлении или изменении времени после момента закрытия периода;

• выявление невозможного количества часов, пересекающихся смен или резких скачков;

• разделение того, кто редактирует время, и того, кто утверждает исключения;

• пересчёт лимита при корректировке исходных данных.

Правила расчёта зарплаты и лимита

• версионирование формул;

• тестирование перед внедрением;

• требование двухуровневого утверждения для значимых изменений;

• полное сохранение значений до и после изменения;

• отказ от прямого редактирования продуктивных данных ради «быстрого решения»;

• возможность воспроизвести расчёт на основе исходных данных и версии политики.

7. Защита от дублирующих транзакций с помощью идемпотентности

Типичная ситуация: платформа отправляет платёжное поручение, но не получает ответа из-за тайм-аута. Если система расценивает это как сбой и отправляет новое поручение, работник может получить выплату дважды.

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

• уникальный idempotency_key, создаваемый вызывающей стороной;

• уникальное ограничение в базе данных;

• привязку ключа к пользователю, типу транзакции и содержанию запроса;

• срок хранения ключа, достаточный для покрытия всего цикла обработки;

• возврат прежнего transaction_id и статуса при повторной отправке запроса;

• запрет использования того же ключа с другой суммой или другим получателем;

• сохранение ключа при повторных попытках через очередь или после восстановления системы.

Идемпотентность не заменяет сверку. Она предотвращает создание дублей в момент обработки; сверка же выявляет расхождения, уже возникшие между системой доступа к заработанной зарплате, платёжным партнёром и системой расчёта зарплаты/ERP.

8. Управление статусом транзакций с неопределённым результатом

Платёжная транзакция не сводится только к «успеху» и «неудаче». Нужен промежуточный статус для случаев, когда поручение уже отправлено, но окончательный результат ещё не известен.

stateDiagram-v2
    [*] --> Created
    Created --> Validating
    Validating --> Processing
    Processing --> Succeeded
    Processing --> Failed
    Processing --> Unknown
    Unknown --> Succeeded
    Unknown --> Failed
    Succeeded --> Reconciled
    Succeeded --> Reversed

При статусе UNKNOWN или эквивалентном ему:

• временно заблокировать соответствующую часть лимита;

• не создавать автоматически новое платёжное поручение;

• запрашивать статус по прежнему референсному номеру;

• оповещать операционную команду при превышении внутреннего срока;

• сверять с отчётом или выпиской партнёра;

• фиксировать исполнителя и основание при ручной обработке;

• возвращать лимит только после подтверждения того, что средства не были переведены или были возвращены.

9. Сигналы тревоги о мошенничестве следует рассматривать в совокупности

Одного отдельного сигнала обычно недостаточно для вывода. Например, смена телефона работником может быть абсолютно законной. Риск возрастает, когда несколько сигналов проявляются одновременно.

Сигналы, связанные с аккаунтом и устройством

• вход с нового устройства с последующей сменой счёта получателя;

• необычно большое количество аккаунтов на одном устройстве;

• многократные неудачные попытки аутентификации;

• аномальные изменения информации об устройстве;

• входы из удалённых друг от друга мест за нереально короткое время;

• запрос на восстановление с немедленной транзакцией сразу после.

Сигналы, связанные с рабочим временем и лимитом

• резкий рост учтённого времени по сравнению с историей или графиком смен;

• массовая корректировка рабочего времени непосредственно перед созданием транзакции;

• множество записей, утверждённых одним и тем же лицом в нерабочее время;

• значительное изменение лимита без соответствующего события в расчёте зарплаты;

• данные из устаревшей версии перезаписывают более новые;

• у уволенного сотрудника продолжает формироваться лимит.

Сигналы, связанные с транзакциями

• множество запросов, следующих друг за другом с малым интервалом;

• транзакции, постоянно приближающиеся к верхнему пределу;

• смена получателя с последующим запросом крупной суммы;

• перевод средств нескольких сотрудников на один и тот же счёт;

• повторяющиеся неудачные транзакции с разными счетами получателей;

• один платёжный код фигурирует в нескольких транзакциях;

• транзакция, выходящая за рамки обычного поведения аккаунта.

Сигналы, связанные с внутренним персоналом

• предоставление прав с последующим возникновением аномальной транзакции;

• один и тот же человек редактирует данные, утверждает их и обрабатывает исключения;

• массовая выгрузка данных без рабочей необходимости;

• множество административных операций в нерабочее время;

• игнорирование сигналов тревоги или массовое указание одинаковой причины исключения;

• вмешательство в аккаунты, связанные общим устройством, счётом получателя или подразделением.

Детальные пороговые значения следует хранить во внутренней операционной документации с ограниченным доступом.

10. Модель оценки риска не должна становиться «чёрным ящиком»

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

Пример справочного процесса принятия решений:

Необходимо отслеживать как минимум:

• долю верных сигналов тревоги;

• долю добросовестных пользователей, заблокированных ошибочно;

• время обработки сигнала тревоги;

• сумму предотвращённого ущерба;

• количество проигнорированных сигналов;

• количество мошеннических транзакций, не вызвавших сигнал;

• влияние в разрезе групп работников, подразделений или устройств.

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

11. Контроль внутреннего мошенничества

Внутренний сотрудник хорошо знает процессы и может обладать законными правами доступа (см. защита данных и конфиденциальность при внедрении доступа к заработанной зарплате). Поэтому одного контроля входа в систему недостаточно.

Основные принципы:

• разделение ролей создающего, утверждающего и проводящего сверку;

• запрет на использование общих административных аккаунтов;

• предоставление прав в рамках юридического лица, подразделения и должностных обязанностей;

• временные особые права, предоставляемые только при наличии обоснования;

• двухуровневое утверждение для чувствительных операций;

• неизменяемые журналы изменений данных и конфигурации;

• оповещение о массовой выгрузке данных;

• периодический пересмотр прав и их немедленный отзыв при смене должности;

• ротация или обязательный отпуск для чувствительных должностей, если это предусмотрено политикой;

• наличие канала для информирования о нарушениях и механизма независимого расследования.

В состав команды расследования не должны входить непосредственные руководители или лица, имеющие конфликт интересов с проверяемым сотрудником.

12. Многосторонняя сверка для выявления потерь

Сверку следует проводить как минимум между тремя источниками (см. процесс доступа к заработанной зарплате от учёта рабочего времени до сверки):

1. журнал транзакций платформы доступа к заработанной зарплате;

2. результаты банка или платёжного партнёра;

3. утверждённые записи расчёта зарплаты/ERP или итоговых расчётов.

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

Расхождения, которые необходимо выделять отдельно

• система доступа к заработанной зарплате сообщает об успехе, но партнёр это не подтвердил;

• партнёр сообщает об успехе, но в системе доступа к заработанной зарплате транзакция отсутствует;

• несовпадение суммы, комиссии или получателя;

• транзакция возвращена, но лимит не обновлён;

• успешная транзакция отсутствует в системе расчёта зарплаты/ERP;

• один платёжный референс связан с несколькими транзакциями;

• одна транзакция дважды встречается в файле сверки;

• данные о рабочем времени скорректированы уже после совершения транзакции.

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

13. Порядок обработки сигналов тревоги и расследования

flowchart TD
    A["Формирование сигнала тревоги"] --> B["Отбор и приоритизация"]
    B --> C["Защита аккаунта и транзакции"]
    C --> D["Сбор доказательств"]
    D --> E["Вывод и обработка"]
    E --> F["Устранение первопричины"]
    F --> G["Оценка эффективности и обновление правил"]

Шаг 1. Отбор

Проверить, содержит ли сигнал тревоги полные данные, в каком статусе находится транзакция и может ли ущерб продолжать нарастать.

Шаг 2. Ограничение ущерба

В зависимости от полномочий можно завершить сессию, временно заблокировать аккаунт, приостановить ещё не выплаченную транзакцию, отменить изменение счёта получателя или остановить поток интеграции. Меры должны быть соразмерными и допускать отмену, если сигнал окажется ложным.

Шаг 3. Сохранение доказательств

Зафиксировать журналы, версии данных, конфигурацию, код транзакции, платёжный референс, историю изменений и переписку со службой поддержки. Не редактировать исходные доказательства напрямую.

Шаг 4. Анализ причин

Разграничить захват аккаунта, внутреннее мошенничество, ошибку данных, системный сбой и злоупотребление политикой. Рассмотреть как технические причины, так и уязвимости процесса.

Шаг 5. Обработка и уведомление

Действовать в соответствии с договором, внутренними регламентами и требованиями законодательства. Не делать публичных выводов и не применять дисциплинарные меры до завершения надлежащей процедуры проверки.

Шаг 6. Предотвращение повторения

Скорректировать правила, распределение прав, исходный код, процессы, обучающие материалы и отслеживать эффективность изменений после их внедрения.

14. Защита работников при ложных срабатываниях системы

Противодействие мошенничеству не должно превращаться в барьер, из-за которого добросовестный работник не может вовремя получить положенные средства.

Компании необходимо иметь:

• чёткое уведомление о том, что транзакция проверяется, без ярлыка «мошенничество» до завершения расследования;

• удобный канал подачи жалоб;

• номер обращения и статус его обработки;

• внутренние сроки в зависимости от степени влияния;

• механизм быстрой разблокировки или восстановления при подтверждении добросовестности;

• уполномоченное лицо для рассмотрения исключений;

• измерение доли ложных блокировок по каждому правилу;

• анализ того, не создаёт ли правило необоснованных неудобств для определённой группы пользователей.

Служба поддержки не должна видеть больше данных, чем необходимо. Информация о расследованиях должна иметь отдельное разграничение доступа для защиты конфиденциальности и предотвращения раскрытия правил противодействия мошенничеству.

15. Показатели управления рисками, которые следует отслеживать

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

16. Чек-лист тестирования на мошенничество перед запуском

Идентификация и аккаунт

• [ ] Активация с кодом сотрудника другого человека отклоняется.

• [ ] Многократные попытки или автоматизация создают соответствующий сигнал тревоги/ограничение.

• [ ] Смена устройства и восстановление аккаунта требуют надлежащей проверки.

• [ ] Старые сессии аннулируются после изменения учётных данных.

• [ ] Сотрудник поддержки не может в одиночку обойти контроль.

Счёт получателя

• [ ] Смена счёта требует повторной аутентификации.

• [ ] Уведомление об изменении отправляется по верному каналу.

• [ ] Транзакции сразу после изменения обрабатываются согласно политике риска.

• [ ] Использование одного счёта получателя несколькими сотрудниками выявляется.

• [ ] Сотрудники без соответствующих прав не могут просматривать или редактировать полные данные.

Рабочее время, зарплата и лимит

• [ ] Неутверждённое рабочее время не формирует лимит, если политика требует утверждения.

• [ ] Позднее исправление времени приводит к корректному пересчёту лимита.

• [ ] Устаревшие данные не перезаписывают более новую версию.

• [ ] Доступ уволенного сотрудника приостанавливается по дате вступления в силу.

• [ ] Изменение формулы сопровождается утверждением и журналом «до/после».

Транзакции и платежи

• [ ] Повторная отправка с тем же idempotency_key не приводит к двойной выплате.

• [ ] Тот же ключ с другой суммой отклоняется.

• [ ] Тайм-аут создаёт статус «неопределённый» без автоматической отправки нового поручения.

• [ ] Поддельные или повторные callback-уведомления отклоняются.

• [ ] Возврат транзакции обновляет лимит согласно утверждённой процедуре.

Внутреннее мошенничество

• [ ] Один человек не может самостоятельно создавать, утверждать и сверять исключения.

• [ ] Временные права автоматически истекают.

• [ ] Массовая выгрузка данных создаёт запись в журнале и сигнал тревоги.

• [ ] Административные действия невозможно удалить из обычного аудиторского следа.

• [ ] Права сотрудников при переводе или увольнении отзываются своевременно.

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

• [ ] Отсутствие транзакции в одном из трёх источников создаёт кейс расхождения.

• [ ] У кейса есть ответственный и история обработки.

• [ ] Доказательства сохраняются без прямого редактирования.

• [ ] У ошибочно заблокированного пользователя есть канал для жалобы и разблокировки.

• [ ] Проведены учения по сценариям захвата аккаунта и ошибочных транзакций.

17. Правовая база и защита данных при противодействии мошенничеству

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

Во Вьетнаме Закон о защите персональных данных № 91/2025/QH15 вступает в силу с 1 января 2026 года. Постановление 356/2025/NĐ-CP, также вступающее в силу с 1 января 2026 года, детализирует ряд положений и меры по применению Закона. В зависимости от роли и платёжного потока компании также следует учитывать Постановление 52/2024/NĐ-CP о безналичных платежах и соответствующие отраслевые нормы.

Мониторинг мошенничества не означает сбор всех возможных данных. Каждый сигнал должен быть привязан к цели, необходимому объёму, сроку хранения, праву доступа и порядку разъяснения/реагирования на обращения работника. Конкретные юридические выводы должны проверяться применительно к реальной архитектуре и договорам.

Что касается управления информационной безопасностью, NIST Cybersecurity Framework 2.0 предлагает подход через функции Govern, Identify, Protect, Detect, Respond и Recover. OWASP Application Security Verification Standard может служить основой для тестирования технических мер контроля приложений и API. Это справочные концепции, которые не заменяют юридических обязательств или собственной оценки рисков компании.

Заключение

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

Цель не в том, чтобы блокировать как можно больше, а в том, чтобы вовремя предотвращать ущерб, одновременно защищая добросовестных работников. Если компания рассматривает внедрение доступа к заработанной зарплате, стоит заранее подготовить сценарии рисков, схему распределения прав и ситуации для приёмочного тестирования (UAT), а затем ознакомиться с разделом доступ к заработанной зарплате для бизнеса, чтобы запросить документацию по контролю транзакций, сверке и подходящему масштабу пилотного проекта.

Список источников

• Закон о защите персональных данных № 91/2025/QH15

• Постановление 356/2025/NĐ-CP о порядке применения Закона о защите персональных данных

• Постановление 52/2024/NĐ-CP о безналичных платежах

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

Автор: Tran Van Tai — помощник заместителя генерального директора по стратегии развития, Nhan Kiet Manpower Supply Co., Ltd.

Консультация по доступу к заработанной зарплате для бизнеса: Hotline 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса