Arrangement Architecture (AA) — nhà máy sản phẩm của T24

Ở các bài trước của series, chúng ta đã đi qua triết lý parameter-driven của T24: phần lớn nghiệp vụ không viết cứng bằng code mà khai báo bằng tham số. Không ở đâu triết lý này được đẩy tới cực điểm rõ ràng như Arrangement Architecture (AA) — khung "dựng sản phẩm" (Product Builder) mà Temenos xây để thay thế cách định nghĩa sản phẩm cũ trong các module cổ điển. Nếu bạn làm Data/IT ở một ngân hàng chạy T24 đời mới, gần như chắc chắn các sản phẩm cho vay, tiền gửi và tài khoản đều được dựng bằng AA. Hiểu AA là hiểu cách một sản phẩm ngân hàng thực sự "ra đời" bên trong core.

Vấn đề mà AA sinh ra để giải quyết

Trong T24 cổ điển, mỗi loại sản phẩm gắn với một module riêng, mỗi module có bảng tham số và logic riêng:

• ACCOUNT — tài khoản vãng lai, tiền gửi không kỳ hạn (xem bài core operations về ACCOUNT và tiền gửi).
• AZ (AZ.ACCOUNT) — tiền gửi có kỳ hạn (deposits).
• LD (Loans & Deposits) — cho vay, hạn mức, tiền gửi doanh nghiệp (xem bài về cho vay và tín dụng).
• MM, PD… — thị trường tiền tệ, các khoản phải thu…

Cách này có ba điểm đau lớn. Thứ nhất, định nghĩa sản phẩm cứng nhắc: muốn thêm một biến thể (ví dụ khoản vay lãi thả nổi có ân hạn gốc 6 tháng) thường phải đụng đến nhiều bảng tham số rải rác, thậm chí phát triển thêm. Thứ hai, khó tái sử dụng: logic tính lãi ở module tiền gửi và module cho vay là hai cài đặt khác nhau, dù bản chất "tính lãi trên số dư theo day basis" là giống nhau. Thứ ba, khó cá biệt hóa cho từng khách hàng: muốn giảm biên độ (margin) cho một khách VIP, cơ chế override ở cấp hợp đồng không đồng nhất giữa các module.

AA trả lời cả ba điểm này bằng một ý tưởng: componentization — tháo rời sản phẩm thành các thành phần nghiệp vụ dùng chung, rồi lắp ráp lại. Thay vì "module tiền gửi" và "module cho vay" tách biệt, AA cung cấp một tập Property Class chuẩn (lãi, phí, lịch trả, số dư, tài khoản…) và bạn lắp chúng vào để dựng bất kỳ sản phẩm nào — tiền gửi, cho vay, tài khoản, thẻ. Cùng một Property Class INTEREST được tái sử dụng cho cả sản phẩm vay lẫn tiết kiệm.

Phân tầng sản phẩm: Product Line → Group → Product

AA tổ chức sản phẩm thành ba tầng, đi từ trừu tượng đến cụ thể:

• Product Line (AA.PRODUCT.LINE) — phân loại cao nhất, ví dụ Lending (cho vay), Deposits (tiền gửi), Accounts (tài khoản), Cards (thẻ). Điểm quan trọng cần nhớ: Product Line chỉ do Temenos định nghĩa, người dùng (ngân hàng) không tạo được Product Line mới. Mỗi Product Line xác định tập Property Class được phép dùng và cách chúng phối hợp.
• Product Group (AA.PRODUCT.GROUP) — nhóm sản phẩm ở tầng giữa, ví dụ Mortgages (vay mua nhà), Personal Loans, Term Deposits. Một số Product Group được T24 định nghĩa sẵn cho các ứng dụng chọn lọc, phần còn lại ngân hàng tự định nghĩa. Product Group được dẫn xuất từ một Product Line.
• Product (AA.PRODUCT) — sản phẩm cụ thể mà ngân hàng bán, ví dụ "Vay mua nhà lãi cố định 15 năm". Đây là tầng hoàn toàn do người dùng định nghĩa. Product được dẫn xuất từ một Product Group, và thừa hưởng các Property Class của Product Line tương ứng.

Một chi tiết vận hành then chốt: Product phải được publish (AA.PRODUCT.CATALOG) thì mới dùng được để mở hợp đồng. Trước khi publish, sản phẩm còn đang thiết kế; sau khi publish, nó vào "catalog" sẵn sàng bán. Việc publish cũng gắn với hiệu lực theo ngày — bạn có thể publish một phiên bản sản phẩm có hiệu lực từ một ngày trong tương lai.

Property Class và Property: các "viên gạch" nghiệp vụ

Nền tảng của AA là tiên đề: mọi sản phẩm đều cấu thành từ một số thành phần nghiệp vụ cơ bản, mỗi thành phần là một Property Class (AA.PROPERTY.CLASS). Các Property Class tiêu biểu:

• INTEREST — quy tắc tính lãi (lãi suất, biên độ/margin, day basis, chu kỳ tính).
• CHARGE — phí (phí giải ngân, phí quản lý, phí phạt trả trước…).
• PAYMENT.SCHEDULE — lịch trả nợ / lịch thu (số kỳ, tần suất, ngày đến hạn, thành phần gốc-lãi-phí trong mỗi kỳ).
• ACCOUNT — tạo và quản lý bản ghi tài khoản đi kèm cho các sản phẩm "account based" (thông tin mô tả, phân loại của arrangement).
• TERM.AMOUNT — số tiền và kỳ hạn của hợp đồng (số tiền cam kết, ngày bắt đầu, ngày đáo hạn).
• SETTLEMENT — tài khoản giải ngân / tài khoản thanh lý (drawdown account nhận tiền, liquidation account để thu tiền).
• BALANCE — cách theo dõi và phân loại các loại số dư (gốc, lãi dồn tích, quá hạn…).
• CUSTOMER — gắn hợp đồng với khách hàng và vai trò của họ.

Mỗi Property Class gồm hai phần:

1. Conditions (điều kiện) — các tham số mô tả đặc tính của sản phẩm: lãi suất, margin, day basis, số kỳ trả, mức phí… Đây là phần bạn "điền số".
2. Actions (hành động) — các xử lý mà thành phần đó thực hiện: tính lãi và dồn tích, tạo bút toán, sinh kỳ đến hạn, thu phí…

Cần phân biệt Property Class và Property. Property Class là khuôn trừu tượng (ví dụ class INTEREST). Property là một hiện thực cụ thể của class đó trong một sản phẩm — một sản phẩm vay có thể có nhiều Property của cùng class INTEREST: PRINCIPALINT (lãi trên gốc), PENALTYINT (lãi phạt quá hạn). Mỗi Property lại có một bản ghi condition riêng (ví dụ AA.INTEREST cho INTEREST). Đây là cơ chế cho phép một sản phẩm có nhiều "loại lãi", nhiều "loại phí" mà không cần code thêm.

Arrangement: khi khách hàng "mua" sản phẩm

Product mới chỉ là khuôn mẫu. Khi một khách hàng thực sự mở khoản vay hay gửi tiết kiệm, T24 tạo ra một Arrangement (AA.ARRANGEMENT) — đây là hợp đồng cụ thể, gắn:

• một CUSTOMER (khách hàng chủ hợp đồng),
• một Product (sản phẩm được chọn),
• và một bộ conditions cụ thể — mặc định kế thừa từ Product, nhưng có thể override ở cấp arrangement.

Cơ chế override chính là chỗ AA giải quyết bài toán cá biệt hóa. Ví dụ kinh điển: một sản phẩm Mortgage dùng lãi thả nổi theo LIBOR với biên độ chuẩn 0,5%. Với một khách hàng cụ thể, ngân hàng đồng ý giảm biên độ xuống 0,25%. Khi đó Product Condition của Property INTEREST được sửa ở cấp arrangement và trở thành Arrangement Condition. Điều quan trọng: việc sửa này chỉ được phép nếu Negotiation Rules đặt ở condition của Property đó cho phép. Nghĩa là ngân hàng kiểm soát được đâu là tham số "cứng" (không cho sửa) và đâu là tham số "đàm phán được" (giao dịch viên/RM có thể điều chỉnh trong biên độ cho phép).

Điều kiện có hiệu lực theo thời gian (effective-dated)

Mọi condition trong AA đều effective-dated — gắn với một ngày hiệu lực. Đây là đặc tính rất mạnh: bạn có thể khai báo trước rằng "từ ngày 01/01 năm sau, lãi suất khoản vay này đổi từ 8% sang 8,5%". T24 lưu nhiều phiên bản condition theo thời gian, và tại mỗi thời điểm xử lý, nó dùng đúng phiên bản có hiệu lực. Điều này phản ánh đúng thực tế hợp đồng ngân hàng: điều khoản thay đổi theo mốc thời gian (hết ưu đãi, tái định giá, đổi lịch trả). Không cần "sửa tay tại thời điểm đó" — mọi thay đổi tương lai được lên lịch sẵn.

Activity: mọi thay đổi đều đi qua "hành động"

Đây là nguyên tắc bất di bất dịch của AA: không thay đổi arrangement trực tiếp; mọi thay đổi phải thực hiện qua một Activity (AA.ARRANGEMENT.ACTIVITY). Activity là "động từ" tác động lên arrangement. Tên activity thường theo mẫu PRODUCT.LINE-ACTION-PROPERTY, ví dụ:

• LENDING-NEW-ARRANGEMENT — tạo mới một hợp đồng vay.
• LENDING-DISBURSE-COMMITMENT — giải ngân khoản cam kết.
• LENDING-REPAY-PAYMENT.SCHEDULE — ghi nhận một khoản trả nợ.
• DEPOSITS-INTEREST-CAPITALISE — nhập lãi (capitalise) vào gốc tiền gửi.
• LENDING-CHANGE-INTEREST — thay đổi điều kiện lãi.

Mỗi activity thực hiện trên arrangement đều effective-dated và được ghi vào Activity Log của arrangement. T24 lưu toàn bộ chuỗi activity, cùng liên kết tới mọi giao dịch tài chính (giải ngân, trả nợ, gửi, rút) và mọi bút toán kế toán phát sinh. Đây là kho vàng cho đội Data: Activity Log cho bạn dòng thời gian đầy đủ, có thể kiểm toán được, của mọi điều đã xảy ra với một hợp đồng — ai làm gì, ngày hiệu lực nào, sinh ra bút toán nào.

Chính activity là nơi các actions của Property Class được kích hoạt. Khi bạn chạy LENDING-DISBURSE-COMMITMENT, action của Property SETTLEMENT chuyển tiền vào tài khoản giải ngân, action của PAYMENT.SCHEDULE sinh lịch trả nợ, action của ACCOUNT tạo/cập nhật bản ghi tài khoản, và các bút toán gốc được ghi vào GL (đối chiếu bài về bút toán kép và GL).

Bức tranh tổng thể

Ví dụ minh họa: một sản phẩm vay và các điều kiện của nó

Dưới đây là hình dung một Product AA cùng vài Property/condition. Đây là minh họa khái niệm, không phải cú pháp T24 chính xác từng trường:

PRODUCT: MORTGAGE.FIXED.15Y                         (minh hoạ)
  Product Line  : LENDING
  Product Group : MORTGAGES
  Status        : PUBLISHED (hiệu lực từ 2026-01-01)

  Property [TERM.AMOUNT] "COMMITMENT"
    conditions:
      Amount        = (nhập khi mở hợp đồng)
      Term          = 180 tháng (15 năm)

  Property [INTEREST] "PRINCIPALINT"
    conditions:
      Rate Type     = FIXED
      Fixed Rate    = 8.0%
      Day Basis     = ACT/365
      Negotiable    = YES (margin đàm phán trong ±0.5%)

  Property [INTEREST] "PENALTYINT"        (lãi quá hạn)
    conditions:
      Rate          = PRINCIPALINT + 3.0%

  Property [PAYMENT.SCHEDULE] "REPAYMENT"
    conditions:
      Frequency     = MONTHLY
      Type          = Annuity (gốc+lãi cố định mỗi kỳ)
      Start         = 1 tháng sau giải ngân

  Property [CHARGE] "DISBURSE.FEE"
    conditions:
      Amount        = 0.5% số tiền giải ngân

  Property [SETTLEMENT] "SETTLE"
    conditions:
      Payin Account  = tài khoản khách nhận tiền
      Payout Account = tài khoản khách trích trả nợ

Khi ngân hàng cho khách VIP vay, họ mở một arrangement từ product này và override điều kiện PRINCIPALINT xuống 7,7% — hợp lệ vì Negotiable = YES trong biên độ cho phép. Product gốc không đổi; chỉ arrangement của khách đó mang condition riêng.

Use case thực tế

Tình huống 1 — Dựng sản phẩm tiền gửi có kỳ hạn. Đội sản phẩm muốn ra "Tiết kiệm 12 tháng, lãi cuối kỳ, tự động tái tục". Họ tạo một Product trong Product Line Deposits, Product Group Term Deposits, lắp các Property: TERM.AMOUNT (kỳ hạn 12 tháng), INTEREST (lãi suất theo biểu, day basis), PAYMENT.SCHEDULE (trả lãi cuối kỳ), ACCOUNT (bản ghi tài khoản tiền gửi), SETTLEMENT (tài khoản nguồn và tài khoản nhận tiền đáo hạn). Publish sản phẩm. Từ đó giao dịch viên chỉ việc mở arrangement cho từng khách — không ai phải sửa code.

Tình huống 2 — Điều gì xảy ra khi chạy activity trên một khoản vay. Khách ký hợp đồng vay:

1. LENDING-NEW-ARRANGEMENT tạo arrangement, gắn customer + product, snapshot các condition (có override margin nếu có).
2. LENDING-DISBURSE-COMMITMENT giải ngân: action của SETTLEMENT chuyển tiền vào tài khoản khách, CHARGE thu phí giải ngân, PAYMENT.SCHEDULE sinh lịch trả 180 kỳ, và bút toán ghi Nợ "Cho vay khách hàng" / Có "Tài khoản khách" vào GL.
3. Hằng ngày trong COB (xem bài Close Of Business), action của INTEREST dồn tích lãi (accrual) trên số dư gốc; đến ngày đến kỳ, PAYMENT.SCHEDULE làm kỳ trả đến hạn, sinh bút toán tương ứng và các khoản phải thu.
4. Khi khách trả, LENDING-REPAY-PAYMENT.SCHEDULE phân bổ tiền vào lãi/gốc/phí theo thứ tự đã cấu hình, cập nhật số dư.

Mọi bước đều nằm trong Activity Log — đội Data trích xuất để dựng dòng đời hợp đồng, tính lãi dự thu, phân tích nợ quá hạn. Lưu ý: AA sinh phần lớn bút toán dồn tích và các kỳ đến hạn trong COB, nên hiểu lịch COB là điều kiện để hiểu vì sao số liệu "nhảy" vào cuối ngày.

AA so với module cổ điển

Xu hướng rõ ràng: các ngân hàng triển khai T24/Transact mới đều dùng AA cho lending, deposits và accounts; module cổ điển chủ yếu còn ở các hệ thống cũ chưa migrate. Vì vậy khi bạn tiếp cận một dữ liệu core hiện đại, khả năng cao bạn sẽ gặp các bảng AA.ARRANGEMENT, AA.PRODUCT, AA.ARRANGEMENT.ACTIVITY thay vì AZ.ACCOUNT hay LD.LOANS.AND.DEPOSITS.

Ghi nhớ

• AA = Product Builder theo hướng componentized. Sản phẩm được lắp ráp từ các Property Class dùng chung, không viết cứng theo module.
• Ba tầng: Product Line (chỉ Temenos tạo) → Product Group → Product (ngân hàng dựng, phải publish mới bán được).
• Property Class = conditions (tham số) + actions (xử lý). Property là hiện thực cụ thể của class; một sản phẩm có thể có nhiều Property cùng class.
• Arrangement = hợp đồng cụ thể gắn customer + product; override được điều kiện ở cấp hợp đồng nếu Negotiation Rules cho phép.
• Mọi thay đổi đi qua Activity — effective-dated, ghi vào Activity Log cùng liên kết giao dịch tài chính và bút toán GL.
• Condition effective-dated cho phép lên lịch thay đổi lãi/điều khoản trong tương lai.
• AA sinh bút toán dồn tích và kỳ đến hạn trong COB — muốn hiểu số liệu cuối ngày phải hiểu quan hệ AA ↔ COB. Xem thêm mô hình dữ liệu T24 và core operations.

Nguồn tham khảo (kiểm chứng thuật ngữ AA):

• T24 Arrangement Architecture — tài liệu Product Builder (Scribd)
• Temenos T24 Arrangement Architecture Overview (Studocu)
• Arrangement Activities — Property Class (Course Hero)
• T3TAAC Arrangement Architecture Core R14 (PDFCoffee)
• Corporate Lending — Temenos T24 Transact (Temenos, chính hãng)