Mở đầu — vì sao bài này quan trọng
Suốt cả khóa học, chúng ta đã đi qua từng mảnh ghép: cách viết requirements, cách model process, cách quản lý stakeholder, cách làm UAT. Nhưng kiến thức rời rạc giống như những viên gạch chưa được xây thành nhà. Bài học này là nơi chúng ta ráp tất cả lại trong một dự án thật, có đầu có cuối: dự án eKYC mobile của một ngân hàng Việt Nam.
Vì sao tôi chọn eKYC làm case study cuối khóa? Vì nó hội tụ đầy đủ những thứ khó nhất mà một BA chuyển từ developer sẽ gặp: bài toán nghiệp vụ ngân hàng phức tạp, ràng buộc pháp lý chặt chẽ (NHNN, Luật Bảo vệ dữ liệu cá nhân), tích hợp công nghệ AI (nhận diện khuôn mặt, OCR giấy tờ), nhiều bên liên quan với lợi ích xung đột, và áp lực thời gian thật. Quan trọng hơn, đây chính là loại dự án mà nền tảng developer của bạn trở thành vũ khí, chứ không phải gánh nặng.
Nếu bạn từng nghĩ "tôi bỏ code để làm BA thì uổng phí mấy năm kỹ thuật" — bài này sẽ cho bạn thấy điều ngược lại. Trong một dự án eKYC, người BA hiểu được sự khác nhau giữa liveness detection client-side và server-side, hiểu được vì sao OCR fail trên CMND mờ, hiểu được latency của một API call tới Cục Cảnh sát — người đó tạo ra giá trị mà một BA "thuần nghiệp vụ" không thể.
Khái niệm cốt lõi
eKYC là gì và vì sao ngân hàng VN lao vào nó
KYC (Know Your Customer) là quy trình định danh khách hàng bắt buộc của ngành ngân hàng — xác minh "bạn đúng là bạn" trước khi mở tài khoản. Truyền thống, KYC làm tại quầy: khách mang CMND/CCCD đến, giao dịch viên đối chiếu mặt người với ảnh trên giấy tờ, photo, nhập liệu. eKYC (electronic KYC) là làm toàn bộ việc đó qua điện thoại, không cần đến quầy.
Tại Việt Nam, eKYC bùng nổ sau khi Ngân hàng Nhà nước ban hành Thông tư 16/2020 (và sau này là 17/2024) cho phép mở tài khoản thanh toán bằng phương thức điện tử. Đây là cú hích pháp lý — trước đó các ngân hàng không dám làm vì sợ vi phạm quy định định danh. TPBank, VPBank, VIB, Techcombank đua nhau ra mắt eKYC trong 2020–2021 vì nó là cánh cửa để giành thị phần khách hàng số.
Bài toán nghiệp vụ điển hình
Hãy lấy một kịch bản cụ thể làm trục xuyên suốt bài: TPBank muốn launch eKYC trên app mobile để giảm thời gian onboard từ 45 phút (tại quầy) xuống còn 5 phút. Đây là bài toán thật, con số thật mà nhiều ngân hàng VN đã đặt ra.
Phân rã bài toán này, một eKYC flow điển hình gồm các bước nghiệp vụ:
- Chụp giấy tờ — khách chụp mặt trước/sau CCCD.
- OCR — hệ thống trích xuất thông tin (họ tên, số CCCD, ngày sinh, quê quán) từ ảnh.
- Verify giấy tờ thật/giả — kiểm tra dấu hiệu giả mạo, ảnh chụp lại màn hình.
- Liveness detection — yêu cầu khách nháy mắt/quay đầu để chứng minh là người thật, không phải ảnh tĩnh hay video.
- Face matching — so khớp khuôn mặt selfie với ảnh trên CCCD (và lý tưởng là với cơ sở dữ liệu C06 - Bộ Công an).
- Sàng lọc rủi ro — đối chiếu danh sách blacklist, AML (chống rửa tiền), sanction list.
- Mở tài khoản — tạo tài khoản, sinh số tài khoản, gửi thông báo.
Vì sao đây là bài toán "khó nuốt" với BA
Mỗi bước trên không chỉ là một feature — nó là một điểm va chạm giữa nghiệp vụ, công nghệ và pháp lý:
- Face matching đạt ngưỡng bao nhiêu thì pass? Đặt threshold 99% thì an toàn nhưng nhiều khách thật bị từ chối (false reject cao, khách bỏ cuộc). Đặt 90% thì thông thoáng nhưng rủi ro gian lận (false accept). Đây là quyết định business dựa trên hiểu biết technical.
- Khách OCR fail vì CCCD mờ thì sao? Cần fallback flow — nhập tay rồi review thủ công? Hay từ chối luôn?
- Dữ liệu sinh trắc học lưu ở đâu, bao lâu? Luật Bảo vệ dữ liệu cá nhân (Nghị định 13/2023) xếp dữ liệu sinh trắc học vào nhóm "nhạy cảm", có yêu cầu riêng.
Tình huống thực tế
Ví dụ 1 — TPBank: cuộc chiến với "tỷ lệ rớt" ở bước liveness
Bối cảnh: Trong dự án eKYC giả định tại TPBank, sau khi launch bản đầu tiên, đội data phát hiện một con số đáng báo động: 38% người dùng bắt đầu flow eKYC nhưng bỏ cuộc ở bước liveness detection (bước nháy mắt/quay đầu). Mỗi khách rớt là một khách hàng tiềm năng mất đi — với chi phí marketing thu hút mỗi lead khoảng 150.000–300.000 đồng, đây là tiền thật chảy ra ngoài.
Diễn giải: BA (vốn là cựu developer) không dừng ở việc báo cáo "tỷ lệ rớt cao". Anh ấy kéo log của SDK liveness, phân tích theo dòng máy điện thoại và phát hiện: trên các máy Android tầm trung (RAM 3GB, camera trước kém), thuật toán liveness chạy chậm, yêu cầu khách quay đầu nhưng frame rate thấp khiến hệ thống không bắt được chuyển động, báo fail dù khách làm đúng. Đây là một insight mà chỉ người hiểu cả nghiệp vụ lẫn kỹ thuật mới đào ra được — một BA thuần nghiệp vụ sẽ chỉ thấy "khách lười không làm theo hướng dẫn".
BA viết một requirement mới: hạ độ phức tạp của thử thách liveness (challenge) một cách thích ứng (adaptive) dựa trên năng lực thiết bị, và thêm hướng dẫn trực quan dạng animation thay vì chữ. Đồng thời đề xuất nới ngưỡng timeout từ 8 giây lên 15 giây cho nhóm máy yếu.
Bài học: Trong dự án có thành phần AI/ML, data của chính sản phẩm là nguồn requirements quan trọng nhất. Nền developer giúp BA đọc được log, hiểu được vì sao một thuật toán fail, và đề xuất giải pháp khả thi về mặt kỹ thuật chứ không phải mong ước viển vông.
Ví dụ 2 — VPBank: bài toán threshold face matching và xung đột stakeholder
Bối cảnh: Tại một ngân hàng cỡ VPBank, khi thiết kế eKYC, có ba phòng ban ngồi cùng bàn với ba mong muốn xung đột nhau:
- Phòng Phát triển khách hàng (Sales/Growth): "Cho tôi flow thật mượt, đừng để khách rớt. Đặt threshold thấp thôi."
- Phòng Quản lý rủi ro & Tuân thủ: "Một tài khoản giả mạo lọt lưới có thể dẫn tới rửa tiền, phạt từ NHNN hàng tỷ đồng, mất giấy phép. Đặt threshold cao."
- Phòng Công nghệ: "Vendor face-matching cam kết accuracy 98.5% ở threshold X, nếu hạ xuống thì không đảm bảo SLA."
| Threshold | False Reject Rate (khách thật bị từ chối) | False Accept Rate (kẻ gian lọt) |
|---|---|---|
| 95% | 2% (cứ 100 khách thật, 2 người bị từ chối oan) | 0.8% |
| 98% | 6% | 0.2% |
| 99.5% | 15% | 0.02% |
Bài học: Vai trò cốt lõi của BA trong dự án AI không phải là chọn con số ma thuật, mà là biến quyết định kỹ thuật mơ hồ thành đánh đổi (trade-off) rõ ràng mà business có thể cân nhắc. Và luôn nhớ: với mỗi automated decision, hãy thiết kế một fallback cho trường hợp máy sai.
Ví dụ 3 — Một fintech nhỏ: bỏ quên compliance dẫn tới làm lại từ đầu
Bối cảnh: Một fintech startup ở TP.HCM (giả định) xây eKYC cho ví điện tử, đội ngũ toàn dev giỏi, build rất nhanh, 6 tuần ra MVP. Nhưng khi đem đi xin phê duyệt, bộ phận Legal hỏi: "Dữ liệu khuôn mặt và CCCD của khách lưu ở đâu? Có để trên cloud server Singapore không? Khách đã đồng ý cho xử lý dữ liệu sinh trắc học chưa? Màn hình consent đâu?" — Cả đội đứng hình.
Diễn giải: Họ đã xây xong sản phẩm mà thiếu hẳn yêu cầu phi chức năng (non-functional) về data localization và yêu cầu pháp lý về consent. Theo Nghị định 13/2023, dữ liệu sinh trắc học là dữ liệu cá nhân nhạy cảm, phải có sự đồng ý rõ ràng và tách bạch của chủ thể, và việc chuyển dữ liệu ra nước ngoài có ràng buộc. Kết quả: họ phải migrate hạ tầng về data center trong nước, thiết kế lại màn hình consent, bổ sung cơ chế cho phép khách yêu cầu xóa dữ liệu — mất thêm 5 tuần và một khoản chi phí không nhỏ.
Bài học: Trong dự án ngân hàng/fintech, compliance không phải là việc làm cuối cùng — nó là requirement bậc một, phải xuất hiện ngay từ requirements gathering. Một BA cựu dev rất dễ rơi vào bẫy "build trước, tính sau" vì tư duy kỹ thuật thích tối ưu tốc độ giao hàng. Hãy ý thức điểm yếu này.
Hướng dẫn từng bước
Đây là cách tôi khuyên bạn tiếp cận một dự án eKYC (hoặc bất kỳ dự án ngân hàng có yếu tố AI nào) với vai trò BA:
Bước 1 — Định nghĩa bài toán bằng metric kinh doanh, không phải bằng feature. Đừng bắt đầu bằng "chúng ta cần OCR và liveness". Bắt đầu bằng: "giảm onboard time từ 45 phút xuống 5 phút" và "đạt conversion rate từ mở app đến hoàn tất ≥ 60%". Mọi requirement sau đó phải truy ngược về được các metric này.
Bước 2 — Vẽ AS-IS và TO-BE process. Dùng kỹ năng BPMN đã học (Bài 17): vẽ luồng KYC tại quầy hiện tại (AS-IS) và luồng eKYC mục tiêu (TO-BE). Việc này phơi bày những bước nghiệp vụ ẩn — ví dụ bước "đối chiếu blacklist nội bộ" mà quầy đang làm thủ công, dễ bị bỏ sót khi số hóa.
Bước 3 — Phân rã từng bước thành requirement + rủi ro + fallback. Với mỗi bước (OCR, liveness, face match...), viết ba thứ: yêu cầu chức năng (cái máy phải làm), tiêu chí chấp nhận (acceptance criteria — pass ở điều kiện nào), và fallback (làm gì khi máy fail). Bước fallback là nơi BA cựu dev hay quên nhất vì tư duy "happy path" của lập trình.
Bước 4 — Làm việc với đội AI/ML như một peer, không như một người ngoài. Hỏi họ về confusion matrix, về điều kiện ánh sáng/thiết bị mà model hoạt động tốt, về độ trễ (latency) của mỗi lần gọi model. Dịch các con số này thành ngôn ngữ rủi ro và trải nghiệm cho stakeholder business.
Bước 5 — Đưa compliance vào từ đầu. Liệt kê các văn bản pháp lý liên quan: Thông tư về mở tài khoản điện tử của NHNN, Nghị định 13/2023 về bảo vệ dữ liệu cá nhân. Mỗi điều khoản trở thành một non-functional requirement. Mời Legal/Compliance vào ngay từ workshop đầu tiên.
Bước 6 — Định nghĩa UAT scenarios bao gồm cả "đường xấu". UAT eKYC không chỉ test khách hoàn hảo. Phải test: CCCD mờ, ánh sáng kém, người đeo kính, sinh đôi, ảnh chụp lại màn hình (thử gian lận), mạng yếu giữa chừng. Đây là lúc tư duy edge-case của dev cực kỳ giá trị.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi AI như "hộp đen ma thuật" hoặc ngược lại, sa đà vào kỹ thuật. BA cựu dev có hai cực: hoặc tin model "tự khắc đúng", hoặc lao vào tranh luận thuật toán với data scientist. Vị trí đúng là ở giữa: hiểu đủ để hỏi câu hỏi sắc, nhưng giữ vai trò dịch giữa kỹ thuật và nghiệp vụ.
Lỗi 2 — Quên thiết kế luồng thất bại. Mỗi bước tự động đều có xác suất fail. Không có fallback nghĩa là một bộ phận khách hàng bị kẹt cứng và bỏ đi. Mẹo: với mỗi requirement "máy làm X", luôn hỏi "nếu máy không làm được X thì sao?".
Lỗi 3 — Bỏ quên compliance đến phút chót. Như ví dụ 3. Mẹo: tạo một mục "Regulatory & Privacy Requirements" riêng trong tài liệu BRD/SRS ngay từ đầu, không nhồi chung với functional.
Lỗi 4 — Đo lường sai thành công. Nếu chỉ đo "tỷ lệ pass eKYC" mà không đo "tỷ lệ false accept", bạn có thể tự hào về một hệ thống đang để kẻ gian lọt lưới. Mẹo: mỗi metric "tốt" cần đi kèm một metric "rủi ro" đối trọng.
Mẹo vàng: Trong dự án eKYC, hãy luôn giữ một bảng tổng hợp gọi là decision log — ghi lại mọi quyết định trade-off (threshold bao nhiêu, ai duyệt, dựa trên số liệu nào). Khi NHNN hoặc kiểm toán hỏi "vì sao đặt ngưỡng này", bạn có câu trả lời truy vết được. Đây là thói quen mà nền kỹ thuật có version control giúp bạn làm tự nhiên.
Bài tập thực hành
- Vẽ process TO-BE: Lấy kịch bản TPBank (45 phút → 5 phút), vẽ luồng eKYC TO-BE bằng BPMN với đầy đủ 7 bước nghiệp vụ. Đánh dấu rõ mỗi điểm decision (gateway) và mỗi nhánh fallback.
- Viết bảng trade-off: Giả sử vendor face-matching cho bạn confusion matrix ở 3 mức threshold. Viết một bảng tóm tắt (như ví dụ 2) và soạn 5 câu bạn sẽ nói trong cuộc họp để giúp Growth và Risk đi đến thống nhất.
- Liệt kê 8 UAT scenario "đường xấu": Ngoài happy path, hãy nghĩ ra 8 tình huống test khắc nghiệt cho eKYC (gợi ý: giấy tờ, ánh sáng, gian lận, mạng, thiết bị). Với mỗi scenario, ghi kết quả mong đợi của hệ thống.
- Soạn mục Compliance Requirements: Tra cứu Nghị định 13/2023 và viết 5 non-functional requirement liên quan đến xử lý dữ liệu sinh trắc học trong eKYC (consent, lưu trữ, xóa, chuyển dữ liệu, mã hóa).
Tóm tắt
Dự án eKYC ngân hàng là phép thử hoàn hảo cho một BA chuyển từ developer, vì nó đòi hỏi đồng thời ba thứ: tư duy nghiệp vụ, hiểu biết kỹ thuật và nhạy bén pháp lý. Qua case study TPBank và các ví dụ thực tế, chúng ta thấy nền developer không phải gánh nặng mà là lợi thế: bạn đọc được log để tìm root cause của tỷ lệ rớt, bạn hiểu confusion matrix để biến quyết định AI thành trade-off rõ ràng, bạn nghĩ ra edge case để UAT không bỏ sót đường xấu.
Ba bài học cốt lõi cần khắc ghi: (1) định nghĩa bài toán bằng metric kinh doanh và truy ngược mọi requirement về đó; (2) mỗi bước tự động phải có fallback cho trường hợp máy sai; (3) compliance là requirement bậc một, đưa vào ngay từ đầu chứ không phải việc làm cuối cùng. Nắm vững ba điều này, bạn đã sẵn sàng cầm trịch một dự án ngân hàng số thực thụ — đúng vị trí mà sự kết hợp giữa code cũ và nghiệp vụ mới của bạn trở nên vô giá.