Trình Ban Giám Đốc · Project UFO

Hệ thống giao dịch chứng khoán
tốc độ cao — UFO

Đề xuất đầu tư hệ thống Front Office / OMS mới thay thế Flex/FDS, đáp ứng khối lượng giao dịch lớn với độ trễ thấp và khả năng mở rộng dài hạn.

Người trình bày: An Nguyễn — Head of IT Services Đề xuất: Triển khai POC đánh giá 3 nhà cung cấp
3
Nhà cung cấp đề xuất POC
10 tỷ ₫
Ngân sách dự kiến (phần cứng + phần mềm)
~4.000
TPS mục tiêu (lệnh/giây)
> 3%
Thị phần mục tiêu

Ước tính phân bổ ngân sách 10 tỷ ₫

[ASSUMED] Ước tính sơ bộ — chưa có báo giá chính thức
~5,5 tỷ ₫
Phần mềm / License OMS
~3 tỷ ₫
Phần cứng / Hạ tầng máy chủ
~1,5 tỷ ₫
Triển khai, tích hợp & dự phòng phát sinh

Tỷ lệ phân bổ cụ thể sẽ được chốt sau khi có báo giá chính thức từ nhà cung cấp được chọn qua POC.

Phần 2 · Đánh giá hiện trạng

Đánh giá hiện trạng hệ thống giao dịch KAFI

Hệ thống hiện tại đang tiệm cận ngưỡng xử lý tối đa, trong khi thị phần giao dịch và hiệu năng vận hành vẫn còn nhiều dư địa cải thiện.

100 TPS
TPS tối đa hệ thống hiện tại
~70 TPS
Đạt được trong T4/2026 (~70% max)
~50K
Tổng lệnh trung bình/ngày (đỉnh)
1%
Thị phần giao dịch hiện tại
50%
Performance hệ thống đạt được

Tổng lệnh trung bình mỗi ngày

~50.000 lệnh/ngày

Mức đỉnh đã ghi nhận của tổng số lệnh xử lý trong một ngày giao dịch.

Đây là khối lượng lệnh trong ngày (daily volume), khác với TPS (tốc độ xử lý tức thời tại thời điểm cao điểm). Cả hai chỉ số đều cho thấy hệ thống hiện tại đang tiệm cận giới hạn xử lý.

TPS thực tế so với ngưỡng tối đa

0 25 50 75 100 TPS TPS tối đa 100 Đạt được (T4/26) ~70 Dư địa còn lại ~30%

Thị phần giao dịch

1%

Thị phần môi giới hiện tại của KAFI trên tổng thị trường.

Performance hệ thống

50%

Mức đáp ứng hiệu năng hệ thống so với công suất thiết kế.

[VERIFY] Số liệu TPS, tổng lệnh/ngày, thị phần và performance do IT Services tổng hợp — cần rà soát cùng bộ phận vận hành trước khi trình bản chính thức.

Phần 3 · Định hướng

Tại sao phải triển khai UFO?

Hệ thống hiện tại đã tiệm cận ngưỡng tối đa và không còn nhiều dư địa để hỗ trợ mục tiêu tăng trưởng thị phần. UFO là bước đầu tư bắt buộc để mở khóa năng lực xử lý mới.

Lý do triển khai

  • Hệ thống hiện tại đã đạt ~70/100 TPS (~70% ngưỡng tối đa) trong T4/2026 — dư địa còn lại không đủ cho các đợt bùng nổ giao dịch.
  • Thị phần giao dịch chỉ ở mức 1% — muốn tăng trưởng, hạ tầng phải đáp ứng khối lượng lệnh lớn hơn nhiều so với hiện nay.
  • Kiến trúc hiện tại gộp chung Back Office và xử lý lệnh, khó mở rộng độc lập và tăng rủi ro vận hành khi tải tăng.

Sau khi triển khai, hệ thống sẽ đạt được

TPS (lệnh/giây) 70 → hiện tại ~4.000 lệnh/giây (~57 lần) Thị phần giao dịch 1% → hiện tại > 3%
SẴN SÀNG BÙNG NỔ

Đáp ứng các đợt tăng đột biến khối lượng giao dịch mà không nghẽn hệ thống.

CHIA TẢI THEO CỤM OMS

UFO cho phép chia khách hàng giao dịch theo từng cụm OMS riêng biệt (Customer Sharding), mở rộng độc lập theo từng phân khúc.

KHẢ NĂNG CHỊU TẢI

POC đánh giá với các nhà cung cấp sẽ đo đạc thực tế thông lượng và độ trễ, kiểm chứng khả năng đáp ứng mục tiêu vận hành ~4.000 lệnh/giây (chi tiết ở Phần 5).

Phần 4 · Chức năng

UFO làm được những gì?

UFO là nền tảng giao dịch chứng khoán hiệu năng cao, kiến trúc module hóa, hỗ trợ cả thị trường Cơ sở và Phái sinh, tích hợp linh hoạt với Back Office và các kênh giao dịch.

Scale-out / Scale-up

Đặc tính nền tảng quan trọng nhất của UFO: không giới hạn số instance/cụm OMS mở rộng — mở rộng ngang theo tải thực tế thay vì bị giới hạn bởi một cụm xử lý duy nhất.

MODULE LÕI

Giao dịch lệnh

HOSE/HNX/UPCOM theo KRX. Đặt/Hủy/Sửa, thỏa thuận, đặt lệnh trước giờ. Cổ phiếu, trái phiếu, ETF, CW.

MODULE LÕI

Quản trị rủi ro

Kiểm tra & phân bổ Pool/Room realtime, cảnh báo vi phạm, bán xử lý auto/manual, force-cover cho phái sinh.

TÍCH HỢP

Đồng bộ Back Office

Đồng bộ đầu ngày & trong ngày với BO (FLEX), realtime hai chiều, tương thích Oracle/Postgres.

VẬN HÀNH

Web Admin

Quản lý tài khoản, tiền, chứng khoán, sổ lệnh; phân quyền theo role (ADMIN, RISK, BO_MAKER/CHECKER...).

MỞ RỘNG

Omnibus & Care Order

Tài khoản tổng cho NĐT nước ngoài; xử lý lệnh lô lớn do Dealer quản lý, chia nhỏ lệnh linh hoạt.

KẾT NỐI

Gateway Sở & API

Kết nối Sở theo KRX (Cơ sở & Phái sinh), chuẩn FIX + RESTful API, kênh Web/Mobile/Home Trading.

Đặc tính kỹ thuật nền tảng (Non-functional)

Event-driven

In-memory, multi-worker, xử lý song song

Scale-out / Scale-up

Không giới hạn số instance mở rộng

VM / K8s / Cloud

Tương thích đa hạ tầng triển khai

Toàn vẹn dữ liệu

Cơ chế transaction, API giám sát sự cố

Phần 5 · Hiệu năng

Khả năng chịu tải sau khi triển khai UFO

Đây là các tiêu chí năng lực mà đợt POC với 3 nhà cung cấp sẽ đo đạc và kiểm chứng thực tế, tham chiếu theo kết quả đánh giá kỹ thuật đã thực hiện trước đó (07/2025).

~4.000
TPS mục tiêu vận hành (lệnh/giây)
Scale-out / Scale-up
Không giới hạn số cụm OMS mở rộng
< 10 ms
Độ trễ mục tiêu cho 80% lệnh
Tối thiểu hoá
Downtime — SLA cụ thể chốt theo hợp đồng

Kết quả tham chiếu từ đánh giá kỹ thuật trước đó (POC 07/2025)

Chỉ sốKết quả đo được
Response time (median)1,27 ms
Thông lượng GW → Sở20.333 lệnh/giây
Thông lượng đỉnh ORS → GW35.543 lệnh/giây
Độ trễ đặt lệnh (80th percentile)5,97 ms
Đồng bộ dữ liệu đầu ngày (100K tài khoản)15 phút

[VERIFY] Số liệu trên từ một đợt đánh giá kỹ thuật trong quá trình RFP, không đại diện cho toàn bộ 3 nhà cung cấp — mỗi nhà cung cấp sẽ được đo đạc lại độc lập trong đợt POC sắp tới.

Tiêu chí POC cần kiểm chứng

  • Thông lượng và độ trễ xử lý lệnh ở tải cao điểm (ATO/ATC).
  • Khả năng mở rộng ngang khi số lượng tài khoản và lệnh tăng.
  • Tính ổn định khi chạy song song với hệ thống Flex/FDS hiện tại.

Chia tải theo cụm OMS

UFO cho phép chia khách hàng giao dịch theo từng cụm OMS độc lập (Customer Sharding) — mỗi cụm phục vụ một nhóm khách hàng riêng, cho phép mở rộng tuyến tính và cô lập sự cố giữa các cụm.

Phần 6 · Kiến trúc

Kiến trúc tổng thể hệ thống

Mô hình kiến trúc tham chiếu cho UFO: từ kênh giao dịch, tầng tích hợp, Front Office / Middle Office / Back Office, tới kết nối Sở, ngân hàng đối tác và VSD.

KAFI Securities System Architecture Overview

[VERIFY] Sơ đồ tham chiếu cho mục đích tích hợp đối tác — cần rà soát cùng đội kiến trúc trước khi dùng làm chuẩn triển khai chính thức.

Phần 7 · Đánh giá vendor

Đánh giá & Lựa chọn nhà cung cấp qua POC

Triển khai POC để đánh giá trực tiếp cả 3 nhà cung cấp theo cùng một phạm vi (scope) thống nhất bên dưới, sau đó chọn ra 1 nhà cung cấp phù hợp nhất để triển khai chính thức.

BƯỚC 1

POC đánh giá trực tiếp 3 nhà cung cấp

Cả 3 nhà cung cấp thực hiện cùng một phạm vi POC thống nhất (bảng bên dưới), đảm bảo kết quả so sánh được trên cùng một chuẩn.

BƯỚC 2

Chọn 1 nhà cung cấp phù hợp nhất

Dựa trên kết quả POC thực đo (đúng/đủ scope, hiệu năng, độ ổn định), chọn ra nhà cung cấp để tiến hành đàm phán và triển khai chính thức.

Phạm vi (Scope) POC — áp dụng chung cho cả 3 nhà cung cấp

Hạng mụcChi tiết
Đồng bộ dữ liệu Back Office ⇄ UFO
Đồng bộ đầu ngày từ BOFlow đồng bộ dữ liệu đầu ngày và trong ngày.
Đồng bộ dữ liệu trong ngày từ BODữ liệu thay đổi về giao dịch tiền, chứng khoán trong BO được đồng bộ lên UFO.
Đồng bộ dữ liệu lệnh trong ngàyCập nhật lệnh từ FO về BO.
Luồng đặt lệnh, xử lý lệnh & Quản trị rủi ro
Luồng đặt lệnhFlow nhận lệnh và gửi lệnh lên Sở, bán CK chờ về.
Luồng xử lý lệnh OMS & SởXử lý dữ liệu lệnh, cập nhật trạng thái lệnh, trạng thái account balance của tài khoản.
Cập nhật lệnh lên hệ thống ngoàiĐẩy dữ liệu lệnh lên Kafka; cho phép hệ thống ngoài đọc Order Event và noti (EMQX...); FIX GW.
Risk rule cho đặt lệnhFlow sức mua tài khoản cash, margin, phái sinh, tài khoản không lưu ký.
Risk ManagementFlow đang áp dụng cho công ty X (quản lý pool, room, force sell, quản lý MR phái sinh), rule chặn đặt lệnh cổ đông lớn, chặn đặt lệnh blacklist.
Giao dịch tiền / chứng khoán với BO
Rút/nộp tiền, chứng khoán, quyền phát sinh từ BOBO cần gửi request hỏi UFO xem đủ tiền hay chứng khoán không để thực hiện rút, tăng tiền/CK/Quyền từ BO.
Kiểm thử phi chức năng
Performance TestChạy performance test, đo latency p95/p99 ở các mức 100/500/1.000 lệnh/giây (gồm lệnh mới, huỷ, sửa); test capacity ở mức 10 triệu lệnh/ngày.
Failover TestTest các kịch bản tắt/bật lại từng module để đo thời gian khôi phục dịch vụ và tính đồng nhất dữ liệu.
Reconcile dữ liệuĐối chiếu dữ liệu 1 ngày giao dịch giữa Client ⇄ OMS ⇄ FSS ⇄ Exchange.
‹
›