Mở đầu — vì sao bài này quan trọng
Đến đây, bạn đã đi qua 56 bài học: từ BABOK, elicitation, viết requirement, prioritization, cho tới SQL, API, data modeling và cả bộ công cụ nghề nghiệp. Capstone 1 này là nơi bạn ráp tất cả lại thành một sản phẩm thực tế — đúng kiểu một BA sẽ phải làm trong tuần đầu tiên đi làm tại một ngân hàng số ở Việt Nam.
Vì sao tôi chọn eKYC (electronic Know Your Customer — định danh khách hàng điện tử) làm bài capstone đầu tiên? Bởi vì đây là một trong những bài toán "kinh điển" mà gần như mọi ngân hàng, ví điện tử và công ty fintech tại Việt Nam đều đã hoặc đang triển khai. Từ thời điểm Thông tư 16/2020/TT-NHNN cho phép mở tài khoản thanh toán bằng phương thức điện tử, rồi sau này là Thông tư 17/2024 và Quyết định 2345/QĐ-NHNN về xác thực sinh trắc học, eKYC trở thành "cửa ngõ" của mọi sản phẩm ngân hàng số. Một BA hiểu eKYC tới nơi tới chốn là một BA có giá trị thị trường rất rõ ràng.
Quan trọng hơn, eKYC là bài toán "đủ độ phức tạp lành mạnh": nó đụng tới quy định pháp lý (compliance), rủi ro gian lận (fraud), trải nghiệm người dùng (UX), tích hợp hệ thống bên thứ ba (OCR, liveness, NFC), và cả phối hợp với bộ phận vận hành (manual review). Đây chính là môi trường để bạn thực hành tư duy của một BA toàn diện, chứ không chỉ là người chép lại yêu cầu.
Trong bài này, chúng ta sẽ cùng phân tích một dự án eKYC từ đầu tới cuối — đóng vai BA cho "Ngân hàng X" — và bạn sẽ tự tay sản xuất các deliverable mà một dự án thật cần.
Khái niệm cốt lõi
eKYC là gì và phạm vi của nó
eKYC là quá trình một tổ chức tài chính xác minh danh tính của khách hàng bằng phương thức điện tử, không cần khách hàng đến quầy. Mục tiêu kép: (1) tuân thủ quy định phòng chống rửa tiền (AML — Anti-Money Laundering) và định danh khách hàng, (2) cho phép onboarding 100% online để giảm chi phí và tăng tốc tăng trưởng tệp khách hàng.
Với BA, điều quan trọng là hiểu eKYC không phải một tính năng đơn lẻ, mà là một luồng nghiệp vụ end-to-end gồm nhiều bước có thể thất bại độc lập. Một luồng eKYC điển hình tại Việt Nam:
- Chụp giấy tờ tùy thân (CCCD gắn chip / hộ chiếu).
- OCR — trích xuất thông tin từ ảnh giấy tờ.
- Đọc chip NFC (với CCCD gắn chip) để lấy dữ liệu gốc đã ký số.
- Liveness check — xác nhận người trước camera là người thật, đang sống, không phải ảnh/video/mặt nạ.
- Face matching — so khớp khuôn mặt selfie với ảnh trên giấy tờ.
- Đối chiếu với cơ sở dữ liệu dân cư (qua kết nối C06 — Bộ Công an) khi có.
- Sàng lọc rủi ro: blacklist, sanction list, PEP (Politically Exposed Person).
- Quyết định: tự động duyệt, tự động từ chối, hoặc chuyển manual review.
Phân biệt 3 cấp độ định danh
Một concept BA hay bị bỏ sót: không phải eKYC nào cũng giống nhau. Theo quy định Việt Nam, có sự phân tầng hạn mức theo mức độ xác thực:
- Mức cơ bản: OCR + selfie + liveness, chưa đọc NFC. Tài khoản bị giới hạn hạn mức giao dịch (ví dụ tổng giao dịch không quá 100 triệu/tháng theo từng thời kỳ quy định).
- Mức nâng cao: có đọc NFC chip CCCD và/hoặc đối chiếu C06, mở hạn mức cao hơn.
- Xác thực sinh trắc học theo Quyết định 2345: bắt buộc với một số ngưỡng giao dịch (ví dụ trên 10 triệu/giao dịch hoặc 20 triệu/ngày).
Các non-functional requirement đặc thù
eKYC nặng về NFR (đã học ở Bài 34). Cụ thể:
- Hiệu năng: thời gian xử lý OCR + liveness + face match dưới một ngưỡng (ví dụ p95 < 8 giây) để không làm rớt người dùng giữa luồng.
- Độ chính xác: FAR (False Acceptance Rate — nhận nhầm người giả là thật) và FRR (False Rejection Rate — từ chối nhầm người thật). Đây là cặp đánh đổi: siết FAR thì FRR tăng, gây ma sát UX.
- Bảo mật & quyền riêng tư: dữ liệu sinh trắc học là dữ liệu cá nhân nhạy cảm theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân. Cần mã hóa, kiểm soát truy cập, và đồng thuận (consent) rõ ràng.
- Khả năng audit: mọi quyết định duyệt/từ chối phải lưu vết để thanh tra.
Tình huống thực tế
Tình huống 1 — Ngân hàng X và "vực thẳm drop-off" ở bước NFC
Ngân hàng X (giả định, một ngân hàng tầm trung) ra mắt eKYC và rất tự hào vì conversion tổng thể đạt 62%. Nhưng đội tăng trưởng phát hiện một vấn đề: trong số người bỏ cuộc, gần 40% rớt đúng tại bước đọc NFC chip CCCD. Lý do? Nhiều dòng điện thoại Android giá rẻ có ăng-ten NFC đặt ở vị trí lệch, người dùng áp CCCD vào sai chỗ, quét 3–4 lần không được rồi bỏ.
BA được giao điều tra. Thay vì chỉ ghi "cải thiện NFC", BA làm phân tích funnel cụ thể: tách tỷ lệ thành công NFC theo nhóm thiết bị, đo số lần thử trung bình trước khi thành công, và phỏng vấn 8 người dùng thất bại. Kết quả dẫn tới một quyết định nghiệp vụ quan trọng: cho phép fallback — nếu NFC thất bại sau N lần, hệ thống tự chuyển sang luồng "OCR + đối chiếu C06" để vẫn định danh được ở mức nâng cao mà không cần chip.
Bài học: một BA giỏi không dừng ở việc mô tả tính năng. Bạn phải định lượng điểm rớt, hiểu nguyên nhân gốc, rồi thiết kế business rule cho trường hợp ngoại lệ. Chính các luồng fallback và edge case mới là nơi BA tạo ra giá trị, không phải happy path mà ai cũng nghĩ ra.
Tình huống 2 — Vụ gian lận deepfake tại một ví điện tử Đông Nam Á
Một ví điện tử ở khu vực (tạm gọi là PayMoto, mô phỏng từ các vụ thật đã được báo chí khu vực đưa tin) bị một nhóm gian lận khai thác: chúng dùng video deepfake và ảnh CCCD đánh cắp để mở hàng loạt tài khoản ảo, sau đó dùng để nhận tiền lừa đảo. Trong một tháng, hơn 1.200 tài khoản gian lận lọt qua liveness check vì hệ thống chỉ dùng "passive liveness" đời cũ.
Đội rủi ro yêu cầu BA viết requirement nâng cấp. BA không tự quyết kỹ thuật, nhưng phối hợp với fraud team và vendor để xác định các business rule mới: bổ sung active liveness (yêu cầu người dùng quay đầu, chớp mắt theo lệnh ngẫu nhiên), thêm rule chặn khi cùng một khuôn mặt cố mở nhiều tài khoản với CCCD khác nhau (face dedup), và đặt ngưỡng device fingerprint để phát hiện một thiết bị mở quá nhiều tài khoản.
Điểm tinh tế BA phải cân: siết quá thì người thật bị từ chối (FRR tăng), mất khách. Vì vậy BA đề xuất rule theo risk-based: tài khoản hạn mức thấp đi luồng nhẹ, tài khoản muốn nâng hạn mức cao thì bắt buộc qua kiểm tra chặt hơn.
Bài học: trong eKYC, requirement luôn là cuộc thương lượng giữa ba phía — compliance, fraud và growth. BA là người ngồi giữa, dịch ngôn ngữ rủi ro thành rule cụ thể, và minh bạch hóa đánh đổi cho stakeholder ra quyết định.
Tình huống 3 — Manual review queue bị nghẽn ngày cao điểm
Ngân hàng X chạy chương trình ưu đãi mở thẻ, lượng đăng ký tăng gấp 5 lần trong 3 ngày. Vấn đề: tỷ lệ chuyển manual review là 18%, mà đội back-office chỉ có 6 người, dẫn tới hàng nghìn hồ sơ chờ duyệt quá SLA 24 giờ. Khách hàng phàn nàn, một số bỏ sang ngân hàng khác.
BA phân tích và phát hiện hai gốc rễ: (1) ngưỡng face-match confidence đặt quá thận trọng khiến nhiều hồ sơ "biên" bị đẩy sang người, (2) màn hình review của back-office hiển thị thông tin lộn xộn, mỗi hồ sơ mất 4 phút xử lý. BA đề xuất: tinh chỉnh lại ngưỡng theo dữ liệu thực (giảm tỷ lệ manual xuống 11% mà không tăng gian lận), thiết kế lại màn hình review với layout so sánh ảnh cạnh nhau và highlight điểm bất thường, kéo thời gian xử lý xuống còn 1,5 phút.
Bài học: eKYC không chỉ là luồng của khách hàng. Nửa còn lại là luồng vận hành nội bộ (manual review). Một BA hoàn chỉnh phải thiết kế cả hai, và phải gắn requirement với SLA và năng lực nhân sự thực tế.
Hướng dẫn từng bước
Đây là cách tôi khuyên bạn tiếp cận capstone này như một dự án BA thật.
Bước 1 — Làm rõ business context và mục tiêu. Viết một đoạn problem statement: Ngân hàng X muốn cho phép khách hàng cá nhân mở tài khoản thanh toán 100% online, tuân thủ Thông tư của NHNN, đạt conversion ≥ 60%, tỷ lệ gian lận lọt qua < 0,1%, và thời gian từ lúc bắt đầu tới khi có tài khoản < 5 phút. Định nghĩa rõ scope (cá nhân, không phải doanh nghiệp) và out-of-scope (mở thẻ tín dụng, vay — để giai đoạn sau).
Bước 2 — Identify stakeholder và phân tích (vận dụng Bài 21–22). Lập danh sách: Compliance/Legal, Fraud/Risk, Growth/Product, Back-office Operations, IT/Security, vendor eKYC, và NHNN với tư cách regulator. Dùng Power/Interest grid để xác định ai cần "manage closely" — thường là Compliance và Fraud.
Bước 3 — Vẽ business process bằng BPMN (Bài 4). Mô hình hóa luồng end-to-end với các swimlane: Customer, eKYC Engine, Fraud Service, Back-office, Core Banking. Thể hiện rõ các gateway quyết định: liveness pass/fail, face-match trên/dưới ngưỡng, hit blacklist hay không. Đừng quên các nhánh ngoại lệ.
Bước 4 — Viết requirement phân loại theo schema (Bài 20, 28). Tách rõ:
- Business requirement: "Giảm chi phí onboarding 70% so với mở tại quầy."
- Stakeholder requirement: "Compliance cần lưu vết mọi quyết định trong tối thiểu 5 năm."
- Functional requirement: "Hệ thống phải so khớp khuôn mặt selfie với ảnh CCCD và trả về confidence score 0–100."
- Non-functional: hiệu năng, FAR/FRR, bảo mật, khả dụng.
Bước 6 — Đặc tả business rule. Lập bảng rule: ngưỡng face-match, số lần thử NFC trước fallback, điều kiện đẩy manual review, hạn mức tài khoản theo cấp độ định danh. Đây là phần "ruột" của eKYC.
Bước 7 — Thiết kế data và tích hợp (Bài 43–45). Vẽ ERD cho customer, kyc_session, document, decision_log. Mô tả các API gọi vendor (OCR, liveness) bằng REST/JSON, định nghĩa request/response và mã lỗi.
Bước 8 — Lập Requirements Traceability Matrix (Bài 32). Truy vết từ business objective → requirement → user story → test case, để chứng minh không có yêu cầu nào bị bỏ rơi.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ thiết kế happy path. Người mới thường mô tả luồng "mọi thứ chạy đúng" rồi dừng. Nhưng trong eKYC, 30–40% giá trị nằm ở edge case: ảnh mờ, chip không đọc được, người dùng đeo kính, ánh sáng yếu, CCCD hết hạn, tên có dấu bị OCR sai. Mẹo: với mỗi bước, hãy tự hỏi "bước này thất bại thì sao?" và viết rule cho nó.
Lỗi 2 — Quên compliance là một stakeholder thực sự. Nhiều BA coi pháp lý là chuyện "ai đó lo". Sai. Một requirement không tuân thủ Thông tư NHNN hay Nghị định 13 có thể khiến cả sản phẩm bị dừng. Mẹo: đưa Compliance vào review từ sớm, và ghi rõ nguồn quy định cho mỗi rule pháp lý trong tài liệu.
Lỗi 3 — Không định lượng NFR. Viết "hệ thống phải nhanh" là vô nghĩa. Hãy viết "p95 thời gian xử lý eKYC < 8 giây", "FRR < 5% trên tập người dùng thật". Số liệu giúp test được và tránh tranh cãi sau này.
Lỗi 4 — Bỏ quên consent và quyền riêng tư. Thu thập sinh trắc học mà không có màn hình đồng thuận rõ ràng là vi phạm. Mẹo: thêm requirement về consent screen, quyền rút lại đồng thuận, và chính sách lưu trữ/xóa dữ liệu.
Lỗi 5 — Thiết kế luồng khách hàng mà quên luồng vận hành. Như tình huống 3 cho thấy, manual review queue có thể là nút thắt cổ chai. Mẹo: luôn thiết kế song song cả màn hình và SLA cho back-office.
Mẹo vàng: khi trình bày trade-off FAR/FRR cho stakeholder, đừng đưa con số khô khan. Hãy dịch ra ngôn ngữ kinh doanh: "Siết ngưỡng giúp chặn thêm 50 hồ sơ gian lận/tháng, nhưng sẽ từ chối nhầm khoảng 800 khách thật, tương đương mất X triệu doanh thu." Lúc đó stakeholder mới ra quyết định đúng.
Bài tập thực hành
Hãy hoàn thành bộ deliverable sau cho dự án eKYC của Ngân hàng X. Đây là sản phẩm bạn có thể đưa vào portfolio.
- Problem statement & scope (1 trang): viết mục tiêu, KPI đo lường (conversion, fraud rate, thời gian), in-scope và out-of-scope.
- Stakeholder map: lập Power/Interest grid cho ít nhất 6 nhóm stakeholder và nêu chiến lược tương tác cho 2 nhóm quan trọng nhất.
- BPMN diagram: vẽ luồng eKYC end-to-end với tối thiểu 4 swimlane và ít nhất 3 gateway quyết định, có thể hiện ít nhất 2 nhánh ngoại lệ (ví dụ NFC fail → fallback, liveness fail → từ chối).
- Bảng business rule: liệt kê tối thiểu 8 rule, gồm ngưỡng face-match, điều kiện manual review, hạn mức theo cấp độ định danh, rule chống gian lận deepfake.
- Requirement set: viết 3 functional requirement và 3 non-functional requirement có số liệu đo được, theo chuẩn chất lượng đã học ở Bài 28.
- User stories: viết 4 user story (chụp giấy tờ, liveness, xem kết quả, xử lý lỗi) kèm acceptance criteria có cả luồng lỗi.
- Mini ERD: vẽ 4–5 thực thể (customer, kyc_session, document, decision_log...) và quan hệ giữa chúng.
- RTM rút gọn: truy vết tối thiểu 5 dòng từ business objective xuống test case.
Tóm tắt
eKYC là bài capstone lý tưởng vì nó buộc bạn vận dụng gần như mọi kỹ năng đã học: từ stakeholder analysis, BPMN, viết requirement và NFR, user story, data modeling, tích hợp API, cho tới RTM. Điểm cốt lõi bạn cần khắc ghi:
- eKYC là một luồng nghiệp vụ end-to-end với nhiều điểm thất bại độc lập — giá trị BA nằm ở edge case và fallback, không phải happy path.
- Requirement eKYC luôn là cuộc thương lượng ba bên: compliance, fraud và growth. BA là người dịch rủi ro thành rule và minh bạch hóa đánh đổi.
- Phải thiết kế cả hai nửa: luồng khách hàng và luồng vận hành (manual review) với SLA thực tế.
- NFR phải định lượng (FAR/FRR, p95 latency), và compliance (Thông tư NHNN, Nghị định 13) là stakeholder không thể bỏ qua.