20 условий, которые необходимо проверить в контракте на внедрение доступа к заработанной зарплате

Что должно быть в контракте на внедрение доступа к заработанной зарплате? 20 условий, которые компании должны проверить

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

> Кратко: Контракт на EWA должен отвечать на четыре вопроса: кто подтверждает право на получение денег, кто выплачивает деньги, кто несёт ответственность за ошибки и кто обрабатывает данные. Техническое приложение, SLA, защита данных и сверка не менее важны, чем коммерческие условия.

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

1. Почему контракт на EWA может не охватывать весь объём?

В цепочке EWA может быть как минимум пять сторон или ролей:

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

Название в контракте не обязательно отражает все роли. Компания должна заранее нарисовать три потока: данные, деньги и ответственность; затем проверить, есть ли соответствующие условия для каждого потока.

2. Что должно входить в комплект документов контракта?

Полный комплект документов обычно включает:

1. основной контракт;
2. приложение, описывающее услуги и функциональные возможности;
3. коммерческое/тарифное приложение;
4. приложение по интеграции и словарь данных;
5. SLA и процедуры поддержки;
6. соглашение или приложение по обработке персональных данных;
7. процедуры сверки, расчётов и исключений;
8. матрица RACI и контактные лица;
9. план внедрения, приёмки и перехода;
10. план завершения, возврата и удаления данных.

Не следует всё сводить к одной фразе "по процедурам поставщика на момент времени", так как компании будет сложно контролировать изменения.

3. Группа A — Объём, определения и модель услуг

3. Группа A — Объём, определения и модель услуг

(См. также: Документы для оценки доступа к заработанной зарплате и Образец регламента доступа к заработанной зарплате (EWA) в компании.)

Условие 1 — Определение EWA и предоставляемые услуги

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

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

Условие 2 — Объекты и условия использования

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

Исключения, которые необходимо обработать: испытательный срок, увольнение, временная приостановка, перевод, работа в нескольких местах, блокировка счёта или неверные данные.

Условие 3 — Границы ответственности сторон

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

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

Условие 4 — Включённые функции и среда

Разделите функции на "имеющиеся в продукте", "настроенные", "принятые" и "фактически включённые".

В случае с доступом к заработанной зарплате, автоматический код выплаты уже разработан, но по умолчанию отключён и включается постепенно в зависимости от клиента. Контракт или протокол go-live должны отражать фактическое состояние, а не только технические возможности.

4. Группа B — Работа, формулы и денежная политика

Условие 5 — Источник данных о работе и источник истины

Перечислите источники: приложение для учёта рабочего времени, система клиента, Google Sheet, ERP или расчётная ведомость; ключи соединения; частоту обновления; правила приоритетов при расхождениях.

Должно быть: ответственность за ввод/исправление, время закрытия и способ хранения истории.

Условие 6 — Право утверждения и исправления работы

Определите, кто имеет право утверждать, отклонять и исправлять; влияет ли исправление утверждённой работы на её статус; кто получает уведомления.

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

Условие 7 — Формула расчёта доступной суммы

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

утверждённая работа × тариф/день − сумма, полученная в периоде − резервируемая сумма

Результат округляется вниз до кратного 1.000 VND и подлежит ограничениям. Тариф в формуле должен отличаться от общего дохода в конце периода.

Условие 8 — Лимиты и резервы

Укажите минимальную сумму, лимит на каждую транзакцию, дневной/периодический лимит, процент доступа, резерв и кто имеет право изменять.

Лимиты 50.000 VND за раз, 3 миллиона VND за транзакцию и 5 миллионов VND на человека в день являются стандартными в коде доступа к заработанной зарплате; они включаются в контракт только после подтверждения реальной политики.

Условие 9 — Изменение политики

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

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

5. Группа C — Денежные потоки, сборы и расчёты

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

Условие 10 — Источник средств и счёт для выплат

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

Minh Khang NguyễnВ текущем техническом потоке доступ к заработанной зарплате осуществляется с помощью специального счёта Nhân Kiệt в VPBank. Источник фонда за этим должен быть подтверждён Nhân Kiệt перед распространением информации или подписанием.

Условие 11 — Сборы, налоги и дополнительные расходы

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

"Без процентов" не означает "без каких-либо расходов". Модель доступа к заработанной зарплате в настоящее время не взимает проценты/сборы с работников по технической информации, но официальная коммерческая политика должна быть утверждена.

Условие 12 — Платёжные поручения и счёт получателя

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

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

Условие 13 — Сверка и статус транзакций

Определите, какая книга является источником проверки, цикл, cut-off, код транзакции, правила сопоставления и сроки обработки расхождений.

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

Условие 14 — Расчётная ведомость и невозвратные суммы

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

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

6. Группа D — Данные, безопасность и непрерывность бизнеса

(Полный каркас: см. Защита данных и конфиденциальность при внедрении EWA.)

Условие 15 — Роли и цели обработки данных

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

Закон о защите персональных данных 91/2025/QH15 и Декрет 356/2025/NĐ-CP вступают в силу с 01.01.2026. Приложение должно быть обновлено в соответствии с действующими нормативами и реальной моделью.

Условие 16 — Меры безопасности

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

Не считайте количество тестов или отдельные сертификаты достаточным доказательством для всех контролей.

Условие 17 — Инциденты и нарушения данных

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

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

Условие 18 — SLA, RTO и RPO

SLA должен быть измеримым: доступность, время отклика, время обработки, задержка синхронизации и возраст зависших транзакций. RTO/RPO должны быть связаны с планом восстановления и результатами учений.

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

7. Группа E — Управление жизненным циклом контракта

Условие 19 — Аудит, отчёты и право проверки

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

Определите меры безопасности при предоставлении журналов и способы скрытия персональных данных в доказательствах.

Условие 20 — Завершение, передача и удаление данных

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

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

8. Таблица проверки "кто несёт ответственность, когда..."

8. Таблица проверки "кто несёт ответственность, когда..."

Ситуация	Контракт должен чётко указать
Ошибочная или исправленная работа	Сторона, подтверждающая, способ пересчёта, сторона, несущая расхождения
Дублирование выплат	Ответственный за проверку, возврат, компенсацию и сроки
Деньги списаны, но не поступили	Источник статуса, SLA, канал поддержки
Неправильный счёт	Обязанность проверки и ответственность за ввод/исправление
Увольнение работника	Cut-off, блокировка прав, расчёт и возврат
Утечка данных паспорта/зарплаты	Руководитель инцидента, уведомление, исправление
Перебои в работе банка	Fail-closed, очередь, уведомление и восстановление
Завершение контракта	Открытые транзакции, данные, долги и доступ

9. Критерии приёмки перед оплатой/go-live

Компания должна проводить приёмку на основе сценариев, а не только демонстрации:

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

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

10. Десять признаков, что контракт не готов к подписанию

1. Нет определения утверждённой работы.
2. Нет формулы для пересчёта.
3. Неясно, кто предоставляет источник средств.
4. Только объявлено 0% процентов без таблицы сборов.
5. Нет правил тайм-аута/зависших транзакций.
6. Нет связи сверки с расчётной ведомостью.
7. Не указана роль обработки данных.
8. SLA — это просто рекламная фраза.
9. Поставщик может изменить политику без контроля.
10. Нет плана выхода из услуги и удаления данных.

11. Часто задаваемые вопросы

Можно ли использовать этот контрольный список вместо образца контракта?

Нет. Контрольный список помогает выявить недостающий объём; юрист должен преобразовать согласованные требования в условия, соответствующие модели и законодательству.

Нужно ли подписывать техническое приложение вместе с контрактом?

Следует чётко определить, какое приложение является частью контракта, порядок приоритета при конфликте, кто имеет право на изменения и механизм управления версиями.

Кто должен участвовать в утверждении контракта на EWA?

Минимально должны участвовать владелец услуги, HR/расчётная ведомость, финансы-бухгалтерия, юридический отдел, ИТ-безопасность/данные, интеграция ИТ и поддержка эксплуатации.

Достаточно ли в контракте указать "не является займом"?

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

Следует ли сразу подписывать долгосрочный контракт или сначала провести пилот?

Следует предусмотреть пилотный этап, критерии приёмки, право на остановку и условия расширения. Решение зависит от уровня готовности и рисков компании.

Официальные правовые источники

• Закон о защите персональных данных № 91/2025/QH15, принят 26.06.2025, вступает в силу 01.01.2026.
• Декрет № 356/2025/NĐ-CP, устанавливающий подробные положения и меры по реализации Закона о защите персональных данных, вступает в силу 01.01.2026.

---

Minh Khang NguyễnАвтор: Do Huy Le — [Должность], Nhan Kiet Manpower Supply Co., Ltd.

Minh Khang NguyễnКонсультации по решениям доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса