Mở đầu — vì sao bài này quan trọng
Nếu bạn xuất thân từ Sales/BD và đang muốn rẽ sang BA, thì fintech là một trong những "vùng đất hứa" hợp lý nhất để bạn đặt chân vào. Lý do rất đơn giản: fintech bán sản phẩm tài chính cho con người và doanh nghiệp — mà bán hàng, hiểu khách hàng, xử lý phản đối, đọc tâm lý người ra quyết định lại chính là cơ bắp bạn đã rèn nhiều năm. Một ex-Sales hiểu vì sao khách hàng ngại mở tài khoản online, vì sao họ bỏ giữa chừng khi bị yêu cầu chụp căn cước, vì sao một SME ngại vay vì sợ thủ tục — đó là vốn liếng mà nhiều BA "thuần kỹ thuật" không có.
Nhưng fintech cũng là domain "khó nhằn" nhất với người mới. Nó không giống làm BA cho một app đặt đồ ăn, nơi bạn chỉ cần đúng nghiệp vụ và UX tốt. Fintech bị bao quanh bởi luật pháp, bởi Ngân hàng Nhà nước (NHNN/SBV), bởi quy định phòng chống rửa tiền (AML), bởi yêu cầu định danh khách hàng điện tử (e-KYC) và kết nối Cơ sở dữ liệu quốc gia về dân cư của Bộ Công An. Một dòng requirement viết sai ở đây không chỉ gây bug — nó có thể khiến công ty bị phạt, bị thanh tra, hoặc tệ hơn là bị thu hồi giấy phép.
Bài này giúp bạn nắm bản đồ domain fintech Việt Nam: những đặc thù pháp lý, các hệ thống thanh toán bạn chắc chắn sẽ phải tích hợp (Napas, VietQR, VNPAY, MoMo, ZaloPay), logic e-KYC, và cách tư duy của một BA khi viết requirement trong môi trường bị quản lý chặt (regulated). Mục tiêu là khi bạn ngồi vào phòng họp đầu tiên ở một fintech, bạn không bị "ngợp" mà hiểu được người ta đang nói về cái gì.
Khái niệm cốt lõi
Fintech VN là một domain "regulated"
Từ khóa quan trọng nhất bạn cần khắc cốt ghi tâm là regulated — bị quản lý. Khác với một startup thương mại điện tử có thể "làm trước, sửa sau", fintech vận hành trong khung pháp lý do nhiều cơ quan đặt ra:
- NHNN/SBV (Ngân hàng Nhà nước): cơ quan quản lý cao nhất về hoạt động ngân hàng, trung gian thanh toán, ví điện tử, hạn mức giao dịch, lãi suất. Mọi tính năng liên quan đến tiền — nạp, rút, chuyển, giữ số dư — đều phải soi chiếu với quy định của NHNN.
- Bộ Công An (C06): chủ quản Cơ sở dữ liệu quốc gia về dân cư và ứng dụng VNeID. e-KYC hiện đại ở VN gần như bắt buộc đối chiếu với dữ liệu này để xác thực danh tính thật.
- Cục Phòng chống rửa tiền và Luật Phòng, chống rửa tiền (Luật số 14/2022/QH15): quy định AML, KYC, báo cáo giao dịch đáng ngờ.
e-KYC và tích hợp định danh
e-KYC (electronic Know Your Customer) là quy trình định danh khách hàng điện tử — thay vì khách phải ra quầy. Một flow e-KYC điển hình ở fintech VN gồm:
- Khách chụp/ quét căn cước công dân (CCCD) gắn chip (đọc chip NFC để lấy dữ liệu gốc, chống làm giả).
- Khách quay video selfie có liveness detection (kiểm tra "người sống" thật, không phải ảnh tĩnh hay deepfake).
- Hệ thống đối chiếu khuôn mặt (face matching) giữa selfie và ảnh trên CCCD.
- Đối chiếu với Cơ sở dữ liệu quốc gia về dân cư của Bộ Công An (qua NIC — National Identity Connection / kết nối định danh) để xác nhận danh tính có thật và khớp.
Hệ sinh thái thanh toán: Napas, VietQR, VNPAY, MoMo, ZaloPay
Đây là "đường ống" tiền chảy ở Việt Nam:
- Napas: công ty chuyển mạch tài chính quốc gia. Gần như mọi chuyển khoản liên ngân hàng, rút tiền thẻ nội địa đều đi qua Napas. Nếu sản phẩm của bạn cần chuyển tiền giữa các ngân hàng, bạn đang tích hợp gián tiếp với Napas.
- VietQR: chuẩn QR code thanh toán do Napas vận hành, cho phép quét mã chuyển khoản nhanh 24/7. Là tính năng "must-have" của hầu hết app tài chính hiện nay.
- VNPAY: cổng thanh toán (payment gateway) phổ biến, hỗ trợ thanh toán thẻ, QR, ví — thường dùng cho các merchant/website cần nhận tiền.
- MoMo, ZaloPay: ví điện tử (e-wallet) lớn nhất VN. Khi tích hợp, bạn làm việc với API của họ để khách thanh toán bằng ví.
AML — luật chơi vô hình nhưng nặng nề
AML (Anti-Money Laundering — phòng chống rửa tiền) là tập hợp quy tắc nhằm ngăn tiền bẩn đi qua hệ thống. Với BA, AML hiện ra dưới dạng business rule phức tạp:
- Ngưỡng báo cáo giao dịch giá trị lớn (ví dụ giao dịch tiền mặt từ một mức nhất định phải báo cáo).
- Phát hiện giao dịch đáng ngờ (structuring — chia nhỏ giao dịch để né ngưỡng; giao dịch bất thường về tần suất/giá trị).
- Sàng lọc danh sách đen (sanction list, PEP — Politically Exposed Persons / người có ảnh hưởng chính trị).
- Phân loại rủi ro khách hàng (risk rating) để áp mức KYC tương ứng.
Tình huống thực tế
Tình huống 1 — Mở ví điện tử và bài toán hạn mức theo cấp tài khoản
Một fintech ví điện tử (giả định tên "PayViet") muốn cho phép người dùng mở ví chỉ bằng số điện thoại, để tăng tỉ lệ đăng ký. Team Growth (vốn là dân Sales/Marketing) ép tiến độ: "Càng ít bước càng nhiều người đăng ký, ông cứ bỏ bớt e-KYC đi."
Là BA, bạn phải đưa ra sự thật pháp lý: theo quy định về ví điện tử, ví chưa định danh đầy đủ chỉ được phép giữ số dư và giao dịch ở hạn mức rất thấp; muốn nâng hạn mức, muốn liên kết ngân hàng, muốn rút tiền lớn thì bắt buộc e-KYC đầy đủ. Bạn thiết kế giải pháp dạng tiered KYC (KYC phân tầng):
- Tài khoản Cấp 1: chỉ SĐT, hạn mức giao dịch tối đa thấp, không rút tiền mặt.
- Tài khoản Cấp 2: e-KYC đầy đủ (CCCD chip + liveness + đối chiếu C06), mở khóa hạn mức cao và liên kết ngân hàng.
Bài học: trong fintech, "bỏ bớt bước" không phải quyết định UX — đó là quyết định pháp lý. BA giỏi không nói "không", mà thiết kế đường đi hợp pháp đạt được mục tiêu kinh doanh.
Tình huống 2 — Liveness fail và bài toán luồng ngoại lệ (edge case)
Tại một công ty cho vay tiêu dùng (giả định "CreditNow"), tỉ lệ rớt ở bước e-KYC lên tới 25%. Đào sâu, BA phát hiện phần lớn fail ở bước liveness/face matching: người lớn tuổi quay video không đúng cách, người dùng điện thoại cũ camera kém, ảnh CCCD cũ không khớp khuôn mặt hiện tại.
BA cũ (chưa có kinh nghiệm) chỉ viết requirement cho "happy path": chụp CCCD → selfie → khớp → xong. Toàn bộ nhánh fail bị bỏ ngỏ, dev tự xử, kết quả là khách bị văng ra màn hình lỗi cụt và bỏ luôn.
Bạn — BA ex-Sales — viết lại theo tư duy "phễu rớt ở đâu, đỡ ở đó":
- Fail liveness lần 1: hướng dẫn lại + cho thử lại tối đa 3 lần.
- Fail face matching nhưng chip CCCD đọc tốt: chuyển sang manual review (nhân viên thẩm định thủ công) thay vì từ chối thẳng.
- Fail quá số lần: chuyển kênh hỗ trợ (gọi điện/video call định danh) — giữ chân khách thay vì mất.
Bài học: ở fintech, requirement giá trị nhất thường nằm ở các nhánh fail, không phải happy path. Đây cũng là chỗ ex-Sales tỏa sáng — bạn quen với việc "khách từ chối thì làm gì tiếp", và đó đúng là tư duy xử lý ngoại lệ.
Tình huống 3 — Đối soát thanh toán đa kênh ở một SaaS thu hộ
Một startup SaaS B2B (giả định "ThuHo") làm nền tảng thu hộ học phí cho trường học, cho phép phụ huynh trả qua VietQR, VNPAY và ví MoMo/ZaloPay. Vấn đề kinh điển xuất hiện: cuối ngày, số tiền hệ thống ghi nhận không khớp với tiền thực về tài khoản — vì mỗi kênh trả kết quả với độ trễ và định dạng khác nhau, một số giao dịch "thành công ở app nhưng tiền chưa về" hoặc ngược lại.
BA vào cuộc, viết requirement cho module đối soát (reconciliation):
- Định nghĩa trạng thái giao dịch rõ ràng: Khởi tạo → Chờ thanh toán → Thành công (app báo) → Đã đối soát (tiền thực về khớp).
- Quy tắc xử lý lệch: nếu app báo thành công mà 24h chưa thấy tiền → đánh dấu "nghi ngờ", chặn ghi nhận doanh thu.
- Tích hợp file đối soát từ từng kênh (Napas/VNPAY/ví) và đối chiếu tự động theo mã giao dịch.
Bài học: "thanh toán thành công" với BA fintech là một khái niệm nhiều tầng, không phải một trạng thái. Hiểu vòng đời giao dịch và đối soát là kỹ năng phân biệt BA fintech với BA thường.
Hướng dẫn từng bước
Đây là quy trình một BA ex-Sales nên theo khi nhận một feature trong fintech VN:
- Xác định feature có "chạm tiền" hay "chạm danh tính" không. Nếu có — bật cờ "regulated", chuẩn bị tinh thần tra cứu quy định và mời compliance vào sớm.
- Tìm quy định liên quan trước khi viết requirement. Hỏi đội Pháp chế/Compliance: feature này thuộc khung nào? (ví dụ thanh toán → quy định trung gian thanh toán; vay → quy định cho vay). Đừng tự suy diễn hạn mức, lãi suất, điều kiện.
- Vẽ flow chính + liệt kê toàn bộ nhánh fail. Đặc biệt với e-KYC và thanh toán: mỗi bước có thể fail, mỗi fail cần một lối ra (retry, manual review, chuyển kênh, từ chối kèm lý do).
- Định nghĩa vòng đời trạng thái của đối tượng nghiệp vụ. Giao dịch, hồ sơ KYC, khoản vay — tất cả đều có state machine. Viết rõ trạng thái và điều kiện chuyển trạng thái.
- Catalog hóa business rule, tách AML/compliance ra riêng. Đừng nhét rule rửa tiền lẫn vào logic UI. Lập bảng rule có mã, mô tả, nguồn quy định, người sở hữu (owner là compliance).
- Làm rõ tích hợp đối tác thanh toán. Với mỗi kênh (Napas/VietQR/VNPAY/MoMo/ZaloPay): realtime hay không, có refund không, có webhook callback không, file đối soát ra sao, hành vi khi timeout.
- Đưa compliance/legal review trước khi chốt SRS. Trong fintech, chữ ký của compliance trên tài liệu quan trọng ngang dev lead.
Lỗi thường gặp & mẹo
- Lỗi: chỉ viết happy path. Đây là lỗi chí mạng ở fintech. Mẹo: với mỗi bước, tự hỏi "nếu bước này fail thì sao?" và viết ít nhất một nhánh xử lý.
- Lỗi: tự quyết định pháp lý. Bạn không phải luật sư. Mẹo: mọi con số hạn mức/lãi suất/điều kiện định danh phải dẫn nguồn từ quy định và được compliance xác nhận. Ghi rõ "theo Thông tư X" trong requirement.
- Lỗi: coi "thanh toán thành công" là một trạng thái. Mẹo: luôn tách "app báo thành công" và "tiền thực đã về & đối soát khớp" — hai cái khác nhau.
- Lỗi: nhét AML rule vào logic ứng dụng chung. Mẹo: lập một business rule catalog riêng cho AML/KYC, do compliance làm owner, để khi luật đổi chỉ sửa một chỗ.
- Lỗi: thiết kế e-KYC quá ngặt làm rớt khách thật. Mẹo (lợi thế ex-Sales): cân bằng giữa chống gian lận và trải nghiệm — đề xuất manual review thay vì từ chối thẳng ở các ca biên.
- Mẹo tận dụng nền Sales: bạn hiểu nỗi sợ và sự lười của khách hàng. Hãy dùng nó để dự đoán điểm rớt trong phễu định danh/thanh toán và đề xuất cách "đỡ" khách — đây là giá trị mà BA thuần kỹ thuật khó tạo ra.
Bài tập thực hành
- Bản đồ quy định: Chọn một feature fintech (mở ví, vay tiêu dùng, hoặc nạp tiền). Liệt kê các cơ quan/quy định có thể liên quan (NHNN, Bộ Công An, AML) và với mỗi quy định, ghi một câu "nó ràng buộc requirement của tôi như thế nào".
- Thiết kế flow e-KYC có nhánh fail: Vẽ sơ đồ flow e-KYC đầy đủ gồm: đọc CCCD chip, liveness, face matching, đối chiếu C06. Với mỗi bước, viết ít nhất một nhánh xử lý khi fail (retry / manual review / chuyển kênh / từ chối).
- State machine giao dịch: Vẽ vòng đời một giao dịch thanh toán qua VietQR từ lúc tạo mã đến lúc đối soát khớp. Đánh dấu trạng thái "nghi ngờ" và điều kiện kích hoạt nó.
- Business rule AML: Viết 3 business rule AML dạng "Khi [điều kiện] thì [hành động]" (ví dụ: phát hiện structuring, vượt ngưỡng giá trị lớn, trùng sanction list). Ghi rõ owner và nguồn quy định giả định.
- So sánh kênh thanh toán: Lập bảng so sánh Napas/VietQR, VNPAY, MoMo, ZaloPay theo các tiêu chí: realtime, có refund, có webhook, cơ chế đối soát. Đánh dấu kênh nào phù hợp cho bài toán "thu hộ học phí".
Tóm tắt
Fintech là domain lý tưởng cho ex-Sales chuyển BA vì nó thưởng cho khả năng hiểu khách hàng và đọc tâm lý người ra quyết định — nhưng nó cũng đòi hỏi kỷ luật cao vì là môi trường regulated. Bốn trụ cột bạn cần nắm: (1) khung pháp lý từ NHNN, Bộ Công An và Luật Phòng chống rửa tiền; (2) quy trình e-KYC với đối chiếu dữ liệu dân cư và xử lý dày đặc các nhánh fail; (3) hệ sinh thái thanh toán Napas, VietQR, VNPAY, MoMo, ZaloPay cùng bài toán đối soát; và (4) hệ thống business rule AML phức tạp.
Tư duy cốt lõi của BA fintech: mỗi requirement chạm tiền hoặc danh tính đều phải dẫn nguồn quy định; happy path chỉ là phần nổi, giá trị nằm ở các nhánh ngoại lệ; và "thanh toán thành công" luôn là khái niệm nhiều tầng cần đối soát. Hãy biến vốn liếng Sales — hiểu nỗi sợ, sự ngại ngần, điểm rớt của khách — thành lợi thế khi thiết kế các luồng định danh và thanh toán vừa an toàn pháp lý vừa giữ chân khách hàng. Đó chính là BA fintech mà thị trường VN đang khát.