Mở đầu — vì sao bài này quan trọng
Khi bạn đi phỏng vấn vị trí BA cho một ngân hàng hay công ty fintech tại Việt Nam, gần như chắc chắn sẽ có một câu hỏi quen thuộc: "Em hiểu gì về core banking?". Đây là câu hỏi sàng lọc. Người ta không kỳ vọng bạn — một người từ nền Marketing — code được hệ thống, nhưng họ cần biết bạn có nắm được "bộ não" của ngân hàng vận hành ra sao hay không. Vì nếu không hiểu core banking, bạn sẽ viết requirement sai, hứa với khách hàng những thứ hệ thống không làm được, và mất uy tín với đội dev ngay trong sprint đầu tiên.
Banking là một trong những domain trả lương BA cao nhất Việt Nam (chúng ta đã nói chi tiết ở Bài 49 về bảng lương), nhưng cũng là domain có rào cản kiến thức cao nhất. Tin tốt là: rào cản đó chủ yếu nằm ở thuật ngữ và cách hệ thống được lắp ghép, chứ không phải ở kỹ thuật lập trình. Một marketer giỏi vốn quen làm việc với "khách hàng, hành trình, điểm chạm" — và bạn sẽ thấy banking cũng xoay quanh đúng những thứ đó, chỉ là dưới một lớp vỏ nghiệp vụ khắt khe hơn.
Bài này tập trung riêng vào core banking system — trái tim công nghệ của ngân hàng. Chúng ta sẽ đi từ kiến trúc tổng thể, các nền tảng phổ biến tại Việt Nam (T24, Flexcube), đến cách dữ liệu chạy bên trong khi một giao dịch xảy ra, và cuối cùng là những gì một BA cần biết để làm việc hiệu quả trong dự án ngân hàng. (Bài 41 đã bàn về compliance PDPD/GDPR, nên ở đây tôi sẽ không đi sâu vào pháp lý mà tập trung vào hệ thống.)
Khái niệm cốt lõi
Core banking là gì?
"Core banking" (viết tắt là CBS — Core Banking System) là hệ thống trung tâm xử lý các nghiệp vụ ngân hàng cốt lõi: mở tài khoản, ghi sổ giao dịch, tính lãi, quản lý khoản vay, hạch toán kế toán. Chữ "core" (lõi) rất quan trọng — nó là nơi lưu sự thật cuối cùng về số dư của khách hàng. Mọi kênh khác (app mobile, Internet Banking, ATM, quầy giao dịch) đều chỉ là "cửa sổ" nhìn vào core, còn con số thật nằm trong core.
Hãy hình dung bằng một phép so sánh từ Marketing: nếu app mobile banking giống như giao diện chiến dịch quảng cáo mà khách hàng nhìn thấy, thì core banking chính là cái database tổng và hệ thống tính tiền phía sau — nơi quyết định khách hàng thực sự có bao nhiêu tiền, nợ bao nhiêu, lãi suất ra sao.
Các nền tảng core banking phổ biến tại Việt Nam
Bạn sẽ nghe các tên này liên tục trong môi trường ngân hàng VN, nên cần thuộc:
- T24 (Temenos) — nền tảng core của Thụy Sĩ, phổ biến bậc nhất. Được dùng tại Vietcombank, Techcombank, VPBank, Sacombank (giai đoạn nhất định) và nhiều ngân hàng khác. T24 nổi tiếng linh hoạt, mạnh về retail banking, có khái niệm "COB" (Close Of Business — chạy cuối ngày) mà BA cần hiểu rất rõ.
- Flexcube (Oracle FLEXCUBE) — nền tảng của Oracle, được dùng tại một số ngân hàng như ACB và nhiều ngân hàng trong khu vực. Mạnh về hạch toán, tích hợp tốt với hệ sinh thái Oracle.
- TCBS / Symbols / BDS và các core nội địa hoặc khác — một số ngân hàng dùng các nền tảng khác như Profile (FIS), hoặc các giải pháp được tùy biến sâu. Ngoài ra, các ngân hàng số thế hệ mới (Cake, Timo, TNEX) thường dùng core "cloud-native" như Mambu hoặc Thought Machine Vault — đây là xu hướng core banking thế hệ mới, nhẹ hơn, mở API tốt hơn.
Kiến trúc tổng thể: core không đứng một mình
Một hiểu lầm phổ biến của người mới là nghĩ "core banking làm tất cả". Thực tế, core chỉ là trung tâm của một hệ sinh thái lớn gồm nhiều hệ thống vệ tinh:
- Core banking (CBS): tài khoản, sổ cái, tiền gửi, khoản vay.
- Card Management System (CMS): quản lý thẻ tín dụng/ghi nợ.
- Payment switch / Napas: định tuyến giao dịch liên ngân hàng (chuyển khoản 24/7 tại VN đi qua Napas).
- Internet/Mobile Banking (digital channels): kênh khách hàng tương tác.
- LOS / LMS (Loan Origination/Management System): khởi tạo và quản lý khoản vay.
- CRM, Data Warehouse, ESB/API Gateway: quản lý quan hệ khách hàng, kho dữ liệu, và lớp tích hợp.
Những khái niệm nghiệp vụ BA banking buộc phải nắm
- CIF (Customer Information File): hồ sơ định danh khách hàng, là "khóa" duy nhất gắn khách hàng với mọi tài khoản. Một khách hàng = một CIF = nhiều account.
- Account / Tài khoản: gắn với CIF, có loại (thanh toán, tiết kiệm, vay), số dư, trạng thái.
- GL (General Ledger — Sổ cái): mọi giao dịch đều phải hạch toán cân đối Nợ/Có vào sổ cái. Đây là điểm khác biệt lớn so với hệ thống thường: trong banking, không có giao dịch nào "biến mất" — mọi thứ đều phải cân sổ.
- EOD / COB (End Of Day / Close Of Business): quá trình "chốt ngày" — tính lãi, phân loại nợ, sinh báo cáo. Trong khoảng thời gian này hệ thống thường hạn chế giao dịch. BA hay bị "dính" yêu cầu liên quan đến thời điểm chốt ngày.
- Posting date vs Value date: ngày ghi sổ và ngày hiệu lực (ngày bắt đầu tính lãi) có thể khác nhau — một chi tiết nhỏ nhưng sai là lệch tiền lãi của khách.
- Reconciliation (đối soát): so khớp giao dịch giữa core và các hệ thống bên ngoài (Napas, đối tác). Sai một đồng cũng phải tìm ra.
Tình huống thực tế
Tình huống 1 — Ra mắt tài khoản tiết kiệm online tại một ngân hàng dùng T24
Một ngân hàng cổ phần tầm trung (giả định tên "Ngân hàng Phương Đông Bank") muốn cho khách mở sổ tiết kiệm online ngay trên app, lãi suất cao hơn 0,3% so với quầy. Sản phẩm nghe đơn giản, nhưng BA mới — vốn từ Marketing — viết requirement kiểu "khách bấm nút, tiền chuyển vào sổ tiết kiệm, hệ thống tính lãi".
Khi vào họp với đội core T24, hàng loạt câu hỏi bật ra mà bạn không lường được: Sổ tiết kiệm online sẽ tạo product code nào trong T24? Lãi nhập gốc hay trả cuối kỳ? Value date là thời điểm khách bấm nút hay thời điểm tiền thực ghi có? Nếu khách rút trước hạn thì tính lãi không kỳ hạn ra sao và core có tự xử lý hay phải build thêm? Giao dịch chuyển từ tài khoản thanh toán sang sổ tiết kiệm hạch toán vào GL account nào?
Bài học: requirement banking không thể dừng ở "trải nghiệm khách hàng" — nó phải đi xuống tới cấu hình sản phẩm và hạch toán trong core. BA giỏi từ nền Marketing là người vẫn giữ được tư duy hành trình khách hàng, nhưng học cách "dịch" nó sang ngôn ngữ product code, value date và GL của core T24.
Tình huống 2 — Sự cố lệch số dư do hiểu sai EOD tại một ví điện tử kết nối ngân hàng
Một fintech (giả định "PayGo") tích hợp với ngân hàng đối tác để khách nạp tiền từ tài khoản ngân hàng vào ví. BA phía PayGo viết flow nạp tiền là đồng bộ (synchronous): khách bấm nạp → gọi API ngân hàng → ngân hàng trừ tiền → cộng tiền vào ví ngay.
Vấn đề xảy ra vào khung 22h–23h mỗi ngày: nhiều giao dịch nạp bị treo "pending" rồi báo lỗi, nhưng vài tiếng sau khách lại thấy tài khoản ngân hàng bị trừ tiền. Lý do: đó là khung COB của core ngân hàng, hệ thống trả timeout cho API nhưng giao dịch vẫn được ghi sổ ở phía core. Vì PayGo không thiết kế cơ chế đối soát (reconciliation) cuối ngày, ví không cộng tiền dù ngân hàng đã trừ — khách hàng mất tiền, tổng đài cháy máy.
Bài học: trong banking, không bao giờ được giả định "API lỗi nghĩa là giao dịch không xảy ra". BA phải luôn thiết kế kèm cơ chế đối soát và xử lý giao dịch "nghi ngờ" (suspicious/unknown). Hiểu COB và recon là kiến thức sống còn, không phải chi tiết kỹ thuật phụ.
Tình huống 3 — Migration từ core cũ sang core mới (Mambu) tại một ngân hàng số
Một ngân hàng số mới thành lập quyết định chuyển từ một core nội bộ sang Mambu (core cloud-native) để mở API nhanh hơn cho các sản phẩm cho vay tiêu dùng. BA được giao viết requirement mapping dữ liệu khách hàng và khoản vay từ hệ cũ sang Mambu.
Thách thức không nằm ở công nghệ mà ở sự khác biệt mô hình dữ liệu: core cũ gộp khách hàng và tài khoản lỏng lẻo, còn Mambu tách rất rõ Client — Account — Loan. Có những khách hàng ở hệ cũ có hai bản ghi trùng (không có CIF chuẩn), khi sang Mambu phải gộp lại. BA phải làm bảng mapping từng trường, định nghĩa rule gộp CIF, và xử lý các case lỗi dữ liệu lịch sử.
Bài học: dự án core banking lớn nhất thường là core migration, và ở đó BA đóng vai trò trung tâm trong việc làm rõ mô hình dữ liệu cũ – mới. Đây cũng là loại dự án trả lương cao và là điểm vàng để một BA tích lũy domain expertise banking thật sự.
Hướng dẫn từng bước
Nếu bạn vừa nhận một task BA trong dự án có dính tới core banking, hãy đi theo trình tự này:
- Xác định core đang dùng: Hỏi ngay "ngân hàng/dự án này chạy core gì — T24, Flexcube, Mambu hay core nội bộ?". Câu trả lời định hình toàn bộ giới hạn và khả năng của hệ thống.
- Vẽ bản đồ hệ thống (system landscape): Liệt kê core và các hệ vệ tinh liên quan đến yêu cầu của bạn (CMS, channels, ESB, Napas, LOS...). Xác định yêu cầu của bạn "chạm" vào những hệ nào.
- Truy vết luồng dữ liệu của một giao dịch: Với mỗi yêu cầu, vẽ flow: kênh nào khởi tạo → đi qua API gateway/ESB nào → core xử lý gì → hạch toán GL ra sao → trả kết quả về đâu. Đây là kỹ năng cốt lõi.
- Làm rõ các "thời điểm" nghiệp vụ: posting date, value date, ảnh hưởng của COB/EOD. Hỏi rõ giao dịch xảy ra trong giờ hành chính hay 24/7, có chạm khung chốt ngày không.
- Định nghĩa hạch toán và đối soát: Mỗi luồng tiền phải làm rõ ghi vào GL nào, và cơ chế đối soát với hệ thống bên ngoài là gì. Luôn hỏi: "Nếu bước này lỗi giữa chừng thì tiền đi đâu, ai chịu, đối soát thế nào?".
- Làm rõ trạng thái và ngoại lệ: Liệt kê đầy đủ trạng thái giao dịch (pending, success, failed, reversed, suspicious) và rule chuyển trạng thái. Banking sống bằng việc xử lý đúng các case ngoại lệ.
- Kiểm tra với SME core: Trước khi chốt requirement, ngồi với chuyên gia vận hành core (thường là người làm config T24/Flexcube) để xác nhận hệ thống "làm được thật" theo cách bạn mô tả.
Lỗi thường gặp & mẹo
- Lỗi: coi core như hộp đen "làm được mọi thứ". Người mới hứa với business những thứ core không hỗ trợ sẵn, đến lúc dev báo "T24 không có product type này" thì vỡ kế hoạch. Mẹo: luôn xác nhận năng lực core trước khi cam kết.
- Lỗi: bỏ qua hạch toán GL và đối soát. Marketer quen nghĩ tới trải nghiệm, hay quên phần "tiền phải cân sổ". Mẹo: với mọi luồng tiền, tự hỏi ba câu — ghi Nợ tài khoản nào, ghi Có tài khoản nào, đối soát với ai.
- Lỗi: thiết kế giao dịch chỉ cho "happy path". Banking là domain của ngoại lệ: timeout, reversal, double-charge, giao dịch treo. Mẹo: dành ít nhất một nửa thời gian phân tích cho các case lỗi và cơ chế phục hồi.
- Lỗi: lẫn lộn posting date và value date, dẫn tới sai tiền lãi. Mẹo: trong mọi sản phẩm có lãi, ghi rõ value date được xác định thế nào.
- Mẹo vàng cho người từ Marketing: tận dụng điểm mạnh của bạn. Bạn quen vẽ customer journey — hãy biến nó thành "transaction journey" xuyên qua các hệ thống. Bạn quen nói chuyện với người, hãy dùng kỹ năng đó để khai thác SME core (những người này thường ít giải thích, bạn phải biết hỏi đúng). Đừng cố trở thành kỹ sư; hãy là cây cầu giữa business và core.
- Mẹo học nhanh thuật ngữ: lập một glossary riêng (CIF, GL, COB, value date, recon, Napas, switch...) và bổ sung mỗi khi gặp từ mới trong họp. Sau 2–3 tháng bạn sẽ "nói được tiếng core".
Bài tập thực hành
- Bài tập vẽ luồng: Chọn nghiệp vụ "chuyển khoản 24/7 liên ngân hàng 5 triệu đồng qua Napas". Vẽ sơ đồ luồng từ app mobile → core ngân hàng gửi → Napas → core ngân hàng nhận, chỉ rõ ở mỗi bước: hệ thống nào xử lý, tiền được hạch toán ra sao, và điểm nào cần đối soát. Đánh dấu ít nhất 2 điểm có thể lỗi và mô tả cách xử lý.
- Bài tập glossary: Tự viết định nghĩa bằng lời của bạn cho 8 thuật ngữ: CIF, GL, EOD/COB, value date, posting date, reconciliation, payment switch, ESB. Mỗi thuật ngữ kèm một ví dụ thực tế.
- Bài tập tình huống: Một ngân hàng dùng T24 muốn ra mắt "tài khoản tích lũy tự động" — mỗi khi khách chi tiêu qua thẻ, hệ thống làm tròn số tiền lên và chuyển phần lẻ vào một tài khoản tiết kiệm. Hãy liệt kê 10 câu hỏi bạn sẽ đặt cho đội core và đội thẻ để có thể viết requirement đầy đủ. (Gợi ý: nghĩ về CIF, product code, value date, hạch toán, ngoại lệ khi tài khoản nguồn không đủ tiền, COB.)
Tóm tắt
Core banking là "trái tim" lưu sự thật về tiền của khách hàng; mọi kênh khác chỉ là cửa sổ nhìn vào nó. Tại Việt Nam, bạn sẽ gặp chủ yếu T24 (Temenos) — VCB, Techcombank, VPBank; Flexcube (Oracle) — ACB và một số ngân hàng; cùng làn sóng core cloud-native như Mambu, Thought Machine ở các ngân hàng số. Core không đứng một mình mà là trung tâm của hệ sinh thái gồm CMS, channels, Napas, LOS và lớp tích hợp ESB/API.
Là BA, bạn không cần code core, nhưng buộc phải nắm các khái niệm sống còn: CIF, GL, COB/EOD, value date vs posting date, và reconciliation. Ba tình huống trong bài cho thấy cùng một bài học: requirement banking phải đi xuống tới cấu hình sản phẩm, hạch toán và xử lý ngoại lệ — không được dừng ở trải nghiệm bề mặt. Hãy biến điểm mạnh customer journey từ Marketing thành "transaction journey" xuyên hệ thống, lập glossary riêng, và luôn xác nhận với SME core trước khi cam kết. Làm được vậy, bạn không chỉ vượt qua câu hỏi phỏng vấn "em hiểu gì về core banking", mà thực sự trở thành một BA banking có giá trị trên thị trường.