Close of Business (COB) & tích hợp hiện đại của T24

Hai chủ đề trong bài này thoạt nhìn không liên quan, nhưng với người làm Data thì chúng là hai mặt của cùng một câu hỏi: khi nào dữ liệu trong T24 "chốt" và bằng cách nào tôi lấy được nó ra ngoài? COB (Close of Business) trả lời vế thứ nhất — nó là tiến trình cuối ngày biến các số dư "đang chạy" thành con số chính thức của ngày. Tích hợp hiện đại (IRIS/API, Data Framework/Event, CDC) trả lời vế thứ hai — làm sao đưa dữ liệu đó ra kho dữ liệu, ra hệ thống vệ tinh, ra kênh số. Hiểu cả hai, bạn sẽ biết chính xác đâu là thời điểm an toàn để trích xuất và đâu là con đường kỹ thuật để trích xuất.

Bài này nối tiếp T24 7 — OFS (Open Financial Service), T24 2 — Kiến trúc tSA/tSM/phantom và T24 4 — Core operations & GL. Nếu chưa đọc, bạn nên nắm sơ trước vì COB dùng lại đúng những khái niệm đó.

Phần A — Close of Business (COB)

COB là gì và vì sao nó tồn tại

T24 xử lý thời gian thực (real-time) trong ngày: mỗi giao dịch cập nhật số dư ngay lập tức. Nhưng có một lớp công việc không thể — và không nên — làm theo từng giao dịch, mà phải gom lại chạy theo lô vào cuối ngày. Đó chính là COB: một chuỗi xử lý lô cuối ngày, thực hiện những việc mang tính "chốt sổ" cho toàn hệ thống:

• Tính lãi (accrual/capitalisation) cho tiền gửi và khoản vay theo số dư trong ngày.
• Thu phí định kỳ (phí quản lý tài khoản, phí dịch vụ...).
• Xử lý đến hạn (maturity/due date): khoản vay đến kỳ trả, tiền gửi đáo hạn, chứng từ đến hạn.
• Kết chuyển GL (accounting/consolidation): dồn các bút toán trong ngày vào sổ cái tổng hợp, tính số dư GL cuối ngày.
• Sinh báo cáo cuối ngày (báo cáo quản trị, báo cáo tuân thủ, file gửi cơ quan quản lý).
• Chuyển ngày hệ thống: đổi biến ngày làm việc TODAY → next working day (ngày làm việc kế tiếp, bỏ qua cuối tuần/ngày lễ theo lịch cấu hình).

Điểm dễ hiểu lầm: COB không nhất thiết khoá toàn bộ hệ thống. Tuỳ cấu hình và phiên bản, một số kênh (ví dụ Internet/Mobile banking chỉ đọc, hoặc ATM) vẫn có thể mở song song trong lúc COB chạy — vì nhiều xử lý COB thao tác trên vùng dữ liệu riêng. Tuy nhiên các nghiệp vụ ghi trực tiếp vào bảng đang được COB xử lý thì thường bị hạn chế. Đừng mặc định "COB = downtime toàn hệ thống"; hãy hỏi cấu hình cụ thể của ngân hàng.

Các mốc trong một ngày vận hành

Một chu kỳ ngày của T24 gồm ba mốc chính:

1. Start of Day (SOD) — mở đầu ngày mới sau khi ngày trước đã COB xong; hệ thống ở trạng thái ngày làm việc mới, sẵn sàng nhận giao dịch.
2. Xử lý online ban ngày — real-time, giao dịch của quầy, kênh số, hệ vệ tinh đổ vào (nhiều qua OFS).
3. COB cuối ngày — chạy chuỗi job lô, rồi kết thúc bằng bước chuyển ngày; hệ thống bước sang SOD của ngày kế tiếp.

Định nghĩa job: application BATCH

Chuỗi COB không phải một script cứng. Mỗi bước được khai báo như một job trong application BATCH — đúng tinh thần parameter-driven của T24. Bản ghi BATCH mô tả cho một job:

• Chạy routine gì: tên chương trình/subroutine sẽ thực thi.
• Tần suất: chạy hằng ngày, cuối tháng, cuối năm, hay theo điều kiện.
• Phụ thuộc/thứ tự: job này chạy sau job nào (ví dụ kết chuyển GL phải sau khi tính lãi và thu phí đã sinh bút toán). Các job xâu thành chuỗi phụ thuộc (dependency chain) — hoàn thành mắt xích trước mới sang mắt xích sau.
• Đơn hay đa agent: job có thể chạy đơn tiến trình, hoặc được chia cho nhiều agent chạy song song (multi-threaded) để rút ngắn thời gian trên khối dữ liệu lớn.

Định nghĩa job trong BATCH (minh hoạ)

BATCH  BNK/INTEREST.CAP
  Description ....... : Capitalise deposit interest
  Batch.Stage ....... : 30            ; vị trí trong chuỗi (chạy theo thứ tự stage)
  Frequency ......... : DAILY
  Job.Name .......... : ACCT.INT.CAP  ; routine thực thi
  Job.Type .......... : M             ; M = Multi-threaded (nhiều agent)
  Batch.Job ......... : BNK/FEE.CHARGE ; job kế tiếp trong chuỗi (phụ thuộc)

(minh hoạ — tên trường và cú pháp thực tế tuỳ phiên bản Transact; ý ở đây là job = routine + tần suất + thứ tự + kiểu chạy)

Các job được nhóm theo stage (giai đoạn). Một COB điển hình đi qua nhiều stage: khởi tạo, các job nghiệp vụ (lãi, phí, đến hạn), kết chuyển kế toán, báo cáo, và cuối cùng là change date. Trong mỗi stage, các job có thể chạy song song; giữa các stage là điểm đồng bộ — sang stage sau chỉ khi stage trước hoàn tất.

Thực thi: tSA và tSM

COB được đẩy chạy bởi hai thành phần đã gặp ở bài kiến trúc:

• tSA (TSA.SERVICE) — Temenos Service Agent: khai báo và chạy các service, trong đó có service loại COB. Mỗi service có thể gắn nhiều agent.
• tSM (Temenos Service Manager) — điều phối/giám sát các service, quyết định service nào đang chạy, khởi động/dừng, và cấp phát agent.

Cơ chế song song là chìa khoá tốc độ: thay vì một tiến trình xử lý tuần tự hàng triệu tài khoản, service COB tách công việc cho nhiều agent (phantom process) chạy đồng thời, mỗi agent nuốt một phần dữ liệu. Tăng số agent (trong giới hạn tài nguyên máy và cấu hình khoá) sẽ rút ngắn cửa sổ COB. Xem lại tSA/tSM và phantom để hiểu mô hình tiến trình.

Giám sát & xử lý lỗi EOD

COB là quy trình vận hành nghiêm trọng nhất trong ngày của một ngân hàng chạy T24. Nếu COB không xong, ngày mới không mở được, báo cáo không ra, hệ thống "kẹt" ở ngày cũ. Vì vậy đội vận hành theo dõi COB rất sát:

• Giám sát tiến độ: xem service/agent đang ở stage nào, job nào đang chạy, job nào đã xong, thời gian từng bước so với baseline (để phát hiện job chạy chậm bất thường).
• Bản ghi lỗi EOD: khi một job lỗi, T24 ghi lại vào các bảng lỗi cuối ngày (ví dụ dạng EB.EOD.ERROR / báo lỗi job). Bản ghi này cho biết job nào hỏng, trên bản ghi/tài khoản nào, thông điệp lỗi gì.
• Restart từ điểm dừng: nguyên tắc là COB restartable — sửa nguyên nhân rồi khởi động lại từ job/stage bị dừng, không chạy lại từ đầu (chạy lại từ đầu có thể tính lãi/thu phí hai lần). Đây là lý do dependency chain và trạng thái từng job phải rõ ràng.

Với người làm Data, thông điệp cốt lõi: đừng trích xuất khi COB chưa xong hoặc đang dở dang — số liệu lúc đó chưa "chốt".

Tác động tới dữ liệu

Nhiều bảng chỉ mang giá trị "chính thức của ngày" sau khi COB hoàn tất: số dư GL cuối ngày, dư nợ, lãi dự thu, trạng thái đến hạn... Trong ngày, các con số này còn biến động theo giao dịch real-time và chưa qua kết chuyển. Do đó:

• Job trích xuất DWH/ODS thường được lập lịch sau COB (và sau bước change date), để ảnh chụp dữ liệu là con số đã chốt của đúng ngày kinh doanh.
• Ngày kinh doanh (business date) dùng để gán nhãn dữ liệu chính là biến TODAY trước khi chuyển sang ngày kế — cần thống nhất quy ước này để tránh lệch một ngày (off-by-one) khi đối chiếu.

Phần B — Tích hợp hiện đại

Từ OFS tới API-first

Con đường tích hợp T24 tiến hoá qua nhiều thế hệ, và các thế hệ này cùng tồn tại — bạn sẽ gặp cả ở một ngân hàng thực tế:

1. OFS (bài trước): định dạng bản tin gốc để đẩy giao dịch/inquiry vào T24. Là "ngôn ngữ" nền tảng, các lớp trên vẫn quy về OFS.
2. Temenos Web Services (SOAP) / Interaction Framework: bọc OFS bằng dịch vụ web SOAP — thế hệ tích hợp doanh nghiệp cổ điển, dựa trên WSDL.
3. IRIS / Temenos API (các bản mới): tầng tích hợp REST, API-first. IRIS (Interaction/Integration framework) là giải pháp nhẹ, chuẩn REST, và bên trong vẫn dùng định dạng bản tin OFS để nói chuyện với T24. Đi kèm là bộ Transact APIs chuẩn hoá, hỗ trợ open banking và API marketplace.

Nói cách khác: OFS không biến mất, nó bị "giấu" phía sau REST. Một lời gọi REST tới IRIS được dịch thành OFS bên trong, T24 xử lý, rồi trả kết quả dạng JSON.

// Gọi Transact API qua IRIS (minh hoạ) - đọc thông tin tài khoản
GET /irf-provider-container/api/v1.0.0/holdings/accounts/12345
Authorization: Bearer <token>

// Phản hồi (rút gọn)
{
  "header": { "status": "success" },
  "body": [
    {
      "accountId": "12345",
      "customerId": "100237",
      "currency": "VND",
      "onlineActualBalance": 15200000,
      "workingBalance": 15200000
    }
  ]
}

(minh hoạ — đường dẫn/tên trường thực tế tuỳ phiên bản và bộ API được bật; ý ở đây là REST vào, JSON ra, OFS chạy ngầm)

DFE — Data Framework/Event

Ngoài lối gọi request–response (bên ngoài chủ động hỏi T24), còn cần lối đẩy sự kiện (T24 chủ động phát khi có thay đổi) để phục vụ tích hợp gần thời gian thực. Đó là vai trò của DFE (Data Framework/Event): khi một bản ghi được tạo/sửa (ví dụ mở tài khoản, hạch toán), T24 phát một sự kiện ra ngoài để hệ khác tiêu thụ — thay vì hệ ngoài phải liên tục hỏi thăm (polling).

Cơ chế event này rất hợp để xây kiến trúc event-driven: T24 → event → message broker → nhiều consumer (cập nhật cache khách hàng, đẩy thông báo, đồng bộ hệ CRM...). Nó bổ sung cho COB: COB cho ảnh chụp cuối ngày, còn event cho dòng thay đổi trong ngày.

CDC — bắt thay đổi từ CSDL nền

Có một con đường lấy dữ liệu không đi qua tầng ứng dụng T24 chút nào: CDC (Change Data Capture) đọc thẳng từ CSDL nền. Khi T24 chạy trên nền quan hệ (Oracle, DB2, MSSQL), mọi thay đổi cuối cùng đều đáp xuống các bảng dưới DB. Công cụ CDC như Oracle GoldenGate hoặc Debezium đọc redo/transaction log của DB, bắt từng thay đổi (insert/update/delete) và đẩy vào Kafka, rồi từ đó nạp vào DWH/lakehouse.

CDC có ưu điểm lớn cho Data team: không tạo tải lên tầng nghiệp vụ T24, bắt được mọi thay đổi kể cả cột kỹ thuật, và cho độ trễ thấp. Nhược điểm: bạn làm việc ở tầng bảng vật lý — cấu trúc lưu trữ của T24 rất đặc thù (dữ liệu multi-value nén trong một cột), nên thường cần một lớp giải mã/ánh xạ trước khi dùng được. Đây chính là điểm nối vào hai series đã có trong knowledge base — xem Oracle CDC cho GoldenGate/log-based CDC, và Kafka chuyên sâu cho tầng vận chuyển sự kiện.

Triển khai & vận hành

Vòng đời phát triển tích hợp T24 hiện đại xoay quanh:

• Design Studio — IDE của Temenos để phát triển tuỳ biến và đóng gói (package); sản phẩm là các deployment package chuyển giữa môi trường.
• Chuỗi môi trường DEV → UAT → PROD — package được kiểm thử ở UAT trước khi lên PROD; mọi thay đổi tham số/API đều đi theo quy trình này.
• Temenos Banking Cloud — hướng triển khai SaaS/cloud-native, nơi Temenos quản một phần hạ tầng và cung cấp API theo mô hình dịch vụ; ở đây quyền truy cập DB nền cho CDC có thể bị hạn chế, khiến API/event trở thành con đường tích hợp chính.

Use case thực tế

Tình huống 1 — COB fail vì job tính lãi lỗi. 2 giờ sáng, đội vận hành nhận cảnh báo COB dừng ở stage tính lãi. Kiểm tra bản ghi lỗi EOD (dạng EB.EOD.ERROR) thấy một routine capitalisation lỗi trên một nhóm tài khoản có lãi suất cấu hình sai (thiếu bản ghi tham số lãi cho một sản phẩm mới mở). Cách xử lý: (1) không chạy lại COB từ đầu — vì các tài khoản đã tính lãi xong sẽ bị tính hai lần; (2) sửa nguyên nhân gốc (bổ sung tham số lãi); (3) restart từ đúng job/stage bị dừng theo cơ chế restartable của tSM. Song song, báo cho đội Data biết ETL sáng hôm đó sẽ trễ, tuyệt đối không trích xuất khi COB chưa "xanh" hoàn toàn — nếu không, DWH sẽ chụp phải dữ liệu dở dang (một phần tài khoản đã có lãi, phần khác chưa).

Tình huống 2 — dựng luồng CDC T24 → Kafka → DWH. Ngân hàng muốn có bảng giao dịch gần real-time cho phân tích, không chờ tới sau COB. Đội Data dựng GoldenGate đọc redo log của Oracle nền T24, đẩy thay đổi bảng giao dịch vào Kafka, và dùng Kafka Connect nạp vào lakehouse. Thách thức thực tế là giải mã cấu trúc multi-value của T24 (nhiều giá trị nhồi trong một cột) thành cột chuẩn quan hệ — làm ở tầng stream processing hoặc trong transform của DWH. Kết quả: dữ liệu trong-ngày phục vụ dashboard, còn con số chính thức cuối ngày vẫn lấy từ snapshot sau COB để đối chiếu và báo cáo tài chính. Hai nguồn bổ sung cho nhau chứ không thay thế.

Ghi nhớ

• COB là tim của ngày vận hành: chuỗi job lô cuối ngày (lãi, phí, đến hạn, kết chuyển GL, báo cáo) rồi chuyển ngày TODAY → next working day. COB fail = sự cố nghiêm trọng.
• Job = tham số trong BATCH: routine + tần suất + thứ tự/phụ thuộc + đơn/đa agent; xâu thành dependency chain, chạy song song trong stage.
• tSA/tSM điều phối COB, nhiều agent (phantom) chạy song song để rút ngắn cửa sổ. Lỗi ghi vào bản ghi EOD, restart từ điểm dừng — không chạy lại từ đầu.
• Dữ liệu chỉ chốt sau COB: lập lịch trích xuất DWH sau COB + change date, cẩn thận off-by-one với business date.
• Tích hợp tiến hoá: OFS → SOAP/Interaction Framework → IRIS/Temenos API (REST, API-first); IRIS vẫn dùng OFS ngầm. DFE phát sự kiện cho tích hợp gần real-time.
• CDC là con đường của Data team: GoldenGate/Debezium đọc log DB nền → Kafka → DWH; nhớ giải mã cấu trúc multi-value của T24. Nối tiếp series Oracle CDC và Kafka chuyên sâu.
• Vận hành: Design Studio package, chuỗi DEV/UAT/PROD, và xu hướng Temenos Banking Cloud (nơi API/event có thể thay thế truy cập DB trực tiếp).