Toàn cầu, trong số nạn nhân đã báo cáo cho đơn vị thanh toán, chỉ 30% thu hồi được ít nhất một phần (GASA — Global State of Scams 2025, 42 thị trường). Nghĩa là hướng "xử lý sau khi mất tiền" đã được thử ở quy mô lớn và nó không hiệu quả.

Nội dung tuyên truyền hiện tại cũng là đọc/xem thụ động, không tạo được phản xạ đúng lúc người dùng thật sự bị dẫn dắt.

Khoảng trống thật sự nằm ở một chỗ: không có ai nói chuyện với người dùng ngay tại giây họ sắp bấm nút chuyển.

1.3 Vì sao thời điểm là bây giờ

• Thanh toán tức thời phổ biến, không còn cửa sổ hoàn tác — tiền đi là đi.
• Quy định siết định danh chính chủ đang đi cùng chiều với sản phẩm này.
• 49,57 triệu ví điện tử đã kích hoạt — quy mô đủ để một lớp bảo vệ chung có ý nghĩa.
• LLM tiếng Việt đã đủ tốt để đối thoại phản biện trong vài giây, ở chi phí chấp nhận được.

1.4 Người dùng mục tiêu

• Chính: người 32–55 tuổi, giao dịch số thường xuyên, có tài chính nhàn rỗi — nhóm hay nhận link/lời mời đầu tư/yêu cầu chuyển tiền, và thường quá tự tin vào kinh nghiệm cá nhân.
• Phụ: người tin cậy do chính người dùng chỉ định (chỉ nhận cảnh báo, không có quyền điều khiển giao dịch) và đội vận hành nội bộ dùng admin console.

2. Giải pháp

2.1 Ba lớp bảo vệ chạy ngay trong luồng chuyển tiền

Bấm chuyển tiền → Cổng 1 → Cổng 2 → (nếu rủi ro) Trợ lý → Người dùng tự quyết

Cổng 1 — chặn cứng. Đối chiếu người nhận với danh sách đen (số tài khoản, số điện thoại, tên miền). Khớp là chặn, app chuyển thẳng sang màn BLOCK-01, không có nút vượt qua.

Cổng 2 — chấm rủi ro. Mô hình hành vi kết hợp luật tĩnh, cho ra ALLOW / REQUIRE_CONFIRMATION / BLOCK kèm reason_codes. Không dùng LLM ở cổng này — quyết định chặn tiền phải tái lập được và giải thích được.

Lớp 3 — fraud_intervention_agent. Chỉ mở khi rủi ro trung bình/cao (những mức không bị chặn cứng): agent hội thoại hỏi làm rõ, tra kịch bản lừa đảo đã số hoá, giải thích lý do nghi ngờ bằng tiếng Việt có trích nguồn. Người dùng nhập bằng bàn phím hoặc nói — bản ghi âm được chuyển thành văn bản rồi chạy đúng lượt hội thoại đó (agent trả lời bằng chữ, chưa nói lại thành tiếng).

Nguyên tắc xuyên suốt: agent không tự huỷ giao dịch. Nó tạo ma sát đúng lúc và cung cấp căn cứ — cắt đúng thứ kẻ gian cần nhất là sự vội. Quyết định cuối vẫn của người dùng.

2.2 Các thành phần bổ trợ

• Kiểm tra chủ động — người dùng tự gửi link, số điện thoại, số tài khoản nghi ngờ để nhận đánh giá trước khi tương tác, đối chiếu cả danh sách cảnh báo lẫn trustlist số hiệu chính chủ của cơ quan/ngân hàng.
• Người tin cậy — người dùng chỉ định người thân nhận cảnh báo tối thiểu khi giao dịch bất thường; một lớp kiểm tra chéo ngoài bản thân người dùng, không trao quyền điều khiển.
• Bản tin cảnh báo — service crawler riêng thu thập tin lừa đảo từ nguồn tin cậy, viết lại cho dễ đọc, staff duyệt rồi mới đẩy vào app. Endpoint GET /news chỉ trả bài trạng thái APPROVED.
• Báo cáo cộng đồng — người dùng gửi fraud_reports; số tài khoản bị cảnh báo tra lại được qua GET /accounts/{account_number}/warning-status.
• Admin console phân quyền theo vai trò — tài khoản staff tách hẳn khỏi tài khoản người dùng. Nhóm điều hành: Overview, FinOps, Fraud, UserBehaviour, FlaggedAccounts, Reports, NewsReview, Monitor. Nhóm kỹ thuật: CommandCenter, SystemHealth, AgentRag, TracesLogs, SecurityAudit, AlertRules, Admins. Mỗi lượt AI đọc lại được: tra gì, trích kịch bản nào, độ trễ và chi phí bao nhiêu.
• Game FMV — mô phỏng tình huống lừa đảo bằng video tương tác. Hiện hiển thị "Sắp ra mắt".

3. Giải pháp kỹ thuật

3.1 Kiến trúc — lớp AI tách hẳn khỏi lớp tiền

Bốn tầng, phụ thuộc một chiều:

Ràng buộc quan trọng nhất là dòng thứ ba: tầng AI không được tự tay chuyển hay giữ tiền. Nó chỉ trả về phán quyết. Nhờ vậy một lỗi ở tầng model không bao giờ trở thành lỗi số dư.

Chỉ nhánh cảnh báo mới tốn model. Nhánh ALLOW đi thẳng, không phát sinh chi phí LLM — đây là điều khiến mô hình chi phí đứng vững ở quy mô lớn.

3.2 Cổng 2 — hybrid risk engine

Mô hình trả lời "người này thường giao dịch thế nào", không trả lời "giao dịch này có lừa đảo không". Nó chỉ dựng baseline hành vi; điểm bất thường là hàm tất định tính trên baseline đó — nhờ vậy mọi phán quyết chặn tiền tái lập được và giải thích được bằng reason_codes.

Hai mô hình, train thủ công, serve bằng tra bảng:

Tách hai nhóm feature vì lúc train có bộ khảo sát dài (9 trường hành vi), lúc serve chỉ có KYC + survey ngắn (4 trường profile).

Chọn baseline theo độ chắc chắn. User đã có trong user_clusters → dùng cụm đã biết; confidence ≥ 0.70 → đúng một cụm; 0.50–0.70 → trộn 2 cụm cao nhất theo trọng số; < 0.50 → GENERAL_FALLBACK. User có ≥ 10 giao dịch sạch trong 90 ngày được dựng thêm baseline cá nhân từ chính lịch sử.

Chấm điểm:

Thiếu số dư trước giao dịch thì bỏ balance_ratio và renormalize phần còn lại — không coi thiếu dữ liệu là rủi ro thấp. Ngưỡng HIGH 60 / MEDIUM 35, hạ còn 55 / 30 khi rơi về GENERAL_FALLBACK vì baseline chung kém chắc chắn hơn. Khớp blacklist thì trả thẳng CRITICAL / BLOCK, anomaly_score = 100, không chấm component nào.

Lớp luật apply_behavioral_policy ép REQUIRE_CONFIRMATION bất kể điểm số khi: vượt ngưỡng vét số dư (0.30 / 0.45 / 0.60 tuỳ người nhận mới / quen / thân), chia nhỏ giao dịch tới cùng người nhận trong 10 phút vượt ngưỡng động, hoặc tiếp tục chuyển tới người nhận đã bị cảnh báo.

Artifact có checksum. Model ghi atomic bằng os.replace (vpay_anomaly_model.joblib + vpay_user_clusters.csv + vpay_training_report.json kèm artifact_sha256, dataset_sha256, model_version=vpay-anomaly-v2). Lúc nạp, service verify sha256 trước khi joblib.load và từ chối artifact lệch schema_version. Giới hạn đã biết và ghi trong test: checksum bắt file hỏng hoặc bản cũ sót lại, không chặn được người có quyền ghi thư mục vì họ sửa được cả report.

3.3 fraud_intervention_agent

Orchestrator tự xây, không dùng framework agent. Chia tầng:

Luồng một lượt: input_guard chặn ý đồ gây hại và câu dò danh tính → UNDERSTAND (ngoài phạm vi thì dừng) → PLAN (nếu cần hỏi lại thì dừng, hỏi người dùng) → INVESTIGATE chọn tool theo router tri thức, tra pgvector corpus 30 kịch bản lừa đảo cùng blacklist SĐT/domain/số tài khoản và trustlist → SYNTHESIZE → decide_intervention → respond, qua output_guard + redact PII trước khi trả về.

• Giọng nói (một chiều — speech-to-text): POST /agents/conversations/turn/voice nhận một request multipart, server chuyển audio thành văn bản rồi chạy tiếp đúng lượt đó, không thêm nhánh nào trong orchestrator. Không lưu audio. Transcript đi qua redact PII như tin nhắn gõ tay. Chưa có text-to-speech — xem Giai đoạn 2.
• Nguyên tắc phát ngôn: không bao giờ khẳng định "tài khoản này an toàn", chỉ nói "chưa ghi nhận".
• Streaming: client mobile đọc SSE bằng fetch của expo/fetch (RN buffer toàn bộ response nên fetch mặc định làm stream mất tác dụng). Client chỉ giữ session_id; hội thoại và số lượt do server giữ trong chat_sessions, có cột version làm optimistic lock (sửa đồng thời → 409).

3.4 Stack

3.5 Rate limit và backpressure

Vượt ngưỡng trả 429, cạn pool DB trả 503 pool-timeout — cả hai kèm Retry-After.

3.6 Ba quyết định kỹ thuật đáng chú ý

1. Fail-open có chủ đích. Mất Redis thì request vẫn đi tiếp, chỉ mất lớp chặn tần suất. Redis hỏng không được phép biến thành sự cố chặn người dùng chuyển tiền.
2. Hai engine DB. Một engine cho transaction thường, một engine AUTOCOMMIT pool riêng cho đường chỉ SELECT — blacklist lookup và RAG retrieval. Đường đọc nóng không tranh pool với đường ghi tiền.
3. Trace tự động, đánh dấu suy giảm. Middleware chỉ mở Trace cho path /api/v1/agents; span con lồng vào qua contextvar nên route handler không phải biết gì về tracing. Lượt rơi vào nhánh dự phòng được đánh dấu traces.degraded = True — vì HTTP vẫn 2xx nên nếu chỉ nhìn status_code thì success rate sẽ báo 100% sai lệch.

3.7 Bảo mật & riêng tư

JWT access HS256 sống ngắn + refresh token opaque lưu hash trong DB, xoay vòng mỗi lần /auth/refresh. Claim typ tách hẳn tài khoản user (app) và staff (console); staff đăng nhập thêm được bằng Google qua Firebase Admin SDK. Định danh người dùng là SĐT VN nội địa + PIN, chuẩn hoá tập trung một chỗ.

Quy ước tiền: số nguyên VND, không dùng float; mọi thay đổi balance phải sinh một row transactions trong cùng DB transaction. Người nhận lưu dưới dạng HMAC ổn định (counterparty_account_hash), không lưu thô. Redact PII hai chiều ở tầng agent, phân quyền theo vai trò, nhật ký thao tác quản trị (admin_audit_log).

3.8 Triển khai

Hạ tầng khai báo bằng Terraform: Cloud Run service + job migrate, Artifact Registry, Redis chạy trên máy ảo GCE trong VPC riêng (không phải Memorystore), Secret Manager, Workload Identity Federation, Firebase. Terraform không provision database — Neon nằm ngoài GCP, chỉ có connection string trong Secret Manager.

CI chạy song song backend (ruff + pytest), admin, landing, mobile-web; CD chỉ chạy khi CI xanh, xác thực bằng OIDC/WIF nên không giữ khoá service account. Backend không chạy alembic upgrade head lúc khởi động — nhiều instance Cloud Run khởi động song song sẽ chạy trùng; migration là Cloud Run Job riêng.

4. Tính khả thi

4.1 Công nghệ — đã chạy

Không phải bản vẽ. Đang chạy thật trên 3 site Firebase Hosting + backend Cloud Run: hai cổng kiểm tra, agent hội thoại (nhập bằng chữ hoặc bằng giọng nói), trace, admin console phân quyền, app di động, landing page, service crawler tin cảnh báo, CI/CD.

4.2 Đã đo, không mock

Toàn bộ eval chạy gọi thật OpenRouter, thật Neon/pgvector, đúng đường chạy mà API dùng:

FPR 25,6% là con số phải nói thẳng: cứ 4 cảnh báo thì có 1 báo động sai. Nó chấp nhận được chỉ vì mức đó không chặn giao dịch — nó mở hội thoại. Chặn cứng chỉ xảy ra khi khớp danh sách đen.

4.3 Chính sách — đi cùng chiều

Xu hướng siết định danh chính chủ và tăng trách nhiệm của đơn vị thanh toán trong phòng chống lừa đảo đang đi cùng chiều với sản phẩm. Console có sẵn KPI, nhật ký thao tác và khả năng đọc lại từng lượt AI — đây chính là thứ hồ sơ tuân thủ đòi hỏi.

4.4 Con người — cần bổ sung một vai trò

Vận hành thật cần thêm một vai trò chuyên trách dữ liệu cảnh báo: tiếp nhận nguồn, đối soát, xử lý khiếu nại chặn nhầm. Các vai trò còn lại (SRE, developer, security, điều hành) đã có chỗ đứng sẵn trong console.

4.5 Chi phí vận hành

Chỉ nhánh cảnh báo tốn model, chạy trên model hạng flash-lite. Nhánh ALLOW không gọi LLM. So sánh đúng không phải với "chi phí một API call" mà với chi phí một cuộc gọi tổng đài xử lý ca mất tiền — chênh nhau nhiều bậc.

4.6 Rủi ro đã nhận diện

4.7 Đo hiệu quả bằng gì

Tỉ lệ tự huỷ giao dịch sau hội thoại, tỉ lệ báo động sai, tỉ lệ rời bỏ tại màn cảnh báo, độ trễ p50/p95, chi phí mỗi lượt.

5. Hướng phát triển

Giai đoạn 1 — ĐÃ CHẠY

Hai cổng kiểm tra + fraud_intervention_agent + kiểm tra chủ động + người tin cậy + bản tin cảnh báo + trace + admin console phân quyền + app di động.

Giai đoạn 2 — KẾ TIẾP

Hội thoại bằng giọng nói hai chiều. Hiện giọng nói mới đi một chiều: người dùng nói, hệ thống chuyển thành văn bản, agent trả lời bằng chữ. Bước tiếp theo là đối thoại thoại-với-thoại thật sự — bổ sung text-to-speech tiếng Việt, streaming song công, phát hiện ngắt lời (barge-in), tách lượt nói bằng VAD, kéo độ trễ mỗi lượt xuống ngưỡng nghe được là hội thoại chứ không phải chờ máy xử lý. Đây không phải tính năng trang trí: người đang bị dẫn dắt qua điện thoại thường đang cầm máy áp tai, không rảnh mắt để đọc — muốn cắt ngang được kịch bản của kẻ gian thì trợ lý phải nói vào đúng khoảnh khắc đó. Ràng buộc giữ nguyên: không lưu audio, redact PII trước khi rời máy.

Cùng giai đoạn: quy trình khiếu nại khi bị chặn nhầm, hạ FPR của risk engine bằng dữ liệu vận hành thật, dọn thư mục chết còn sót từ scaffold.

Giai đoạn 3 — MỞ RỘNG

Tối đa hoá data pipeline cho cả hai luồng đang phụ thuộc dữ liệu ngoài — luồng kiểm tra của trợ lý (RAG kịch bản, danh sách đen) và luồng bản tin. Hiện crawler mới chạy trên một tập nguồn RSS/HTML hằng ngày; đích đến là pipeline đầy đủ năm chặng:

Mấu chốt: hiện tại corpus kịch bản là tài sản tĩnh — soạn một lần, dùng mãi. Kịch bản lừa đảo thì đổi hằng tuần. Pipeline này biến corpus thành tài sản sống, và đây chính là chỗ khoảng cách với đối thủ nới rộng theo thời gian.

Cùng giai đoạn: nối dữ liệu cảnh báo chính thức từ cơ quan chức năng và ngân hàng, học từ nhãn thực tế — mỗi ca chặn đúng/chặn nhầm quay lại làm dữ liệu huấn luyện, khép kín vòng lặp dữ liệu. Kèm theo đó là tự động hoá vòng train risk engine (hiện train chạy thủ công, không có job tự động).

Giai đoạn 4 — FMV (SẮP TỚI)

Game mô phỏng lừa đảo bằng video tương tác ngay trong ví: người chơi chọn nhánh xử lý, hệ thống giải thích dấu hiệu nhận biết sau mỗi quyết định. Kết quả chơi trở thành tín hiệu đầu vào cho hồ sơ rủi ro — người từng sập bẫy trong mô phỏng sẽ được cảnh báo sớm hơn ở đời thật. Hiện hiển thị "Sắp ra mắt" trên app.

Lợi thế dài hạn

Với ví điện tử triển khai VPay: chi phí sự cố giảm vì chặn ngay từ đầu vào, tổng đài nhẹ đi vì agent xử lý lớp một, tuân thủ dễ hơn vì mọi lượt AI đọc lại được.

Đối thủ sao chép được kiến trúc trong vài tháng. Cái họ không sao chép được là dữ liệu cảnh báo đã tích luỹ và vòng lặp học từ nhãn thực tế — "ví an toàn nhất" là định vị chỉ có được sau thời gian, không mua được bằng tiền.

Nguồn số liệu bài toán: Báo Công an nhân dân 2025, Tuổi Trẻ 25/4/2025 (đã ẩn danh nạn nhân), GASA — Global State of Scams 2025. Số liệu kỹ thuật và eval: P-029/README.md, P-029/ARCHITECTURE.md, P-029/docs/eval-evidences.md.