日薪預支風險管治與防詐騙

要管治日薪預支的詐騙風險,企業須對整條鏈條實施管控——由僱員身份核實、已核准工時及額度計算,到收款戶口、付款指令及對賬,缺一不可。三個關鍵防線分別是:以分權及交易規則作預防;以數據、預警及對賬作偵測;以有節制的凍結、調查、退款及根治問題成因作應對。不應將任何異常都視為詐騙,亦不應在交易結果未明時自動退回款項。

> 注意: 本文提供管治框架及技術參考。預警閾值、額度上限、暫緩時間、調查程序及各方責任,均須由企業、日薪預支服務供應商、付款合作夥伴、法務部門及資訊安全部門,按實際落地模式共同審批確定。

> 名詞解釋: 日薪預支(EWA,按已完成工時預支薪金) · HRIS(人力資源資訊系統) · payroll(薪資計算) · ERP(企業資源規劃) · MFA(多重要素認證) · risk-based auth(按風險程度而定的驗證) · idempotency(冪等性,防止交易重複) · callback/webhook(系統之間的自動通知) · timeout(逾時) · false positive(誤判/假警報) · social engineering(社交工程詐騙) · go-live(正式上線運作) · NIST CSF / OWASP ASVS(資訊安全框架及標準)。

日薪預支的風險與貸款風險有何分別?

日薪預支(Earned Wage Access) 旨在讓僱員提前動用已賺取但未發放的部分薪金。因此,其核心風險並不只在於「無力償還」,而在於系統可能認錯人、算錯工時、算錯額度、匯錯收款戶口,或者判斷錯付款狀態。

例如:

• 僱員戶口被盜用,收款戶口號碼被更改;

• 考勤數據尚未核准,卻已計入額度;

• 申請因逾時而被重新發送,結果產生兩次撥款;

• 員工已離職,但HRIS狀態尚未更新;

• 同一人既有權修改工時,又有權核准交易;

• 交易在銀行端已成功,卻未在薪資系統中登記;

• 真正的僱員因預警模型過於敏感而被誤鎖戶口。

由此可見,日薪預支的風險管治必須同時保障以下四項屬性:

1. 身份正確: 進行交易者須為合法戶口持有人。

2. 權益正確: 金額須按已核准的數據及現行政策計算。

3. 收款人正確: 款項須匯入已驗證的戶口。

4. 僅此一次: 每項有效申請只可產生一個付款結果,並須完整對賬。

1. 區分錯誤、濫用與詐騙

並非所有差異都屬於詐騙。如果營運團隊過早下結論,企業有可能冤枉僱員,或忽略了本應修復的系統缺陷。

良好的系統應先將事件標記為須核實的異常情況,待證據充分後才可判定為詐騙。

2. 按日薪預支交易生命週期劃分的風險地圖

flowchart TD
    A["身份識別與啟動"] --> B["接收工時及薪資數據"]
    B --> C["計算額度"]
    C --> D["建立申請"]
    D --> E["轉賬"]
    E --> F["對賬與結算"]
    F --> G["追蹤、申訴及退款"]

每個環節都有各自的風險類別:

3. 建立日薪預支風險登記冊

風險登記冊可以將籠統的憂慮,轉化為具體的責任及行動。每項風險應記錄:

• 編號及情景描述;

• 受影響的資產或流程;

• 成因及觸發條件;

• 發生機率及影響程度;

• 預防、偵測及補救的管控措施;

• 用作追蹤的數據或指標;

• 風險擁有人;

• 管控後的剩餘風險;

• 有權接受剩餘風險的負責人;

• 下次覆檢日期。

風險矩陣範本

不應直接照搬其他企業的機率評分。評分須根據本身計劃的僱員規模、交易頻率、自動化程度、數據質素及過往事故記錄而定。

4. 身份管控與戶口盜用防範

如果能夠盜用合法戶口,不法分子通常毋須破解額度計算演算法。風險最高的環節,通常在於戶口啟動、戶口復原、更改電話號碼、更換裝置及更改收款戶口。

啟動階段的管控

• 將員工編號與已核准的HRIS來源數據進行核對;

• 驗證聯絡渠道確屬該僱員所有;

• 不依賴容易得知的資料,例如出生日期或員工編號;

• 限制嘗試次數,並偵測同一裝置涉及多個戶口的情況;

• 透過已登記的渠道發出啟動通知;

• 保存條款版本及接受時間的相關記錄作為憑證。

登入及交易時的管控

• 按風險程度採取相應的驗證方式;

• 在進行交易或敏感變更前重新驗證身份;

• 偵測新裝置、異常工作階段及多次失敗嘗試;

• 在更改密碼或報失裝置後,終止舊有工作階段;

• 一有新登入或新交易產生即時通知;

• 提供方便使用的渠道,讓用戶可回報「非本人操作」。

戶口復原的安全程度須與登入同樣嚴謹

假如支援人員只需回答幾條容易猜中的問題便可為戶口進行復原,之前所有登入管控都可能形同虛設。復原程序須要求多項憑證、限制支援人員的權限、完整記錄日誌,並針對高風險個案增設額外審批。

5. 更改收款戶口的管控

更改收款人是其中一項操作,足以將一個被盜用的戶口,轉化為實際的財務損失。

建議採取的管控措施:

1. 重新驗證用戶身份;

2. 按已核准的方式驗證新戶口;

3. 適當情況下,透過舊渠道及新渠道同時通知有關變更;

4. 按風險程度設置等候時間或加強限制;

5. 若變更伴隨新裝置或其他異常跡象,應阻止相關交易;

6. 不應由同一支援人員既負責變更又負責審批;

7. 保存經遮蔽處理的新舊資料紀錄、操作人員及變更原因;

8. 將變更後隨即產生的交易,納入獨立監控流程。

如果公開具體的閾值或等候時間,有可能讓不法分子藉此調整手法以規避管控,故不宜在公開文章中披露。

6. 確保工時數據及僱傭狀態的可靠性

日薪預支的額度直接取決於源頭數據。防詐騙管控須在數據進入平台之前已經展開(參閱何謂已核准工時?及日薪預支與考勤、薪資及ERP系統的整合)。

員工數據方面

• 採用獨一無二的員工編號,不重複使用;

• 更新入職、暫停及離職的生效日期;

• 檢查HRIS、薪資系統及日薪預支平台之間的數據衝突;

• 狀態不明時暫停交易權限;

• 覆檢已離職人員仍在運作中的日薪預支戶口。

考勤數據方面

• 只計算經企業核准的狀態;

• 記錄審批人、審批時間及記錄版本;

• 就鎖定時點後新增或修改的工時發出預警;

• 偵測不合理的工時、重疊更次或異常暴增的情況;

• 將修改工時者與審批例外情況者分開;

• 源頭數據被調整時,須重新計算額度。

薪資及額度規則方面

• 對計算公式進行版本管理;

• 正式套用前先作測試;

• 重大變更須經雙重審批;

• 完整保存變更前後的數值;

• 不應為求「快捷處理」而直接修改正式環境數據;

• 具備從源頭數據及政策版本重新推算結果的能力。

7. 以冪等性(idempotency)防止重複交易

一個典型情況:平台發出付款指令後,因逾時而未收到回應。如果系統將此視為失敗並重新發出指令,僱員便有可能獲得兩次撥款。

冪等性(idempotency)確保同一項申請即使被重複發送多次,亦只會產生一個業務結果。合適的設計須包括:

• 由發起方產生獨一無二的 idempotency_key;

• 在資料庫中設置唯一性約束;

• 將該金鑰與用戶、交易類型及申請內容綁定;

• 金鑰保存時間須涵蓋整個處理生命週期;

• 申請被重新發送時,回傳原有的 transaction_id 及狀態;

• 不允許同一金鑰配上不同金額或收款人;

• 透過隊列重試或系統復原後,金鑰須保持不變。

冪等性並不能取代對賬。它可在處理當刻防止重複交易的產生;而對賬則用於發現日薪預支平台、付款合作夥伴與薪資/ERP系統之間已經出現的差異。

8. 管理結果未明的交易狀態

付款交易並非只有「成功」與「失敗」兩種結果。對於已發出指令但最終結果尚未確定的情況,須設有中間狀態。

stateDiagram-v2
    [*] --> Created
    Created --> Validating
    Validating --> Processing
    Processing --> Succeeded
    Processing --> Failed
    Processing --> Unknown
    Unknown --> Succeeded
    Unknown --> Failed
    Succeeded --> Reconciled
    Succeeded --> Reversed

當交易處於 UNKNOWN(未明)或相近狀態時:

• 暫緩相關的額度部分;

• 不自動產生新的付款指令;

• 以原有的參考編號查詢狀態;

• 超過內部規定時限須向營運團隊發出預警;

• 與合作夥伴提供的報告或結單進行核對;

• 人手處理時須記錄負責人及處理依據;

• 只有在確認款項未曾轉出或已經退回後,方可恢復額度。

9. 詐騙預警訊號須綜合判斷

單一訊號通常不足以下結論。例如僱員更換電話號碼,完全有可能屬正常情況。當多項訊號同時出現時,風險便會上升。

戶口及裝置相關訊號

• 以新裝置登入後隨即更改收款戶口;

• 同一裝置上出現超出正常水平的多個戶口;

• 多次驗證失敗;

• 裝置資料出現異常變化;

• 在不合理的時間內,從相距甚遠的地點登入;

• 提出復原申請後隨即進行交易。

工時及額度相關訊號

• 工時較歷史記錄或更表大幅增加;

• 在建立交易前夕大批量調整工時;

• 大量記錄由同一人在非辦公時間審批;

• 額度大幅變動,卻沒有相應的薪資事件;

• 舊版本數據覆蓋新數據;

• 已離職人員仍然產生額度。

交易相關訊號

• 多項申請在短時間內接連出現;

• 交易金額持續接近上限;

• 更改收款人後隨即申請大額款項;

• 多名員工的款項匯入同一戶口;

• 多個收款戶口均出現重複的交易失敗;

• 同一付款編號出現於多筆交易;

• 交易明顯偏離該戶口一貫的行為模式。

內部人員相關訊號

• 授予權限後隨即出現異常交易;

• 同一人既修改數據、又負責審批及處理例外情況;

• 在沒有工作需要的情況下大批量匯出數據;

• 在非辦公時間進行大量管理操作;

• 大批量忽略預警,或以相同理由批量記錄例外情況;

• 干預與其裝置、收款戶口或所屬單位相關聯的戶口。

具體閾值應保存在存取權限受限的內部營運文件之中。

10. 風險評分模型不應成為「黑箱」

風險評分可以輔助決定是否放行、要求進一步核實、暫緩處理,抑或轉交人手覆核。然而,企業必須清楚模型所依據的訊號,以及誤差的管控方式。

以下為決策流程參考:

至少須追蹤以下事項:

• 預警準確率;

• 合法用戶被誤攔的比率;

• 預警處理時間;

• 已阻截的損失金額;

• 被忽略的預警數量;

• 未被預警偵測到的詐騙交易數量;

• 按僱員群組、部門或裝置劃分的影響情況。

若採用機器學習模型,無論是模型本身或數據來源的變更,均須經過測試、審批,並持續監察模型飄移(model drift),同時須具備足以向調查團隊解釋的能力。在初期階段,一套清晰的規則配合完善的對賬機制,往往比缺乏標準數據支持的複雜模型更容易管控。

11. 內部詐騙管控

內部人員熟悉流程,並可能擁有合法權限(參見實施日薪預支時的數據保安與私隱)。因此,單靠登入管控並不足夠。

主要原則:

• 將建立、審批及對賬的職責分予不同人員;

• 不共用管理員戶口;

• 按法人實體、部門及職務範圍授予權限;

• 特殊權限須設有效期並附有理由;

• 敏感操作須經雙重審批;

• 就數據及設定的變更保存防篡改日誌;

• 就大批量匯出數據發出預警;

• 定期覆檢權限,並在職務調動時即時收回;

• 若政策許可,對敏感職位實行輪調或強制休假;

• 設有舉報渠道及獨立調查機制。

調查團隊不應包括直接管理被調查對象,或與其存在利益衝突的人員。

12. 多維度對賬以偵測資金流失

對賬應至少涵蓋三個數據來源(參見日薪預支從考勤到對賬的流程):

1. 日薪預支平台的交易記錄;

2. 銀行或付款合作夥伴回傳的結果;

3. 已核准的薪資/ERP記錄或結算資料。

視乎系統設計,亦可一併核對工時數據、額度及會計總賬。

須獨立處理的差異情況

• 日薪預支平台顯示成功,但合作夥伴尚未確認;

• 合作夥伴顯示成功,但日薪預支平台沒有相應交易記錄;

• 金額、費用或收款人資料不符;

• 交易已被退回,但額度尚未更新;

• 交易已成功,卻未見於薪資/ERP系統;

• 同一付款參考編號對應多筆交易;

• 同一交易在對賬文件中出現兩次;

• 工時數據在交易產生後才被調整。

每項差異均須設有個案編號、負責人、優先次序、憑證、內部處理期限及最終結果。切勿只因數字已被更正,便刪除差異記錄。

13. 預警處理及調查流程

flowchart TD
    A["產生預警"] --> B["篩選與排序優先次序"]
    B --> C["保護戶口及交易"]
    C --> D["收集證據"]
    D --> E["作出結論及處理"]
    E --> F["根治問題成因"]
    F --> G["評估成效並更新規則"]

步驟一:篩選

核實預警是否具備完整數據、交易目前處於甚麼狀態,以及損失是否仍有機會持續擴大。

步驟二:止損

視乎相關權限,可考慮終止工作階段、暫時凍結戶口、暫緩尚未撥付的交易、撤銷收款戶口變更,或暫停某個整合流程。所採取的措施須與情況相稱,並在預警屬誤判時可予以復原。

步驟三:保存證據

記錄日誌、數據版本、系統設定、交易編號、付款參考、變更歷史及支援聯絡記錄。切勿直接修改原始證據。

步驟四:成因分析

區分戶口盜用、內部詐騙、數據錯誤、系統故障及政策濫用等不同情況,並同時檢視技術成因與流程漏洞。

步驟五:處理及通知

須按合約、內部規定及法律要求行事。在未完成適當核實程序前,不應擅自對外下結論或作出紀律處分。

步驟六:防止再次發生

修訂規則、權限分配、程式碼、流程及培訓資料,並追蹤變更後的成效。

14. 系統誤報時對僱員的保障

防詐騙措施不應變成障礙,令合法僱員未能及時獲取應有權益。

企業須具備:

• 清楚說明交易正在核實當中,在未有結論前不應標籤為「詐騙」;

• 方便使用的申訴渠道;

• 個案編號及處理狀態;

• 按影響程度而定的內部處理時限;

• 核實無誤後可迅速解鎖或復原的機制;

• 有權審視例外情況的負責人;

• 按每項規則量度誤攔比率;

• 檢視有關規則是否對某類用戶造成不合理的不利影響。

支援團隊不應看到超出所需範圍的數據。調查資料須設有獨立的權限管控,以保障私隱及避免洩漏防詐騙規則。

15. 應追蹤的風險管治指標

各項指標須有統一的定義。「已阻截的詐騙」只應在具備充分依據時才予以記錄,避免將所有被拒絕的交易都誇大為已避免的損失。

16. 上線前的防詐騙測試檢查清單

身份及戶口

• [ ] 以他人員工編號進行啟動的申請被拒絕。

• [ ] 多次嘗試或自動化操作會觸發適當的預警/限制。

• [ ] 更換裝置及戶口復原須經足夠程度的驗證。

• [ ] 驗證資料變更後,舊有工作階段會被終止。

• [ ] 支援人員無法單獨繞過相關管控。

收款戶口

• [ ] 更改收款戶口須重新驗證身份。

• [ ] 變更通知會經正確渠道發送。

• [ ] 變更後隨即產生的交易,會按風險政策處理。

• [ ] 同一收款戶口出現於多名員工的情況能被偵測。

• [ ] 沒有權限的員工無法查看或修改完整數據。

工時、薪資及額度

• [ ] 若政策要求須經核准,未核准的工時不會產生額度。

• [ ] 延後修改的工時能令額度正確地重新計算。

• [ ] 舊數據不會覆蓋較新的版本。

• [ ] 已離職員工會按生效日期被暫停權限。

• [ ] 公式變更設有審批,並記錄變更前後的日誌。

交易及付款

• [ ] 以相同 idempotency_key 重複發送不會導致兩次撥款。

• [ ] 同一金鑰配以不同金額的申請會被拒絕。

• [ ] 逾時會產生未明狀態,不會自動發出新指令。

• [ ] 偽造或重複的回調會被拒絕。

• [ ] 交易退款會按已核准的程序更新額度。

內部詐騙

• [ ] 同一人無法自行建立、審批及對賬例外情況。

• [ ] 臨時權限會自動失效。

• [ ] 大批量匯出數據會產生日誌及預警。

• [ ] 管理操作無法從一般審計軌跡中刪除。

• [ ] 職務調動/離職人員的權限會按時被收回。

對賬及調查

• [ ] 三個來源之一缺少交易記錄時,會建立差異個案。

• [ ] 個案設有負責人及處理記錄。

• [ ] 證據獲妥善保存,不會被直接修改。

• [ ] 被誤鎖的用戶設有申訴及解鎖渠道。

• [ ] 已完成戶口盜用及錯誤交易情境的演練。

17. 防詐騙相關的法律框架及數據保護

防詐騙工作可能需要使用戶口、裝置、行為及交易歷史等數據。因此,企業必須同時確保處理目的明確、數據使用恰當,以及保障僱員的私隱。

在越南,第91/2025/QH15號個人資料保護法將於2026年1月1日起生效。第356/2025/NĐ-CP號議定同樣於2026年1月1日起生效,就該法部分條文及實施措施作出具體規定。視乎角色及付款流程,企業亦須考慮關於非現金支付的第52/2024/NĐ-CP號議定,以及相關的專門規定。

監察詐騙,並不等同於可以收集一切可得的數據。每項訊號均須對應明確目的、必要程度、保存期限、存取權限,以及僱員提出反饋時的解釋/處理程序。具體的法律結論,須按實際架構及合約另行審視確定。

在資訊安全管治方面,NIST Cybersecurity Framework 2.0 提供了按 Govern(治理)、Identify(識別)、Protect(保護)、Detect(偵測)、Respond(應對)及 Recover(復原)六項功能劃分的方法。OWASP Application Security Verification Standard 則可作為測試應用程式及API技術管控措施的依據。以上僅屬參考框架,並不能取代企業本身的法律義務或風險評估。

結語

有效的日薪預支風險管治,須建立在多層管控之上:可靠的源頭數據、準確的身份識別、經過驗證的收款人變更、具備冪等性的交易、清晰的付款狀態、分離的內部權限、可解釋的預警,以及逐筆進行的對賬。

目標並非攔截得越多越好,而是在適時阻止損失的同時,保障合法僱員的權益。如果企業正在評估推行日薪預支,建議先準備好風險情景、權限分配架構及須測試的UAT情境,再了解企業版日薪預支方案,索取交易管控、對賬及合適試點範圍的相關文件。

參考資料

• 第91/2025/QH15號個人資料保護法

• 第356/2025/NĐ-CP號議定(個人資料保護法實施細則)

• 關於非現金支付的第52/2024/NĐ-CP號議定

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

作者: Tran Van Tai — 副總經理助理,負責發展策略,Nhan Kiet Manpower Supply Co., Ltd.

企業諮詢: Hotline 0937.022.655 · Email info@nhankiet.vn · 企業版日薪預支方案