Bài 2 — Core Banking System: Trái tim của ngân hàng

Core Banking là gì

Core Banking System (CBS) — thường gọi tắt là "core" — là hệ thống phần mềm trung tâm ghi nhận và xử lý mọi giao dịch tài chính cốt lõi của một ngân hàng: mở tài khoản, nhận tiền gửi, cho vay, chuyển tiền, tính lãi, hạch toán sổ sách. Chữ "core" (lõi) nói lên đúng vai trò: đây là nơi lưu trạng thái sự thật (source of truth) về tiền của ngân hàng và khách hàng. Mọi kênh giao dịch khác — Internet Banking, ATM, ứng dụng mobile, quầy giao dịch — cuối cùng đều phải "nói chuyện" với core để số dư được cập nhật chính xác.

Một cách hình dung: nếu ngân hàng là một cơ thể sống, thì core banking là trái tim bơm máu (tiền) đi khắp nơi và ghi nhận từng nhịp đập (giao dịch). Các kênh bên ngoài chỉ là tay chân, giác quan — chúng thu thập yêu cầu rồi đẩy về tim xử lý.

Trên thị trường có nhiều nền tảng core banking thương mại (ví dụ phổ biến được nhắc đến trong ngành là Temenos T24, Oracle FLEXCUBE, Finacle...) và cũng có những ngân hàng tự phát triển core riêng. Bài viết này không đi sâu vào sản phẩm cụ thể nào, mà tập trung vào bản chất kiến trúc chung mà gần như mọi CBS đều có. Hiểu được bản chất này, bạn nhìn vào core nào cũng sẽ thấy quen.

Vì sao "core" lại quan trọng đến vậy

• Tính nhất quán tiền tệ: Tiền không được tự sinh ra hay biến mất. Mọi thay đổi số dư phải được ghi nhận chính xác đến từng đồng, có thể kiểm toán lại. Core là nơi đảm bảo điều này.
• Tính tập trung: Một khách hàng có thể có tài khoản tiết kiệm, khoản vay, thẻ tín dụng. Tất cả cần được nhìn nhận thống nhất. Core làm việc gom này.
• Tuân thủ và đối chiếu: Báo cáo cho ngân hàng nhà nước, đối chiếu liên ngân hàng, tính toán dự phòng rủi ro... đều bắt nguồn từ dữ liệu core.

---

CIF — Customer Information File

Khái niệm nền tảng đầu tiên cần nắm là CIF (Customer Information File). CIF là hồ sơ định danh duy nhất của một khách hàng trong hệ thống core. Mỗi khách hàng (cá nhân hoặc tổ chức) được cấp một mã CIF (CIF number) duy nhất, dùng để liên kết tất cả tài khoản và sản phẩm mà người đó nắm giữ.

Nguyên tắc vàng cần nhớ:

Một khách hàng — một CIF — nhiều tài khoản/sản phẩm.

Nghĩa là một người có thể mở 3 tài khoản thanh toán, 2 sổ tiết kiệm, 1 khoản vay và 1 thẻ tín dụng, nhưng tất cả đều "treo" dưới một mã CIF duy nhất. Điều này cho phép ngân hàng:

• Nhìn thấy tổng quan quan hệ với khách hàng (tổng tiền gửi, tổng dư nợ, mức độ rủi ro).
• Tránh trùng lặp và mâu thuẫn thông tin định danh (CMND/CCCD, địa chỉ, số điện thoại lưu một chỗ).
• Phục vụ KYC (Know Your Customer), phòng chống rửa tiền, và bán chéo sản phẩm.

CIF chứa các thông tin định danh và nhân khẩu học (tên, giấy tờ tùy thân, ngày sinh, địa chỉ, nghề nghiệp...), không chứa số dư. Số dư nằm ở tầng tài khoản/sản phẩm. Quan hệ phân tầng điển hình:

Sai lầm phổ biến của người mới là nhầm "tài khoản" với "khách hàng". Một số tài khoản (account number) không phải là một con người — nó chỉ là một "túi tiền" thuộc về một CIF. Phân biệt rõ hai tầng này là chìa khóa để hiểu mọi báo cáo và mô hình dữ liệu sau này.

---

Các phân hệ chính của Core Banking

Core banking không phải một khối liền. Nó được chia thành các phân hệ (modules) chuyên trách từng nghiệp vụ. Các phân hệ này chia sẻ chung tầng CIF và đều kết chuyển hạch toán về Sổ cái (GL). Dưới đây là các phân hệ phổ biến nhất.

Phân hệ	Tên thường gặp	Vai trò chính
Tiền gửi	Deposit / CASA	Quản lý tài khoản thanh toán (Current Account) và tài khoản tiết kiệm (Savings Account), tính lãi tiền gửi, không kỳ hạn và có kỳ hạn.
Tín dụng	Loan / Lending	Quản lý khoản vay: giải ngân, lịch trả gốc lãi, tính lãi vay, theo dõi nợ quá hạn, phân loại nhóm nợ.
Quầy / Chi nhánh	Teller / Branch	Giao dịch tại quầy: nộp/rút tiền mặt, mở tài khoản, quản lý tồn quỹ của giao dịch viên và chi nhánh.
Thanh toán	Payment	Xử lý chuyển tiền trong và ngoài ngân hàng, lệnh thanh toán, kết nối hệ thống chuyển mạch.
Sổ cái	GL — General Ledger	Hạch toán kép toàn bộ ngân hàng, lập bảng cân đối, là nơi mọi bút toán đổ về.
Thẻ	Card	Quản lý thẻ ghi nợ/tín dụng, hạn mức, sao kê thẻ, liên kết với mạng chuyển mạch thẻ.

Deposit / CASA — Tiền gửi

CASA viết tắt của Current Account & Savings Account — tài khoản thanh toán và tài khoản tiết kiệm không kỳ hạn. Đây thường là nguồn vốn giá rẻ của ngân hàng vì lãi suất thấp. Phân hệ này quản lý số dư, áp dụng lãi suất, và là điểm khởi nguồn của hầu hết giao dịch hằng ngày. Ngoài CASA, phân hệ tiền gửi còn quản lý tiền gửi có kỳ hạn (Term Deposit) với lãi suất cao hơn và quy tắc đáo hạn riêng.

Loan — Tín dụng

Phân hệ cho vay theo dõi vòng đời khoản vay: phê duyệt, giải ngân (disbursement), lập lịch trả nợ (repayment schedule), tính lãi theo dư nợ giảm dần hoặc cố định, ghi nhận trả nợ, và xử lý nợ quá hạn. Một chức năng quan trọng là phân loại nhóm nợ (nhóm 1 đến nhóm 5) để trích lập dự phòng rủi ro theo quy định — đây là dữ liệu rất quan trọng cho báo cáo và phân tích sau này.

Teller / Branch — Quầy giao dịch

Đây là phân hệ vận hành tại chi nhánh: giao dịch viên (teller) thực hiện nộp tiền, rút tiền, mở tài khoản. Phân hệ này quản lý tồn quỹ tiền mặt của từng quầy và chi nhánh, đảm bảo đầu ngày — cuối ngày khớp quỹ.

Payment — Thanh toán

Phân hệ thanh toán điều phối luồng tiền giữa các tài khoản, giữa các ngân hàng, và ra các hệ thống bên ngoài. Nó xử lý lệnh chuyển khoản, kiểm tra số dư, áp phí, và định tuyến giao dịch tới đúng kênh (nội bộ, liên ngân hàng, quốc tế).

GL — General Ledger (Sổ cái)

GL là đích đến cuối cùng của mọi giao dịch. Mỗi nghiệp vụ ở các phân hệ khác (nhận tiền gửi, giải ngân vay, thu phí...) đều sinh ra các bút toán ghi Nợ/Có vào các tài khoản kế toán trong GL theo nguyên tắc hạch toán kép. GL là nơi lập bảng cân đối kế toán và báo cáo tài chính của ngân hàng. (Chi tiết về hạch toán kép sẽ được trình bày kỹ ở Bài 3.)

Card — Thẻ

Phân hệ thẻ quản lý thẻ ghi nợ và thẻ tín dụng: phát hành, hạn mức, ủy quyền giao dịch (authorization), tính lãi và lập sao kê thẻ tín dụng, đồng thời kết nối với các mạng chuyển mạch thẻ để xử lý giao dịch tại ATM/POS.

Bức tranh tổng thể: CIF tới phân hệ tới GL

Điểm mấu chốt: dù khách hàng dùng phân hệ nào, mọi tác động tài chính cuối cùng đều kết chuyển về GL. Đây là lý do GL được coi là "nguồn sự thật kế toán" của ngân hàng.

---

Online realtime vs Batch / EOD

Đây là một trong những khái niệm dễ gây bối rối nhất với người ngoài ngành, nhưng cực kỳ quan trọng. Core banking xử lý theo hai chế độ song song.

Xử lý online (realtime)

Khi bạn rút tiền ATM, chuyển khoản qua app, hay nộp tiền tại quầy, giao dịch được xử lý ngay lập tức: số dư cập nhật trong vài giây, bút toán được ghi nhận. Đây là xử lý trực tuyến (online / realtime), phục vụ trải nghiệm tức thời cho khách hàng. Mỗi giao dịch là một đơn vị độc lập, được commit ngay.

Xử lý batch / EOD (End of Day)

Có những loại xử lý không thể và không nên làm realtime, mà phải gom lại chạy theo lô (batch) vào một thời điểm nhất định, điển hình là cuối ngày — gọi là EOD (End of Day). Ví dụ:

• Tính lãi dồn tích (accrual): Lãi tiền gửi/tiền vay tích lũy theo từng ngày. Hệ thống chạy batch để tính lãi cho hàng triệu tài khoản cùng lúc, thay vì tính lại liên tục mỗi giây.
• Kết chuyển (posting / settlement): Gom các giao dịch trong ngày, kết chuyển sang GL, đối chiếu nội bộ.
• Phân loại nợ, trích lập dự phòng, áp phí định kỳ.
• Đóng ngày (day-end close): Chốt sổ ngày làm việc hiện tại và mở ngày làm việc kế tiếp.

Vì sao ngân hàng có "ngày làm việc" (business date)

Đây là điểm bản chất nhất. Core banking vận hành theo khái niệm ngày làm việc của ngân hàng (business date / posting date), không hoàn toàn trùng với ngày theo lịch (calendar date). Quy trình EOD đánh dấu việc đóng một ngày làm việc và mở ngày kế tiếp.

Hệ quả thực tế:

• Một giao dịch thực hiện lúc 23h59 hoặc sau giờ cut-off có thể được hạch toán vào ngày làm việc kế tiếp.
• Giao dịch trong ngày cuối tuần/ngày lễ có thể mang business date của ngày làm việc kế tiếp.
• Vì vậy "ngày" trong báo cáo ngân hàng cần được hiểu theo business date, không phải timestamp đơn thuần.

Quy trình EOD thường chạy ban đêm vì khối lượng xử lý lớn và cần "đóng băng" trạng thái để đảm bảo nhất quán. Trong khung giờ này, một số dịch vụ có thể tạm gián đoạn hoặc hạn chế — đó là lý do đôi khi bạn thấy thông báo "hệ thống đang bảo trì" vào nửa đêm.

---

Quan hệ với hệ thống vệ tinh

Core không đứng một mình. Xung quanh nó là các hệ thống vệ tinh (satellite systems) đảm nhận các kênh tiếp xúc khách hàng, kết nối với core qua các giao diện (interface / API / message).

• Internet Banking & Mobile Banking: Kênh số cho khách hàng tra cứu số dư, chuyển khoản. Chúng gọi vào core để đọc số dư và đẩy lệnh giao dịch.
• ATM / POS switch (hệ thống chuyển mạch): Xử lý giao dịch thẻ tại máy ATM và máy POS. Switch nhận yêu cầu từ thiết bị, kiểm tra ủy quyền với core/phân hệ thẻ, rồi trả kết quả.
• NAPAS (chuyển mạch quốc gia tại Việt Nam): Hệ thống chuyển mạch liên ngân hàng giúp giao dịch giữa các ngân hàng khác nhau (rút tiền thẻ ngân hàng A tại ATM ngân hàng B, chuyển nhanh 24/7). Core của mỗi ngân hàng kết nối tới NAPAS qua giao diện chuẩn.

Điểm cần nhớ: dù khách hàng đứng ở kênh nào, trạng thái tiền cuối cùng vẫn nằm ở core. Các hệ thống vệ tinh không tự ý thay đổi số dư — chúng chỉ là cổng tiếp nhận yêu cầu và hiển thị kết quả. Sự phân tầng này giúp ngân hàng đảm bảo tính nhất quán và kiểm soát rủi ro.

---

Vì sao dữ liệu core được trích xuất sang ODS / Data Warehouse ban đêm

Core banking được thiết kế tối ưu cho giao dịch (OLTP) — ghi/đọc nhanh từng giao dịch nhỏ với độ chính xác tuyệt đối. Nó không được thiết kế cho phân tích dữ liệu lớn (OLAP) — chạy báo cáo tổng hợp toàn ngân hàng, truy vấn lịch sử nhiều năm, tính toán phức tạp.

Nếu chạy báo cáo phân tích nặng trực tiếp trên core, ta sẽ:

• Làm chậm hoặc gây rủi ro cho hệ thống giao dịch đang phục vụ khách hàng realtime.
• Tranh chấp tài nguyên với quy trình EOD.

Vì vậy, sau khi EOD hoàn tất (trạng thái dữ liệu đã được chốt và nhất quán), ngân hàng trích xuất (extract) dữ liệu từ core sang:

• ODS (Operational Data Store): Kho dữ liệu tác nghiệp, sao chép dữ liệu core gần thời gian thực hoặc theo ngày, phục vụ truy vấn vận hành mà không đụng vào core.
• Data Warehouse (DWH): Kho dữ liệu phân tích, tổ chức theo mô hình chiều/sự kiện, lưu lịch sử dài hạn cho báo cáo và phân tích.

Lý do chạy ban đêm rất tự nhiên: đó là lúc dữ liệu đã chốt sau EOD, tải giao dịch thấp, và có cửa sổ thời gian để di chuyển khối lượng dữ liệu lớn. Đây chính là nền tảng của toàn bộ kiến trúc dữ liệu ngân hàng — chủ đề sẽ được đào sâu ở Bài 7.

---

Tóm tắt

• Core Banking System là hệ thống trung tâm lưu trạng thái sự thật về tiền của ngân hàng; mọi kênh đều quy về core.
• CIF định danh duy nhất một khách hàng: một khách hàng — một CIF — nhiều tài khoản/sản phẩm. CIF chứa thông tin định danh, không chứa số dư.
• Core chia thành các phân hệ chuyên trách: Deposit/CASA, Loan, Teller/Branch, Payment, GL, Card, tất cả kết chuyển về GL.
• Core xử lý song song online realtime (giao dịch tức thời) và batch/EOD (tính lãi dồn tích, kết chuyển, đóng ngày), từ đó hình thành khái niệm ngày làm việc của ngân hàng.
• Các hệ thống vệ tinh (Internet Banking, ATM/POS switch, NAPAS) kết nối core qua giao diện nhưng không tự thay đổi số dư.
• Sau EOD, dữ liệu được trích xuất sang ODS/DWH ban đêm để phục vụ phân tích mà không ảnh hưởng giao dịch.

Tự kiểm tra

1. Một khách hàng có 2 sổ tiết kiệm và 1 khoản vay thì có bao nhiêu mã CIF? Vì sao CIF không lưu số dư?
2. Hãy kể tên ít nhất 4 phân hệ core và cho biết tất cả chúng có điểm chung gì khi hạch toán?
3. Vì sao tính lãi dồn tích thường chạy theo batch trong EOD thay vì realtime?
4. "Ngày làm việc của ngân hàng" khác gì với ngày theo lịch, và điều đó ảnh hưởng thế nào đến cách đọc báo cáo?
5. Vì sao không nên chạy báo cáo phân tích lớn trực tiếp trên core, và giải pháp là gì?

Đọc tiếp

Bài 3 — Hạch toán kép & Sổ cái GL