日薪預支(EWA)風險治理與詐欺防範

為有效治理日薪預支(EWA)的詐欺風險,企業須對整個流程進行全面控管,從員工身分驗證、已核准的出勤工時與可預支額度,到收款帳戶、付款指令與對帳作業,環環相扣。三個關鍵層次分別是:以權限分工與交易規則進行預防;以數據、警示與對帳進行偵測;以有節制的凍結、調查、退補與根本原因改善進行應變。企業不應將所有異常都直接視為詐欺,也不應在交易結果尚未確認時就自動退回額度。

> 提醒: 本文提供的是治理架構與技術參考。實際的警示門檻、預支額度、暫扣時間、調查流程,以及各方權責,都必須由企業、日薪預支服務商、金流合作夥伴、法務與資訊安全部門,依實際導入模式共同核准。

> 名詞解釋: 日薪預支(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,EWA)的設計初衷,是讓員工能夠預先領取已經賺取的部分薪資。因此,其核心風險並非「無法償還債務」,而在於系統是否認錯了人、算錯了工時、算錯了額度、匯錯了收款帳戶,或是誤判了付款狀態。

舉例來說:

• 員工帳戶遭盜用,收款帳號被竄改;

• 尚未核准的出勤資料卻被計入預支額度;

• 請求在逾時後被重新送出,導致重複撥款兩次;

• 員工已離職,但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日起生效。同樣自2026年1月1日起生效的第356/2025/NĐ-CP號議定,則對該法部分條文及實施辦法做出細部規定。依企業角色與金流性質的不同,企業還須留意關於非現金支付的第52/2024/NĐ-CP號議定,以及其他相關的專業法規。

監測詐欺並不代表可以蒐集一切可得的資料。每一項訊號都須對應明確的處理目的、必要程度、保存期限、存取權限,以及員工提出反映時的說明與處理流程。具體的法律結論仍須依實際系統架構與契約內容進行審查確認。

在資訊安全治理方面,NIST Cybersecurity Framework 2.0提供了以Govern(治理)、Identify(識別)、Protect(保護)、Detect(偵測)、Respond(應變)與Recover(復原)六大功能為核心的架構方法;OWASP Application Security Verification Standard則可作為測試應用程式與API技術控管的依據。這些都僅是參考框架,無法取代法律義務,也無法取代企業自身應進行的風險評估。

結語

有效的日薪預支風險治理,建立在多層次的控管之上:可信的來源資料、正確的身分識別、經過驗證的收款人變更、具備冪等性設計的交易、清楚明確的付款狀態、內部權限的適當分工、可解釋的警示機制,以及落實到每一筆交易的對帳作業。

目標並非攔截得越多越好,而是要在適時阻止損失的同時,持續保護合法員工的權益。若企業正在評估導入日薪預支,建議先備妥風險情境、權限分工架構圖,以及需要測試的UAT情境,再進一步了解企業版日薪預支方案,索取交易控管、對帳機制與適合的試辦(pilot)範圍等相關文件。

參考資料

• 第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 · 企業版日薪預支方案