Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Designer, có lẽ bạn đã quen với những dự án kéo dài vài tuần đến vài tháng: một tính năng mới, một lần redesign, một chiến dịch. Bây giờ hãy tưởng tượng bạn bước vào một dự án kéo dài 18 đến 36 tháng, ngân sách trên 100 tỷ đồng, với hàng chục nhân sự BA, hàng trăm requirement liên quan đến tiền của khách hàng thật. Đó chính là thế giới của core banking — và nó khác biệt hoàn toàn với bất kỳ domain nào bạn từng chạm tới.
Banking là một trong những domain trả lương BA cao nhất tại Việt Nam. Một BA có kinh nghiệm core banking tại VPBank, Techcombank, TPBank hay các đối tác triển khai như FPT Information System, TCB có thể nhận mức 30–60 triệu/tháng, thậm chí cao hơn nếu làm cho vendor quốc tế. Lý do đơn giản: rào cản gia nhập rất cao. Domain knowledge banking không thể học trong một tuần, và sai một requirement ở đây không chỉ là lỗi UX — nó có thể khiến ngân hàng bị phạt bởi Ngân hàng Nhà nước, mất tiền thật, hoặc vi phạm quy định chống rửa tiền.
Với nền tảng Design, bạn có một lợi thế bất ngờ mà nhiều BA thuần kỹ thuật không có: khả năng nhìn hệ thống từ góc độ trải nghiệm khách hàng và tư duy về luồng end-to-end. Nhưng bạn cũng cần lấp đầy một khoảng trống rất lớn về kiến thức nghiệp vụ ngân hàng. Bài này sẽ giúp bạn hiểu banking/core banking đủ sâu để không bị "ngợp" khi bước vào phòng họp, và biết chính xác cần học gì trước tiên.
Khái niệm cốt lõi
Core banking là gì?
Core banking (viết tắt CBS — Core Banking System) là "trái tim" của ngân hàng — hệ thống trung tâm xử lý các nghiệp vụ nền tảng: mở tài khoản, ghi nợ/ghi có (debit/credit), tính lãi, quản lý sổ cái (general ledger), xử lý khoản vay, tiền gửi. Mọi giao dịch của khách hàng, dù đi qua ứng dụng mobile, ATM, hay quầy giao dịch, cuối cùng đều "đáp xuống" core banking để được ghi nhận chính thức.
Điều quan trọng cần hiểu: core banking là hệ thống ghi sổ (system of record). Nếu app mobile là "gương mặt" của ngân hàng, thì core banking là "quyển sổ cái" — nơi con số cuối cùng được coi là sự thật. Đây là lý do các dự án core banking cực kỳ khắt khe: một lỗi làm số dư sai lệch dù chỉ 1 đồng cũng là không thể chấp nhận.
Các vendor core banking lớn
Trên thế giới và tại Việt Nam, thị trường core banking bị thống trị bởi vài "ông lớn" mà bạn nhất định phải biết tên:
- Temenos T24 (Transact) — vendor Thụy Sĩ, phổ biến nhất tại VN. Nhiều ngân hàng như VPBank, Sacombank, ABBank từng hoặc đang dùng T24. Thuật ngữ đặc trưng: "T24 modules", "COB" (Close of Business — quy trình chốt cuối ngày).
- Finacle (Infosys) — vendor Ấn Độ, được dùng bởi ICB (VietinBank), một số ngân hàng lớn.
- Oracle FLEXCUBE — vendor Mỹ, mạnh về khả năng tùy biến.
- TCBS / các core nội địa — một số ngân hàng và công ty VN phát triển core riêng.
Cấu trúc một dự án core banking điển hình
Một dự án triển khai/thay thế core banking (core replacement) thường có các đặc điểm:
- Thời gian: 18–36 tháng. Không phải Agile sprint 2 tuần. Đây thường là mô hình lai (hybrid) hoặc waterfall có kiểm soát nghiêm ngặt.
- Ngân sách: trên 100 tỷ đồng, có khi lên tới vài nghìn tỷ với ngân hàng lớn.
- Nhiều luồng song song (workstream): Deposit (tiền gửi), Lending (cho vay), Payment (thanh toán), GL (sổ cái), Trade Finance (tài trợ thương mại), và tích hợp (integration).
- Data migration khổng lồ: chuyển hàng triệu tài khoản, hàng chục triệu bản ghi lịch sử giao dịch từ core cũ sang core mới — đây là phần rủi ro nhất.
- Nhiều bên tham gia: ngân hàng (khách hàng), vendor core (Temenos/Infosys), SI (System Integrator như FPT IS, TCB), và đôi khi cả tư vấn (Big4).
Vai trò BA trong core banking
BA trong core banking thường được phân theo module/nghiệp vụ. Bạn có thể là "BA Lending" chuyên về cho vay, "BA Payment" chuyên về thanh toán. Công việc chính:
- Requirement gathering theo nghiệp vụ ngân hàng — hiểu và mô tả quy trình như giải ngân khoản vay, phân loại nợ, trích lập dự phòng.
- Gap analysis — so sánh giữa quy trình hiện tại của ngân hàng (As-Is) với chức năng chuẩn của core mới (vanilla/out-of-the-box), xác định phần nào cần customize.
- Mapping data giữa core cũ và core mới trong data migration.
- Đảm bảo tuân thủ (compliance) — đối chiếu requirement với quy định của Ngân hàng Nhà nước (thông tư, quyết định) và các chuẩn quốc tế như Basel, AML/CFT.
Từ vựng nghiệp vụ bạn phải nắm
Đây là "ngôn ngữ" bạn cần học ngay, nếu không sẽ không hiểu người ta đang nói gì trong phòng họp:
- CASA — Current Account Savings Account (tài khoản thanh toán và tiết kiệm không kỳ hạn).
- GL — General Ledger (sổ cái).
- NPL — Non-Performing Loan (nợ xấu).
- Provisioning / trích lập dự phòng — theo Thông tư 11/2021 của NHNN, phân loại nợ nhóm 1–5.
- KYC / eKYC — nhận biết khách hàng.
- AML/CFT — phòng chống rửa tiền / tài trợ khủng bố.
- Interest accrual — dồn tích lãi hằng ngày.
- COB / EOD — Close of Business / End of Day, quy trình chốt cuối ngày.
- Reconciliation — đối soát.
Tình huống thực tế
Tình huống 1: Dự án core replacement tại một ngân hàng TMCP tầm trung
Một ngân hàng thương mại cổ phần cỡ trung tại VN (giả định tên "NamViet Bank") quyết định thay thế core cũ đã dùng 12 năm bằng Temenos T24. Ngân sách được duyệt là 380 tỷ đồng, timeline 28 tháng. Anh Tuấn — trước đây là UX Designer, mới chuyển sang BA được 8 tháng — được phân vào workstream Deposit.
Trong 3 tháng đầu, anh Tuấn gặp khó khăn không phải vì kỹ năng phân tích, mà vì không hiểu nghiệp vụ. Khi vendor T24 trình bày về cách tính lãi tiền gửi có kỳ hạn với các phương thức "lãi trả trước, lãi trả sau, lãi định kỳ", anh không phân biệt được và không biết ngân hàng mình đang áp dụng cách nào cho từng sản phẩm.
Bước ngoặt đến khi anh dùng chính lợi thế Design của mình: anh ngồi với các giao dịch viên (teller) ở chi nhánh, quan sát họ mở sổ tiết kiệm cho khách hàng thật, ghi lại toàn bộ luồng như một cách "user research". Từ đó anh vẽ ra được luồng As-Is chi tiết đến từng bước, phát hiện ra 3 sản phẩm tiết kiệm có quy tắc tính lãi khác nhau mà tài liệu chính thức không mô tả rõ.
Bài học: Nền tảng Design cho bạn kỹ năng quan sát và đồng cảm với người dùng cuối (teller, khách hàng). Nhưng bạn phải chủ động lấp đầy khoảng trống domain knowledge — không ai chờ bạn học từ từ trong dự án trăm tỷ.
Tình huống 2: Gap analysis và bài học "đừng customize bừa"
Cũng tại NamViet Bank, workstream Lending gặp một tình huống kinh điển. Ngân hàng có một quy trình phê duyệt khoản vay đặc thù với 7 cấp duyệt tùy theo hạn mức. Đội nghiệp vụ khăng khăng muốn giữ nguyên quy trình này và yêu cầu customize T24 để khớp 100%.
BA trưởng workstream — chị Hà — làm một việc rất quan trọng: chị làm gap analysis và trình bày rằng để customize workflow phê duyệt 7 cấp, chi phí ước tính 4,2 tỷ đồng và thêm 3 tháng vào timeline, đồng thời mỗi lần T24 nâng cấp (upgrade) sau này sẽ tốn thêm chi phí duy trì customization đó. Chị đề xuất phương án dùng cơ chế workflow chuẩn của T24 (chỉ hỗ trợ tối đa 5 cấp linh hoạt) và điều chỉnh chính sách phê duyệt nội bộ để phù hợp.
Sau khi cân nhắc, ban lãnh đạo chọn phương án của chị Hà: điều chỉnh quy trình thay vì customize hệ thống. Kết quả: tiết kiệm hơn 4 tỷ và tránh được "nợ kỹ thuật" dài hạn.
Bài học: Trong core banking, nguyên tắc vàng là "fit to standard" — ưu tiên điều chỉnh quy trình để dùng chức năng chuẩn của core, thay vì customize core theo quy trình cũ. BA giỏi không phải người viết requirement chiều lòng mọi bên, mà là người dám phân tích chi phí–lợi ích và tư vấn phương án tối ưu. Đây là nơi kỹ năng "business case" (đã học ở bài 9) của bạn tỏa sáng.
Tình huống 3: Data migration và cái giá của một requirement thiếu sót
Một ngân hàng khác (giả định "Đông Á Digital Bank") trong lúc go-live core mới đã gặp sự cố nghiêm trọng. Trong quá trình migrate dữ liệu, đội BA đã bỏ sót việc mô tả requirement cho các tài khoản tiết kiệm đã tất toán nhưng còn treo lãi chưa chi trả. Kết quả: khoảng 2.400 tài khoản sau khi lên core mới bị tính sai số dư lãi, tổng chênh lệch khoảng 180 triệu đồng.
Sự cố này không lớn về tiền, nhưng gây khủng hoảng niềm tin: bộ phận vận hành phải rà soát thủ công hàng nghìn tài khoản, và ngân hàng phải giải trình với NHNN về tính toàn vẹn dữ liệu (data integrity). Nguyên nhân gốc: BA chỉ mô tả requirement cho các trường hợp "bình thường" (happy path) mà không liệt kê đầy đủ các edge case của dữ liệu lịch sử.
Bài học: Trong core banking, "edge case" không phải chuyện phụ — nó là chuyện sống còn. Bạn phải tư duy về mọi trạng thái dữ liệu: tài khoản đóng, tài khoản đóng băng, khoản vay đã đảo nợ, giao dịch treo. Đây là lúc kỹ năng state machine (bài 22) và tư duy về mọi trạng thái nghiệp vụ trở nên quan trọng sống còn.
Hướng dẫn từng bước
Nếu bạn muốn định vị bản thân để bước vào domain core banking, đây là lộ trình thực tế:
Bước 1 — Xây nền tảng nghiệp vụ ngân hàng. Học 3 nhóm nghiệp vụ cốt lõi: tiền gửi (deposit), cho vay (lending), thanh toán (payment). Hiểu vòng đời của một khoản vay từ khi thẩm định đến tất toán, hiểu cách một giao dịch chuyển tiền được ghi nhận qua các tài khoản GL. Nguồn học tốt: giáo trình nghiệp vụ ngân hàng thương mại của các trường như Học viện Ngân hàng, và các thông tư của NHNN.
Bước 2 — Nắm khung pháp lý VN. Đọc và hiểu ít nhất: Thông tư 11/2021 (phân loại nợ và trích lập dự phòng), các quy định về eKYC, và quy định về phòng chống rửa tiền (Luật Phòng chống rửa tiền 2022). Không cần thuộc lòng, nhưng phải biết chúng tồn tại và ảnh hưởng đến requirement như thế nào.
Bước 3 — Làm quen với một core cụ thể. Chọn Temenos T24 (phổ biến nhất tại VN) để tìm hiểu qua tài liệu công khai và cộng đồng. Hiểu khái niệm module, parameter table, COB. Bạn không cần dựng được hệ thống, chỉ cần hiểu "ngôn ngữ" của nó.
Bước 4 — Học kỹ thuật gap analysis và fit-gap. Thực hành lập bảng so sánh As-Is (quy trình hiện tại) với chức năng chuẩn của core, phân loại mỗi gap thành: Fit (dùng được ngay), Configuration (chỉnh tham số), hoặc Customization (phải code). Với mỗi customization, luôn kèm ước tính chi phí và rủi ro.
Bước 5 — Rèn tư duy compliance-first. Với mỗi requirement bạn viết, tự hỏi: "Requirement này có vi phạm quy định nào không? Có cần lưu vết (audit trail) không? Dữ liệu này có nhạy cảm không?" Trong banking, tuân thủ không phải tùy chọn.
Bước 6 — Tận dụng mạng lưới. Kết nối với cộng đồng BA banking VN (bài 56 sẽ nói kỹ hơn về networking). Nhiều cơ hội core banking đến qua giới thiệu vì vendor và SI luôn thiếu BA có domain knowledge.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ core banking giống làm app fintech. Fintech app (ví điện tử, app cho vay) thường là lớp giao diện phía trước, chạy Agile nhanh. Core banking là hệ thống ghi sổ nền tảng, chạy chậm và khắt khe. Đừng mang tư duy "ship nhanh, fail nhanh" vào đây.
Lỗi 2 — Viết requirement chỉ theo happy path. Như tình huống 3 đã cho thấy, edge case trong banking là nơi phát sinh thảm họa. Mẹo: với mỗi nghiệp vụ, luôn liệt kê các trạng thái bất thường và câu hỏi "điều gì xảy ra nếu...".
Lỗi 3 — Sợ hỏi vì nghĩ mình dốt nghiệp vụ. Khi mới vào, bạn sẽ không hiểu nhiều thuật ngữ. Đừng giả vờ hiểu. Mẹo: chuẩn bị một cuốn glossary cá nhân, mỗi lần gặp thuật ngữ mới thì ghi lại và hỏi ngay. Sau 3 tháng bạn sẽ có "từ điển" của riêng mình.
Lỗi 4 — Chiều lòng nghiệp vụ bằng cách customize vô tội vạ. Mỗi customization là một khoản nợ kỹ thuật dài hạn. Mẹo: luôn hỏi "chức năng chuẩn của core làm được điều tương tự không? Chi phí customize so với lợi ích là bao nhiêu?"
Lỗi 5 — Bỏ qua data migration đến phút cuối. Migration là phần rủi ro nhất nhưng thường bị coi nhẹ. Mẹo: tham gia vào việc mapping dữ liệu từ sớm, và luôn yêu cầu reconciliation (đối soát) trước và sau migration.
Mẹo tận dụng nền Design: Dùng kỹ năng visualize của bạn để vẽ luồng nghiệp vụ (process flow, state diagram) mà đội thuần kỹ thuật thường trình bày bằng văn bản khô khan. Một BA từ Design có thể biến một requirement 10 trang chữ thành một sơ đồ dễ hiểu — đây là giá trị khác biệt của bạn.
Bài tập thực hành
Bài tập 1 — Xây glossary banking. Chọn nghiệp vụ tiền gửi có kỳ hạn (term deposit). Liệt kê và giải thích ngắn gọn ít nhất 15 thuật ngữ liên quan (ví dụ: kỳ hạn, lãi suất, tất toán trước hạn, lãi phạt rút trước hạn, gia hạn tự động...). Đây là bước đầu để xây "từ điển" của bạn.
Bài tập 2 — Vẽ vòng đời khoản vay. Vẽ một state diagram cho vòng đời một khoản vay tiêu dùng: từ trạng thái "Đăng ký" → "Thẩm định" → "Phê duyệt" → "Giải ngân" → "Đang trả nợ" → và các nhánh: "Quá hạn", "Nợ xấu", "Tất toán", "Đảo nợ". Với mỗi chuyển trạng thái, ghi rõ điều kiện kích hoạt.
Bài tập 3 — Mini gap analysis. Giả định ngân hàng của bạn muốn tính năng "tự động gia hạn sổ tiết kiệm khi đến hạn". Lập bảng gap analysis giả định với 3 cột: chức năng chuẩn core (giả định), quy trình mong muốn của ngân hàng, và phân loại gap (Fit/Config/Customize) kèm lý do. Mục tiêu là luyện tư duy fit-to-standard.
Bài tập 4 — Tìm edge case. Với nghiệp vụ chuyển khoản liên ngân hàng, liệt kê ít nhất 8 trường hợp bất thường (edge case) mà requirement phải xử lý (ví dụ: tài khoản người nhận bị đóng băng, số dư không đủ sau khi trừ phí, giao dịch trùng lặp...).
Tóm tắt
Core banking là domain có rào cản cao nhất nhưng cũng trả lương hậu hĩnh nhất cho BA tại Việt Nam. Điểm cốt lõi cần nhớ:
- Core banking là hệ thống ghi sổ (system of record) — nơi con số cuối cùng được coi là sự thật, nên độ chính xác là tuyệt đối.
- Dự án core banking khác hoàn toàn dự án thông thường: 18–36 tháng, ngân sách trên 100 tỷ, waterfall/hybrid, nhiều workstream song song, data migration rủi ro cao.
- Bạn phải biết các vendor lớn: Temenos T24 (phổ biến nhất VN), Finacle, Oracle FLEXCUBE — và hiểu giới hạn của chúng.
- Nguyên tắc vàng là "fit to standard" — ưu tiên điều chỉnh quy trình để dùng chức năng chuẩn, tránh customize vô tội vạ.
- Compliance và edge case là chuyện sống còn, không phải chuyện phụ.
- Lợi thế Design của bạn là khả năng quan sát người dùng cuối và visualize luồng nghiệp vụ phức tạp — hãy tận dụng, đồng thời chủ động lấp đầy khoảng trống domain knowledge.