越南的日薪預支模式地圖

越南的日薪預支模式地圖：企業應如何分類和比較？

越南市場使用多種名稱，如Earned Wage Access (EWA)、靈活支付、提前支付已賺工資和預支工資。名稱相同不一定架構相同。要正確比較，企業必須從公共數據來源、已賺取工資的確定方式、資金來源、費用、批准權限到期末對賬進行分析。

> 簡而言之： 不應僅僅通過“錢來得快嗎？”來選擇EWA。應驗證六個層面：正確的人 → 已確認的正確工資 → 正確的可用金額 → 正確的賬戶 → 正確的交易 → 正確的工資期。

> 警告： 本文是業務分類地圖，不是供應商排名或法律意見。一個單位自我描述產品的方式不能決定該產品的法律性質。所有結論必須基於合同、資金流、費用、權限和實際流程。

1. EWA應如何理解？

從運營的角度來看，EWA允許勞動者在定期發薪日前獲得一部分已從已完成工作中產生的收入。三個核心要素是：

1. 可用金額與已產生的勞動數據相關聯；
2. 勞動者在政策範圍內主動申請；
3. 交易在正確的工資期內進行對賬或結算。

如果金額不基於已完成的工作，如果產生獨立的信貸義務，或者如果應付款項存在於工資關係之外，企業需要單獨審核，而不是默認稱其為EWA。

2. 為什麼不能僅通過應用名稱來繪製地圖？

一個應用程序可能只是界面層，而勞動數據來自企業的HRM，資金來自金融合作夥伴，工資由另一方處理。相反，一個系統可能幾乎管理從考勤到工資對賬的整個鏈條。

因此，“供應商A有EWA”不足以進行比較。需要回答：

• 誰確認勞動者正在工作；
• 哪個來源證明已完成的工作；
• 誰批准或鎖定勞動數據；
• 哪個公式生成可用金額；
• 資金從誰的賬戶支付；
• 勞動者或企業支付哪些費用；
• 交易失敗、掛起或重複如何處理；
• 期末誰與工資表對賬。

3. 企業調查EWA時常見的六種模式

(與預支比較：參見傳統預支工資與EWA有何不同？。)

這是根據架構進行的分類，並不表示市場上只有六種類型。

模式1 — 由企業管理的傳統預支工資

勞動者提交申請；管理、HR或會計檢查；企業自行支付並在工資期內收回。

適合情況： 規模小、需求少且政策有許多例外需要手動批准。

注意點： 處理時間、批准權限、憑證、對工資表的壓力和決策不一致的風險。

這可能是內部預支制度，未必是數字化的EWA系統。

模式2 — 與HRM或工資系統集成的EWA

供應商從企業系統獲取人事、工資或收入數據。可用金額自動計算，交易返回工資系統進行結算。

優點： 減少手續並可在多個考勤系統上部署。

關鍵問題： 數據更新頻率，誰負責當工資被修改時，以及防止重複使用同一部分收入的機制。

模式3 — 從考勤到工資的封閉EWA鏈

考勤、工資審核、可用金額計算、資金申請、資金支付、對賬和工資單都在一個可追溯的鏈條中。

優點： 減少數據斷裂點，便於從結果到來源的偏差調查。

挑戰： 更廣泛的數據處理範圍，需要更嚴格的權限分配、安全性、業務連續性和審計。

Nhân Kiệt的日薪預支在系統範圍內屬於這種架構：工資來源可以來自應用程序、客戶工資表或ERP；只有已批准的工資才會生成可用金額；成功的交易被納入對賬和工資期。

模式4 — 由第三方資助資金流的EWA

供應商或金融合作夥伴提前支付資金；企業根據協議履行結算義務。

潛在優點： 企業不必直接組織每日的每次支付。

需要澄清： 資金提供者、追索權、費用、勞動者離職、工資減少和無法收回的交易情況。不能僅從“0%利息”推斷法律性質。

模式5 — 與銀行合作的EWA

EWA供應商、企業和銀行合作確定接收權限並執行支付。一些平台描述其解決方案為與企業和銀行合作，使勞動者在發薪日前獲得已賺工資。

需要評估的點： 銀行是支付還是資助角色；資金到賬時間；賬戶條件；費用；對賬；交易狀態不明時的責任。

模式6 — 以EWA為組成部分的財務福利平台

EWA與財務教育、福利、內部通信或其他服務一起提供。一些平台自稱為“靈活支付”解決方案，與企業連接，更新工資/收入並提供財務內容；另一些則將EWA描述為員工福利包中的已賺工資接入權。

注意點： 將EWA功能與其他產品明確分開，分享給誰的每種類型數據，勞動者是否真正自願以及每個組成部分的費用。

4. 快速比較矩陣

標準	傳統預支	HRM/工資系統集成	封閉鏈條	第三方資助	銀行合作	福利平台
勞動數據	手動檢查	來自企業系統	在鏈條或多來源	來自企業	來自企業/合作夥伴	視配置而定
速度	根據批准	可以自動化	可以接近實時	取決於集成	取決於銀行	取決於EWA組成部分
資金來源	企業	視合同而定	視設計而定	供應商/合作夥伴	需要驗證	需要驗證
工資對賬	內部	通過集成	在可追溯鏈條中	多方交流	多方	視供應商而定
主要風險	批准慢/錯	數據偏差	系統範圍大	資金來源/追索	跨方狀態	目的/數據混合

矩陣只是起點。一個供應商可能結合多種模式。

5. 企業必須使用的12個審核軸

(標準集：參見選擇EWA供應商的清單和企業如何評估EWA供應商。)

5.1. 就業關係

誰確認勞動者正在工作、已離職、調動或在多地工作？數據是根據事件還是日程更新？

5.2. 勞動數據來源

真實來源是考勤機、應用程序、Google Sheet、HRM還是工資系統？如果兩個來源不一致，哪個來源優先？

5.3. 可使用的工資狀態

系統使用剛記錄的工資、已結算的工資還是已批准的工資？是否阻止當前和未來日期？

5.4. 可用金額公式

公式必須顯示單價、已收金額、保留、限額和四捨五入。HR需要能夠使用原始數據重新計算一個樣本。

5.5. 限額和負責任的使用

檢查最低限額、每次命令的上限、每日/每期的上限、可接入比例和保留以便結算的部分。

5.6. 資金來源

資金來自企業、供應商還是金融合作夥伴？工資減少或勞動者離職時誰承擔風險？

5.7. 費用

誰支付費用：勞動者、企業還是其他方？費用是按交易、訂閱、比例還是套餐計算？是否有可選服務？

5.8. 身份驗證和接收賬戶

賬戶是否為本人？是否有姓名查詢、eKYC、設備更換和賬戶更換控制？

5.9. 交易安全

是否有穩定的交易碼、重複支付鎖、反饋驗證和狀態不明時的fail-closed機制？

5.10. 對賬

是否有系統–銀行–工資對賬？誰處理掛起的款項，期限是多長？

5.11. 數據和安全

誰決定目的，誰處理，數據存儲在哪裡，存儲多久，哪些第三方可以訪問？

5.12. 法律和合同

合同需要正確描述服務、資金流、費用、責任、數據、投訴、事故、終止和餘額處理。企業必須為具體模式獲得法律意見。

6. 日薪預支在這張地圖上的位置？

(參見：日薪預支與獨立預支應用有何不同和誰為日薪預支提供資金？。)

根據Nhân Kiệt的系統文件，日薪預支設計圍繞以下鏈條：

合格勞動者 → 已批准工資 → 可用金額 → 申請接收 → 銀行支付 → 對賬 → 工資

技術上可驗證的點：

• 三組工資來源：應用程序、客戶工資表和ERP；
• 客戶或監督有權批准；修改已批准的工資將返回待批准並記錄日誌；
• 公式取已批准工資減去已收金額和保留；
• 服務器在每次交易前重新檢查條件；
• 勞動者的VPBank賬戶經過姓名查詢和標準流程中的驗證後鎖定；
• 狀態不明的情況下保持掛起而不是推測為失敗；
• 有掛起款項的查詢和T+1對賬；
• 已使用的工資日被標記以防止累加到下一期。

如果Nhân Kiệt未批准，則不能用作市場聲明的點包括：商業資金來源、長期費用政策、正式法律結論、交易規模、對離職率的影響以及與其他解決方案的比較。

7. 演示前應向供應商提出的20個問題

1. 系統如何定義“已賺工資”？
2. 使用哪些工資來源，更新頻率如何？
3. 未批准的工資是否生成可用金額？
4. 如果勞動者已經收到資金後修改工資怎麼辦？
5. 公式和四捨五入規則是什麼？
6. 是否有保留或保留比例？
7. 誰配置和批准限額？
8. 資金從哪個法人賬戶支付？
9. 是否有金融合作夥伴參與？
10. 勞動者和企業支付哪些費用？
11. 資金進入哪個賬戶，如何驗證賬戶所有權？
12. 如何防止重複交易？
13. 當銀行超時時，系統如何處理？
14. 對賬和工資對賬的周期是什麼？
15. 誰承擔無法收回的款項？
16. 如何支持離職或多地工作的勞動者？
17. 收集哪些數據，存儲多久，分享給誰？
18. SLA、RTO、RPO和事故流程是什麼？
19. 是否允許企業導出數據/審計日誌？
20. 終止服務時，數據和餘額如何處理？

8. 需要暫停以進一步審核的六個跡象

• 只說“無利息”但未公佈完整費用；
• 無法解釋可用金額來源；
• 未來工資或未確認收入仍被使用；
• 銀行狀態不明但系統立即允許重新發送；
• 沒有交易與工資對賬的報告；
• 使用“EWA”名稱代替法律分析和合同。

9. 企業應選擇哪種模式？

沒有一種模式適合所有企業。選擇取決於規模、工資數據質量、工資能力、資金流、行業、地點分佈和風險偏好。

• 小型企業、需求少的企業可以優化預支流程。
• 已有穩定HRM/工資系統的企業可以優先考慮集成。
• 使用大量一線勞動者、多個工作地點或多個工資表的企業應評估更深的追溯鏈條。
• 不想自行組織資金流的企業需要仔細審核資金支持模式和多方責任。

應在小範圍內進行試點，重新計算樣本交易，演練例外情況，並在三個賬本工資 – 銀行 – 工資表匹配後才擴大。

10. 常見問題

EWA和預支工資完全相同嗎？

不應默認為相同。“預支工資”是一個廣泛的稱呼；EWA通常強調已產生的收入部分和從勞動數據到結算的可追溯性。具體性質取決於流程、合同和適用法律。

EWA是貸款嗎？

不能僅從EWA標籤得出結論。需要查看金額是否基於已完成的工作，是否有獨立的還款義務，是否有費用/利息，誰提供資金和追索權如何。

“0%利息”是否意味著免費？

不是。可能存在交易費、訂閱費、可選服務費或由企業支付的費用。必須要求完整的費用表。

是否需要集成考勤？

如果系統希望根據已完成的工作計算可用金額，則需要可靠的數據來源。集成方式可以是API、文件、Sheet、工資或同一系統中的考勤。

是否應該通過資金轉移速度來比較供應商？

速度重要但不足。一筆快速的交易如果工資錯誤、錯誤的人或無法對賬，將帶來比收益更大的風險。

市場參考來源

• CFPB: Data Spotlight on the Paycheck Advance Market — 消費者金融保護局。
• Federal Reserve Bank of Kansas City: As Earned Wage Access Grows, Oversight Tries to Catch Up。

本文描述了通用類型的模式，未提及具體品牌名稱，亦未獨立確認任何供應商的效果、市場份額或法律性質。

---

作者： Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

企業日薪預支解決方案諮詢： 熱線 0937.022.655 · 電郵 info@nhankiet.vn · 企業日薪預支