Quản trị rủi ro và phòng chống gian lận trong EWA

Để quản trị rủi ro gian lận EWA, doanh nghiệp cần kiểm soát toàn bộ chuỗi từ xác minh nhân viên, công đã duyệt và hạn mức đến tài khoản nhận tiền, lệnh thanh toán và đối soát. Ba lớp quan trọng là: phòng ngừa bằng phân quyền và quy tắc giao dịch; phát hiện bằng dữ liệu, cảnh báo và đối soát; phản ứng bằng khóa có kiểm soát, điều tra, hoàn trả và khắc phục nguyên nhân gốc. Không nên coi mọi bất thường là gian lận, cũng không nên tự động chi trả lại khi kết quả giao dịch chưa rõ.

> Lưu ý: Bài viết cung cấp khung quản trị và kỹ thuật tham khảo. Ngưỡng cảnh báo, hạn mức, thời gian tạm giữ, quy trình điều tra và trách nhiệm của từng bên phải được doanh nghiệp, nhà cung cấp EWA, đối tác thanh toán, bộ phận pháp lý và an toàn thông tin phê duyệt theo mô hình triển khai thực tế.

> Giải thích thuật ngữ: EWA (nhận lương theo ngày công đã làm) · HRIS (hệ thống thông tin nhân sự) · payroll (tính lương) · ERP (hoạch định nguồn lực doanh nghiệp) · MFA (xác thực đa yếu tố) · risk-based auth (xác thực theo mức rủi ro) · idempotency (chống lặp giao dịch) · callback/webhook (thông báo tự động giữa các hệ thống) · timeout (hết thời gian chờ) · false positive (chặn nhầm/cảnh báo sai) · social engineering (lừa đảo phi kỹ thuật) · go-live (đưa vào vận hành chính thức) · NIST CSF / OWASP ASVS (khung và tiêu chuẩn an toàn thông tin).

Rủi ro EWA khác gì rủi ro của một khoản vay?

EWA – Earned Wage Access – được thiết kế để người lao động tiếp cận một phần tiền lương đã kiếm được. Vì vậy, rủi ro cốt lõi không chỉ nằm ở khả năng “không trả được nợ”, mà nằm ở việc hệ thống xác định sai người, sai công, sai hạn mức, sai tài khoản nhận tiền hoặc sai trạng thái thanh toán.

Ví dụ:

• tài khoản của người lao động bị chiếm và số tài khoản nhận tiền bị đổi;

• dữ liệu chấm công chưa duyệt nhưng được tính vào hạn mức;

• một yêu cầu bị gửi lại sau timeout và phát sinh hai lần chi trả;

• nhân viên đã nghỉ việc nhưng trạng thái HRIS chưa cập nhật;

• người có quyền sửa công đồng thời có quyền duyệt giao dịch;

• giao dịch thành công tại ngân hàng nhưng chưa được ghi nhận trong payroll;

• người lao động thật bị khóa nhầm do mô hình cảnh báo quá nhạy.

Như vậy, quản trị rủi ro EWA phải bảo vệ đồng thời bốn thuộc tính:

1. Đúng người: người thực hiện giao dịch là chủ tài khoản hợp lệ.

2. Đúng quyền lợi: số tiền được tính từ dữ liệu đã được phê duyệt và chính sách hiện hành.

3. Đúng người nhận: tiền được chuyển đến tài khoản đã xác minh.

4. Đúng một lần: mỗi yêu cầu hợp lệ chỉ tạo một kết quả thanh toán và được đối soát đầy đủ.

1. Phân biệt lỗi, lạm dụng và gian lận

Không phải mọi chênh lệch đều là gian lận. Nếu đội vận hành kết luận quá sớm, doanh nghiệp có thể xử lý oan người lao động hoặc bỏ qua lỗi hệ thống cần khắc phục.

Một hệ thống tốt nên ghi nhận sự kiện là bất thường cần xác minh trước khi có đủ bằng chứng để kết luận gian lận.

2. Bản đồ rủi ro theo vòng đời giao dịch EWA

```mermaid
flowchart TD
A["Định danh và kích hoạt"] --> B["Nhận dữ liệu công, lương"]
B --> C["Tính hạn mức"]
C --> D["Tạo yêu cầu"]
D --> E["Chuyển tiền"]
E --> F["Đối soát và quyết toán"]
F --> G["Theo dõi, khiếu nại, hoàn trả"]
```

Mỗi bước có nhóm rủi ro riêng:

3. Xây dựng sổ đăng ký rủi ro EWA

Sổ đăng ký rủi ro biến các lo ngại chung thành trách nhiệm và hành động cụ thể. Mỗi rủi ro nên có:

• mã và mô tả kịch bản;

• tài sản hoặc quy trình bị ảnh hưởng;

• nguyên nhân và điều kiện kích hoạt;

• xác suất và mức độ tác động;

• kiểm soát phòng ngừa, phát hiện và khắc phục;

• dữ liệu hoặc chỉ số theo dõi;

• chủ sở hữu rủi ro;

• rủi ro còn lại sau kiểm soát;

• người có thẩm quyền chấp nhận rủi ro còn lại;

• ngày rà soát tiếp theo.

Mẫu ma trận rủi ro

Không nên sao chép mức xác suất từ doanh nghiệp khác. Điểm số phải dựa trên quy mô lao động, tần suất giao dịch, mức tự động hóa, chất lượng dữ liệu và lịch sử sự cố của chính chương trình.

4. Kiểm soát danh tính và chiếm đoạt tài khoản

Kẻ gian thường không cần phá thuật toán tính hạn mức nếu có thể chiếm tài khoản hợp lệ. Điểm rủi ro cao nhất thường là kích hoạt, khôi phục tài khoản, đổi số điện thoại, đổi thiết bị và đổi tài khoản nhận tiền.

Kiểm soát khi kích hoạt

• đối chiếu mã nhân viên với nguồn HRIS đã được phê duyệt;

• xác minh kênh liên hệ thuộc người lao động;

• không dựa vào các thông tin dễ biết như ngày sinh hoặc mã nhân viên;

• giới hạn số lần thử và phát hiện nhiều tài khoản từ cùng thiết bị;

• thông báo kích hoạt qua kênh đã đăng ký;

• lưu bằng chứng về phiên bản điều khoản và thời điểm chấp thuận.

Kiểm soát khi đăng nhập và giao dịch

• xác thực phù hợp với mức rủi ro;

• tái xác thực trước giao dịch hoặc thay đổi nhạy cảm;

• phát hiện thiết bị mới, phiên bất thường và nhiều lần thử thất bại;

• vô hiệu hóa phiên cũ sau khi đổi mật khẩu hoặc báo mất thiết bị;

• thông báo ngay khi đăng nhập mới hoặc giao dịch được tạo;

• cho phép người dùng báo “không phải tôi” qua kênh dễ tiếp cận.

Khôi phục tài khoản phải mạnh như đăng nhập

Nếu nhân viên hỗ trợ có thể khôi phục tài khoản chỉ bằng vài câu hỏi dễ đoán, mọi kiểm soát đăng nhập phía trước có thể bị vô hiệu. Quy trình khôi phục cần nhiều bằng chứng, giới hạn quyền của nhân viên hỗ trợ, ghi log đầy đủ và áp dụng phê duyệt bổ sung cho trường hợp rủi ro cao.

5. Kiểm soát thay đổi tài khoản nhận tiền

Thay đổi người nhận tiền là thao tác có khả năng biến một tài khoản bị chiếm thành thiệt hại tài chính thực tế.

Kiểm soát khuyến nghị:

1. tái xác thực người dùng;

2. xác minh tài khoản mới theo phương thức được phê duyệt;

3. thông báo thay đổi qua kênh cũ và kênh mới khi phù hợp;

4. áp dụng thời gian chờ hoặc giới hạn tăng cường dựa trên rủi ro;

5. chặn giao dịch nếu thay đổi đi kèm thiết bị mới hoặc dấu hiệu bất thường khác;

6. không để một nhân viên hỗ trợ vừa thay đổi vừa phê duyệt;

7. lưu lịch sử giá trị cũ đã che bớt, giá trị mới đã che bớt, người thực hiện và lý do;

8. đưa giao dịch ngay sau thay đổi vào luồng giám sát riêng.

Không nên công bố cụ thể ngưỡng hoặc thời gian chờ trên bài viết công khai nếu thông tin đó có thể giúp kẻ gian điều chỉnh hành vi để né kiểm soát.

6. Bảo đảm dữ liệu công và trạng thái lao động là đáng tin cậy

Hạn mức EWA phụ thuộc trực tiếp vào dữ liệu nguồn. Kiểm soát chống gian lận phải bắt đầu trước khi dữ liệu vào nền tảng (xem Công đã duyệt là gì? và Tích hợp EWA với chấm công, payroll và ERP).

Với dữ liệu nhân viên

• dùng mã nhân viên duy nhất, không tái sử dụng;

• cập nhật ngày hiệu lực của tuyển mới, tạm nghỉ và nghỉ việc;

• kiểm tra xung đột giữa HRIS, payroll và EWA;

• tạm dừng quyền giao dịch khi trạng thái chưa rõ;

• rà soát tài khoản EWA còn hoạt động của người đã nghỉ.

Với dữ liệu chấm công

• chỉ tính trạng thái được doanh nghiệp phê duyệt;

• lưu người duyệt, thời điểm duyệt và phiên bản bản ghi;

• cảnh báo công được thêm hoặc sửa sau thời điểm khóa;

• phát hiện số giờ bất khả thi, ca chồng lấn hoặc tăng đột biến;

• phân tách người sửa công và người phê duyệt ngoại lệ;

• tính lại hạn mức khi dữ liệu nguồn bị điều chỉnh.

Với quy tắc lương và hạn mức

• quản lý phiên bản công thức;

• thử nghiệm trước khi áp dụng;

• yêu cầu phê duyệt hai lớp với thay đổi quan trọng;

• lưu đầy đủ giá trị trước và sau;

• không sửa trực tiếp dữ liệu sản xuất để “xử lý nhanh”;

• có khả năng tái tạo phép tính từ dữ liệu nguồn và phiên bản chính sách.

7. Chống giao dịch trùng bằng idempotency

Một tình huống điển hình: nền tảng gửi lệnh thanh toán nhưng không nhận phản hồi do timeout. Nếu hệ thống coi đó là thất bại và gửi lệnh mới, người lao động có thể nhận hai lần.

Idempotency bảo đảm nhiều lần gửi lại cùng một yêu cầu chỉ tương ứng với một kết quả nghiệp vụ. Một thiết kế phù hợp cần:

• idempotency_key duy nhất do bên gọi tạo;

• ràng buộc duy nhất trong cơ sở dữ liệu;

• liên kết khóa với người dùng, loại giao dịch và nội dung yêu cầu;

• thời gian lưu khóa đủ bao phủ vòng đời xử lý;

• trả lại transaction_id và trạng thái cũ khi yêu cầu được gửi lại;

• không cho cùng khóa đi kèm số tiền hoặc người nhận khác;

• giữ nguyên khóa khi retry qua hàng đợi hoặc sau khôi phục hệ thống.

Idempotency không thay thế đối soát. Nó ngăn lỗi tạo trùng tại thời điểm xử lý; đối soát phát hiện chênh lệch đã xảy ra giữa EWA, đối tác thanh toán và payroll/ERP.

8. Quản lý trạng thái giao dịch chưa rõ kết quả

Giao dịch thanh toán không chỉ có “thành công” và “thất bại”. Cần trạng thái trung gian cho trường hợp đã gửi lệnh nhưng chưa biết kết quả cuối cùng.

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

Khi ở trạng thái UNKNOWN hoặc tương đương:

• tạm giữ phần hạn mức liên quan;

• không tự động tạo lệnh thanh toán mới;

• truy vấn trạng thái bằng mã tham chiếu cũ;

• cảnh báo đội vận hành nếu quá thời gian nội bộ;

• đối chiếu với báo cáo hoặc sao kê của đối tác;

• ghi nhận người và căn cứ khi xử lý thủ công;

• chỉ hoàn lại hạn mức sau khi xác định tiền chưa được chuyển hoặc đã hoàn trả.

9. Tín hiệu cảnh báo gian lận nên được kết hợp

Một tín hiệu đơn lẻ thường không đủ để kết luận. Ví dụ, người lao động đổi điện thoại có thể hoàn toàn hợp lệ. Rủi ro tăng khi nhiều tín hiệu xuất hiện cùng lúc.

Tín hiệu về tài khoản và thiết bị

• đăng nhập từ thiết bị mới rồi đổi tài khoản nhận tiền;

• nhiều tài khoản trên cùng một thiết bị vượt mức bình thường;

• nhiều lần xác thực thất bại;

• thông tin thiết bị thay đổi bất thường;

• đăng nhập từ các vị trí cách xa trong thời gian không hợp lý;

• yêu cầu khôi phục rồi giao dịch ngay.

Tín hiệu về công và hạn mức

• số công tăng mạnh so với lịch sử hoặc lịch ca;

• điều chỉnh công hàng loạt ngay trước khi tạo giao dịch;

• nhiều bản ghi được cùng một người phê duyệt ngoài giờ;

• hạn mức thay đổi lớn mà không có sự kiện payroll tương ứng;

• dữ liệu đến từ phiên bản cũ ghi đè dữ liệu mới;

• người đã nghỉ việc vẫn phát sinh hạn mức.

Tín hiệu về giao dịch

• nhiều yêu cầu sát nhau;

• giao dịch liên tục ở mức gần trần;

• đổi người nhận rồi yêu cầu số tiền lớn;

• nhiều nhân viên chuyển vào cùng một tài khoản;

• giao dịch thất bại lặp lại với nhiều tài khoản nhận;

• một mã thanh toán xuất hiện ở nhiều giao dịch;

• giao dịch ngoài mẫu hành vi thông thường của tài khoản.

Tín hiệu về nhân sự nội bộ

• cấp quyền rồi phát sinh giao dịch bất thường;

• cùng một người sửa dữ liệu, phê duyệt và xử lý ngoại lệ;

• xuất dữ liệu hàng loạt không có yêu cầu công việc;

• nhiều thao tác quản trị ngoài giờ;

• bỏ qua cảnh báo hoặc ghi lý do ngoại lệ giống nhau hàng loạt;

• can thiệp vào tài khoản có quan hệ chung về thiết bị, tài khoản nhận hoặc đơn vị.

Ngưỡng chi tiết nên được giữ trong tài liệu vận hành nội bộ, có quyền truy cập hạn chế.

10. Mô hình chấm điểm rủi ro không được trở thành “hộp đen”

Điểm rủi ro có thể hỗ trợ quyết định cho phép, yêu cầu xác minh thêm, tạm giữ hoặc chuyển kiểm tra thủ công. Tuy nhiên, doanh nghiệp cần biết mô hình dựa trên tín hiệu nào và kiểm soát sai số ra sao.

Một quy trình quyết định tham khảo:

Cần theo dõi ít nhất:

• tỷ lệ cảnh báo đúng;

• tỷ lệ người hợp lệ bị chặn nhầm;

• thời gian xử lý cảnh báo;

• giá trị thiệt hại đã ngăn chặn;

• số cảnh báo bị bỏ qua;

• số giao dịch gian lận không được cảnh báo;

• tác động theo nhóm người lao động, đơn vị hoặc thiết bị.

Nếu sử dụng mô hình học máy, thay đổi mô hình hoặc nguồn dữ liệu phải được kiểm thử, phê duyệt, theo dõi trôi mô hình và có khả năng giải thích đủ cho đội điều tra. Với giai đoạn đầu, một bộ quy tắc rõ ràng và đối soát tốt thường dễ kiểm soát hơn một mô hình phức tạp nhưng thiếu dữ liệu chuẩn.

11. Kiểm soát gian lận nội bộ

Người nội bộ có hiểu biết về quy trình và có thể sở hữu quyền hợp pháp (gắn với bảo mật dữ liệu và quyền riêng tư khi triển khai EWA). Do đó, chỉ kiểm soát đăng nhập là chưa đủ.

Các nguyên tắc chính:

• tách người tạo, người duyệt và người đối soát;

• không dùng chung tài khoản quản trị;

• cấp quyền theo phạm vi pháp nhân, đơn vị và nhiệm vụ;

• quyền đặc biệt có thời hạn và phải có lý do;

• thao tác nhạy cảm yêu cầu phê duyệt hai lớp;

• lưu log chống sửa đổi cho thay đổi dữ liệu và cấu hình;

• cảnh báo việc xuất dữ liệu hàng loạt;

• rà soát quyền định kỳ và thu hồi ngay khi chuyển việc;

• luân chuyển hoặc nghỉ bắt buộc với vị trí nhạy cảm nếu chính sách phù hợp;

• có kênh tố giác và cơ chế điều tra độc lập.

Đội điều tra không nên bao gồm người trực tiếp quản lý hoặc có xung đột lợi ích với đối tượng bị xem xét.

12. Đối soát nhiều chiều để phát hiện thất thoát

Đối soát nên được thực hiện giữa ít nhất ba nguồn (theo quy trình Lương Ngày từ chấm công đến đối soát):

1. sổ giao dịch của nền tảng EWA;

2. kết quả từ ngân hàng hoặc đối tác thanh toán;

3. hồ sơ payroll/ERP hoặc quyết toán đã được phê duyệt.

Tùy thiết kế, có thể đối chiếu thêm dữ liệu công, hạn mức và sổ cái kế toán.

Những chênh lệch phải được tách riêng

• EWA báo thành công nhưng đối tác chưa xác nhận;

• đối tác báo thành công nhưng EWA không có giao dịch;

• số tiền, phí hoặc người nhận không khớp;

• giao dịch bị hoàn nhưng hạn mức chưa được cập nhật;

• giao dịch thành công nhưng thiếu trong payroll/ERP;

• một tham chiếu thanh toán gắn với nhiều giao dịch;

• một giao dịch xuất hiện hai lần trong file đối soát;

• dữ liệu công bị điều chỉnh sau khi đã phát sinh giao dịch.

Mỗi chênh lệch cần có mã case, người phụ trách, mức ưu tiên, bằng chứng, thời hạn nội bộ và kết quả cuối. Không xóa bản ghi chênh lệch chỉ vì đã sửa số liệu.

13. Quy trình xử lý cảnh báo và điều tra

```mermaid
flowchart TD
A["Tạo cảnh báo"] --> B["Sàng lọc và ưu tiên"]
B --> C["Bảo vệ tài khoản và giao dịch"]
C --> D["Thu thập bằng chứng"]
D --> E["Kết luận và xử lý"]
E --> F["Khắc phục nguyên nhân"]
F --> G["Đo hiệu quả và cập nhật quy tắc"]
```

Bước 1: Sàng lọc

Xác minh cảnh báo có dữ liệu đầy đủ không, giao dịch đang ở trạng thái nào và thiệt hại có thể tiếp tục hay không.

Bước 2: Hạn chế thiệt hại

Tùy thẩm quyền, có thể thu hồi phiên, tạm khóa tài khoản, giữ giao dịch chưa chi, vô hiệu hóa thay đổi tài khoản nhận hoặc dừng một luồng tích hợp. Biện pháp phải tương xứng và có khả năng khôi phục nếu cảnh báo sai.

Bước 3: Bảo toàn bằng chứng

Ghi nhận log, phiên bản dữ liệu, cấu hình, mã giao dịch, tham chiếu thanh toán, lịch sử thay đổi và liên lạc hỗ trợ. Không sửa trực tiếp bằng chứng gốc.

Bước 4: Phân tích nguyên nhân

Phân biệt chiếm tài khoản, gian lận nội bộ, lỗi dữ liệu, lỗi hệ thống và lạm dụng chính sách. Xem xét cả nguyên nhân kỹ thuật lẫn lỗ hổng quy trình.

Bước 5: Xử lý và thông báo

Thực hiện theo hợp đồng, quy định nội bộ và yêu cầu pháp lý. Không tự ý kết luận công khai hoặc xử lý kỷ luật khi chưa hoàn thành quy trình xác minh phù hợp.

Bước 6: Ngăn tái diễn

Sửa quy tắc, phân quyền, mã nguồn, quy trình, tài liệu đào tạo và theo dõi hiệu quả sau thay đổi.

14. Bảo vệ người lao động khi hệ thống cảnh báo sai

Chống gian lận không nên biến thành rào cản khiến người lao động hợp lệ không tiếp cận được quyền lợi đúng lúc.

Doanh nghiệp cần có:

• thông báo rõ rằng giao dịch đang được xác minh, không gắn nhãn “gian lận” khi chưa kết luận;

• kênh khiếu nại dễ sử dụng;

• mã hồ sơ và trạng thái xử lý;

• thời hạn nội bộ theo mức độ ảnh hưởng;

• cơ chế mở khóa hoặc phục hồi nhanh khi xác minh hợp lệ;

• người có thẩm quyền xem xét ngoại lệ;

• đo tỷ lệ chặn nhầm theo từng quy tắc;

• rà soát xem quy tắc có gây bất lợi không hợp lý cho một nhóm người dùng hay không.

Đội hỗ trợ không nên nhìn thấy nhiều dữ liệu hơn mức cần thiết. Thông tin điều tra phải được phân quyền riêng để bảo vệ quyền riêng tư và tránh làm lộ quy tắc chống gian lận.

15. Các chỉ số quản trị rủi ro nên theo dõi

Các chỉ số phải có định nghĩa thống nhất. “Gian lận đã ngăn chặn” chỉ nên ghi nhận khi có căn cứ, tránh thổi phồng mọi giao dịch bị từ chối thành thiệt hại đã phòng tránh.

16. Checklist kiểm thử gian lận trước go-live

Danh tính và tài khoản

• [ ] Kích hoạt bằng mã nhân viên của người khác bị từ chối.

• [ ] Thử nhiều lần hoặc tự động hóa tạo cảnh báo/giới hạn phù hợp.

• [ ] Đổi thiết bị và khôi phục tài khoản yêu cầu xác minh đúng mức.

• [ ] Phiên cũ bị thu hồi sau thay đổi thông tin xác thực.

• [ ] Nhân viên hỗ trợ không thể bỏ qua kiểm soát một mình.

Tài khoản nhận tiền

• [ ] Đổi tài khoản yêu cầu tái xác thực.

• [ ] Thông báo thay đổi được gửi đúng kênh.

• [ ] Giao dịch ngay sau thay đổi được xử lý theo chính sách rủi ro.

• [ ] Một tài khoản nhận xuất hiện ở nhiều nhân viên được phát hiện.

• [ ] Nhân viên không có quyền không xem hoặc sửa được dữ liệu đầy đủ.

Công, lương và hạn mức

• [ ] Công chưa duyệt không tạo hạn mức nếu chính sách yêu cầu đã duyệt.

• [ ] Công sửa muộn làm hạn mức được tính lại đúng.

• [ ] Dữ liệu cũ không ghi đè phiên bản mới.

• [ ] Nhân viên nghỉ việc bị tạm dừng theo ngày hiệu lực.

• [ ] Thay đổi công thức có phê duyệt và nhật ký trước/sau.

Giao dịch và thanh toán

• [ ] Gửi lặp cùng idempotency_key không chi hai lần.

• [ ] Cùng một khóa nhưng khác số tiền bị từ chối.

• [ ] Timeout tạo trạng thái chưa rõ, không tự động gửi lệnh mới.

• [ ] Callback giả mạo hoặc lặp bị từ chối.

• [ ] Giao dịch hoàn trả được cập nhật hạn mức theo quy trình đã duyệt.

Gian lận nội bộ

• [ ] Một người không thể tự tạo, duyệt và đối soát ngoại lệ.

• [ ] Quyền tạm thời tự hết hạn.

• [ ] Xuất dữ liệu hàng loạt tạo log và cảnh báo.

• [ ] Hành động quản trị không thể xóa khỏi dấu vết kiểm toán thông thường.

• [ ] Quyền của người chuyển việc/nghỉ việc được thu hồi đúng hạn.

Đối soát và điều tra

• [ ] Thiếu giao dịch ở một trong ba nguồn tạo case chênh lệch.

• [ ] Case có chủ sở hữu và lịch sử xử lý.

• [ ] Bằng chứng được bảo toàn, không chỉnh sửa trực tiếp.

• [ ] Người dùng bị khóa nhầm có kênh khiếu nại và mở lại.

• [ ] Diễn tập tình huống chiếm tài khoản và giao dịch sai đã hoàn tất.

17. Khung pháp lý và bảo vệ dữ liệu khi chống gian lận

Phòng chống gian lận có thể sử dụng dữ liệu tài khoản, thiết bị, hành vi và lịch sử giao dịch. Vì vậy, doanh nghiệp phải đồng thời bảo đảm mục đích xử lý rõ ràng, dữ liệu phù hợp và quyền riêng tư của người lao động.

Tại Việt Nam, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 có hiệu lực từ ngày 1/1/2026. Nghị định 356/2025/NĐ-CP, cũng có hiệu lực từ ngày 1/1/2026, quy định chi tiết một số điều và biện pháp thi hành Luật. Tùy vai trò và luồng thanh toán, doanh nghiệp còn phải xem xét Nghị định 52/2024/NĐ-CP về thanh toán không dùng tiền mặt cùng các quy định chuyên ngành liên quan.

Việc theo dõi gian lận không đồng nghĩa với thu thập mọi dữ liệu có thể. Mỗi tín hiệu phải gắn với mục đích, mức cần thiết, thời hạn lưu, quyền truy cập và quy trình giải thích/xử lý khi người lao động phản hồi. Những kết luận pháp lý cụ thể cần được rà soát trên kiến trúc và hợp đồng thật.

Về quản trị an toàn thông tin, NIST Cybersecurity Framework 2.0 cung cấp cách tiếp cận theo các chức năng Govern, Identify, Protect, Detect, Respond và Recover. OWASP Application Security Verification Standard có thể làm cơ sở kiểm thử các kiểm soát kỹ thuật của ứng dụng và API. Đây là khung tham chiếu, không thay thế nghĩa vụ pháp lý hay đánh giá rủi ro riêng của doanh nghiệp.

<!-- MỤC CHỜ NHÂN KIỆT HOÀN THIỆN (ẩn khi đăng) — Product/Risk/IT/Payroll/Pháp lý cần xác nhận mô hình quản trị rủi ro thật; KHÔNG công bố ngưỡng cảnh báo/logic chấm điểm/giới hạn chống gian lận khi chưa được phê duyệt (tránh giúp đối tượng xấu né kiểm soát).
## 18. Những thông tin Nhân Kiệt cần xác nhận trước khi xuất bản chính thức

Để nội dung phản ánh đúng Lương Ngày, Product, Risk, IT, Payroll và Pháp lý cần xác nhận:

• mô hình quản trị rủi ro và đầu mối chịu trách nhiệm;

• trạng thái giao dịch chính thức và cách xử lý kết quả chưa rõ;

• cơ chế định danh, xác thực và khôi phục tài khoản;

• quy trình đổi tài khoản nhận tiền;

• quy tắc idempotency và đối soát đang sử dụng;

• nhóm tín hiệu gian lận có thể công khai mà không làm suy yếu kiểm soát;

• cách phân tách nhiệm vụ và phê duyệt ngoại lệ;

• thời gian, kênh và thẩm quyền tạm khóa/mở khóa;

• kênh khiếu nại và hỗ trợ người lao động;

• chỉ số rủi ro đã được định nghĩa và có dữ liệu thực tế;

• quy trình điều tra, bảo toàn bằng chứng và xử lý sự cố;

• trách nhiệm giữa Nhân Kiệt, doanh nghiệp và đối tác thanh toán.

Không nên công bố ngưỡng cảnh báo, logic chấm điểm chi tiết, giới hạn chống gian lận hoặc kết quả vận hành khi chưa được phê duyệt. Những thông tin này có thể giúp đối tượng xấu tìm cách né kiểm soát.

-->

Kết luận

Quản trị rủi ro EWA hiệu quả dựa trên nhiều lớp kiểm soát: dữ liệu nguồn đáng tin cậy, định danh đúng người, thay đổi người nhận được xác minh, giao dịch có idempotency, trạng thái thanh toán rõ ràng, quyền nội bộ được tách, cảnh báo có thể giải thích và đối soát đến từng giao dịch.

Mục tiêu không phải chặn càng nhiều càng tốt, mà là ngăn thiệt hại đúng lúc trong khi vẫn bảo vệ người lao động hợp lệ. Nếu doanh nghiệp đang đánh giá triển khai Lương Ngày, hãy chuẩn bị các kịch bản rủi ro, sơ đồ phân quyền và tình huống UAT cần kiểm thử, rồi tìm hiểu Lương Ngày cho doanh nghiệp để yêu cầu tài liệu kiểm soát giao dịch, đối soát và phạm vi pilot phù hợp.

Nguồn tham khảo

• Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15

• Nghị định 356/2025/NĐ-CP hướng dẫn Luật Bảo vệ dữ liệu cá nhân

• Nghị định 52/2024/NĐ-CP về thanh toán không dùng tiền mặt

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

Tác giả: Trần Văn Tài — Trợ Lý Tổng Giám Đốc Chiến Lược, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Tư vấn giải pháp Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Lương Ngày cho doanh nghiệp

<!-- GHI CHÚ NỘI BỘ (ẩn khi đăng):
• Gợi ý ảnh đã cài: (1) bản đồ rủi ro theo vòng đời (2) mô hình ba lớp (3) vòng đời giao dịch trạng thái chưa rõ (4) checklist kiểm thử gian lận.
• Schema: Article/BlogPosting, BreadcrumbList, FAQPage, Organization, Person.
• Chưa gắn link tới bài chưa tồn tại: doi-soat-giao-dich-ewa-voi-payroll-va-ke-toan (bài 18). -->