日薪預支審核檔案：法律、安全性、SLA及對賬
企業在審核日薪預支時需要的檔案：法律、安全性、SLA及對賬
在審核日薪預支/EWA時，企業不應只問“錢來得快嗎？”。最低限度的檔案必須證明交易性質、數據處理依據、訪問權限、資金發放機制、薪資對賬、故障處理及各方責任。在試點之前檔案越清晰，運營風險和爭議就越低。
> 簡而言之： 一份足夠的EWA審核檔案應包括八個組別：法人–合同；法律意見；資金流描述；個人數據保護；信息安全；集成規範；SLA/運營；及對賬–審計。市場營銷資料或演示不能替代這些檔案。
> 警告： 本文是審核清單，不是法律意見、安全認證或Nhân Kiệt的SLA承諾。只有正式簽署/批准的文件才具有適用價值。
1. 為什麼需要將EWA視為一個鏈條而不是一個應用程序來審核？
(標準和評分：參見選擇EWA供應商清單和企業如何評估EWA供應商。)
一個資金請求需要經過多個環節：
- 勞動檔案確認正確人員；
- 工作數據確認已完成的工作；
- 有權人員批准工作；
- 服務器計算可用金額；
- 勞動者確認請求；
- 資金發放服務發送銀行指令；
- 交易狀態被查詢；
- 已收到的款項被抵扣到薪資中；
- 工資單和對賬單保存痕跡。
如果企業只審核應用程序界面，他們會忽略最大風險部分：輸入數據、批准權限、資金轉移和結算。
2. 總體審核檔案矩陣
| 檔案組別 | 需要的文件 | 審核主導 |
|---|---|---|
| 法人 | 企業註冊、簽署權限、合同 | 法務/採購 |
| 法律模型 | EWA性質、與勞動者的條款、抵扣機制 | 法務/人力資源 |
| 資金流 | 資金來源、銀行、交易狀態 | 財務/會計 |
| 個人數據 | 各方角色、目的、同意/通知、存儲 | 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 · 企業日薪預支