日薪預支審核文件：法律、安全性、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 · 企業日薪預支