Mở đầu — vì sao bài này quan trọng
Nếu bạn là developer đang chuyển sang BA và nhắm tới thị trường IT Việt Nam, có một sự thật khó chối cãi: banking (ngân hàng) là mỏ vàng lớn nhất và cũng khắc nghiệt nhất. Các ngân hàng như Vietcombank, Techcombank, VPBank, ACB, TPBank chi hàng trăm tỷ đồng mỗi năm cho các dự án chuyển đổi số, và họ luôn thiếu BA hiểu được cả hai thế giới: nghiệp vụ ngân hàng và kiến trúc hệ thống bên dưới. Đây chính là chỗ bạn — một dev cũ — có lợi thế cực lớn, nếu bạn chịu học đúng thứ cần học.
Vấn đề là hầu hết dev khi phỏng vấn BA cho ngân hàng đều rớt ở cùng một câu hỏi: "Em hiểu core banking hoạt động thế nào không?" hoặc "Một giao dịch chuyển khoản đi qua những hệ thống nào?". Bạn có thể code cực giỏi, nhưng nếu không phân biệt được core banking với channel, không biết T24 khác Flexcube ra sao, không hiểu tại sao một giao dịch lại phải chạy qua Napas thì nhà tuyển dụng sẽ đánh giá bạn chỉ là "dev biết viết tài liệu", chứ không phải BA domain banking.
Bài này không dạy bạn thành chuyên gia ngân hàng trong một buổi — điều đó bất khả thi. Mục tiêu là cho bạn bản đồ kiến trúc hệ thống lõi ngân hàng: những khối chính, cách chúng nói chuyện với nhau, và những thuật ngữ nghiệp vụ bạn bắt buộc phải nắm để không "chết ngộp" trong buổi họp đầu tiên với team core banking.
Khái niệm cốt lõi
Core banking system (CBS) là gì
Core banking là "trái tim" của ngân hàng — hệ thống ghi nhận và quản lý toàn bộ tài khoản khách hàng, số dư, sổ cái (general ledger), lãi suất, và xử lý các giao dịch tài chính cơ bản: gửi tiền, rút tiền, chuyển khoản, tính lãi, tất toán. Chữ "core" (lõi) rất quan trọng: mọi con số tiền thật cuối cùng đều phải được ghi nhận ở đây. Nếu app mobile báo bạn có 10 triệu, con số đó là bản sao đọc từ core; số dư "chính thống" nằm trong CBS.
Một cách hình dung dễ nhớ cho dev: core banking giống như database layer + business logic layer của tiền thật, còn tất cả app mobile, internet banking, ATM chỉ là các "client" gọi vào nó.
Ba lớp kiến trúc bạn phải phân biệt
Đây là mô hình mà mọi BA banking ở Việt Nam đều dùng để tư duy:
Core banking (lõi): quản lý tài khoản, sổ cái, sản phẩm tiền gửi/tiền vay, tính lãi. Đây là nơi ghi "sự thật" về tiền.
Channels (kênh): những điểm khách hàng chạm vào — mobile banking, internet banking, ATM, POS, quầy giao dịch (teller), call center. Channel không tự ghi tiền; nó gọi xuống core qua các lớp trung gian.
Middleware / integration layer: lớp ở giữa, thường là ESB (Enterprise Service Bus) hoặc API gateway, làm nhiệm vụ định tuyến, chuyển đổi định dạng, và bảo vệ core khỏi bị gọi trực tiếp. Ở nhiều ngân hàng VN, lớp này dùng công nghệ như IBM MQ, WSO2, hoặc các API layer tự xây.
Khi bạn viết requirement cho một tính năng "chuyển tiền nhanh 24/7", bạn phải biết nó chạm cả ba lớp: channel (app) → middleware → core → và ra ngoài qua Napas. Nếu bạn chỉ mô tả phần app, BA của bạn bị coi là hời hợt.
Các hệ core banking phổ biến tại Việt Nam
Đây là kiến thức "đắt giá" mà bạn nên thuộc lòng vì nó hay được hỏi trong phỏng vấn:
T24 (Temenos): đây là hệ core banking phổ biến nhất thế giới và cũng rất phổ biến ở VN. Vietcombank, Techcombank, VPBank và nhiều ngân hàng lớn dùng T24. T24 nổi tiếng với khái niệm COB (Close of Business) — quá trình chạy cuối ngày để chốt sổ, tính lãi, sinh báo cáo. Là BA, bạn sẽ nghe cụm "sau COB" rất nhiều: nghĩa là giao dịch chỉ được phản ánh đầy đủ sau khi hệ thống chạy xong batch cuối ngày.
Flexcube (Oracle FLEXCUBE): một hệ core banking mạnh khác, được các ngân hàng như Sacombank, ACB và một số ngân hàng khác sử dụng ở các thời kỳ. Flexcube cũng theo mô hình có batch cuối ngày và cấu trúc module theo sản phẩm (deposit, loan, trade finance...).
Core in-house / tự phát triển: một số tổ chức chọn tự xây một phần. Ví dụ TCBS (Techcom Securities) trong lĩnh vực chứng khoán, hay xu hướng các ngân hàng số mới xây core theo hướng cloud-native, microservice để linh hoạt hơn T24 truyền thống.
Bạn không cần cài đặt được T24, nhưng bạn phải nói được: "T24 là core banking của Temenos, có COB cuối ngày, các ngân hàng lớn VN dùng nhiều." Chỉ một câu đó đã tách bạn khỏi 80% ứng viên BA khác.
Real-time vs batch — cái bẫy tư duy của dev
Dev quen tư duy mọi thứ real-time: gọi API, có kết quả ngay. Trong banking, rất nhiều thứ chạy theo batch (xử lý theo lô, thường cuối ngày). Tính lãi tiết kiệm, sinh sao kê, đối soát (reconciliation) với Napas — đa số là batch. Hiểu ranh giới này giúp bạn viết requirement đúng: ví dụ "số dư khả dụng" (available balance) khác "số dư sổ sách" (ledger balance) vì có các giao dịch đang treo (pending) chưa được core hạch toán cuối ngày.
Những thực thể nghiệp vụ cốt lõi
Là BA banking, bạn phải thuộc các thực thể: CIF (Customer Information File — hồ sơ thông tin khách hàng, mỗi khách một CIF duy nhất), Account (tài khoản, một CIF có thể có nhiều account), GL / General Ledger (sổ cái kế toán), Transaction (giao dịch), Product (sản phẩm — loại tiền gửi, loại vay). Quan hệ CIF → nhiều Account → nhiều Transaction là xương sống dữ liệu của mọi ngân hàng.
Tình huống thực tế
Tình huống 1: Dự án "chuyển tiền nhanh 24/7" tại một ngân hàng dùng T24
Một ngân hàng tầm trung ở TP.HCM muốn ra mắt tính năng chuyển tiền nhanh liên ngân hàng 24/7 qua Napas. Một BA vốn là dev được giao viết requirement. Bạn ấy mô tả rất kỹ phần API mobile app, nhưng bỏ qua một điều: T24 chạy COB mỗi đêm, và trong khoảng thời gian COB (thường 30–90 phút), core "đóng băng" không nhận giao dịch hạch toán bình thường.
Kết quả: khi demo, các giao dịch gửi vào lúc 1 giờ sáng (đang COB) bị lỗi, tiền khách bị trừ ở app nhưng chưa vào core, gây ra tình trạng "treo tiền". Team vận hành phải xử lý thủ công.
Bài học: BA banking phải hỏi ngay từ đầu: "Trong lúc COB, giao dịch được xử lý thế nào?" Giải pháp thường là dùng cơ chế "hold and post" — tạm giữ và hạch toán sau khi COB xong, cộng với hàng đợi (queue) ở middleware. Nếu bạn từng làm việc với message queue khi còn là dev, đây chính là lúc kiến thức đó tỏa sáng. Bạn hiểu queue, retry, idempotency — những thứ cực kỳ quan trọng khi thiết kế luồng giao dịch qua Napas để tránh chuyển tiền trùng (double posting).
Tình huống 2: Phân biệt available balance và ledger balance ở một ví điện tử liên kết ngân hàng
Một startup fintech ở Hà Nội xây ví điện tử liên kết tài khoản ngân hàng. BA (dev cũ) viết yêu cầu: "Hiển thị số dư tài khoản cho user." Team dev lấy thẳng ledger balance từ core hiển thị lên. Nhưng khách hàng vừa quẹt thẻ mua hàng 500.000đ, giao dịch này đang pending, chưa được core hạch toán. App hiển thị số dư cao hơn số tiền khách thực sự tiêu được, khách rút hết và... âm quỹ.
Bài học: Trong banking, "số dư" không phải một con số duy nhất. Có ledger balance (số dư sổ sách, đã hạch toán) và available balance (số dư khả dụng = ledger trừ các khoản đang giữ/pending). BA phải chỉ rõ trong requirement dùng loại nào cho màn hình nào. Đây là chi tiết mà chỉ BA hiểu core mới bắt được, và nó cứu ngân hàng khỏi rủi ro tài chính thật.
Tình huống 3: Migration từ core cũ sang T24 tại một ngân hàng thương mại
Một ngân hàng quyết định thay core cũ bằng T24 của Temenos, dự án kéo dài gần hai năm, ngân sách hàng trăm tỷ. BA nền dev được giao phần data migration. Thách thức lớn nhất không phải kỹ thuật ETL — mà là mapping dữ liệu: core cũ lưu khách hàng theo số tài khoản, T24 tổ chức theo CIF. Một khách có 3 tài khoản ở core cũ phải gộp về 1 CIF trong T24, nhưng dữ liệu cũ trùng lặp, sai chính tả tên, CMND không chuẩn.
BA phải làm data profiling, định nghĩa quy tắc gộp (dedup rule), và quan trọng nhất là quy tắc đối chiếu số dư trước và sau migration phải khớp tuyệt đối — sai một đồng cũng không được chấp nhận.
Bài học: Trong dự án core banking, chính xác dữ liệu tài chính là bất khả xâm phạm. Kỹ năng data modeling và SQL từ thời dev giúp bạn viết reconciliation report, nhưng tư duy BA đòi hỏi bạn hiểu nghiệp vụ đủ sâu để biết "một CIF gộp từ nhiều account" nghĩa là gì về mặt pháp lý và vận hành.
Hướng dẫn từng bước
Đây là quy trình để một dev-turned-BA "vào nghề" domain banking mà không bị chết chìm:
Bước 1 — Dựng bản đồ hệ thống của chính ngân hàng bạn đang làm. Xin sơ đồ kiến trúc (system landscape) từ team giải pháp. Xác định: core banking nào (T24/Flexcube/khác), middleware gì, các channel nào, kết nối ra Napas/SWIFT ra sao. Vẽ lại bằng ngôn ngữ của bạn.
Bước 2 — Học từ vựng nghiệp vụ trước, kỹ thuật sau. Thuộc CIF, GL, COB, available vs ledger balance, debit/credit, reconciliation. Mỗi ngày ghi chú 5 thuật ngữ mới nghe trong họp và tra nghĩa.
Bước 3 — Truy vết một giao dịch end-to-end. Chọn một luồng đơn giản như "chuyển khoản nội bộ" và vẽ nó đi qua từng lớp: app → middleware → core → GL. Đây là bài tập giá trị nhất, nó buộc bạn hiểu cả kiến trúc lẫn nghiệp vụ.
Bước 4 — Xác định ranh giới real-time và batch. Với mỗi tính năng, hỏi: cái gì xảy ra ngay, cái gì đợi COB? Ghi rõ trong requirement.
Bước 5 — Kết nối với các hệ thống vệ tinh. Banking không chỉ có core: còn LOS (Loan Origination System) cho khoản vay, card management cho thẻ, AML/KYC cho tuân thủ, Napas/SWIFT cho liên ngân hàng. Biết chúng tồn tại và vai trò của chúng.
Bước 6 — Viết requirement có "reconciliation mindset". Với mỗi luồng tiền, luôn tự hỏi: nếu lỗi giữa chừng thì tiền ở đâu, ai chịu, làm sao đối soát và bù trừ.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi core banking như một API bình thường. Core không phải microservice bạn muốn gọi lúc nào cũng được. Nó có giờ COB, có giới hạn tải, có ràng buộc kế toán. Đừng thiết kế luồng giả định core luôn sẵn sàng real-time.
Lỗi 2 — Nhầm số dư. Như tình huống 2, dùng sai available/ledger balance là lỗi kinh điển và nguy hiểm. Luôn hỏi rõ.
Lỗi 3 — Bỏ qua idempotency và double posting. Dev giỏi thường biết idempotency, nhưng khi thành BA lại quên đưa vào requirement. Trong banking, hạch toán trùng một giao dịch nghĩa là tạo/mất tiền thật. Luôn yêu cầu mã giao dịch duy nhất và cơ chế chống trùng.
Lỗi 4 — Nhảy vào giải pháp kỹ thuật quá sớm. Đây là bẫy của dev. Trong họp với business, họ cần bạn hiểu quy trình nghiệp vụ (ví dụ quy trình phê duyệt hạn mức vay), chứ chưa cần bạn bàn database schema. Kiềm chế "máu code".
Mẹo: Tận dụng đúng lợi thế dev — khi team core banking giải thích luồng batch, retry, message queue, bạn hiểu ngay và có thể đặt câu hỏi sắc bén mà BA thuần nghiệp vụ không đặt được. Đó là "signature move" của bạn, hãy dùng nó để tạo uy tín.
Mẹo: Học nghiệp vụ ngân hàng qua chính app ngân hàng bạn dùng hằng ngày. Mỗi tính năng trên app đều có một luồng core đằng sau — tập thói quen tự hỏi "cái này chạm core thế nào?".
Bài tập thực hành
- Vẽ landscape 3 lớp. Vẽ sơ đồ core – middleware – channels cho một ngân hàng giả định dùng T24, chú thích Napas nằm ở đâu. Ghi rõ điểm nào real-time, điểm nào batch.
- Truy vết giao dịch. Viết mô tả từng bước một giao dịch "chuyển khoản 2 triệu từ Vietcombank sang Techcombank qua app", đi qua channel, middleware, core, Napas. Đánh dấu chỗ nào có thể lỗi và tiền "kẹt" ở đâu.
- Phân tích số dư. Cho một tài khoản có ledger balance 5.000.000đ, một giao dịch quẹt thẻ pending 1.200.000đ chưa hạch toán. Tính available balance và viết requirement cho màn hình "Số dư khả dụng" trên mobile app, nêu rõ dùng loại số dư nào và vì sao.
- Bảng thuật ngữ. Lập bảng 15 thuật ngữ core banking (CIF, GL, COB, ledger balance, available balance, reconciliation, debit/credit, posting, batch, Napas, SWIFT, LOS, KYC/AML, T24, Flexcube), mỗi thuật ngữ một câu giải thích cho người mới.
Tóm tắt
Domain banking là cánh cửa lương cao nhất cho BA ở Việt Nam, và bạn — một dev cũ — có lợi thế thật sự nếu nắm được kiến trúc hệ thống lõi. Điều cốt lõi cần nhớ: core banking (T24 của Temenos, Flexcube của Oracle, hay core in-house) là nơi ghi "sự thật" về tiền, phân biệt rõ ba lớp core – middleware – channel, hiểu ranh giới real-time và batch (đặc biệt là COB cuối ngày), và không bao giờ nhầm giữa available balance với ledger balance. Ba tình huống trong bài — chuyển tiền 24/7 vướng COB, ví điện tử nhầm số dư, và migration sang T24 — đều cho thấy cùng một chân lý: trong banking, tiền là thật và sai sót không được tha thứ.
Lợi thế dev của bạn nằm ở chỗ hiểu queue, idempotency, batch, retry — những thứ quyết định sự an toàn của luồng tiền. Hãy dùng nó, nhưng luôn kiềm chế "nhảy vào giải pháp" quá sớm và ưu tiên hiểu nghiệp vụ. Nắm vững bài này, bạn đã sẵn sàng bước vào buổi họp đầu tiên với team core banking mà không còn thấy lạc lõng.