Mở đầu — vì sao bài này quan trọng
Nếu bạn đang chuyển từ Designer sang BA và muốn có một "bàn đạp" domain đủ mạnh để bứt tốc thu nhập ở Việt Nam, fintech gần như là lựa chọn số một. Đây là ngành trả lương BA cao nhất thị trường (cao hơn e-commerce trung bình 20–35% ở cùng level), tăng trưởng nhanh, và — quan trọng cho người nền Design như bạn — cực kỳ coi trọng trải nghiệm người dùng. Một BA từng làm Designer hiểu được cách một luồng onboarding rối rắm khiến khách hàng bỏ giữa chừng sẽ là "của hiếm" trong phòng dự án fintech.
Nhưng fintech cũng là domain "khó nhằn" nhất để một BA non kinh nghiệm mắc lỗi. Ở e-commerce, một requirement sai làm hỏng giỏ hàng — bạn hotfix trong ngày. Ở fintech, một requirement sai về KYC, về hạn mức giao dịch, hay về đối chiếu số dư có thể khiến công ty bị Ngân hàng Nhà nước (NHNN) tuýt còi, bị phạt, hoặc tệ hơn là bị rút giấy phép trung gian thanh toán. Nói cách khác: ở fintech, BA không chỉ viết requirement cho đẹp, mà còn phải viết requirement cho đúng luật.
Bài này giúp bạn nắm được những gì đặc thù riêng của fintech VN mà không domain nào khác có: mật độ quy định pháp lý dày đặc, quy trình eKYC bắt buộc, các tích hợp hệ thống liên ngân hàng như Napas, và tư duy "compliance-first" khi viết tài liệu. Đây chính là phần kiến thức domain mà mọi khóa BA đại trà bỏ qua — và cũng là thứ giúp bạn tự tin gật đầu khi nhà tuyển dụng fintech hỏi "em biết eKYC hoạt động thế nào không?".
Khái niệm cốt lõi
Fintech VN là một ngành bị quản lý (regulated industry)
Điểm khác biệt lớn nhất giữa fintech và mọi domain "bình thường" là fintech hoạt động dưới sự giám sát của nhiều cơ quan quản lý cùng lúc. Là BA, bạn không cần thuộc luật như một luật sư, nhưng bạn phải biết "ai quản cái gì" để mỗi khi viết requirement, bạn biết mình đang chạm vào ranh giới nào.
- Ngân hàng Nhà nước (NHNN/SBV — State Bank of Vietnam): cơ quan quản lý trung tâm. Cấp phép trung gian thanh toán (ví điện tử, cổng thanh toán), quy định hạn mức giao dịch, quy định về tài khoản định danh. Các văn bản quan trọng bạn sẽ nghe nhắc thường xuyên: Thông tư 40/2024 (về hoạt động trung gian thanh toán), các quy định về mở tài khoản bằng phương thức điện tử.
- Bộ Công an (C06): quản lý dữ liệu định danh công dân. Từ 2023–2024, việc đối chiếu thông tin khách hàng với Cơ sở dữ liệu quốc gia về dân cư (NIC — National Identity Database) thông qua CCCD gắn chip trở thành trọng tâm của eKYC. App VNeID và dịch vụ xác thực C06 giờ là một phần không thể thiếu.
- PCI-DSS (Payment Card Industry Data Security Standard): không phải luật VN mà là chuẩn quốc tế bắt buộc nếu hệ thống của bạn lưu trữ, xử lý hoặc truyền dữ liệu thẻ (số thẻ, CVV). Nó chi phối cách bạn được — và không được — thiết kế luồng nhập thẻ, lưu thẻ.
- Nghị định 13/2023 về bảo vệ dữ liệu cá nhân (PDPD): quy định cách thu thập, lưu trữ, xử lý dữ liệu cá nhân — cực kỳ liên quan khi bạn thiết kế màn hình xin quyền, đồng ý (consent).
eKYC — trái tim của onboarding fintech
KYC (Know Your Customer — "biết khách hàng của bạn") là quy trình xác minh danh tính khách hàng trước khi cho phép họ sử dụng dịch vụ tài chính. eKYC là phiên bản điện tử, làm hoàn toàn qua app, không cần ra quầy. Đây là luồng nghiệp vụ mà bạn — với tư cách BA fintech — gần như chắc chắn sẽ phải viết requirement trong 6 tháng đầu.
Một luồng eKYC điển hình tại VN gồm các bước:
- Chụp giấy tờ tùy thân: khách chụp mặt trước và mặt sau CCCD gắn chip (hoặc CMND cũ với hệ thống chưa nâng cấp). Hệ thống dùng OCR để bóc tách thông tin: họ tên, số CCCD, ngày sinh, quê quán.
- Liveness detection (kiểm tra "người sống"): khách quay/nghiêng mặt theo hướng dẫn để chứng minh đây là người thật đang thao tác, không phải ảnh tĩnh hay video deepfake.
- Face matching: so khớp khuôn mặt vừa quay với ảnh trên giấy tờ.
- Đối chiếu với NIC/C06: gửi thông tin sang dịch vụ xác thực của Bộ Công an để xác nhận CCCD là thật, còn hiệu lực, và thông tin trùng khớp với dữ liệu dân cư quốc gia.
- Đọc chip NFC (tùy hệ thống): với CCCD gắn chip, app có thể yêu cầu khách áp thẻ vào lưng điện thoại để đọc dữ liệu trong chip — độ tin cậy cao nhất.
Tích hợp hệ sinh thái thanh toán: Napas, ngân hàng, và các cổng
Fintech VN không hoạt động một mình. Mọi giao dịch chuyển tiền, liên kết ngân hàng, nạp/rút tiền đều đi qua hạ tầng chung. Trung tâm của hạ tầng đó là Napas (Công ty Cổ phần Thanh toán Quốc gia Việt Nam) — đơn vị vận hành hệ thống chuyển mạch tài chính và bù trừ điện tử liên ngân hàng, bao gồm cả chuẩn VietQR (mã QR chuyển khoản liên ngân hàng) và dịch vụ chuyển tiền nhanh 24/7.
Khi bạn viết requirement cho tính năng "liên kết ngân hàng" hay "chuyển tiền", bạn sẽ phải hiểu:
- Luồng liên kết tài khoản qua Napas (khách nhập số tài khoản, hệ thống gửi OTP qua ngân hàng phát hành).
- Xử lý các trạng thái bất định của giao dịch: thành công, thất bại, và pending/timeout (giao dịch treo — tiền đã trừ nhưng chưa nhận được xác nhận). Đây là loại trạng thái đặc thù fintech mà designer thường bỏ sót.
- Reconciliation (đối soát): cuối ngày, hệ thống của bạn phải đối chiếu từng giao dịch với báo cáo từ Napas/ngân hàng để đảm bảo không lệch một đồng nào.
Tình huống thực tế
Ví dụ 1: Ví điện tử và bài toán "tỷ lệ rớt eKYC"
Một ví điện tử tầm trung tại VN (giả định tên "PayViet", quy mô ~2 triệu người dùng) gặp vấn đề: tỷ lệ hoàn tất eKYC chỉ đạt 58%. Nghĩa là cứ 100 người tải app và bắt đầu định danh, 42 người bỏ giữa chừng — một con số khủng khiếp vì mỗi lượt tải app tốn chi phí marketing khoảng 25.000–40.000đ.
BA của dự án (vốn xuất thân Designer) không vội yêu cầu dev "sửa cho mượt hơn". Cô ấy làm điều một BA thực thụ làm: phân tích data theo từng bước funnel. Kết quả: 70% số người bỏ cuộc rơi vào đúng bước liveness detection — khách quay mặt mãi mà hệ thống báo "không nhận diện được". Đào sâu thêm, hóa ra ngưỡng (threshold) chấp nhận của thuật toán được nhà cung cấp đặt quá cao để giảm gian lận, vô tình loại luôn người dùng thật trong điều kiện ánh sáng yếu.
Requirement cô ấy viết không phải là "làm liveness dễ hơn" (mơ hồ), mà là một business rule cụ thể: "Sau 2 lần liveness thất bại liên tiếp, hệ thống hạ ngưỡng nhận diện xuống mức B (do risk team định nghĩa) VÀ hiển thị hướng dẫn 'di chuyển đến nơi đủ sáng'. Nếu vẫn thất bại lần 3, chuyển sang luồng KYC hỗ trợ bởi nhân viên (video call)."
Bài học: Ở fintech, cải thiện trải nghiệm phải luôn đi kèm ràng buộc rủi ro. Một BA nền Design có lợi thế nhìn ra điểm rớt UX, nhưng phải "gói" giải pháp trong ngôn ngữ rule + ngưỡng rủi ro thì mới được risk team và compliance phê duyệt.
Ví dụ 2: Giao dịch "treo" và cơn ác mộng đối soát
Một fintech cho vay tiêu dùng liên kết với nhiều ngân hàng qua Napas để giải ngân. Một ngày, bộ phận CSKH nhận hàng loạt khiếu nại: "Tôi đã bị trừ tiền trả nợ nhưng app vẫn báo chưa thanh toán." Đào ra thì đây là các giao dịch timeout: hệ thống fintech gửi lệnh sang ngân hàng, ngân hàng đã trừ tiền khách nhưng phản hồi xác nhận về bị mất do lỗi mạng, nên hệ thống fintech mặc định coi là "thất bại".
Vấn đề gốc: requirement ban đầu chỉ mô tả hai trạng thái "thành công" và "thất bại", bỏ quên trạng thái thứ ba — "chưa xác định, cần đối soát". BA phải bổ sung một quy trình xử lý: mọi giao dịch timeout được đưa vào trạng thái PENDING_RECONCILE, hệ thống gọi lại API tra cứu trạng thái (transaction inquiry) của ngân hàng sau 5, 15, 30 phút; nếu sau đối soát cuối ngày xác nhận tiền đã trừ, tự động cập nhật trả nợ và gửi thông báo cho khách.
Bài học: Tư duy về trạng thái (state) trong fintech phức tạp hơn hẳn e-commerce hay app thông thường. "Tiền đã ra khỏi tài khoản khách nhưng chưa chắc đã đến đích" là một trạng thái có thật và có hậu quả pháp lý. BA fintech phải chủ động liệt kê đủ mọi trạng thái, đặc biệt các trạng thái "xám" (edge case tiền bạc).
Ví dụ 3: PCI-DSS chặn đứng một thiết kế đẹp
Một startup fintech muốn làm tính năng "lưu thẻ để thanh toán nhanh". Designer đề xuất một màn hình rất mượt: hiển thị lại 4 số cuối thẻ, cho phép khách sửa thông tin thẻ ngay trong app. BA — nếu không hiểu PCI-DSS — có thể vui vẻ viết requirement y hệt bản thiết kế.
Nhưng BA fintech có kinh nghiệm sẽ dừng lại: theo PCI-DSS, hệ thống của startup không được phép lưu trữ số thẻ đầy đủ hay CVV. Toàn bộ thông tin thẻ phải được "token hóa" qua một đối tác đạt chuẩn PCI-DSS (thường là cổng thanh toán như OnePay, hoặc trực tiếp qua các dịch vụ tokenization). App của startup chỉ giữ một token vô hại, không phải số thẻ thật. Do đó, "cho phép sửa thông tin thẻ trong app" là bất khả thi về mặt compliance — khách phải xóa token cũ và thêm thẻ mới.
Bài học: BA fintech đôi khi là người phải nói "không" với một thiết kế đẹp. Việc bạn từng là Designer giúp bạn giải thích lý do một cách tôn trọng và đề xuất phương án thay thế khả thi (ví dụ: thay nút "Sửa thẻ" bằng "Xóa và thêm thẻ mới"), thay vì chỉ ném ra một lệnh cấm khô khan.
Hướng dẫn từng bước
Đây là quy trình gợi ý khi bạn nhận một requirement trong dự án fintech VN:
- Xác định "vùng quản lý" (regulatory footprint). Trước khi viết một dòng nào, tự hỏi: tính năng này chạm vào tiền, dữ liệu định danh, hay dữ liệu thẻ? Nếu có, ghi lại các cơ quan/chuẩn liên quan (NHNN, C06, PCI-DSS, Nghị định 13). Đây là "cờ đỏ" bạn cần bàn với compliance sớm.
- Vẽ luồng As-Is và các trạng thái đầy đủ. Với tư duy Design, bạn đã quen vẽ user flow. Giờ nâng cấp: bổ sung mọi trạng thái tiền bạc và định danh — thành công, thất bại, treo/timeout, đang chờ đối soát, bị từ chối bởi risk. Đừng để sót trạng thái "xám".
- Định nghĩa business rule kèm nguồn ràng buộc. Mỗi rule ghi rõ nó đến từ đâu: "hạn mức giao dịch ví ≤ 100 triệu/tháng — nguồn: Thông tư NHNN" khác hoàn toàn với "hạn mức do sản phẩm tự quyết". Nguồn ràng buộc quyết định ai được thay đổi rule đó.
- Làm việc song song với 3 nhóm đặc thù fintech: risk (rủi ro/gian lận), compliance (tuân thủ pháp lý), và security. Ở domain khác, BA chủ yếu làm với dev và business. Ở fintech, ba nhóm này là stakeholder bắt buộc phải có mặt từ đầu.
- Đặc tả rõ luồng thất bại và phục hồi. Fintech "sống chết" ở phần xử lý lỗi. Requirement của bạn phải trả lời: nếu bước này lỗi thì khách thấy gì, tiền đi đâu, hệ thống retry thế nào, và khi nào cần con người can thiệp.
- Xác định yêu cầu về audit trail (nhật ký kiểm toán). Mọi thao tác liên quan tiền và định danh phải được ghi log đầy đủ, không sửa được, để phục vụ thanh tra. Đây là non-functional requirement bạn không được quên.
Lỗi thường gặp & mẹo
- Lỗi: Coi eKYC là "chụp ảnh cho vui". Nhiều BA mới viết requirement eKYC như một form nhập liệu bình thường, bỏ qua liveness, đối chiếu NIC, và các ngưỡng rủi ro. Mẹo: luôn tách bạch hai câu hỏi — "làm sao để dễ cho người dùng thật" và "làm sao để chặn kẻ gian lận" — rồi tìm điểm cân bằng cùng risk team.
- Lỗi: Chỉ thiết kế cho luồng thành công (happy path). Đây là thói quen chết người mang từ Design sang. Mẹo: với mỗi bước động đến tiền, viết ít nhất 3 kịch bản: thành công, thất bại rõ ràng, và treo/không xác định.
- Lỗi: Tự ý đề xuất thay đổi hạn mức, phí, hay quy tắc mà không kiểm tra nguồn pháp lý. Mẹo: trước khi đề xuất, hỏi "con số này do luật quy định hay do sản phẩm quyết?". Nếu do luật, bạn không có quyền thay — chỉ compliance mới xác nhận được.
- Lỗi: Quên yêu cầu bảo mật và audit trail vì chúng "vô hình" với người dùng. Mẹo: coi security, logging, và mã hóa là requirement hạng nhất, không phải "nice to have". Ghi chúng vào NFR ngay từ đầu.
- Mẹo tận dụng thế mạnh Designer: Bạn có lợi thế lớn khi thiết kế màn hình consent (đồng ý xử lý dữ liệu theo Nghị định 13) và các màn hình lỗi eKYC — nơi trải nghiệm tệ khiến khách bỏ cuộc. Hãy biến điểm mạnh đó thành giá trị khác biệt của một "BA gốc Design".
Bài tập thực hành
Bài tập 1 — Bản đồ trạng thái giao dịch. Chọn một tính năng "nạp tiền vào ví điện tử qua liên kết ngân hàng". Vẽ sơ đồ trạng thái (state) đầy đủ cho giao dịch này, bao gồm ít nhất: khởi tạo, chờ OTP, thành công, thất bại, timeout/treo, đang đối soát. Với mỗi trạng thái, ghi rõ (a) khách hàng nhìn thấy gì, (b) tiền đang ở đâu, (c) hành động tiếp theo của hệ thống.
Bài tập 2 — Business rule cho eKYC. Viết 5 business rule cho luồng eKYC của một app cho vay, trong đó bắt buộc có: một rule về số lần thử liveness tối đa, một rule về đối chiếu NIC/C06, và một rule về xử lý khi khách dưới 18 tuổi. Mỗi rule ghi kèm nguồn ràng buộc (luật hay sản phẩm).
Bài tập 3 — Phản biện compliance. Cho tình huống: sản phẩm muốn làm tính năng "thanh toán 1 chạm không cần OTP cho giao dịch dưới 500.000đ". Viết một đoạn phân tích ngắn (200–300 từ) nêu: rủi ro, các bên cần tham vấn, và câu hỏi bạn sẽ đặt cho compliance trước khi đồng ý viết requirement.
Tóm tắt
Fintech là domain "vàng" cho BA tại VN — trả lương cao, tăng trưởng nhanh, và đặc biệt trọng dụng người hiểu trải nghiệm người dùng như bạn, một Designer đang chuyển đổi. Nhưng để thành công, bạn phải nạp thêm ba khối kiến thức đặc thù mà không domain nào khác có: (1) tư duy compliance-first với mạng lưới quy định dày đặc từ NHNN, Bộ Công an, PCI-DSS và Nghị định 13; (2) hiểu sâu luồng eKYC — từ chụp giấy tờ, liveness, face matching đến đối chiếu NIC; và (3) nắm được cách fintech tích hợp vào hệ sinh thái thanh toán qua Napas, cùng với những trạng thái "xám" đặc thù như giao dịch treo và đối soát.
Điều then chốt cần nhớ: ở fintech, requirement không chỉ cần đẹp mà phải đúng luật và chặn được rủi ro. Lợi thế Designer của bạn — nhìn ra điểm rớt trải nghiệm, thiết kế màn hình lỗi và consent tử tế — sẽ tỏa sáng, miễn là bạn học cách "gói" nó trong ngôn ngữ business rule, trạng thái, và ràng buộc rủi ro. Đó chính là chân dung một BA fintech giỏi mà thị trường VN đang khát.