Tổng quan Temenos T24 / Transact — vị trí trong core banking

Nếu bạn làm việc trong lĩnh vực dữ liệu, tích hợp hay vận hành CNTT của một ngân hàng, sớm muộn gì bạn cũng sẽ đụng đến cái tên T24. Đây là một trong những hệ thống lõi ngân hàng (core banking system) phổ biến nhất thế giới, đang chạy tại hàng trăm ngân hàng trên hơn 150 quốc gia. Bài đầu tiên trong series này sẽ giúp bạn có bức tranh toàn cảnh: T24 là gì, nó nằm ở đâu trong kiến trúc hệ thống của ngân hàng, và tại sao đội Data/IT bắt buộc phải hiểu nó — trước khi đi sâu vào những chủ đề kỹ thuật khó hơn ở các bài sau.

T24 là gì?

T24 là sản phẩm core banking của Temenos — một công ty phần mềm ngân hàng của Thụy Sĩ, trụ sở tại Geneva. Cái tên "T24" đến từ ý tưởng một hệ thống ngân hàng vận hành 24 giờ mỗi ngày, xử lý giao dịch thời gian thực (real-time).

Điểm cần lưu ý về tên gọi: từ tháng 1 năm 2019, Temenos đã đặt lại thương hiệu cho sản phẩm này thành Temenos Transact. Lý do là T24 trong tâm trí nhiều người gắn liền với hình ảnh một hệ thống nguyên khối (monolithic), tích hợp chặt và theo module; trong khi các phiên bản mới đã chuyển dần sang kiến trúc microservices và cloud-native, không còn "monolithic" theo nghĩa triển khai hay nâng cấp nữa. Dù vậy, trong thực tế công việc hằng ngày, rất nhiều ngân hàng và kỹ sư vẫn quen gọi là "T24" — vì vậy trong series này chúng ta sẽ dùng lẫn cả hai tên, và bạn nên hiểu chúng là một.

Hai đặc tính cốt lõi định hình nên bản chất của T24, quyết định cách bạn làm việc với nó:

1. Real-time processing — giao dịch được ghi nhận và phản ánh vào số dư ngay lập tức (đối lập với các hệ thống batch đời cũ chỉ cập nhật sau khi chạy xử lý cuối ngày). Điều này không có nghĩa là T24 không có xử lý theo lô: nó vẫn có tiến trình cuối ngày rất quan trọng gọi là COB (Close Of Business) — chúng ta sẽ dành hẳn một bài cho chủ đề này.

2. Parameter-driven — đây là triết lý thiết kế quan trọng nhất và thường gây bất ngờ cho người mới. Phần lớn "logic nghiệp vụ" trong T24 không được viết cứng bằng code, mà được cấu hình bằng tham số trong các bảng thiết lập. Muốn tạo một sản phẩm tiền gửi mới, một loại tài khoản, một quy tắc tính lãi, một bút toán kế toán — bạn khai báo tham số chứ không (hoặc rất ít khi) sửa mã nguồn. Đây là điều làm T24 vừa cực kỳ linh hoạt, vừa cực kỳ phức tạp để nắm bắt.

Vị trí của T24 trong bức tranh core banking

Hãy hình dung toàn bộ hệ thống CNTT của một ngân hàng như một hệ mặt trời. T24 là mặt trời ở trung tâm — nó đóng vai trò "sổ cái nghiệp vụ" (system of record) chính, nơi lưu trữ và xử lý những dữ liệu quan trọng bậc nhất:

• CUSTOMER — hồ sơ khách hàng (thông tin định danh, phân loại, quan hệ).
• ACCOUNT — tài khoản và số dư.
• Deposits / Loans — tiền gửi và tín dụng.
• Payments / Funds Transfer — chuyển tiền, thanh toán.
• GL / Accounting — sổ cái tổng hợp, hạch toán kế toán.

Xung quanh mặt trời T24 là hàng loạt hệ thống vệ tinh chuyên biệt. Ngân hàng hiện đại không dồn mọi thứ vào core; thay vào đó, mỗi chức năng đặc thù được giao cho một hệ thống riêng, và tất cả kết nối về T24 vì T24 giữ "sự thật" về khách hàng và số dư:

Điều quan trọng cần rút ra: khi một khách hàng quẹt thẻ, chuyển khoản qua app, hay vay một khoản mới, thao tác có thể bắt đầu ở hệ thống vệ tinh, nhưng bút toán cuối cùng lên số dư và sổ cái đều quy về T24. Đây chính là lý do T24 được gọi là "system of record" — nguồn dữ liệu gốc, đáng tin cậy nhất của ngân hàng.

Model Bank — bộ khởi tạo best-practice

Một câu hỏi tự nhiên: nếu T24 cấu hình bằng tham số, và một ngân hàng có hàng nghìn sản phẩm, quy tắc, thì lẽ nào mỗi lần triển khai đều phải khai báo mọi thứ từ con số không? Đây là lúc Model Bank xuất hiện.

Model Bank là một bộ cấu hình, sản phẩm và quy trình nghiệp vụ mẫu, được Temenos đóng gói sẵn dựa trên best-practice của ngành ngân hàng. Nó giống như một "ngân hàng mẫu chạy được ngay": đã có sẵn các loại sản phẩm tiền gửi, cho vay, tài khoản thanh toán, cấu trúc kế toán, quy tắc tính lãi phổ biến...

Cách tiếp cận thực tế khi triển khai:

• Ngân hàng bắt đầu từ nền Model Bank thay vì tờ giấy trắng — rút ngắn đáng kể thời gian và rủi ro dự án.
• Sau đó tùy biến (customize) trên nền đó: điều chỉnh sản phẩm cho phù hợp thị trường địa phương, quy định của ngân hàng nhà nước, đặc thù của tổ chức.

Bài học thực chiến: mức độ ngân hàng "đi lệch" khỏi Model Bank càng lớn thì chi phí nâng cấp về sau càng cao. Các ngân hàng có kỷ luật tốt cố gắng bám sát chuẩn Model Bank và chỉ tùy biến ở những chỗ thực sự cần thiết.

Chu kỳ release R-series và bài toán nâng cấp

Temenos phát hành T24/Transact theo các phiên bản gọi là R-series — chữ "R" là Release. Bạn sẽ thường nghe những cái tên như R13, R14, R15... và các bản gần đây được đánh số theo năm (ví dụ các bản thuộc dòng R202x). Mỗi bản release mang theo tính năng mới, cập nhật quy định, cải tiến hiệu năng và vá lỗi.

Từ đây nảy sinh một trong những chủ đề nhức nhối nhất của giới ngân hàng: upgrade / uplift.

• Upgrade là quá trình đưa hệ thống từ một bản R cũ lên bản R mới hơn.
• Uplift thường dùng để chỉ việc "nâng" các phần tùy biến (customization) của ngân hàng lên tương thích với bản release mới.

Vì sao đây là bài toán khó? Chính vì đặc tính tùy biến ở trên. Một ngân hàng chạy R13 với hàng trăm điều chỉnh riêng, khi muốn lên bản mới hơn, phải kiểm tra từng tùy biến xem còn tương thích không, có bị bản chuẩn mới ghi đè không, có cần viết lại không. Nhiều ngân hàng "kẹt" ở một bản R cũ nhiều năm vì chi phí và rủi ro nâng cấp quá lớn. Kiến trúc microservices ở các bản mới một phần chính là để giải bài toán này — cho phép nâng cấp từng thành phần độc lập thay vì "nâng cả khối".

Các module chức năng lớn

T24 được tổ chức thành nhiều module (hay nhóm ứng dụng). Bạn không cần nhớ hết ngay, nhưng nên nhận diện được các cái tên sau vì chúng sẽ xuất hiện liên tục khi làm dữ liệu:

• Customer — quản lý hồ sơ khách hàng, nền tảng cho mọi quan hệ.
• Accounts — tài khoản và số dư.
• Funds Transfer (FT) — chuyển tiền, thanh toán trong và ngoài ngân hàng.
• Teller — giao dịch tại quầy (nộp/rút tiền mặt, thu chi).
• Lending — Arrangement Architecture (AA) — kiến trúc sản phẩm hiện đại của Temenos cho tín dụng và cả nhiều sản phẩm khác. AA là một chủ đề rất quan trọng, sẽ có bài riêng.
• Deposits — sản phẩm tiền gửi (có kỳ hạn, không kỳ hạn).
• Trade Finance (LC, Guarantees) — tài trợ thương mại: thư tín dụng, bảo lãnh.
• Treasury — kinh doanh nguồn vốn, ngoại hối, thị trường tiền tệ.
• Limits — quản lý hạn mức tín dụng của khách hàng/nhóm khách hàng.
• Collateral — quản lý tài sản bảo đảm.
• Accounting / GL — hạch toán kế toán và sổ cái tổng hợp.
• MIS — thông tin quản trị, phục vụ phân tích và báo cáo.

Một điểm tinh tế: Arrangement Architecture (AA) là hướng đi hiện đại mà Temenos khuyến khích cho các sản phẩm mới (đặc biệt là lending và deposits), trong khi vẫn tồn tại các module "cổ điển" hơn. Việc một ngân hàng dùng AA hay dùng các module truyền thống ảnh hưởng trực tiếp đến cấu trúc dữ liệu mà bạn khai thác — nên chúng ta sẽ mổ xẻ kỹ trong bài về Arrangement Architecture.

Các lựa chọn triển khai

Ngày nay Temenos cho ngân hàng nhiều lựa chọn về cách vận hành hệ thống, phản ánh xu hướng chuyển dịch lên đám mây:

• On-premise — ngân hàng tự vận hành trên hạ tầng máy chủ của mình. Đây vẫn là mô hình phổ biến với các ngân hàng lớn, có yêu cầu chủ quyền dữ liệu chặt chẽ.
• Private cloud — chạy trên hạ tầng đám mây riêng của ngân hàng hoặc do đối tác quản lý.
• Temenos Banking Cloud (SaaS) — mô hình dịch vụ, Temenos vận hành, ngân hàng "thuê bao". Đây là hướng được khuyến khích cho các ngân hàng nhỏ và vừa vì triển khai nhanh, giảm gánh nặng vận hành CNTT.

Về nền tảng hạ tầng, các phiên bản Transact hiện đại là cloud-native, cloud-agnostic — có thể chạy trên các nhà cung cấp đám mây lớn như AWS, Microsoft Azure và Google Cloud. Kiến trúc cũng dịch chuyển mạnh sang microservices và API-first: các năng lực như Accounts & Deposits, Retail Lending được tách thành những microservice độc lập, tích hợp qua API, cho phép triển khai và thay đổi từng phần nhanh và an toàn hơn. Temenos đã công bố các bài kiểm thử hiệu năng trên Banking Cloud đạt tới quy mô hàng trăm triệu tài khoản/khoản vay và hàng trăm nghìn giao dịch mỗi giây — cho thấy hệ thống có thể co giãn đàn hồi ở quy mô rất lớn.

Use case thực tế

Hãy lấy một tình huống rất quen thuộc với đội Data: xây dựng kho dữ liệu (data warehouse) và báo cáo từ T24.

Một ngân hàng cần báo cáo dư nợ tín dụng, huy động vốn, và phân khúc khách hàng hằng ngày cho ban lãnh đạo và cho báo cáo gửi ngân hàng nhà nước. Nguồn "sự thật" của mọi con số này nằm trong T24. Bài toán đặt ra cho đội Data:

1. Xác định bảng nguồn — dư nợ, số dư, hồ sơ khách hàng nằm ở những "file" (bảng) nào trong T24? Ví dụ dữ liệu khách hàng ở CUSTOMER, tài khoản ở ACCOUNT, các khoản vay theo AA nằm trong cấu trúc arrangement... (chi tiết ở các bài sau).
2. Trích xuất dữ liệu — không thể "cắm SQL" thẳng vào T24 như một cơ sở dữ liệu quan hệ thông thường, vì T24 dùng mô hình dữ liệu multivalue đặc thù, không phải bảng phẳng kiểu quan hệ. Đây là cú sốc đầu tiên với nhiều kỹ sư đến từ thế giới SQL.
3. Lấy dữ liệu thay đổi (CDC) — để không phải trích xuất toàn bộ mỗi ngày, đội Data thường dựng cơ chế Change Data Capture bắt các bản ghi thay đổi.
4. Hiểu chu kỳ COB — dữ liệu cuối ngày chỉ "chốt" sau khi tiến trình COB chạy xong. Trích xuất sai thời điểm sẽ ra số liệu chưa chốt.

Chỉ riêng use case này đã cho thấy: muốn làm dữ liệu tốt, đội Data không thể coi T24 như một hộp đen. Phải hiểu mô hình dữ liệu, cách nghiệp vụ ghi bản ghi, và nhịp vận hành của hệ thống.

Vì sao đội Data/IT cần hiểu T24

Tóm lại trong một câu: T24 là nguồn dữ liệu gốc — system of record — của gần như mọi con số tài chính trong ngân hàng. Data warehouse, hệ thống báo cáo quản trị, báo cáo tuân thủ, mô hình rủi ro, phân tích khách hàng — tất cả đều lấy dữ liệu bắt nguồn từ T24 (trực tiếp hoặc qua CDC). Nếu bạn hiểu sai cách T24 lưu và xử lý dữ liệu, mọi lớp phía trên sẽ sai theo. Đó là lý do đầu tư thời gian hiểu T24 là khoản đầu tư đáng giá nhất cho một kỹ sư dữ liệu trong ngành ngân hàng.

Ghi nhớ

• T24 = Temenos Transact (đổi tên từ 1/2019); nhiều người vẫn quen gọi "T24" — hai tên chỉ một sản phẩm.
• Là core banking real-time, parameter-driven: logic nghiệp vụ chủ yếu là cấu hình tham số, không phải viết code cứng.
• T24 là system of record trung tâm: CUSTOMER, ACCOUNT, deposits, loans, payments, GL — các hệ thống vệ tinh (thẻ, digital banking, payment hub, AML, CRM, DWH) đều xoay quanh nó.
• Model Bank = bộ cấu hình/sản phẩm mẫu best-practice để triển khai nhanh; ngân hàng tùy biến trên nền đó. Đi lệch càng nhiều, nâng cấp càng đắt.
• R-series (R13, R14, ... các bản theo năm) là chu kỳ release; upgrade/uplift là bài toán khó vì phải xử lý phần tùy biến.
• Module lớn cần nhớ: Customer, Accounts, Funds Transfer, Teller, Lending (AA), Deposits, Trade Finance, Treasury, Limits, Collateral, Accounting/GL, MIS.
• Triển khai: on-premise, private cloud, và Temenos Banking Cloud (SaaS); bản mới là cloud-native / microservices / API-first, chạy trên AWS/Azure/GCP.
• Với đội Data: T24 không "cắm SQL" như Postgres được — dữ liệu theo mô hình multivalue, cần hiểu CDC và nhịp COB.

Đọc tiếp trong series

• Kiến trúc kỹ thuật (TAFJ / jBASE) — nền tảng runtime và cơ chế lưu trữ của T24.
• Mô hình dữ liệu multivalue — vì sao T24 không phải là cơ sở dữ liệu quan hệ, và điều đó ảnh hưởng gì đến việc trích xuất dữ liệu.
• OFS (Open Financial Service) — cơ chế "cổng vào" chuẩn để đẩy giao dịch và tích hợp với T24.
• Arrangement Architecture (AA) — kiến trúc sản phẩm hiện đại cho lending, deposits và hơn thế nữa.
• COB (Close Of Business) — tiến trình cuối ngày và ý nghĩa với dữ liệu.