Những trường hợp hệ thống EWA phải dừng giao dịch để kiểm tra

Hệ thống EWA nên dừng hoặc giữ giao dịch ở trạng thái chờ khi chưa đủ bằng chứng rằng yêu cầu là đúng người, đúng công, đúng số tiền, đúng tài khoản và không trùng với một giao dịch khác. Nguyên tắc an toàn là fail-closed: dữ liệu quan trọng chưa rõ thì không tự đoán và không tiếp tục chi.

Dừng giao dịch không phải là lỗi

Một hệ thống tài chính tốt không được đánh giá bằng việc “luôn cho qua”.

Có những thời điểm dừng lại là hành vi đúng:

• dữ liệu công đang mâu thuẫn;
• công vừa bị sửa và chưa duyệt lại;
• tài khoản đang chờ xác minh;
• số tiền đã thay đổi so với lúc người dùng mở màn hình;
• giao dịch trước đang chờ;
• phát hiện dấu hiệu trùng;
• ngân hàng chưa trả trạng thái chắc chắn;
• hệ thống mất kết nối với nguồn quan trọng.

Mục tiêu của stop condition là ngăn một trạng thái chưa chắc chắn trở thành thiệt hại tiền thật.

Nhóm 1: Dữ liệu công chưa đủ tin cậy

Hệ thống nên dừng khi:

• chưa có công đã duyệt;
• công vừa bị sửa;
• hai nguồn công cho kết quả khác nhau;
• bản ghi nghi trùng;
• mã chấm công không khớp người;
• ca hoặc ngày chưa xác định được;
• người lao động vừa điều chuyển nhưng assignment chưa rõ.

Công là nguồn gốc của phần tiền đã hình thành. Nếu công chưa chắc chắn, bước tính tiền cũng chưa chắc chắn.

Nhóm 2: Số tiền yêu cầu không còn khớp dữ liệu máy chủ

Người lao động có thể mở app và nhìn thấy một số tiền tại thời điểm A.

Đến lúc bấm xác nhận, dữ liệu có thể đã thay đổi vì:

• có công bị sửa;
• có giao dịch khác vừa thành công;
• phần đã nhận trong kỳ tăng;
• chính sách vừa chuyển phiên bản;
• khoản giữ thay đổi theo cấu hình.

Vì vậy máy chủ cần tính lại.

Nếu số yêu cầu lớn hơn số mới đủ điều kiện, hệ thống không nên dùng số cũ từ màn hình.

Nhóm 3: Tài khoản nhận chưa đủ điều kiện

Giao dịch nên dừng khi:

• tài khoản chưa được xác minh;
• tên chủ tài khoản không khớp;
• tài khoản vừa bị thay đổi;
• hồ sơ định danh liên quan đang chờ kiểm tra;
• trạng thái tài khoản không còn hợp lệ.

Không nên “cho qua tạm” rồi sửa sau, vì tiền có thể đã chuyển sang người nhận sai.

Nhóm 4: Đã có giao dịch trước đang xử lý

Nếu cùng người lao động đã có một giao dịch trên cùng phần giá trị ở trạng thái:

• processing;
• pending;
• unknown;

thì yêu cầu mới có thể tạo rủi ro chi trùng.

Hệ thống cần khóa phần giá trị liên quan và không cho một luồng thứ hai sử dụng lại.

Đây là nơi concurrency control và idempotency phối hợp với nhau.

Nhóm 5: Timeout hoặc trạng thái ngân hàng chưa rõ

Timeout không đồng nghĩa thất bại.

Có thể lệnh đã được ngân hàng xử lý nhưng phản hồi chưa về.

Quy tắc an toàn:

1. giữ giao dịch chờ;
2. không tạo mã mới;
3. không mở lại phần giá trị;
4. tra soát;
5. kiểm tra bằng chứng độc lập;
6. chỉ kết luận khi đủ dữ liệu.

Không nên retry tiền theo kiểu “thử lại xem sao”.

Nhóm 6: Dấu hiệu giao dịch trùng

Cần dừng nếu phát hiện:

• cùng request ID;
• cùng idempotency key;
• cùng người, cùng số tiền, sát thời gian bất thường;
• hai tiến trình cùng giữ một phần giá trị;
• một lệnh đã có kết quả nhưng lại được gửi lần nữa.

Một tín hiệu trùng không nhất thiết chứng minh gian lận; nhưng nó đủ để buộc hệ thống kiểm tra.

Nhóm 7: Chính sách không xác định được phiên bản áp dụng

Eligibility Engine phải biết policy version nào đang hiệu lực.

Nếu hệ thống không xác định được:

• chính sách khách hàng;
• ngày hiệu lực;
• hạn mức;
• phần giữ;
• quyền sử dụng;

thì không nên tự lấy một cấu hình mặc định không được xác nhận.

Một chính sách “không rõ” cũng là stop condition.

Nhóm 8: Người lao động không còn ở trạng thái phù hợp

Có thể dừng nếu:

• người lao động đã nghỉ;
• assignment đã hết hiệu lực;
• bị điều chuyển nhưng nơi mới chưa hoàn tất;
• hồ sơ bị khóa theo quy trình;
• kỳ liên quan đã đóng.

Cần dựa vào trạng thái có hiệu lực theo thời gian, không chỉ trạng thái hiện tại chung chung.

Nhóm 9: Hệ thống nguồn quan trọng đang lỗi

Ví dụ:

• nguồn công không truy cập được;
• Eligibility Engine không phản hồi;
• Payment Orchestration mất kết nối;
• dịch vụ xác minh tài khoản gián đoạn;
• dữ liệu ngân hàng không thể kiểm chứng.

Không phải mọi lỗi đều cần dừng toàn hệ thống.

Nên dừng đúng phạm vi bị ảnh hưởng.

Ví dụ: nếu chỉ một khách hàng lỗi nguồn công, có thể giữ yêu cầu của khách hàng đó mà không ảnh hưởng khách hàng khác.

Nhóm 10: Công tắc dừng khẩn cấp được kích hoạt

Trong sự cố nghiêm trọng, doanh nghiệp có thể cần ngăn lệnh mới.

Các tình huống có thể gồm:

• nghi chi trùng;
• sai người nhận;
• lỗi tính diện rộng;
• sự cố bảo mật;
• mất khả năng xác định trạng thái giao dịch.

Quyền bật/tắt cần:

• giới hạn;
• có log;
• có phê duyệt phù hợp;
• có tiêu chí mở lại.

Không nên để bất kỳ admin thông thường nào có thể bật/tắt luồng tiền mà không để lại dấu vết.

Dừng, giữ chờ và từ chối khác nhau thế nào?

Kết quả	Dùng khi	Ví dụ
Từ chối	Điều kiện chắc chắn không đạt	Không có công đủ điều kiện
Giữ chờ	Chưa đủ bằng chứng	Ngân hàng timeout
Dừng luồng	Có rủi ro hệ thống rộng	Nghi chi trùng diện rộng
Yêu cầu sửa dữ liệu	Dữ liệu nguồn sai	Sai mã chấm công
Yêu cầu xác minh lại	Danh tính/tài khoản chưa chắc	Đổi tài khoản

Không nên dùng cùng một thông báo “giao dịch thất bại” cho mọi trường hợp.

Người lao động nên thấy thông báo gì?

Thông báo nên:

• nói trạng thái thật;
• không gây hiểu nhầm;
• không yêu cầu gửi lại ngay nếu đang chờ;
• có mã tham chiếu;
• chỉ dẫn bước tiếp theo.

Ví dụ:

> “Yêu cầu đang được kiểm tra. Xin không tạo yêu cầu mới cho cùng khoản này cho đến khi có kết quả.”

Không nên hiển thị “thất bại” khi thực tế trạng thái vẫn chưa rõ.

Ai có quyền bỏ qua stop condition?

Về nguyên tắc, rất ít stop condition nên có nút “bỏ qua”.

Nếu có ngoại lệ thủ công, cần:

• quyền cao hơn;
• lý do;
• người phê duyệt;
• log;
• giới hạn phạm vi;
• bằng chứng sau xử lý.

Không nên tạo “superadmin override” chung cho mọi kiểm soát tiền.

Dashboard stop condition nên theo dõi

Có thể theo dõi:

• số yêu cầu bị giữ;
• lý do giữ;
• tuổi giao dịch;
• số pending;
• số duplicate signal;
• số tài khoản đang chờ xác minh;
• số công sửa sau duyệt;
• số override thủ công;
• số lần dùng emergency stop;
• thời gian mở lại.

Nếu một loại stop condition tăng nhanh, đó là tín hiệu cần sửa nguồn gốc.

Kết luận

Hệ thống EWA phải biết khi nào không nên tiếp tục. Những stop condition quan trọng gồm dữ liệu công chưa chắc chắn, số tiền thay đổi, tài khoản đang chờ xác minh, giao dịch trước đang chờ, dấu hiệu trùng, trạng thái ngân hàng chưa rõ và sự cố hệ thống. Fail-closed không làm hệ thống “yếu”; nó là cơ chế giúp tiền chỉ đi khi dữ liệu và trạng thái đủ chắc chắn.

Tác giả: Đỗ Huy Lê — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

Tư vấn Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Tìm hiểu Lương Ngày cho doanh nghiệp