Mở đầu — vì sao bài này quan trọng
Khi bạn từ QA/Tester chuyển sang BA và nộp đơn vào một ngân hàng hay công ty fintech, có một sự thật phũ phàng bạn cần biết sớm: nhà tuyển dụng không sợ bạn thiếu kỹ năng viết user story hay vẽ process flow. Cái họ sợ là bạn không hiểu domain ngân hàng. Một BA giỏi nghiệp vụ nhưng không biết "hạch toán kép" (double-entry) là gì, không phân biệt được tài khoản CASA với tài khoản tiền gửi có kỳ hạn, không hiểu quy định của Ngân hàng Nhà nước về phòng chống rửa tiền — thì sẽ viết ra những tài liệu yêu cầu sai về bản chất, và không ai trong team nghiệp vụ tin tưởng giao việc.
Đây chính là lý do bài này tồn tại. Banking là một trong những domain "khó vào nhưng đáng tiền nhất" cho BA tại Việt Nam. Lương BA banking thường cao hơn BA domain phổ thông 20–40%, nhưng đổi lại đòi hỏi bạn hiểu cả nghiệp vụ ngân hàng lẫn lớp compliance (tuân thủ pháp lý) dày đặc. Tin vui là: với nền tảng QA, bạn có một lợi thế cực lớn ở mảng compliance — bởi vì compliance về bản chất chính là một tập hợp khổng lồ các "acceptance criteria bắt buộc" do luật pháp đặt ra, và bạn vốn đã quen với tư duy "điều kiện phải thỏa mãn, không được vi phạm".
Bài này tập trung chuyên sâu vào domain banking và lớp compliance — phần kiến thức nghiệp vụ mà bạn phải nạp để làm BA ngân hàng thực thụ. (Phần compliance ở góc độ luật chung như PDPD/GDPR đã có ở Bài 36 và Bài 56; ở đây ta đi sâu riêng vào ngân hàng.)
Khái niệm cốt lõi
Core banking — trái tim của ngân hàng
"Core banking" là hệ thống lõi xử lý mọi giao dịch tiền tệ và quản lý tài khoản của một ngân hàng. Khi bạn rút tiền ATM, chuyển khoản, hay vay tiền — tất cả cuối cùng đều chạm vào core banking. Là BA ngân hàng, bạn gần như chắc chắn sẽ làm việc xung quanh hệ thống này. Tại Việt Nam có ba "dòng máu" core banking phổ biến bạn cần thuộc tên:
- T24 (Temenos) — hệ thống core banking của hãng Temenos (Thụy Sĩ), phổ biến nhất tại VN. Vietcombank, Techcombank, VPBank đều dùng nền tảng dòng Temenos. T24 nổi tiếng linh hoạt nhưng cấu hình phức tạp, dùng ngôn ngữ jBASE/Infobasic ở lớp dưới.
- Flexcube (Oracle FLEXCUBE) — core banking của Oracle, được Sacombank, ACB và nhiều ngân hàng dùng. Mạnh về module tín dụng và kế toán, chạy trên nền Oracle Database.
- TCBS / core in-house — một số ngân hàng tự xây hoặc tùy biến sâu. Techcombank có hệ sinh thái tự phát triển mạnh; nhiều ngân hàng số (Cake, Timo, TNEX) xây core hiện đại theo kiến trúc microservices, API-first.
Các module nghiệp vụ chính của một ngân hàng
Một BA banking nên hình dung ngân hàng như tập hợp các module nghiệp vụ. Đây là bản đồ tối thiểu:
- CIF (Customer Information File) — hồ sơ thông tin khách hàng. Mọi khách hàng có một mã CIF duy nhất, gắn với CMND/CCCD/hộ chiếu. Đây là gốc của KYC.
- CASA (Current Account – Savings Account) — tài khoản thanh toán và tiết kiệm không kỳ hạn. Nguồn vốn rẻ nhất của ngân hàng.
- Deposit / Term Deposit — tiền gửi có kỳ hạn, sổ tiết kiệm, tính lãi theo kỳ.
- Loan / Credit — cho vay: vay tiêu dùng, vay thế chấp, thẻ tín dụng. Phức tạp nhất về quy tắc nghiệp vụ (lãi suất, kỳ trả, phân loại nợ, dự phòng rủi ro).
- Payment & Transfer — chuyển khoản nội bộ, liên ngân hàng (qua NAPAS, Citad của NHNN), thanh toán quốc tế (SWIFT).
- Card — thẻ ghi nợ (debit), thẻ tín dụng (credit), kết nối tổ chức thẻ Visa/Mastercard/NAPAS.
- Trade Finance / Treasury — tài trợ thương mại (L/C), kinh doanh ngoại hối, nguồn vốn.
- GL (General Ledger) — sổ cái kế toán. Mọi giao dịch đều phải hạch toán kép (Nợ – Có) cân bằng. Đây là nơi compliance kế toán sống.
Compliance trong ngân hàng — "acceptance criteria do luật đặt ra"
Đây là phần bạn — dân QA — sẽ thấy thân quen lạ thường. Compliance ngân hàng là tập hợp các quy định bắt buộc, vi phạm sẽ bị phạt nặng hoặc rút giấy phép. Các trụ cột chính:
- KYC (Know Your Customer) — định danh khách hàng. Theo Luật Phòng chống rửa tiền 2022 và Thông tư 17/2024/TT-NHNN, ngân hàng phải xác minh danh tính, làm eKYC, đối chiếu sinh trắc học.
- AML/CFT (Anti-Money Laundering / Chống tài trợ khủng bố) — giám sát giao dịch đáng ngờ, báo cáo giao dịch giá trị lớn (từ 400 triệu VND trở lên) cho NHNN, sàng lọc danh sách cấm vận (sanction screening) như OFAC, UN.
- Quyết định 2345/QĐ-NHNN — quy định xác thực sinh trắc học cho giao dịch chuyển tiền trên 10 triệu/lần hoặc 20 triệu/ngày (hiệu lực từ 01/07/2024). Đây là ví dụ kinh điển một quy định compliance biến thành hàng loạt yêu cầu hệ thống.
- Basel / phân loại nợ & trích lập dự phòng — Thông tư 11/2021/TT-NHNN quy định nhóm nợ 1–5 và tỷ lệ dự phòng.
- Bảo mật dữ liệu & PCI-DSS — chuẩn bảo mật dữ liệu thẻ; cộng với Nghị định 13/2023 về bảo vệ dữ liệu cá nhân (PDPD).
Tình huống thực tế
Tình huống 1 — Quyết định 2345 và bài học "luật là acceptance criteria"
Giữa năm 2024, toàn bộ ngân hàng Việt Nam phải triển khai Quyết định 2345/QĐ-NHNN: mọi giao dịch chuyển tiền trên 10 triệu VND/lần hoặc tổng trên 20 triệu VND/ngày bắt buộc xác thực bằng sinh trắc học khuôn mặt khớp với dữ liệu CCCD gắn chip.
Tại một ngân hàng tầm trung (giả định gọi là Ngân hàng An Bình), một BA xuất thân QA tên Linh được giao viết yêu cầu cho luồng này. Thay vì viết chung chung "thêm xác thực khuôn mặt", Linh bóc tách quy định thành một bảng business rules với các ngưỡng cụ thể: giao dịch ≤ 10 triệu và lũy kế ngày ≤ 20 triệu thì xác thực OTP như cũ; vượt ngưỡng thì bắt buộc liveness check + so khớp khuôn mặt với chip CCCD qua NFC. Cô còn liệt kê hàng loạt edge case từ phản xạ nghề QA: khách chuyển 9 triệu ba lần liên tiếp trong ngày (tổng 27 triệu) thì giao dịch thứ ba có bị chặn không? Khách CCCD cũ chưa gắn chip thì xử lý ra sao? Đối chiếu khuôn mặt thất bại 3 lần liên tiếp thì khóa hay cho thử lại?
Diễn giải: Phần lớn BA non-domain chỉ viết được "happy path". Linh, nhờ nền QA, biến quy định pháp lý thành một ma trận điều kiện đầy đủ — và đội kiểm thử lẫn dev đều khen tài liệu "test được ngay". Bài học: trong banking, một văn bản pháp lý chính là nguồn acceptance criteria. Người đọc luật giỏi và bóc được edge case chính là BA banking giỏi.
Tình huống 2 — CIF trùng và nỗi đau KYC tại ngân hàng dùng Flexcube
Một ngân hàng dùng Oracle Flexcube (giả định là Phương Nam Bank) gặp sự cố: một khách hàng có hai mã CIF khác nhau vì khi mở tài khoản tiết kiệm năm 2019 nhân viên nhập sai một ký tự số CMND, còn năm 2023 lúc làm thẻ tín dụng thì nhập CCCD mới. Hậu quả: hệ thống tính hạn mức tín dụng và phân loại nợ tách rời trên hai CIF, dẫn đến rủi ro AML (một người hai danh tính) và sai lệch báo cáo gửi NHNN.
BA phụ trách dự án "hợp nhất CIF" phải hiểu rằng đây không chỉ là bài toán kỹ thuật gộp bản ghi. Cô phải làm việc với phòng Compliance để định nghĩa quy tắc đối sánh trùng (matching rule): trùng số định danh + ngày sinh + họ tên đã chuẩn hóa thì coi là một người; xử lý hậu hợp nhất với các tài khoản, khoản vay, lịch sử giao dịch đang treo trên cả hai CIF; và đảm bảo dấu vết kiểm toán (audit trail) cho mỗi lần gộp để giải trình với thanh tra NHNN.
Diễn giải: Bài học ở đây là CIF là "single source of truth" về khách hàng, và mọi quy định KYC/AML đều xây trên nền CIF sạch. Bài học: BA banking phải tư duy ở tầng dữ liệu nền — một lỗi nhập liệu nhỏ ở CIF có thể đẻ ra vi phạm compliance lớn. Đây cũng là chỗ kỹ năng phân tích dữ liệu của QA phát huy.
Tình huống 3 — Sàng lọc cấm vận chặn nhầm khách hàng thật
Tại một ngân hàng có nghiệp vụ thanh toán quốc tế qua SWIFT, hệ thống sàng lọc cấm vận (sanction screening) liên tục báo "khớp" với một khách hàng tên Nguyễn Văn Minh, chặn lệnh chuyển tiền của anh ra nước ngoài. Lý do: thuật toán fuzzy matching khớp tên anh với một cá nhân trong danh sách OFAC trùng họ và tên đệm. Đây gọi là false positive — chặn nhầm người vô tội.
BA được giao tinh chỉnh quy tắc sàng lọc. Cô phải cân bằng hai phía: nếu nới lỏng quá thì bỏ lọt đối tượng thật (rủi ro pháp lý nghiêm trọng); nếu siết quá thì chặn nhầm hàng loạt khách hàng tốt, gây trải nghiệm tệ và quá tải đội xử lý thủ công. Cô thiết kế quy tắc nhiều tầng: khớp 100% tên + ngày sinh + quốc tịch thì chặn cứng; chỉ khớp tên thì chuyển sang hàng đợi review thủ công thay vì chặn ngay; đồng thời định nghĩa ngưỡng điểm tương đồng (matching score) cho từng mức.
Diễn giải: Khái niệm false positive / false negative là ngôn ngữ mẹ đẻ của QA. Một BA từng làm QA hiểu ngay rằng đây là bài toán đánh đổi (trade-off) giữa "độ phủ" và "độ nhiễu", giống hệt việc cân bằng test coverage. Bài học: trong compliance banking, không có quy tắc nào "đúng tuyệt đối" — BA phải thiết kế cơ chế phân tầng và đo lường, đúng tinh thần đo lường mà QA đã rèn.
Hướng dẫn từng bước
Đây là lộ trình thực tế để bạn — một QA — nạp đủ domain banking compliance để tự tin nhận việc BA:
- Dựng bản đồ nghiệp vụ ngân hàng trong đầu. Vẽ ra 8 module ở trên và mối quan hệ giữa chúng: CIF là gốc, CASA/Deposit/Loan gắn vào CIF, mọi giao dịch hạch toán xuống GL. Bạn phải trả lời được "một giao dịch chuyển khoản đi qua những module nào".
- Học một core banking đại diện. Chọn T24 hoặc Flexcube (tùy ngân hàng bạn nhắm tới) và đọc tài liệu khái niệm: cách nó tổ chức account, transaction, sản phẩm (product condition). Bạn không cần thành admin, chỉ cần hiểu mô hình dữ liệu và thuật ngữ.
- Lập "thư viện compliance". Lập một file tổng hợp các văn bản cốt lõi và tóm tắt mỗi cái thành vài quy tắc hệ thống: Luật Phòng chống rửa tiền 2022, Thông tư 17/2024 (KYC/eKYC), Quyết định 2345 (sinh trắc học), Thông tư 11/2021 (phân loại nợ), Nghị định 13/2023 (PDPD). Mỗi quy định, viết một câu "hệ thống phải/không được...".
- Dịch một quy định thành business rules. Lấy Quyết định 2345 làm bài tập: viết ra bảng điều kiện đầy đủ (ngưỡng, ngoại lệ, edge case). Đây là kỹ năng cốt lõi và cũng là cách bạn chứng minh giá trị trong phỏng vấn.
- Ánh xạ tư duy QA sang BA. Mỗi lần gặp quy định, tự hỏi: "Nếu là QA, tôi sẽ viết test case gì để chứng minh hệ thống tuân thủ?" — rồi đảo ngược thành requirement. Tư duy negative testing của bạn chính là nguồn phát hiện lỗ hổng compliance.
- Học từ vựng để nói chuyện với nghiệp vụ. Thuộc các thuật ngữ: nhóm nợ (1–5), CASA, dư nợ, hạn mức, hạch toán Nợ/Có, đối chiếu (reconciliation), bút toán (journal entry). Dùng đúng từ là cách nhanh nhất để được tin tưởng.
- Tìm một dự án/case study để thực hành. Nếu chưa làm banking, hãy lấy một quy định công khai (như 2345) và tự viết bộ requirement hoàn chỉnh đưa vào portfolio. Nhà tuyển dụng banking đánh giá rất cao điều này.
Lỗi thường gặp & mẹo
- Lỗi: coi compliance là "ràng buộc phụ" thay vì requirement cốt lõi. Trong banking, vi phạm compliance có thể khiến ngân hàng bị phạt hàng tỷ đồng. Hãy đối xử với mỗi điều khoản luật như một acceptance criteria không thể bỏ qua.
- Lỗi: chỉ viết happy path. BA banking yếu thường quên các tình huống ngoại lệ: tài khoản đóng băng theo lệnh tòa, khách hàng nằm trong danh sách cảnh báo, giao dịch vượt ngưỡng lũy kế ngày. Tận dụng phản xạ edge case của QA — đây là siêu năng lực của bạn.
- Lỗi: không phân biệt được "quy định nói gì" và "hệ thống làm gì". Luật viết bằng ngôn ngữ pháp lý mơ hồ. Việc của BA là làm rõ, không phải chép nguyên văn. Luôn truy hỏi phòng Compliance đến khi mỗi quy tắc đủ cụ thể để dev code và QA test.
- Mẹo: kết bạn với phòng Compliance và Pháp chế. Họ là stakeholder quan trọng nhất nhưng thường bị BA bỏ quên. Một buổi cà phê với chuyên viên compliance bằng cả tuần đọc tài liệu.
- Mẹo: luôn nghĩ đến audit trail. Mọi thứ trong banking phải truy vết được: ai làm, khi nào, dữ liệu trước/sau. Khi viết requirement, mặc định thêm yêu cầu ghi log kiểm toán — đây là điểm BA banking chuyên nghiệp khác BA nghiệp dư.
- Mẹo: theo dõi văn bản mới của NHNN. Domain banking compliance thay đổi liên tục. Đặt lịch đọc bản tin NHNN hàng tháng để không bị lạc hậu — và để có chủ đề chứng tỏ độ "cập nhật" khi phỏng vấn.
Bài tập thực hành
- Bản đồ module: Vẽ sơ đồ một giao dịch "khách hàng A chuyển 15 triệu VND cho khách hàng B cùng ngân hàng". Liệt kê đầy đủ các module nó đi qua (CIF, CASA, GL...) và chỉ ra tại bước nào Quyết định 2345 buộc phải chèn xác thực sinh trắc học.
- Dịch luật thành business rules: Lấy Quyết định 2345, viết một bảng business rules đầy đủ gồm ít nhất 8 dòng điều kiện, trong đó có ít nhất 3 edge case (ví dụ: lũy kế ngày vượt ngưỡng dù từng giao dịch dưới ngưỡng; CCCD chưa gắn chip; liveness check thất bại nhiều lần).
- Phân tích false positive: Với tình huống sàng lọc cấm vận ở Tình huống 3, đề xuất một quy tắc phân tầng (chặn cứng / review thủ công / cho qua) và giải thích bạn cân bằng rủi ro pháp lý với trải nghiệm khách hàng ra sao.
- Portfolio piece: Viết một trang requirement ngắn (1–2 trang) cho tính năng "hợp nhất CIF trùng", gồm: mô tả vấn đề, matching rule, xử lý hậu hợp nhất, và yêu cầu audit trail. Lưu lại để đưa vào portfolio BA của bạn.
Tóm tắt
Banking là domain "khó vào nhưng đáng tiền" cho BA tại Việt Nam, và lợi thế lớn nhất của người từ QA chuyển sang nằm chính ở lớp compliance — bởi vì compliance về bản chất là một tập hợp khổng lồ các acceptance criteria do luật pháp đặt ra. Bạn cần nạp ba khối kiến thức: (1) core banking (T24/Temenos ở VCB-TCB-VPBank, Flexcube/Oracle ở Sacombank-ACB, core in-house ở các ngân hàng số); (2) các module nghiệp vụ từ CIF, CASA, Deposit, Loan đến Payment, Card và GL; và (3) các trụ cột compliance gồm KYC, AML/CFT, Quyết định 2345 về sinh trắc học, phân loại nợ và bảo vệ dữ liệu.
Kỹ năng cốt lõi của BA banking là dịch điều khoản pháp lý mơ hồ thành business rules cụ thể, đầy đủ edge case — đúng phản xạ mà bạn đã rèn suốt thời làm QA. Hãy đối xử với mỗi quy định như acceptance criteria bắt buộc, luôn nghĩ đến ngoại lệ và audit trail, kết thân với phòng Compliance, và biến một quy định công khai như Quyết định 2345 thành portfolio piece để chứng minh năng lực. Khi làm được điều đó, bạn không còn là "QA muốn đổi nghề" nữa — bạn là một BA banking thực thụ mà thị trường đang khát.