T24 5 — OFS: cổng giao dịch & tích hợp của T24

OFS là gì, và vì sao nó tồn tại?

Hãy tưởng tượng bạn đang xây dựng một ứng dụng internet banking. Khách hàng bấm nút "Chuyển khoản" trên điện thoại. Đằng sau nút bấm đó, một lệnh chuyển tiền phải đi vào core banking T24, phải được kiểm tra số dư, kiểm tra hạn mức, ghi bút toán kép vào sổ cái, cập nhật số dư tài khoản, sinh phí — nghĩa là phải chạy đúng toàn bộ luồng nghiệp vụ mà một teller sẽ chạy khi họ nhập tay giao dịch đó trên màn hình T24.

Câu hỏi cốt lõi là: làm sao hệ thống bên ngoài "nói chuyện" được với T24? T24 không thể mở database cho ứng dụng ngoài ghi trực tiếp — làm vậy sẽ bỏ qua toàn bộ validation, authorisation và accounting, dẫn tới dữ liệu rác và bút toán lệch. Cần một cửa vào chuẩn buộc mọi giao dịch từ bên ngoài đi qua đúng engine nghiệp vụ giống như nhập tay. Cửa vào đó chính là OFS — Open Financial Service.

OFS là một giao thức/định dạng message chuẩn cho phép hệ thống ngoài (internet banking, mobile banking, payment hub, middleware ESB, batch loader...) gửi một giao dịch hoặc một truy vấn vào T24 và nhận lại kết quả. Điều cần khắc cốt: một message OFS không phải là "SQL ghi thẳng vào bảng". Nó là một yêu cầu chạy một application của T24 (ví dụ FUNDS.TRANSFER, CUSTOMER) đúng theo luồng: validation → override/error → authorisation → accounting → cập nhật bản ghi. OFS mô phỏng chính xác việc "một người dùng đăng nhập, mở đúng VERSION, nhập dữ liệu và commit".

Chính đặc tính này khiến OFS trở thành nền tảng tích hợp bên dưới cho gần như mọi kênh: web services SOAP cũ, REST API đời đầu, connector middleware — tất cả cuối cùng đều dịch yêu cầu thành message OFS rồi đẩy vào T24.

Bức tranh tổng thể: message OFS đi từ đâu tới đâu

Luồng đọc từ trên xuống:

1. Hệ thống ngoài dựng một message OFS (native hoặc XML) mô tả "chạy application gì, làm gì, với dữ liệu nào, dưới quyền user nào".
2. Message tới một OFS.SOURCE — bản ghi cấu hình khai báo kênh vật lý để T24 nhận request (phantom lắng nghe, hàng đợi MQ, thư mục, hay lời gọi trực tiếp).
3. OFS engine parse message, xác định application + function, rồi chạy đúng như nhập tay.
4. Kết quả ghi ra bản ghi (LIVE hoặc $NAU nếu chờ duyệt), đồng thời ghi log vào OFS.REQUEST.DETAIL.
5. Một response OFS quay ngược lại hệ thống ngoài: thành công hay lỗi, @ID sinh ra, danh sách lỗi từng field nếu có.

Hai định dạng message: Native và XML

OFS hiểu hai "phương ngữ" cho cùng một nội dung:

• Native format — chuỗi text, các phần phân tách bằng dấu phẩy (,). Đây là dạng gọn nhất, hay thấy trong log, script test và middleware cũ. Nhược điểm: cần cẩn thận khi giá trị dữ liệu có chứa dấu phẩy.
• XML format — thường gọi là Browser XML (gắn với Temenos Browser). Cùng thông tin nhưng bọc trong thẻ XML: dễ đọc máy hơn, an toàn hơn với ký tự đặc biệt, và là cầu nối tự nhiên tới web services.

Cả hai mang cùng ngữ nghĩa — bài này dùng native để minh hoạ vì nó phơi bày rõ cấu trúc nhất.

Giải phẫu một message OFS transaction (native)

Một message OFS kiểu transaction gồm 5 phần, nối nhau bằng dấu phẩy, theo thứ tự cố định:

OPERATION , OPTIONS , USER_INFORMATION , TRANSACTION_ID , MESSAGE_DATA

Lần lượt từng phần:

1. OPERATION — chạy application nào

Đây là tên application T24 cần thực thi: FUNDS.TRANSFER, CUSTOMER, ACCOUNT, TELLER, AA.ARRANGEMENT.ACTIVITY... Đây chính là "cửa" nghiệp vụ mà giao dịch sẽ đi qua.

2. OPTIONS — version, function, process type

Phần này gói ba thông tin, thường viết dưới dạng VERSION/FUNCTION/PROCESS:

• VERSION — tên VERSION của application (ví dụ FUNDS.TRANSFER,AC.INT.COY). Version quyết định bộ field hiển thị, giá trị mặc định, quy tắc validation bổ sung, và cả số người duyệt. Nếu để trống, T24 dùng bản ghi gốc (unversioned).
• FUNCTION — chức năng thao tác: I = INPUT (tạo/sửa), A = AUTHORISE (duyệt), R = REVERSE, D = DELETE, S = SEE (xem)... Đây là chữ cái quyết định message này làm gì.
• PROCESS TYPE — PROCESS (chạy thật, commit) hay VALIDATE (chỉ kiểm tra, không commit — hữu ích để "thử" giao dịch xem có lỗi gì trước khi thật sự ghi).

Ví dụ một chuỗi options điển hình là /I/PROCESS (input và commit) hoặc /I/VALIDATE (input nhưng chỉ validate). Ngoài ra options còn có thể mang GTS.CONTROL và số người duyệt (no of authorisers) — nếu cung cấp, chúng ghi đè cấu hình tương ứng trong Version. GTS.CONTROL điều khiển cách xử lý lỗi/override: ví dụ null = lỗi thì reject và override thì tự chấp nhận; 1 = lỗi thì đưa bản ghi vào HLD (hold); 2 = override thì đưa vào hold. Đây là cần gạt tinh chỉnh hành vi xử lý lỗi qua OFS.

3. USER INFORMATION — chạy dưới quyền ai

Danh tính người dùng T24 sẽ thực thi giao dịch: sign-on name, password (hoặc token/cơ chế xác thực khác tuỳ triển khai), và có thể kèm company code khi hệ thống đa pháp nhân. Phần này quyết định mọi kiểm soát quyền hạn: user này có được phép chạy application đó, tại chi nhánh đó, với version đó hay không. Không có danh tính hợp lệ, message bị từ chối ngay.

4. TRANSACTION ID — @ID của bản ghi

Khoá (ID) của bản ghi cần tạo/sửa. Quy tắc quan trọng:

• Để trống ⇒ với các application có ID tự sinh (như FUNDS.TRANSFER), T24 sẽ tự sinh ID và trả về trong response.
• Cung cấp ID ⇒ dùng khi sửa/duyệt một bản ghi đã tồn tại, hoặc khi application dùng ID có ý nghĩa nghiệp vụ (ví dụ số tài khoản, mã khách hàng).

5. MESSAGE DATA — dữ liệu, các cặp FIELD=VALUE

Phần cuối là dữ liệu thực, gồm nhiều cặp FIELD.NAME=VALUE nối nhau bằng dấu phẩy. Đây là bản dịch trực tiếp của việc điền vào từng ô trên màn hình:

• Field đơn trị: DEBIT.ACCT.NO=150008
• Field multivalue (đa trị) và subvalue: dùng cú pháp vị trí FIELD:pos:sub=VALUE. Ví dụ CHARGE.CODE:1:1=DEBIT.PLUS.CHARGES nghĩa là gán giá trị vào multivalue thứ 1, subvalue thứ 1 của field CHARGE.CODE. Đây là cách OFS diễn đạt các nhóm field lặp lại (associated multivalue) mà mô hình dữ liệu T24 hay dùng.

Chỉ cần những field không có mặc định hoặc muốn ghi đè mặc định; phần còn lại Version sẽ tự điền.

Ví dụ message OFS cụ thể

Dưới đây là các ví dụ (minh hoạ) — cú pháp thực tế phụ thuộc phiên bản T24, cấu hình Version và OFS.SOURCE tại từng ngân hàng.

Ví dụ 1 — Transaction: tạo một lệnh chuyển khoản FUNDS.TRANSFER

Một hệ internet banking muốn tạo lệnh chuyển 1.000.000 VND từ tài khoản 150008 sang 600123, chạy dưới user INETUSER, để T24 tự sinh ID giao dịch:

(minh hoạ)

FUNDS.TRANSFER,/I/PROCESS,INETUSER/pwd123,,TRANSACTION.TYPE=AC,DEBIT.ACCT.NO=150008,CREDIT.ACCT.NO=600123,DEBIT.AMOUNT=1000000,DEBIT.CURRENCY=VND,ORDERING.CUST=Nguyen Van A,PAYMENT.DETAILS:1:1=Chuyen tien noi bo

Đọc từng phần:

• FUNDS.TRANSFER — application chuyển tiền.
• /I/PROCESS — Version để trống (dùng bản gốc), function I (input), process type PROCESS (commit thật).
• INETUSER/pwd123 — user information.
• (trống giữa hai dấu phẩy) — TRANSACTION ID để trống ⇒ T24 tự sinh @ID.
• Phần còn lại là MESSAGE DATA: các cặp field=value, trong đó PAYMENT.DETAILS:1:1=... là ví dụ ghi vào multivalue/subvalue.

Nếu đổi options thành /I/VALIDATE, T24 sẽ chỉ kiểm tra giao dịch (số dư đủ không, tài khoản hợp lệ không, phí ra sao) và trả kết quả mà không commit — rất hữu ích để hiển thị "xem trước" cho khách hàng trước khi họ xác nhận.

Ví dụ 2 — Enquiry: chạy một báo cáo ENQUIRY.SELECT

Truy vấn không dùng cấu trúc transaction ở trên; thay vào đó phần OPERATION luôn là chuỗi cố định ENQUIRY.SELECT — đây là routine chuyên chạy các ENQUIRY và trả về dữ liệu. Cấu trúc:

ENQUIRY.SELECT , (options thường để trống) , USER_INFORMATION , ENQUIRY.NAME , CRITERIA...

Ví dụ lấy danh sách tài khoản của khách hàng 100234 bằng enquiry ACCOUNT.LIST.CUS:

(minh hoạ)

ENQUIRY.SELECT,,INETUSER/pwd123,ACCOUNT.LIST.CUS,CUSTOMER.NO EQ 100234

Đọc:

• ENQUIRY.SELECT — cố định, báo cho OFS "đây là truy vấn".
• (trống) — phần options thường bỏ trống với enquiry.
• INETUSER/pwd123 — user information (giống hệt transaction).
• ACCOUNT.LIST.CUS — tên ENQUIRY, phải là enquiry hợp lệ tồn tại trong application ENQUIRY của T24.
• CUSTOMER.NO EQ 100234 — tiêu chí lọc (selection criteria) truyền vào enquiry.

Response sẽ là tập kết quả của báo cáo — đây là kênh phổ biến để kênh số đọc dữ liệu từ T24 (danh sách tài khoản, sao kê, số dư) mà không cần chọc vào database.

Ví dụ 3 — Subroutine: gọi routine trực tiếp

Loại request thứ ba cho phép OFS gọi thẳng một subroutine (một đoạn logic đã viết trong T24) thay vì chạy một application đầy đủ. Dùng khi cần một tính toán/thao tác đặc thù không map gọn vào một application chuẩn. Ba loại request — transaction, enquiry, subroutine — phủ gần hết nhu cầu tích hợp: ghi giao dịch, đọc báo cáo, và chạy logic tuỳ biến.

Các thành phần triển khai phía T24

Để OFS hoạt động, phía T24 cần một số application cấu hình:

OFS.SOURCE — định nghĩa "kênh vào"

OFS.SOURCE là bản ghi khai báo một nguồn OFS: kênh này nhận request kiểu gì, xử lý ra sao, log thế nào. Các thuộc tính điển hình gồm:

• Kiểu source / cơ chế nhận: nhận qua tSA (T24 Service Agent) / phantom lắng nghe hàng đợi, qua queue (MQ), qua message service, qua thư mục file, hay lời gọi trực tiếp trong tiến trình.
• Đồng bộ (synchronous) vs bất đồng bộ (asynchronous): đồng bộ = gửi request và chờ response ngay (kênh online như internet banking cần điều này); bất đồng bộ = đẩy request vào hàng đợi, T24 xử lý sau, response trả về sau (phù hợp batch, khối lượng lớn, không cần trả lời tức thì).
• Mã hoá/định dạng (native hay XML), quy tắc logging, và mức độ chi tiết ghi lại.

Mỗi kênh tích hợp (internet banking, payment hub, batch loader...) thường có một hoặc nhiều OFS.SOURCE riêng để tách bạch cấu hình và log.

OFS.REQUEST.DETAIL (ORD) — nhật ký request

OFS.REQUEST.DETAIL, thường gọi tắt ORD, lưu lại chi tiết từng request/response cho mục đích logging, audit và debug. Khi một giao dịch từ kênh số bị lỗi, đây là nơi đầu tiên đội vận hành mở ra để xem chính xác message gửi vào là gì và T24 trả về lỗi gì.

EB.PHANTOM và các tiến trình nền

Với các source bất đồng bộ, một phantom (tiến trình nền T24) đóng vai trò "người phục vụ" liên tục lấy request từ hàng đợi ra và đưa vào OFS engine xử lý.

Maker-checker diễn ra thế nào qua OFS

Đây là điểm khiến OFS khác hẳn "ghi thẳng database": OFS tôn trọng nguyên tắc maker-checker (kiểm soát kép) của core banking. Có hai kịch bản:

Kịch bản A — tách input và authorise (an toàn nhất, phổ biến nhất):

1. Gửi message OFS với function I (INPUT). Nếu Version yêu cầu duyệt, bản ghi được tạo ở trạng thái $NAU (Not Authorised / Unauthorised) — nó tồn tại nhưng chưa có hiệu lực, chưa sinh bút toán chính thức. Response trả về @ID của bản ghi vừa tạo.
2. Sau đó, một message OFS thứ hai được gửi với function A (AUTHORISE) và chính @ID đó, dưới quyền một user khác (checker). T24 chuyển bản ghi từ $NAU sang LIVE — lúc này giao dịch mới thực sự có hiệu lực và ghi sổ.

Việc "maker là user gửi message 1, checker là user gửi message 2" phản ánh đúng segregation of duties: hai danh tính khác nhau, đúng như quầy giao dịch thật.

Kịch bản B — input và auth trong một bước:

Nếu chính sách và cấu hình Version cho phép (ví dụ giao dịch giá trị nhỏ, hoặc kênh được tin cậy), có thể dùng option để vừa input vừa auth trong một message duy nhất, bỏ qua bước $NAU. Đây là đánh đổi giữa tốc độ và kiểm soát — thường chỉ mở cho những loại giao dịch rủi ro thấp.

Ngoài ra, cần no of authorisers trong options: nếu đặt là 0 (khi được phép) thì bản ghi input xong là LIVE luôn; nếu >0 thì cần bấy nhiêu lượt duyệt.

Response OFS: đọc kết quả trả về

Message quay ngược lại hệ thống ngoài mang các thông tin then chốt:

• Trạng thái: thành công hay lỗi (thường có mã/cờ báo hiệu ngay đầu response).
• @ID sinh ra: với giao dịch ID tự sinh, đây là cách hệ ngoài biết bản ghi vừa tạo tên gì để tham chiếu/duyệt sau.
• Danh sách lỗi theo field: nếu validation thất bại, response liệt kê field nào lỗi và lỗi gì (ví dụ số dư không đủ, tài khoản không tồn tại). Đây là dữ liệu vàng để kênh số hiển thị thông báo lỗi chính xác cho người dùng thay vì "giao dịch thất bại" chung chung.
• Trạng thái bản ghi (LIVE / $NAU / HLD tuỳ GTS.CONTROL).

Use case thực tế

1. Internet/Mobile banking gửi lệnh chuyển khoản. Khách bấm "Chuyển tiền". Middleware dựng message FUNDS.TRANSFER,/I/PROCESS,... gửi vào một OFS.SOURCE đồng bộ. T24 chạy đủ luồng (số dư, hạn mức, phí, bút toán), commit, trả @ID giao dịch → app hiển thị "Chuyển tiền thành công, mã GD FT2518...". Nếu số dư thiếu, response trả lỗi field → app báo "Số dư không đủ" ngay. Kênh số chỉ là "cánh tay nối dài" của teller, còn logic tiền tệ vẫn nằm gọn trong core.

2. Batch nạp khách hàng (bulk onboarding). Ngân hàng thâu tóm một danh mục khách hàng cần nhập hàng chục nghìn hồ sơ CUSTOMER vào T24. Đội tích hợp sinh ra hàng loạt message OFS (mỗi khách một message CUSTOMER,/I/PROCESS,... với đầy đủ field), đẩy vào một OFS.SOURCE bất đồng bộ qua hàng đợi. Một phantom lần lượt xử lý; những bản lỗi được ghi vào OFS.REQUEST.DETAIL để đội vận hành soát và sửa lại. Cách này vừa nhanh vừa không phá vỡ validation — mỗi khách hàng vẫn qua đúng quy tắc dữ liệu như nhập tay.

3. Payment hub / SWIFT. Lệnh thanh toán đến từ SWIFT hoặc một payment hub được middleware dịch thành message OFS phù hợp (thường là FUNDS.TRANSFER hoặc application thanh toán chuyên biệt) rồi bơm vào T24 — cùng một cơ chế.

Vai trò của OFS trong tích hợp hiện đại

OFS ra đời sớm và là nền móng cho mọi lớp tích hợp phía trên của T24:

• Các web services SOAP đời cũ và các REST API đời đầu của T24 về bản chất chỉ là lớp bọc: nhận request theo chuẩn của chúng, rồi dịch xuống message OFS để đẩy vào engine.
• Các phiên bản Temenos mới hơn bổ sung IRIS và Temenos API (bộ API/microservices hiện đại, RESTful, event-driven) làm lớp tích hợp chính thức, thân thiện hơn với kiến trúc API-first. Nhưng ngay cả khi dùng chúng, khái niệm cốt lõi "một giao dịch phải chạy đúng application qua đúng luồng nghiệp vụ" vẫn không đổi — hiểu OFS là hiểu bản chất phía dưới.

Chúng ta sẽ nói kỹ về IRIS/Temenos API trong bài về tích hợp T24. Ở đây chỉ cần nhớ: OFS là tầng nền, API hiện đại là tầng mặt.

Ghi nhớ

• OFS = Open Financial Service — cổng chuẩn để hệ ngoài đẩy giao dịch và truy vấn vào T24, buộc mọi thứ đi qua đúng luồng nghiệp vụ (validation → auth → accounting) y như nhập tay. Không phải "ghi thẳng database".
• Hai định dạng: Native (chuỗi phân tách bằng dấu phẩy) và XML (Browser XML). Cùng ngữ nghĩa.
• Cấu trúc transaction native 5 phần: OPERATION , OPTIONS , USER INFO , TRANSACTION ID , MESSAGE DATA. Options gói VERSION/FUNCTION/PROCESS (ví dụ /I/PROCESS, /I/VALIDATE), có thể kèm GTS.CONTROL và số người duyệt.
• Ba loại request: Transaction (chạy application), Enquiry (ENQUIRY.SELECT,,user,ENQUIRY.NAME,criteria), Subroutine (gọi routine trực tiếp).
• Triển khai qua OFS.SOURCE (định nghĩa kênh: tSA/queue/message service; đồng bộ vs bất đồng bộ), log qua OFS.REQUEST.DETAIL (ORD).
• Maker-checker qua OFS: input tạo bản ghi $NAU, message thứ hai với function A (dưới user khác) mới đưa lên LIVE; hoặc input+auth một bước nếu được phép.
• Response cho biết thành công/lỗi, @ID sinh ra, và danh sách lỗi field — nền tảng để kênh số báo lỗi chính xác.
• OFS là tầng nền cho web services/REST cũ; IRIS/Temenos API là lớp hiện đại phía trên (xem bài tích hợp).

Liên quan: VERSION & ENQUIRY · Mô hình dữ liệu & $NAU · Tích hợp T24 (IRIS/API)