Досье на оценку доступа к заработанной зарплате: правовые аспекты, безопасность, SLA и сверка
Досье, которое компании должны запросить при оценке доступа к заработанной зарплате: правовые аспекты, безопасность, SLA и сверка
При оценке доступа к заработанной зарплате компании не должны задаваться только вопросом "деньги приходят быстро?" Минимальное досье должно доказать суть транзакции, основания для обработки данных, права доступа, механизм выплаты, сверку с зарплатой, обработку инцидентов и ответственность каждой стороны. Чем яснее досье до пилотного проекта, тем ниже операционные риски и споры.
> Кратко: Достаточное досье для оценки доступа к заработанной зарплате должно включать восемь групп: юридическое лицо–договор; правовое заключение; описание денежных потоков; защита персональных данных; информационная безопасность; спецификация интеграции; SLA/операции; и сверка–аудит. Маркетинговые материалы или демо-версии не могут заменить эти досье.
> Предупреждение: Nguyen Minh Khang — Chuyên viên ban chiến lược, сертификатом безопасности или обязательством по SLA от Nhan Kiet. Только официально подписанные/утвержденные документы имеют применимую ценность.
1. Почему необходимо оценивать доступ к заработанной зарплате как цепочку, а не как приложение?
(Критерии и шкала оценок: см. Контрольный список выбора поставщика доступа к заработанной зарплате и Как компании оценивают поставщиков доступа к заработанной зарплате по критериям.)
Запрос на получение денег проходит через множество звеньев:
- трудовое досье подтверждает личность;
- данные о выполненной работе подтверждают завершение задачи;
- уполномоченное лицо утверждает работу;
- сервер рассчитывает доступную сумму;
- работник подтверждает запрос;
- служба выплаты отправляет банковский приказ;
- статус транзакции проверяется;
- полученная сумма вычитается из зарплаты;
- расчетные листки и сверочные ведомости сохраняют следы.
Если компания оценивает только интерфейс приложения, она упускает из виду самый большой риск: входные данные, права на утверждение, перевод средств и расчет.
2. Общая матрица досье для оценки
| Группа досье | Необходимые документы | Ответственный за оценку |
|---|---|---|
| Юридическое лицо | Регистрация компании, полномочия на подписание, договор | Юридический отдел/Закупки |
| Правовая модель | Суть доступа к заработанной зарплате, условия для работников, механизм вычета | Юридический отдел/HR |
| Денежные потоки | Источник средств, банк, статус транзакции | Финансовый отдел/Бухгалтерия |
| Персональные данные | Роли сторон, цель, согласие/уведомление, хранение | DPO/Юридический отдел |
| Безопасность | Архитектура, разграничение прав, шифрование, журналы, реагирование | IT/Информационная безопасность |
| Интеграция | Словарь данных, API/файлы, частота, сверка | IT/HRIS |
| SLA | Доступность, отклик, обработка, RTO/RPO, обслуживание | IT/Закупки |
| Сверка | Отчеты о транзакциях, T+1, зарплата, исключения | Зарплата/Бухгалтерия |
| Непрерывность бизнеса | BCP/DR, контактные лица, учения | IT/Риски |
| Завершение услуги | Экспорт данных, удаление/возврат данных, прекращение доступа | Юридический отдел/IT |
3. Группа 1 — Досье юридического лица и полномочий
Компании должны запросить:
- свидетельство о регистрации компании и связанных видов деятельности;
- информацию о юридическом лице, подписывающем договор;
- доверенность, если подписывающий не является законным представителем;
- схему участников: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet, банк и субпоставщики;
- условия использования для работников;
- политику комиссий и ответственных за расходы;
- процесс приема и разрешения жалоб;
- список договорных документов и порядок приоритета в случае конфликта.
Не следует принимать ситуацию, когда сайт говорит одно, приложение показывает другое, а договор определяет третье.
4. Группа 2 — Правовое заключение о доступе к заработанной зарплате
Правовое заключение должно ответить как минимум на следующие вопросы:
- Какова природа суммы, получаемой работником?
- Почему только выполненная и утвержденная работа соответствует условиям?
- На каком основании вычитается полученная сумма из зарплаты?
- Что работник уведомляется и подтверждает?
- Возникают ли проценты, комиссии или кредитные обязательства в модели?
- Кто несет риск, если работа уменьшается после выплаты?
- Как обрабатываются случаи увольнения в середине периода?
- Как распределяется ответственность между клиентом и Nhan Kiet?
По замыслу, доступ к заработанной зарплате позволяет работникам получить доступ к стоимости выполненной и утвержденной работы; сегодняшняя незавершенная работа и будущая работа блокируются. Текущая схема не взимает проценты/комиссии с работников, и полученная сумма вычитается из зарплаты. Однако, технические характеристики не создают правовых выводов. Nhan Kiet должен иметь официальное правовое заключение для модели, договора и публичных заявлений.
При публикации необходимо ссылаться и проверяться юридическим отделом в соответствии с Трудовым кодексом 2019 года и действующими руководящими документами. Не следует использовать статью 101 как "сертификат легальности доступа к заработанной зарплате", если не проведен полный анализ объема статьи и структуры договора.
5. Группа 3 — Схема денежных потоков
(Подробнее: Кто предоставляет источник средств для доступа к заработанной зарплате?.)
Досье должно содержать схему, четко указывающую:
- на кого зарегистрирован источник средств;
- условия для создания запроса на выплату;
- кто может включить/выключить автоматическую выплату;
- какой банк получает средства и как подтверждается владелец счета;
- где создается уникальный код транзакции;
- когда статус считается выплаченным;
- как обрабатываются зависшие/неудачные/возвращенные транзакции;
- когда проводится банковская сверка;
- каким полем данных полученная сумма попадает в зарплату.
В текущей системе деньги переводятся с выделенного счета Nhan Kiet в VPBank через услугу выплаты на счет VPBank, зарегистрированный на имя самого работника. Система проверяет имя владельца счета, использует стабильный код транзакции, блокирует при выплате и фиксирует выплату только при получении корректного ответа. Неясные статусы остаются в ожидании, а не считаются неудачными.
Источник средств за выделенным счетом и ответственность за финансирование должны быть подтверждены Nhan Kiet в письменной форме.
6. Группа 4 — Досье по защите персональных данных
(Полная структура: см. Безопасность данных и конфиденциальность при внедрении доступа к заработанной зарплате.)
С 01.01.2026 года вступает в силу Закон о защите персональных данных № 91/2025/QH15; Декрет 356/2025/НД-CP регулирует некоторые положения и меры его исполнения. Компании должны обновить досье в соответствии с действующим законодательством, а не полагаться на шаблоны, созданные до 2026 года.
Список для оценки должен включать:
- роль каждой стороны в обработке данных;
- перечень данных: удостоверение личности, фото, местоположение, устройство, учет рабочего времени, банковский счет, зарплата;
- цель и основания для обработки каждого поля;
- содержание уведомления/согласия, если это требуется законом;
- срок хранения и критерии удаления;
- права субъектов данных и каналы их реализации;
- субпоставщики обработки и обмен данными;
- место хранения, потоки передачи и передача данных за границу, если есть;
- оценка воздействия и связанные досье по требованию закона;
- процесс уведомления и обработки нарушений данных;
- правила использования селфи, GPS и защиты от подделки GPS;
- процесс возврата/удаления данных при завершении услуги.
Не следует собирать GPS постоянно, если цель — только подтверждение события учета рабочего времени. Хорошая практика — собирать только необходимые данные, в нужное время, для заявленной цели.
7. Группа 5 — Досье по информационной безопасности
Компании должны требовать доказательства, а не просто принимать ответ "система безопасна":
Архитектура и разделение
- схема среды разработки, тестирования и эксплуатации;
- разделение приложения и сервиса хранения банковских ключей;
- потоки подключения к ERP, Google Sheet и банку;
- контроль доступа к администрированию и доступу поставщиков.
Идентификация и права
- механизм входа, блокировки учетной записи и смены устройства;
- принцип минимальных прав;
- матрица ролей работника, супервизора, клиента, администратора, супер-администратора;
- цикл проверки прав;
- журнал действий с чувствительными данными.
Техническая защита
- шифрование при передаче и хранении;
- управление секретами/ключами;
- контроль уязвимостей и обновлений;
- независимое тестирование безопасности, если есть;
- резервное копирование, восстановление и защита от потери данных;
- мониторинг, оповещение и реагирование на инциденты;
- контроль изменений программного обеспечения.
Необходимые доказательства
- утвержденная политика информационной безопасности;
- результаты проверки или пентеста, которые еще действительны;
- образец журнала аудита с удаленными данными;
- протокол учений по реагированию/восстановлению;
- список существующих рисков и план их устранения.
Около 285 тестовых файлов являются сигналом о технической дисциплине, но не равнозначны сертификату информационной безопасности или независимому пентесту.
8. Группа 6 — Спецификация интеграции и качество данных
Досье по интеграции должно описывать:
| Содержание | Вопросы для оценки |
|---|---|
| Ключ соединения | Удостоверение личности, код сотрудника или код учета рабочего времени? |
| Источник данных | ERP, система клиента, приложение или таблица? |
| Частота | В реальном времени, по расписанию или вручную? |
| Версия | Как сохраняется старая версия при изменении данных? |
| Качество | Как обрабатываются дубли, пропуски, ошибки формата? |
| Cut-off | После какого времени данные относятся к следующему периоду? |
| Безопасность | Как осуществляется передача файла/API, аутентификация и шифрование? |
| Сверка | Какой общий контроль между источником и получателем? |
В настоящее время система может получать данные о работе из приложения в реальном времени, из Google Sheet каждые 30 минут и из ERP в 03:00 ежедневно. Это расписание в коде, не следует называть его контрактным SLA, если нет обязательств по обслуживанию и механизма измерения.
9. Группа 7 — SLA должен быть определен численно и иметь точки измерения
Полезный SLA должен содержать:
- показатели: доступность, время отклика, время восстановления;
- область: приложение, API, синхронизация или выплата;
- время начала: с какого события начинается измерение;
- уровни: P1, P2, P3, P4, как они определяются;
- исключения: обслуживание, ошибки банка, ошибки данных клиента;
- точка измерения: какой журнал является эталонным источником;
- отчетность: когда отправляется, кто получает;
- меры: исправление, RCA, кредит на обслуживание, если есть;
- изменения: процесс уведомления об обслуживании и выпуске.
Образец таблицы SLA для заполнения обеими сторонами
| Услуга | Показатель | Официальная цель | Точка измерения | Исключения |
|---|---|---|---|---|
| Вход/приложение | Доступность | Требуется обязательство NK | Мониторинг | Уведомленное обслуживание |
| Синхронизация работы | Задержка | Требуется обязательство NK | Журнал получения–обработки | Задержка исходного файла |
| Запрос на получение денег | Время обработки | Требуется обязательство NK | Журнал транзакций | Банк/контроль |
| Инцидент P1 | Отклик/восстановление | Требуется обязательство NK | Тикет | По договору |
| Сверка | Завершение | Требуется обязательство NK | Протокол/отчет | Отсутствие выписки |
Описания "почти мгновенно", "проверка каждые 5 минут" или "сверка в 08:00 T+1" отражают текущий дизайн/операции в коде. Они не должны автоматически превращаться в обязательства по компенсации или гарантированный SLA.
10. Группа 8 — Сверка и аудит
(Подробнее: см. Сверка транзакций доступа к заработанной зарплате с зарплатой и бухгалтерией.)
Компании должны запросить три уровня сверки:
Сверка транзакций
Каждый запрос должен иметь уникальный код, сумму, время, получателя, внутренний статус, статус банка и историю проверок.
Сверка банка
Система в настоящее время имеет поток чтения выписок VPBank через sFTP и сверку T+1 в 08:00; зависшие суммы проверяются циклически. Закрытие статуса сверки имеет шаг супер-администратора для обеспечения безопасности средств.
Сверка зарплаты
Общая сумма, выплаченная по сотруднику/периоду, должна совпадать с вычетом в расчетной ведомости и расчетном листке. Рабочие дни, использованные для начисления, должны быть отмечены, чтобы не суммироваться в следующий период.
Досье должно содержать:
- образцы дневных и периодических отчетов;
- критерии отклонений и пороги предупреждений;
- кто составляет, проверяет, утверждает;
- процесс обработки зависших, дублированных, ошибочных или неверных транзакций;
- протокол закрытия;
- срок хранения документов и журналов;
- как обрабатываются невозвратные суммы.
11. Группа 9 — План непрерывности бизнеса и завершение услуги
Компании должны задать вопросы до того, как система столкнется с проблемами:
- Где фиксируется работа, если приложение не работает?
- Есть ли безопасное ожидание, если банк прерывается?
- Каковы официальные RTO и RPO?
- Кто имеет право включить аварийный выключатель?
- Как обнаруживаются дубли после восстановления?
- Проводятся ли регулярные учения BCP/DR?
- В каком формате клиент получает данные при завершении договора?
- Когда отзываются учетные записи, токены и права доступа?
- Данные удаляются, анонимизируются или продолжают храниться по обязательствам?
Четкий план завершения не является признаком недоверия; это нормальное требование управления для систем, связанных с данными о работниках и деньгах.
12. Вопросы для использования на оценочной встрече
- Продемонстрируйте транзакцию от утвержденной работы до расчетного листка.
- Докажите, что будущая работа не может создать доступную сумму.
- Кто может изменить утвержденную работу и где следы?
- Что делает система, если ответ банка неясен?
- Как предотвратить повторную отправку одного и того же запроса?
- Как подтверждается подлинность учетной записи работника?
- Кто хранит банковские ключи и имеет ли приложение прямой доступ?
- Какие персональные данные собираются и как долго хранятся?
- Какие субпоставщики могут получить доступ к данным?
- Какие SLA подписаны, какие показатели являются техническими описаниями?
- Какой отчет связывает общие транзакции с зарплатой?
- Кто обрабатывает, если работник увольняется после получения денег?
- Как система предупреждает, если исходные данные работы изменены?
- Как обрабатываются данные и доступ при завершении договора?
13. Рекомендуемая шкала оценок
| Группа | Рекомендуемый вес | Условия исключения |
|---|---|---|
| Правовые аспекты и договор | 20% | Не объяснена суть/вычет |
| Персональные данные | 20% | Не определены роли и цели |
| Безопасность | 20% | Нет разграничения прав/журналов/реагирования |
| Денежные потоки | 15% | Нет контроля дублированных/зависших транзакций |
| Интеграция | 10% | Нет ключа соединения и эталонного источника |
| SLA/операции | 10% | Нет контактных лиц и уровней инцидентов |
| Завершение услуги | 5% | Нет механизма возврата/удаления данных |
Весовые коэффициенты являются примером. Компании могут увеличить вес безопасности или непрерывности бизнеса в соответствии с внутренней политикой.
14. Предупреждающие признаки при оценке поставщика доступа к заработанной зарплате
- называют сумму "не кредитом", но не имеют правового анализа;
- обещают 100% мгновенный перевод в любых случаях;
- не объясняют транзакции с неясным статусом;
- не позволяют клиентам видеть историю изменений работы;
- используют один счет для получения денег без подтверждения подлинности;
- собирают GPS/фото, но не указывают цель и срок хранения;
- используют сертификат банка как сертификат для всего приложения;
- заменяют количество внутренних тестов на пентест/сертификат;
- называют технический график SLA;
- не имеют отчета, связывающего транзакции с зарплатой;
- не имеют процесса завершения услуги.
15. Часто задаваемые вопросы
Достаточно ли работающего демо для утверждения?
Нет. Демо только демонстрирует поток интерфейса. Компании также должны оценивать правовые аспекты, данные, безопасность, деньги, интеграцию, операции и сверку.
Означает ли интеграция с банком, что система сертифицирована банком?
Не следует делать такие выводы. Необходимо запросить точное название соглашения, область интеграции и доказательства разрешения на публикацию.
Является ли частота синхронизации в коде SLA?
Нет. Технический график указывает, когда система планирует работать в нормальных условиях; SLA — это обязательство с четко определенной областью, методами измерения, исключениями и ответственностью.
Нужно ли проверять новые законы о защите данных?
Да. Закон о защите персональных данных 91/2025/QH15 и Декрет 356/2025/НД-CP вступают в силу с 01.01.2026. Досье должно быть проверено юридическим отделом/DPO в соответствии с действующими нормами.
Следует ли сначала провести пилот или завершить все досье?
Основные условия по правовым аспектам, данным, безопасности и денежным потокам должны быть выполнены до пилота. Некоторые оптимальные SLA или расширенные отчеты могут быть завершены в рамках пилотного проекта, но должны быть четко зафиксированы и не снижать основные контрольные функции.
16. Заключение
Хорошая оценка доступа к заработанной зарплате не создает дополнительных процедур, а проясняет ответственность каждой стороны до того, как реальные данные и деньги проходят через систему. Компании должны требовать доказательства для всей цепочки: правильный человек, правильная работа, правильные права, правильная сумма, правильный счет, правильный статус и правильный период зарплаты. Все, что не имеет официальной документации, должно быть зафиксировано как пробел, который нужно закрыть, а не заменено обещаниями продаж.
Официальные правовые источники
- Закон о защите персональных данных № 91/2025/QH15 — принят 26.06.2025, вступает в силу с 01.01.2026.
- Декрет 356/2025/НД-CP — регулирует некоторые положения и меры исполнения Закона о защите персональных данных, вступает в силу с 01.01.2026.
- Декрет 330/2026/НД-CP — административные штрафы в области кибербезопасности и защиты персональных данных, вступает в силу с 19.08.2026.
---
Автор: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.
Консультации по решениям доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса