Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ nền Finance hoặc Kế toán và đang nhắm tới sự nghiệp BA, thì core banking là một trong những "mỏ vàng" mà rất ít người ngoài ngành chạm tới được. Lý do đơn giản: đây là domain khó nhất, được trả lương cao nhất, và đòi hỏi người làm phải hiểu cả nghiệp vụ tài chính lẫn hệ thống. Một BA core banking có kinh nghiệm tại Việt Nam năm 2026 có thể nhận lương từ 40 đến 80 triệu/tháng, và ở cấp lead hoặc khi đi làm dự án cho ngân hàng nước ngoài thì con số còn cao hơn nhiều. Trong khi một BA fintech "thường" có thể bị thay thế bởi hàng trăm ứng viên, BA core banking giỏi thì ngân hàng phải săn đón.
Tại sao bạn — người từ Finance — lại có lợi thế ở đây? Vì core banking về bản chất là số hóa toàn bộ những gì bạn đã từng làm thủ công hoặc trên Excel: sổ cái, bút toán, hạch toán lãi, đối chiếu, báo cáo NHNN. Khi một dev nói về "GL posting", bạn đã hiểu đó là bút toán sổ cái từ lâu rồi. Khi BU yêu cầu "tính lãi theo phương pháp dư nợ giảm dần", bạn không cần ai giải thích. Đó là rào cản kiến thức mà người học IT thuần túy phải mất nhiều năm mới vượt qua, còn bạn thì đã có sẵn.
Bài này không dạy bạn cách viết PRD hay vẽ BPMN (những kỹ năng đó đã có ở các bài trước). Bài này tập trung vào một thứ duy nhất: hiểu đặc thù domain core banking để bạn bước vào dự án ngân hàng mà không bị "ngợp", biết các vendor lớn, hiểu vì sao dự án kéo dài 2-3 năm, và biết compliance khắt khe đến mức nào.
Khái niệm cốt lõi
Core banking là gì
Core banking (Core Banking System — CBS) là "trái tim" của ngân hàng — hệ thống xử lý các giao dịch nền tảng: mở tài khoản, gửi/rút tiền, cho vay, tính lãi, hạch toán sổ cái, và lưu trữ thông tin khách hàng. Mọi kênh khác (Internet Banking, Mobile App, ATM, thẻ) đều là vệ tinh kết nối vào core thông qua API hoặc middleware. Khi bạn chuyển khoản qua app, lệnh đó cuối cùng vẫn đi xuống core để ghi nợ tài khoản người gửi và ghi có tài khoản người nhận.
CBS thường có các module chính: CIF (Customer Information File — hồ sơ khách hàng tập trung), Deposits (tiền gửi), Loans (tín dụng), GL (General Ledger — sổ cái), Treasury (nguồn vốn), Trade Finance (tài trợ thương mại), và Payments. Một BA core banking thường chuyên sâu vào 1-2 module chứ hiếm khi giỏi toàn bộ.
Bốn đặc thù khiến core banking khác mọi domain khác
Thứ nhất — quy mô và thời gian dự án. Một dự án thay thế core banking (core replacement) thường kéo dài 18-36 tháng, ngân sách 100 tỷ đến hàng nghìn tỷ đồng. Đây không phải dự án "2 tuần một sprint, ship liên tục" như startup. Có giai đoạn blueprint kéo dài 4-6 tháng chỉ để phân tích nghiệp vụ trước khi viết một dòng code. Bạn phải quen với nhịp độ chậm, kỹ lưỡng, và việc một quyết định sai có thể tốn hàng tỷ đồng để sửa.
Thứ hai — vendor và sản phẩm đóng gói. Ngân hàng hiếm khi tự code core từ đầu. Họ mua sản phẩm của các vendor lớn rồi cấu hình (configure) và tùy chỉnh (customize). Bốn cái tên bạn bắt buộc phải biết:
- Temenos T24 (Transact) — vendor Thụy Sĩ, phổ biến nhất thế giới và rất mạnh tại Việt Nam (Sacombank, VPBank từng dùng). Đặc trưng bởi ngôn ngữ jBASE/T24, khái niệm "version", "enquiry", "COB" (Close of Business — chạy cuối ngày).
- Infosys Finacle — vendor Ấn Độ, mạnh ở mảng ngân hàng bán lẻ quy mô lớn.
- Oracle FLEXCUBE — chạy trên nền Oracle DB, được nhiều ngân hàng VN dùng (VIB, một số ngân hàng dùng FLEXCUBE).
- TCS BaNCS — của Tata, mạnh ở thị trường ngân hàng và bảo hiểm.
Thứ ba — compliance cực kỳ chặt. Ngân hàng là ngành chịu giám sát nặng nhất. BA core banking phải hiểu các yêu cầu của Ngân hàng Nhà nước (NHNN): Thông tư 39/2016 về cho vay, Thông tư 11/2021 về phân loại nợ và trích lập dự phòng, các quy định về báo cáo CIC, KYC/eKYC, phòng chống rửa tiền (AML), Basel II/III về quản trị rủi ro. Mỗi requirement bạn viết phải truy được về một quy định pháp lý hoặc chính sách nội bộ. Một lỗi tính trích lập dự phòng sai có thể khiến ngân hàng bị NHNN phạt và ảnh hưởng báo cáo tài chính.
Thứ tư — không được phép sai và không được phép downtime. Tiền của hàng triệu khách hàng nằm trong đó. Mọi thay đổi phải qua kiểm thử nghiêm ngặt, có kế hoạch migration dữ liệu cẩn thận, và đặc biệt là phải đối chiếu (reconciliation) — tổng số dư trước và sau khi chuyển đổi phải khớp đến từng đồng. Đây chính là nơi kỹ năng đối chiếu của kế toán phát huy giá trị.
Vòng đời một dự án core banking điển hình
Dự án thường đi qua các pha: Blueprint/Discovery (phân tích nghiệp vụ, fit-gap) → Configuration & Customization (cấu hình sản phẩm) → Data Migration (chuyển đổi dữ liệu từ core cũ) → SIT/UAT (kiểm thử tích hợp và kiểm thử người dùng) → Mock Run / Dress Rehearsal (chạy thử toàn bộ như thật, thường vào cuối tuần) → Go-live & Cutover (chuyển đổi chính thức, thường trong một đêm hoặc một kỳ nghỉ lễ) → Hypercare (hỗ trợ tăng cường sau go-live).
Tình huống thực tế
Tình huống 1 — Fit-gap về tính lãi tiền gửi tại một ngân hàng tầm trung
Một ngân hàng thương mại cổ phần quy mô vừa tại TP.HCM triển khai Temenos T24 thay cho core nội bộ cũ. Trong pha blueprint, BU (Business Unit) phòng Tiền gửi yêu cầu: "Với sản phẩm tiết kiệm linh hoạt, nếu khách rút trước hạn, lãi phần đã gửi đủ kỳ tính theo lãi suất niêm yết, phần rút trước hạn tính theo lãi suất không kỳ hạn 0,1%/năm."
Chị Lan — BA của dự án, vốn là kế toán ngân hàng 6 năm — nhận ra ngay đây là bài toán tính lãi theo từng "lô" (tranche). Chị làm fit-gap: T24 có sẵn cơ chế tính lãi không kỳ hạn cho phần rút trước hạn, nhưng cách tách lô theo logic "đủ kỳ vs chưa đủ kỳ" của ngân hàng này không khớp 100% với chuẩn out-of-the-box. Chị viết một bảng fit-gap rõ ràng: 70% logic dùng cấu hình sẵn, 30% cần customize phần tách lô. Quan trọng hơn, chị đưa ra ví dụ số cụ thể trong tài liệu: khách gửi 100 triệu, rút 40 triệu sau 2 tháng của kỳ 6 tháng, lãi suất 6%/năm — và tính ra con số chính xác để dev và tester có thước đo.
Bài học: Năng lực Finance giúp chị viết requirement không mơ hồ. Một BA không có nền tài chính sẽ chỉ chép lại câu nói của BU; chị Lan thì dịch nó thành công thức, ví dụ số, và phân loại fit-gap — giúp dự án ước lượng đúng chi phí customize.
Tình huống 2 — Đối chiếu dữ liệu migration tại một ngân hàng quốc doanh
Một ngân hàng quốc doanh lớn chuyển đổi từ core cũ sang Oracle FLEXCUBE, di chuyển hơn 8 triệu tài khoản và 2 triệu khoản vay. Đêm cutover, sau khi load dữ liệu, đội dự án phát hiện tổng dư nợ cho vay trên hệ thống mới lệch 0,03% so với core cũ — tương đương vài chục tỷ đồng. Nếu không giải thích được khoản lệch này, NHNN sẽ không chấp nhận và go-live phải hoãn.
Anh Tuấn — BA mảng Loans, xuất thân kế toán tín dụng — dẫn đầu việc reconciliation. Anh dựng một bảng đối chiếu phân tách theo nhóm: lãi dự thu chưa hạch toán, các khoản nợ đã được cơ cấu lại theo Thông tư, và phần làm tròn khi quy đổi cách tính lãi. Nhờ tư duy đối chiếu của kế toán, anh truy ra phần lớn chênh lệch nằm ở "lãi dự thu" được tính theo quy ước ngày khác nhau giữa hai hệ thống (30/360 vs actual/365). Anh chứng minh đây là chênh lệch hợp lệ về phương pháp, lập biên bản giải trình, và go-live diễn ra đúng kế hoạch.
Bài học: Migration core banking là nơi kỹ năng đối chiếu của kế toán trở thành "siêu năng lực". Một BA không hiểu lãi dự thu hay quy ước ngày tính lãi sẽ hoảng loạn khi thấy con số lệch; người từ Finance thì biết chính xác phải bóc tách ở đâu.
Tình huống 3 — Compliance về phân loại nợ tại một ngân hàng số
Một ngân hàng đang xây dựng phân hệ tín dụng mới muốn tự động hóa việc phân loại nhóm nợ và trích lập dự phòng theo Thông tư 11/2021. BU đưa yêu cầu khá ngắn gọn: "Hệ thống tự động chuyển nhóm nợ theo số ngày quá hạn."
Chị Mai — BA có nền kiểm toán — không dừng ở đó. Chị biết Thông tư 11 không chỉ phân nhóm theo ngày quá hạn (định lượng) mà còn theo yếu tố định tính, và quy định nguyên tắc "phân loại nợ theo nhóm cao nhất" khi một khách hàng có nhiều khoản vay ở các nhóm khác nhau. Chị viết một business rule catalog đầy đủ: bảng quy đổi ngày quá hạn sang nhóm 1-5, tỷ lệ trích lập tương ứng (0%, 5%, 20%, 50%, 100%), quy tắc nâng nhóm theo CIC, và xử lý nợ cơ cấu. Chị cũng gắn mỗi rule với điều khoản cụ thể của Thông tư để khi NHNN kiểm tra, ngân hàng có thể truy xuất nguồn gốc từng quy tắc.
Bài học: Compliance là sân chơi mà ex-Finance, đặc biệt người có nền kiểm toán/kế toán, thắng tuyệt đối. Hiểu sâu Thông tư và biết "truy xuất nguồn pháp lý" cho từng requirement là điều mà BA thuần IT gần như không thể làm được nếu thiếu nền tảng.
Hướng dẫn từng bước
Nếu bạn muốn chuẩn bị để bước vào một dự án core banking, đây là lộ trình cụ thể:
Bước 1 — Chọn module chuyên sâu. Đừng cố hiểu cả core. Dựa trên nền Finance của bạn, chọn nơi mạnh nhất: nếu bạn từng làm kế toán tín dụng, đi vào Loans; nếu làm kế toán tổng hợp, đi vào GL; nếu làm giao dịch viên/teller, đi vào Deposits và Payments.
Bước 2 — Học vocabulary của vendor. Đọc tài liệu công khai về Temenos T24 hoặc Oracle FLEXCUBE. Nắm các khái niệm: COB (Close of Business), CIF, GL posting, value date vs booking date, enquiry/version (với T24). Bạn không cần biết cấu hình, chỉ cần hiểu thuật ngữ để nói chuyện được với đội kỹ thuật.
Bước 3 — Lập một "compliance map" cá nhân. Liệt kê các văn bản pháp lý cốt lõi: Thông tư 39 (cho vay), Thông tư 11 (phân loại nợ), quy định eKYC, AML, báo cáo CIC. Với mỗi văn bản, ghi 2-3 dòng nó ảnh hưởng module nào. Đây sẽ là tài sản bạn mang vào phỏng vấn.
Bước 4 — Thực hành fit-gap. Lấy một nghiệp vụ bạn biết rõ (ví dụ tính lãi tiền gửi rút trước hạn), giả định triển khai trên một CBS, rồi tự viết: cái gì out-of-the-box, cái gì cần customize, rủi ro là gì. Đây chính là kỹ năng cốt lõi mà nhà tuyển dụng core banking tìm.
Bước 5 — Hiểu quy trình cutover và reconciliation. Tự dựng một bảng đối chiếu mẫu cho migration: các nhóm tài khoản, tổng số dư, các loại chênh lệch hợp lệ (làm tròn, lãi dự thu, chênh quy ước ngày). Mang được tư duy này vào dự án là bạn đã hơn nhiều BA junior.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng core banking giống làm app fintech. Nhiều bạn quen nhịp Agile nhanh của startup bước vào core banking và sốc vì độ chậm, độ kỹ, và lượng tài liệu khổng lồ. Mẹo: hãy điều chỉnh kỳ vọng — ở đây "chậm mà chắc" là tính năng, không phải lỗi.
Lỗi 2 — Đề xuất customize quá nhiều. Người mới hay nghiêng về customize cho khớp 100% nghiệp vụ hiện tại. Mỗi customize làm tăng chi phí, rủi ro lỗi, và đau đầu khi nâng cấp vendor. Mẹo: luôn ưu tiên cấu hình sẵn, và thách thức BU "liệu quy trình của mình có thể đổi để khớp chuẩn không?"
Lỗi 3 — Viết requirement mà không gắn nguồn pháp lý. Trong core banking, một requirement "treo lơ lửng" không truy được về quy định hay chính sách là requirement nguy hiểm. Mẹo: mỗi business rule liên quan compliance phải có cột "nguồn" (Thông tư nào, điều mấy).
Lỗi 4 — Bỏ qua COB và xử lý cuối ngày. Người mới thường chỉ nghĩ giao dịch real-time mà quên nhiều thứ (tính lãi, hạch toán dự thu, phân loại nợ) chạy theo batch lúc COB. Mẹo: với mỗi tính năng, luôn hỏi "cái này chạy real-time hay trong COB?".
Mẹo vàng: Khi phỏng vấn vị trí BA core banking, hãy kể một câu chuyện cụ thể cho thấy bạn hiểu cả nghiệp vụ tài chính lẫn cách nó được hệ thống hóa — ví dụ giải thích lãi dự thu được hạch toán thế nào trong GL. Đó là thứ tách bạn khỏi đám đông.
Bài tập thực hành
- Fit-gap mini: Chọn nghiệp vụ "tính lãi vay theo dư nợ giảm dần". Giả định triển khai trên một CBS bất kỳ. Viết bảng fit-gap 1 trang: phần out-of-the-box, phần cần customize, 3 rủi ro, và một ví dụ số cụ thể (khoản vay 500 triệu, 12 tháng, lãi 12%/năm).
- Compliance map: Lập bảng gồm 5 văn bản pháp lý ngân hàng quan trọng nhất. Với mỗi văn bản, ghi: nó điều chỉnh gì, ảnh hưởng module core banking nào, và một business rule cụ thể phát sinh từ nó.
- Reconciliation case: Tự dựng tình huống migration một danh mục 1.000 khoản vay. Liệt kê 4 loại chênh lệch hợp lệ có thể xảy ra giữa core cũ và core mới, và cách bạn giải trình từng loại.
- So sánh vendor: Tra cứu và viết nửa trang so sánh Temenos T24 và Oracle FLEXCUBE về: nguồn gốc, ngôn ngữ/nền tảng, điểm mạnh, và ví dụ ngân hàng VN/khu vực đang dùng.
Tóm tắt
Core banking là domain khó nhất và trả lương cao nhất trong nghề BA tại Việt Nam — và cũng là nơi người từ Finance/Kế toán có lợi thế tự nhiên lớn nhất. Bốn đặc thù bạn phải khắc cốt ghi tâm: dự án dài 18-36 tháng với ngân sách hàng trăm tỷ; làm việc trên sản phẩm đóng gói của các vendor lớn (Temenos T24, Finacle, Oracle FLEXCUBE, TCS BaNCS) qua tư duy fit-gap; compliance cực chặt phải truy được về quy định NHNN; và yêu cầu tuyệt đối về độ chính xác cùng đối chiếu dữ liệu khi cutover.
Lợi thế của bạn không phải kiến thức IT, mà là khả năng dịch nghiệp vụ tài chính thành công thức và rule rõ ràng, hiểu lãi dự thu/quy ước ngày/phân loại nợ, và đối chiếu đến từng đồng. Hãy chọn một module chuyên sâu, học vocabulary vendor, lập compliance map cá nhân, và thực hành fit-gap. Khi làm được những điều đó, bạn không còn là "kế toán muốn chuyển nghề" — bạn là BA core banking mà ngân hàng phải săn đón.