日薪预支评估文件：法律、安全、SLA和对账
企业在评估日薪预支时需要的文件：法律、安全、SLA和对账
在评估日薪预支/EWA时，企业不应仅仅问“钱来得快吗？”。最低限度的文件必须证明交易的本质、数据处理依据、访问权限、资金发放机制、工资单对账、故障处理及各方责任。在试点之前文件越清晰，运营风险和争议就越低。
> 简而言之： 一个足够评估的EWA文件应包括八个方面：法人–合同；法律意见；资金流描述；个人数据保护；信息安全；集成规范；SLA/运营；以及对账–审计。营销材料或演示不能替代这些文件。
> 警告： 本文是评估清单，不是Nhân Kiệt的法律意见、安全认证或SLA承诺。只有正式签署/批准的文件才具有适用价值。
1. 为什么需要将EWA视为一个链条而不是一个应用程序来评估？
(标准和评分：参见选择EWA供应商的清单和企业如何根据标准评估EWA供应商。)
一个资金请求经过多个环节：
- 劳动档案确认正确人员；
- 工时数据确认已完成的工作；
- 有权人员批准工时；
- 服务器计算可用金额；
- 劳动者确认请求；
- 资金发放服务发送银行指令；
- 交易状态被查询；
- 已收到的款项被抵扣到工资单；
- 工资单和对账单保存痕迹。
如果企业仅评估应用界面，他们会忽略最大风险部分：输入数据、审批权限、资金转移和结算。
2. 总体评估文件矩阵
| 文件组 | 需要的文件 | 评估主导 |
|---|---|---|
| 法人 | 企业注册、签署权限、合同 | 法务/采购 |
| 法律模型 | EWA本质、与劳动者的条款、抵扣机制 | 法务/HR |
| 资金流 | 资金来源、银行、交易状态 | 财务/会计 |
| 个人数据 | 各方角色、目的、同意/通知、存储 | DPO/法务 |
| 安全 | 架构、权限、加密、日志、应急 | IT/信息安全 |
| 集成 | 数据字典、API/文件、频率、对比 | IT/HRIS |
| SLA | 可用性、响应、处理、RTO/RPO、维护 | IT/采购 |
| 对账 | 交易报告、T+1、工资单、例外 | 工资单/会计 |
| 业务连续性 | BCP/DR、联系人、演练 | IT/风险 |
| 服务退出 | 数据导出、删除/返还数据、访问终止 | 法务/IT |
3. 组1 — 法人文件和权限
企业应要求：
- 企业注册证书及相关行业；
- 签署合同的法人信息；
- 如果签署人不是法定代表人，则需授权书；
- 各方参与图：客户、Nhân Kiệt、银行及供应商；
- 劳动者使用条款；
- 费用政策及承担方；
- 投诉接收和解决流程；
- 合同文件清单及冲突时的优先顺序。
不应接受网站、应用和合同规定不一致的情况。
4. 组2 — EWA法律备忘录
法律备忘录至少应回答：
- 劳动者收到的款项本质是什么？
- 为什么只有已完成和已批准的工时才符合条件？
- 抵扣已收到款项到工资的依据是什么？
- 劳动者被通知和确认了什么？
- 模型是否产生利息、费用或信贷义务？
- 工时减少后已发款项的风险由谁承担？
- 中途离职的处理方式？
- 客户和Nhân Kiệt的责任如何分配？
根据设计，日薪预支仅允许劳动者接触已完成和已批准的工时价值；未结算的工时和未来工时被阻止。当前流程不对劳动者收取利息/费用，已收到款项被抵扣到工资。然而，技术特性不会自动产生法律结论。Nhân Kiệt需要对模型、合同和公开表达提供正式法律意见。
发布时，应根据2019年劳动法及现行指导文件进行法律审查。不应在未充分分析法律条款范围和合同结构的情况下使用第101条作为“EWA合法认证”。
5. 组3 — 资金流图
(更多信息：参见谁为日薪预支提供资金来源？。)
文件必须包含一个明确的图示：
- 资金来源账户属于哪个法人；
- 创建资金请求的条件；
- 谁可以启用/禁用自动发放；
- 接收银行是什么以及如何验证账户持有人；
- 唯一交易码在哪里生成；
- 何时状态被视为已发放；
- 挂起/失败/退款交易如何处理；
- 银行对账何时进行；
- 已收到款项通过哪个数据字段进入工资单。
在当前系统中，资金从Nhân Kiệt在VPBank的专用账户通过代发服务转入以劳动者名义的VPBank账户。系统验证账户持有人姓名，使用稳定的交易码，在发放时锁定，并仅在收到有效反馈时记录为已发放。不明确的状态被保留等待，而不是猜测为失败。
专用账户背后的资金来源和资金提供责任是Nhân Kiệt需要书面确认的商业数据。
6. 组4 — 个人数据保护文件
(完整框架：参见实施EWA时的数据安全和隐私保护。)
自2026年1月1日起，个人数据保护法第91/2025/QH15号生效；第356/2025/NĐ-CP号法令详细规定了一些条款及实施措施。企业需要根据现行法律框架更新文件，而不是仅依赖于2026年前构建的模板。
评估清单应包括：
- 各方在数据处理中的角色；
- 数据目录：身份证、照片、位置、设备、考勤、银行账户、工资；
- 每个字段的处理目的和依据；
- 法律要求时的通知/同意内容；
- 存储期限和删除标准；
- 数据主体的权利及执行渠道；
- 辅助处理方及数据共享；
- 存储地点、传输流和数据出境（如有）；
- 法律要求的影响评估及相关文件；
- 数据违规的通知和处理流程；
- 使用自拍、GPS及防假GPS的规则；
- 服务终止时的数据返还/删除流程。
如果目的仅是确认考勤事件，不应持续收集GPS。良好实践原则是收集必要的数据，在正确的时间，为已通知的正确目的。
7. 组5 — 信息安全文件
企业应要求证据，而不仅仅接受“系统安全”的回答：
架构和分离
- 开发、测试和运营环境图；
- 应用与银行密钥服务的分离；
- 连接ERP、Google Sheet和银行的流；
- 管理访问和供应商访问控制。
身份和权限
- 登录机制、账户锁定和设备更换；
- 最小权限原则；
- 劳动者、监督、客户、管理员、超级管理员的角色矩阵；
- 权限审查周期；
- 敏感操作日志。
技术保护
- 传输和存储时加密；
- 秘密/密钥管理；
- 漏洞控制和更新；
- 独立安全测试（如有）；
- 备份、恢复和数据丢失防护；
- 监控、警报和事故应急；
- 软件变更控制。
需要提供的证据
- 已批准的信息安全政策；
- 有效的审查或渗透测试结果；
- 已隐藏数据的审计日志样本；
- 应急/恢复演练记录；
- 存在风险清单及补救计划。
约285个测试文件是技术纪律的信号，但不等同于信息安全认证或独立渗透测试。
8. 组6 — 集成规范和数据质量
集成文件应描述：
| 内容 | 评估问题 |
|---|---|
| 连接键 | 身份证、员工编号还是考勤编号？ |
| 标准来源 | ERP、客户系统、应用还是Sheet？ |
| 频率 | 实时、按计划还是手动？ |
| 版本 | 数据修改时，旧版本如何保存？ |
| 质量 | 重复、缺失、格式错误如何处理？ |
| 截止时间 | 何时之后的数据属于下一期？ |
| 安全 | 文件/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 — 对账和审计
(详情：参见EWA交易与工资单和会计对账。)
企业需要要求三层对账：
交易对账
每个请求必须有唯一的代码、金额、时间、接收人、内部状态、银行状态和查询历史。
银行对账
当前系统通过sFTP读取VPBank对账单，并在08:00进行T+1对账；挂起的款项按周期查询。对账状态的确认有超级管理员步骤以确保资金安全。
工资单对账
按人/期的总发放金额必须与结算和工资单上的抵扣金额一致。用于生成资金的工时必须标记，以免累积到下一期。
文件需要包括：
- 日报和期末报告样本；
- 偏差标准和警报阈值；
- 制定、检查、批准人员；
- 挂起、重复、错误接收人或金额错误的交易流程；
- 结账记录；
- 凭证和日志的保存期限；
- 无法追回款项的处理方式。
11. 组9 — 业务连续性计划和服务退出
企业应在系统故障前询问：
- 当应用停止工作时，工时仍在哪里记录？
- 当银行中断时，是否有安全等待？
- 官方RTO和RPO是多少？
- 谁有权启用紧急停止开关？
- 恢复后，如何检测重复发放？
- 是否定期进行BCP/DR演练？
- 合同结束时，客户以何种格式接收数据？
- 账户、令牌和连接权限何时被撤销？
- 数据被删除、匿名化还是继续保存以履行义务？
明确的退出计划不是缺乏信任的标志；这是涉及劳动数据和资金系统的正常管理要求。
12. 评估会议中的问题清单
- 请演示从已批准工时到工资单的交易。
- 请证明未来工时无法生成可用金额。
- 谁可以修改已批准的工时，痕迹在哪里？
- 如果银行反馈不明确，系统会怎么做？
- 如何防止重复请求？
- 如何验证劳动者账户的真实性？
- 谁持有银行密钥，应用是否有直接访问？
- 收集和保存哪些个人数据，保存多久？
- 哪些辅助供应商可以访问数据？
- 签署了哪些SLA，哪些指标只是技术描述？
- 哪个报告显示交易与工资单一致？
- 如果劳动者在收到款项后离职，谁来处理？
- 如果源工时数据被修改，系统如何警告？
- 合同终止时，数据和访问权限如何处理？
13. 建议的评估评分标准
| 组 | 建议权重 | 排除条件 |
|---|---|---|
| 法律和合同 | 20% | 无法解释本质/抵扣 |
| 个人数据 | 20% | 无法确定角色和目的 |
| 安全 | 20% | 无权限/日志/应急 |
| 资金流 | 15% | 无法控制重复/挂起交易 |
| 集成 | 10% | 无连接键和标准来源 |
| SLA/运营 | 10% | 无联系人和故障分级 |
| 服务退出 | 5% | 无数据返还/删除机制 |
权重仅为示例。企业可以根据内部政策提高安全或业务连续性的权重。
14. 评估EWA供应商时的警示信号
- 称款项为“非贷款”但无法律分析；
- 承诺在任何情况下100%即时转账；
- 无法解释状态不明的交易；
- 不允许客户查看工时修改历史；
- 使用未经验证的账户接收款项；
- 收集GPS/照片但未说明目的和保存期限；
- 使用银行认证作为整个应用的认证；
- 用内部测试数量替代渗透测试/认证；
- 将技术运行计划称为SLA；
- 无连接交易与工资单的报告；
- 无服务终止流程。
15. 常见问题
可运行的演示是否足以批准？
不。演示仅证明一个界面流程。企业还必须评估法律、数据、安全、资金、集成、运营和对账。
银行集成是否意味着系统已获银行认证？
不应如此推断。需要要求正确的协议名称、集成范围和允许公布的证据。
代码中的同步频率是否为SLA？
不是。技术计划显示系统在正常条件下的预期运行；SLA是具有范围、测量方法、排除和责任的承诺。
是否需要检查新的数据保护法律？
需要。个人数据保护法第91/2025/QH15号和第356/2025/NĐ-CP号法令自2026年1月1日起生效。文件需要根据现行规定由法务/DPO审查。
应该先试点还是先完成所有文件？
法律、数据、安全和资金流的基础条件必须在试点前达到。一些优化的SLA或扩展报告可以根据试验范围完善，但必须明确记录且不降低核心控制。
16. 结论
良好的日薪预支评估不是增加程序，而是明确在真实数据和资金通过系统之前的每项责任。企业应要求整个链条的证据：正确的人、正确的工时、正确的权限、正确的金额、正确的账户、正确的状态和正确的工资期。尚无正式文件的内容应记录为需要填补的空白，而不是销售承诺。
官方法律参考来源
- 个人数据保护法第91/2025/QH15号 — 于2025年6月26日颁布，自2026年1月1日起生效。
- 第356/2025/NĐ-CP号法令 — 详细规定了个人数据保护法的一些条款及实施措施，自2026年1月1日起生效。
- 第330/2026/NĐ-CP号法令 — 在网络安全和个人数据保护领域的行政处罚，自2026年8月19日起生效。
---
作者： Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.
企业日薪预支解决方案咨询： 热线 0937.022.655 · 邮箱 info@nhankiet.vn · 企业日薪预支