Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ Finance hoặc Kế toán và đang nhắm tới nghề BA, thì FinTech chính là "sân nhà" tự nhiên nhất của bạn — và cũng là nơi bạn có lợi thế cạnh tranh lớn nhất so với những BA chuyển từ ngành khác. Lý do rất đơn giản: FinTech là ngành mà mọi yêu cầu phần mềm đều xoay quanh tiền, dòng tiền, đối soát, tuân thủ và rủi ro — đúng những thứ bạn đã sống cùng mỗi ngày trong sự nghiệp tài chính của mình.
Nhưng FinTech Việt Nam có một đặc thù mà nếu không hiểu, bạn sẽ viết requirement sai hoàn toàn: đây là ngành bị quản lý rất chặt (heavily regulated). Bạn không thể thiết kế một luồng mở ví điện tử như cách Uber thiết kế luồng đặt xe. Mỗi nút bấm "Đăng ký", mỗi bước nhập CCCD, mỗi giao dịch chuyển tiền đều bị ràng buộc bởi quy định của Ngân hàng Nhà nước (NHNN/SBV), Bộ Công An, và các quy tắc phòng chống rửa tiền (AML). Một BA giỏi ở FinTech không chỉ hiểu nghiệp vụ — họ hiểu được ranh giới pháp lý của từng tính năng.
Bài này giúp bạn nắm bản đồ domain FinTech VN: ai là cơ quan quản lý, e-KYC và tích hợp định danh quốc gia hoạt động ra sao, hệ sinh thái thanh toán (Napas, VietQR, VNPAY, MoMo, ZaloPay) vận hành thế nào, và AML rule phức tạp ra sao. Đây là kiến thức nền để bạn tự tin nói chuyện với compliance officer, với dev tích hợp cổng thanh toán, và với cả lãnh đạo về risk.
Khái niệm cốt lõi
FinTech VN là một ngành "regulated" — và điều đó định hình mọi requirement
Khác với e-commerce hay edtech, ở FinTech mỗi tính năng đều phải trả lời câu hỏi: "Điều này có được phép theo luật không?". Có ba nhóm cơ quan bạn cần thuộc tên:
- Ngân hàng Nhà nước (NHNN, tiếng Anh hay gọi là SBV — State Bank of Vietnam): cơ quan cấp phép và quản lý trực tiếp ví điện tử, trung gian thanh toán, cho vay ngang hàng. Các thông tư như Thông tư 23/2019, Thông tư 40/2024 (về hoạt động trung gian thanh toán và ví điện tử) quy định cụ thể: ai được mở ví, hạn mức giao dịch, yêu cầu liên kết tài khoản ngân hàng, lưu trữ dữ liệu.
- Bộ Công An (C06): quản lý Cơ sở dữ liệu quốc gia về dân cư và hệ thống định danh điện tử VNeID. Mọi luồng e-KYC nghiêm túc tại VN giờ đều phải đối chiếu với dữ liệu của Bộ Công An.
- Cục Phòng chống rửa tiền (thuộc NHNN): nơi tiếp nhận báo cáo giao dịch đáng ngờ (STR) và giao dịch giá trị lớn (CTR) theo Luật Phòng chống rửa tiền 2022.
e-KYC và tích hợp định danh quốc gia
e-KYC (electronic Know Your Customer) là quy trình xác minh danh tính khách hàng từ xa, không cần ra quầy. Đây là tính năng "xương sống" của mọi FinTech VN. Một luồng e-KYC điển hình gồm:
- Người dùng chụp ảnh CCCD gắn chip (mặt trước/sau).
- OCR đọc thông tin từ thẻ.
- NFC hoặc đối chiếu với CSDL quốc gia về dân cư để xác thực thẻ thật.
- Liveness check (xác minh người sống — yêu cầu quay đầu, nháy mắt) để chống giả mạo bằng ảnh tĩnh.
- Face matching: so khớp khuôn mặt selfie với ảnh trên CCCD.
Hệ sinh thái thanh toán: Napas, VietQR, VNPAY, MoMo, ZaloPay
Hiểu được "ai làm gì" trong chuỗi thanh toán là kỹ năng then chốt khi bạn viết requirement tích hợp:
- Napas (Công ty Cổ phần Thanh toán Quốc gia VN): hạ tầng chuyển mạch tài chính — gần như mọi giao dịch chuyển khoản liên ngân hàng và thanh toán thẻ nội địa đều đi qua Napas. Napas cũng vận hành chuẩn VietQR.
- VietQR: chuẩn mã QR thống nhất cho chuyển khoản ngân hàng. Khi bạn quét một mã QR ngân hàng và thấy tên người nhận tự hiện ra, đó là VietQR đang hoạt động.
- VNPAY: cổng thanh toán (payment gateway) phổ biến, thường được merchant tích hợp để nhận thanh toán qua QR, thẻ, ví.
- MoMo, ZaloPay: ví điện tử (e-wallet) — vừa là phương thức thanh toán cho người dùng cuối, vừa là một kênh mà merchant có thể tích hợp.
AML rule phức tạp
AML (Anti-Money Laundering — phòng chống rửa tiền) là tập quy tắc giám sát giao dịch để phát hiện hành vi rửa tiền và tài trợ khủng bố. Một số khái niệm BA phải nắm:
- CDD/EDD: thẩm định khách hàng (Customer Due Diligence) và thẩm định tăng cường (Enhanced Due Diligence) cho khách hàng rủi ro cao.
- Sàng lọc danh sách: đối chiếu khách hàng với danh sách cấm vận (sanction list), danh sách đen, và PEP (Politically Exposed Person — cá nhân có ảnh hưởng chính trị).
- Transaction monitoring: các rule như "giao dịch chia nhỏ để né ngưỡng báo cáo" (structuring/smurfing), "tốc độ giao dịch bất thường", "nạp vào rút ra ngay".
- CTR & STR: báo cáo giao dịch giá trị lớn (theo ngưỡng quy định, ví dụ từ 400 triệu đồng) và báo cáo giao dịch đáng ngờ gửi cơ quan chức năng.
Tình huống thực tế
Ví dụ 1: Ví điện tử siết hạn mức theo trạng thái KYC
Bối cảnh: Một ví điện tử tầm trung (giả định tên "ViPay", 2 triệu người dùng) yêu cầu BA thiết kế lại luồng nạp/rút tiền sau khi NHNN nhắc nhở về việc cho phép giao dịch quá hạn mức với tài khoản chưa định danh đầy đủ.
Diễn giải: BA phát hiện hệ thống cũ chỉ có hai trạng thái "chưa KYC" và "đã KYC". Nhưng quy định thực tế phân biệt nhiều cấp: ví chưa định danh chỉ được giữ số dư rất nhỏ và không được rút; ví đã e-KYC cơ bản có hạn mức trung bình; ví đã xác thực nâng cao (liên kết tài khoản ngân hàng chính chủ) mới được hạn mức cao. BA mô hình hóa thành một state machine với các trạng thái KYC level và gắn mỗi level một bộ hạn mức (nạp/ngày, rút/ngày, số dư tối đa, số dư/tháng). Mỗi giao dịch trước khi thực hiện đều chạy qua "limit check engine".
Bài học: Đừng mô hình KYC như một boolean. Ở FinTech VN, KYC là nhiều tầng, và mỗi tầng mở khóa một bộ quyền hạn khác nhau. Tư duy phân tầng kiểm soát này chính là thứ dân Finance làm rất tự nhiên.
Ví dụ 2: Đối soát lệch với cổng thanh toán
Bối cảnh: Một sàn TMĐT tích hợp VNPAY để nhận thanh toán. Sau một tháng, kế toán phát hiện báo cáo doanh thu nội bộ lệch khoảng 18 triệu đồng so với file đối soát từ VNPAY. BA được kéo vào để phân tích.
Diễn giải: BA dựng lại sơ đồ trạng thái giao dịch và phát hiện lỗ hổng: khi người dùng thanh toán xong nhưng đóng trình duyệt trước khi callback (IPN — Instant Payment Notification) trả về, hệ thống giữ đơn ở trạng thái "pending" mãi mãi, dù tiền đã vào tài khoản merchant. BA viết bổ sung requirement: (1) một job định kỳ chủ động gọi API "query transaction" của VNPAY để tự đồng bộ trạng thái, không phụ thuộc hoàn toàn vào IPN; (2) một báo cáo đối soát ba chiều giữa đơn hàng nội bộ — log cổng — file đối soát cuối ngày, tự động đánh dấu dòng lệch.
Bài học: Ở FinTech, "thành công ở phía cổng" và "thành công ở phía mình" là hai sự kiện khác nhau và có thể lệch. BA phải luôn thiết kế cơ chế đối soát chủ động, đừng tin tưởng 100% vào callback. Đây là lúc nền kế toán của bạn tỏa sáng.
Ví dụ 3: Rule AML chặn nhầm khách hàng thật
Bối cảnh: Một công ty cho vay tiêu dùng số (giả định "CredFast") triển khai rule AML đơn giản: chặn mọi khách hàng có tên trùng với danh sách PEP. Sau khi go-live, bộ phận CSKH ngập trong khiếu nại — nhiều khách hàng tên phổ thông như "Nguyễn Văn Hùng" bị chặn oan vì trùng tên người trong danh sách.
Diễn giải: BA làm việc với compliance để thiết kế lại logic sàng lọc: thay vì chặn cứng (hard block) khi trùng tên, hệ thống tính điểm khớp dựa trên nhiều yếu tố (tên + ngày sinh + số giấy tờ), và phân luồng theo điểm: điểm cao thì chặn và chuyển compliance review, điểm trung bình thì cho qua nhưng gắn cờ theo dõi, điểm thấp thì cho qua bình thường. BA cũng viết requirement cho một màn hình "case management" để nhân viên compliance xử lý các trường hợp nghi ngờ thủ công.
Bài học: AML rule không phải là logic nhị phân đúng/sai. Nó luôn là cân bằng giữa false positive (chặn nhầm khách thật, gây mất khách) và false negative (bỏ lọt giao dịch xấu, gây rủi ro pháp lý). BA giỏi sẽ định lượng được sự đánh đổi này và thiết kế quy trình con người xử lý phần xám.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi nhận một yêu cầu trong dự án FinTech VN:
- Xác định "lớp tuân thủ" trước tiên. Trước khi viết bất kỳ user story nào, hỏi: tính năng này chịu sự điều chỉnh của quy định nào? (ví điện tử → thông tư của NHNN; định danh → quy định của Bộ Công An; giao dịch → Luật Phòng chống rửa tiền). Liệt kê các ràng buộc pháp lý dưới dạng business rule.
- Vẽ sơ đồ hệ sinh thái tích hợp. Tính năng này chạm tới những đối tác bên ngoài nào (Napas, cổng thanh toán, nhà cung cấp e-KYC, ngân hàng liên kết)? Mỗi đối tác là một integration point cần làm rõ API, SLA, cơ chế lỗi và đối soát.
- Mô hình hóa trạng thái KYC và hạn mức. Liệt kê các cấp KYC, gắn mỗi cấp một bộ hạn mức rõ ràng dưới dạng bảng. Đây thường là tài sản tài liệu quý nhất bạn tạo ra.
- Viết đầy đủ non-happy-path. Với mỗi luồng tiền, liệt kê các trường hợp lỗi: timeout cổng, callback mất, số dư không đủ, vượt hạn mức, KYC thất bại, bị AML chặn. Quy định rõ hành vi hệ thống cho từng case.
- Thiết kế cơ chế đối soát. Với mọi luồng có tiền đi ra/vào hệ thống bên ngoài, định nghĩa quy trình reconciliation cuối ngày: nguồn dữ liệu nào đối với nguồn nào, ngưỡng lệch chấp nhận được, ai xử lý dòng lệch.
- Làm việc với compliance officer sớm. Đừng đợi tới UAT mới đưa compliance vào. Họ là stakeholder bắt buộc, không phải tùy chọn. Hẹn họ review business rule ngay từ đầu.
Lỗi thường gặp & mẹo
- Mô hình KYC như một biến boolean. Sai. KYC ở VN là nhiều tầng, mỗi tầng mở khóa hạn mức khác nhau. Luôn mô hình hóa thành nhiều trạng thái.
- Tin tưởng tuyệt đối vào callback của cổng thanh toán. Callback có thể mất, trễ, hoặc đến hai lần (duplicate). Luôn thiết kế thêm cơ chế chủ động truy vấn trạng thái và xử lý idempotency (gọi nhiều lần nhưng kết quả không bị nhân đôi).
- Bỏ qua đối soát. Nếu requirement của bạn không có phần reconciliation, nó chưa hoàn chỉnh ở FinTech. Mẹo: tận dụng đúng tư duy "khóa sổ cuối kỳ" của dân kế toán — coi mỗi cuối ngày là một lần khóa sổ giao dịch.
- Viết AML rule kiểu chặn cứng. Dễ gây chặn nhầm hàng loạt. Mẹo: luôn kèm cơ chế tính điểm và một luồng "compliance review" cho con người xử lý phần xám.
- Không hiểu giới hạn pháp lý nên hứa tính năng "thoáng" với business. Ví dụ hứa cho phép nạp tiền mặt ẩn danh không giới hạn — vi phạm quy định. Mẹo: với mỗi tính năng "thoáng" mà business muốn, kiểm tra chéo với quy định trước khi cam kết.
- Quên dữ liệu phải lưu trữ trong nước. Nhiều quy định yêu cầu dữ liệu giao dịch và định danh phải lưu tại VN trong thời hạn nhất định. Hãy đưa yêu cầu lưu trữ và truy xuất lịch sử vào non-functional requirement.
Bài tập thực hành
- Bản đồ tuân thủ: Chọn một tính năng FinTech (ví dụ "nạp tiền vào ví bằng QR ngân hàng"). Liệt kê tối thiểu 5 business rule xuất phát từ quy định (hạn mức, yêu cầu KYC, nguồn tiền hợp lệ, lưu trữ, đối soát). Ghi rõ rule nào đến từ NHNN, Bộ Công An hay Luật PCRT.
- Bảng KYC-hạn mức: Thiết kế một bảng gồm 3 cấp KYC (chưa định danh / e-KYC cơ bản / xác thực nâng cao), mỗi cấp ghi rõ: được làm gì, hạn mức nạp/ngày, hạn mức rút/ngày, số dư tối đa.
- Sơ đồ trạng thái giao dịch: Vẽ state machine cho một giao dịch thanh toán qua cổng (VNPAY hoặc MoMo), bao gồm tối thiểu các trạng thái: khởi tạo, chờ thanh toán, thành công, thất bại, chờ đối soát, hoàn tiền. Đánh dấu nơi callback và nơi truy vấn chủ động.
- Thiết kế rule AML: Viết logic phân luồng cho việc sàng lọc một khách hàng mới, sao cho tránh chặn nhầm: nêu các yếu tố tính điểm khớp và ba ngưỡng hành động (chặn / gắn cờ / cho qua).
Tóm tắt
FinTech VN là domain mà người xuất thân Finance/Kế toán có lợi thế tự nhiên, nhưng chỉ khi bạn hiểu đặc thù của nó. Bốn trụ cột cần nắm: (1) đây là ngành bị quản lý chặt bởi NHNN, Bộ Công An và quy định phòng chống rửa tiền — mọi requirement có một lớp tuân thủ nằm trên cùng; (2) e-KYC và tích hợp định danh quốc gia là xương sống, đòi hỏi xử lý kỹ các trường hợp thất bại; (3) hệ sinh thái thanh toán (Napas, VietQR, VNPAY, MoMo, ZaloPay) là chuỗi nhiều mắt xích, mỗi mắt xích cần đối soát riêng; (4) AML rule là bài toán cân bằng false positive và false negative, không phải logic nhị phân.
Lợi thế lớn nhất của bạn: tư duy kiểm soát, đối soát và khóa sổ của dân Finance khớp gần như hoàn hảo với những gì FinTech cần ở một BA. Hãy biến nó thành thương hiệu nghề nghiệp của mình.