Nghiên cứu chuẩn giao thức FIX và ứng dụng xây dựng phần mềm mô phỏng hệ thống khớp lệnh chứng khoán của sở giao dịch chứng khoán hà nội

Vì vậy tác giả đã chọn đề tài “Nghiên cứu chuẩn giao thức FIX và ứng dụng xây dựng phần mềm mô phỏng hệ thống khớp lệnh chứng khoán của Sở giao dịch chứng khoán Hà Nội” với mục tiêu làm

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ ĐỨC HÙNG

NGHIÊN CỨU CHUẨN GIAO THỨC FIX VÀ ỨNG DỤNG XÂY DỰNG PHẦN MỀM MÔ PHỎNG HỆ THỐNG KHỚP LỆNH CHỨNG KHOÁN CỦA SỞ GIAO DỊCH CHỨNG

KHOÁN HÀ NỘI

LUẬN VĂN THẠC SĨ

Hà Nội - 2013

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ ĐỨC HÙNG

NGHIÊN CỨU CHUẨN GIAO THỨC FIX VÀ ỨNG DỤNG XÂY DỰNG PHẦN MỀM MÔ PHỎNG HỆ THỐNG KHỚP LỆNH CHỨNG KHOÁN CỦA SỞ GIAO DỊCH CHỨNG

MỤC LỤC

DANH SÁCH BẢNG BIỂU vii

DANH MỤC CÁC HÌNH VẼ viii

BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT x

MỞ ĐẦU 1

-CHƯƠNG 1: TỔNG QUAN VỀ CÁC GIAO THỨC TRAO ĐỔI DỮ LIỆU TRONG LĨNH VỰC TÀI CHÍNH 3

-1.1 Các giao thức trong đổi dữ liệu trong lĩnh vực tài chính - 3 -

1.2 Giới thiệu về chuẩn giao thức FIX - 4 -

1.2.1 Sơ lược về chuẩn FIX - 4 -

1.2.1 Cấu trúc của một FIX thông điệp - 5 -

CHƯƠNG 2: NGHIÊN CỨU VỀ CHUẨN MESSAGE VÀ GIAO THỨC FIX ĐANG ĐƯỢC SỬ DỤNG TẠI SỞ GIAO DỊCH CHỨNG KHOÁN HÀ NỘI 6 -2.1 Mô hình giao tiếp giữa CTCK và HNX - 6 -

2.1.1 Sơ đồ giai đoạn thiết lập kết nối - 7 -

2.1.2 Sơ đồ giai đoạn truyền dữ liệu - 8 -

2.1.3 Sơ đồ giai đoạn đóng kết nối - 9 -

2.1.4 Một số quy định khi trao đổi dữ liệu của giao thức - 9 -

2.2 Quy trình thực hiện trao đổi dữ liệu giữa CTCK và HNX - 10 -

2.2.1 Danh mục các quy trình - 10 -

2.2.2 Chi tiết các quy trình liên quan đến kết nối - 12 -

2.2.2.2 Quy trình đóng kết nối - 13 -

2.2.3 Chi tiết các quy trình liên quan đến nghiệp vụ - 13 -

2.2.3.1 Quy trình đặt lệnh - 13 -

2.2.3.2 Quy trình hủy lệnh - 14 -

2.2.3.3 Quy trình sửa lệnh - 14 -

2.2.3.4 Quy trình đặt lệnh quảng cáo - 14 -

2.2.3.5 Quy trình xóa lệnh quảng cáo chưa thực hiện - 15 -

2.2.3.6 Quy trình đặt lệnh thỏa thuận của khách hàng cùng công ty - 15 -

2.2.3.7 Quy trình đặt lệnh thỏa thuận của khách hàng khác công ty - 15 -

2.3 Đặc tả các thông điệp trao đổi dữ liệu giữa CTCK và HNX - 16 -

2.3.1 Danh mục các thông điệp - 16 -

2.3.2 Danh mục các TAG sử dụng trong FIX - 18 -

2.3.3 Đặc tả chi tiết các thông điệp - 26 -

2.3.3.1 Thông điệp Logon - 26 -

2.3.3.2 Thông điệp Reject - 27 -

2.3.3.3 Thông điệp NewOrderSingle - 27 -

2.3.3.4 Thông điệp OrderCancelRequest - 28 -

2.3.3.5 Thông điệp OrderCancelReplaceRequest - 29 -

CHƯƠNG 3: XÂY DỰNG PHẦN MỀM MÔ PHỎNG HỆ THỐNG KHỚP LỆNH TẠI SỞ GIAO DỊCH CHỨNG KHOÁN HÀ NỘI – HNX 30

-3.1 Mô tả bài toán - 30 -

3.2 Tổng quan nghiệp vụ giao dịch chứng khoán tại HNX - 30 -

3.2.1 Phiên giao dịch - 31 -

3.2.2 Nguyên tắc khớp lệnh - 31 -

3.2.2.1 Nguyên tắc khớp lệnh định kỳ - 31 -

3.2.2.2 Nguyên tắc khớp lệnh liên tục - 32 -

3.2.3 Các loại lệnh giao dịch - 32 -

3.2.3.1 Lệnh giới hạn (LO) - 32 -

3.2.3.2 Lệnh thị trường (MP) - 33 -

3.2.3.3 Lệnh ATO/ATC - 33 -

3.3 Phân tích yêu cầu - 34 -

3.3.1 Yêu cầu phần mềm - 34 -

3.3.2 Xây dựng mô hình Use-Case - 35 -

3.3.2.1 Tác nhân - 35 -

3.3.2.2 Mô hình - 35 -

3.4 Thiết kế kiến trúc hệ thống - 38 -

3.4.1 Mô hình tương tác dữ liệu CTCK và HNX - 38 -

3.4.2 Kiến trúc xử lý dữ liệu - 41 -

3.4.3 Kiến trúc phần mềm mô phỏng - 44 -

3.5 Thiết kế cơ sở dữ liệu - 46 -

3.5.1 Mô hình quan hệ dữ liệu - 46 -

3.5.2 Chi tiết các bảng dữ liệu - 46 -

3.5.2.1 StockPrice: Thông tin chứng khoá n - 46 - 3.5.2.2 OrderSysStat: Thông tin trạng thái thị trường - 48 -

3.5.2.3 SOrder: Thông tin lệnh bán - 48 -

3.5.2.4 BOrder: Thông tin lệnh mua - 49 -

3.5.2.5 HistOrders: Bảng thông tin lịch sử lệnh - 50 -

3.5.2.6 OrderCancelRequest: Thông tin yêu cầu hủy lệnh báo giá - 51 -

3.5.2.7 OrderReplaceRequest: Thông tin yêu cầu sửa lệnh báo giá - 52 -

3.5.2.8 Advertisement: Thông tin lệnh quảng cáo - 52 -

3.5.2.9 ClientInfo: Thông tin về máy trạm kết nối đến HNX - 53 -

3.5.2.10 Order_PT: Thông tin lệnh giao dịch thỏa thuận - 53 -

3.5.2.10 MatchInfo: Chi tiết khớp lệnh của hệ thống - 54 -

3.6 Thiết kế chức năng - 54 -

3.6.1 Xử lý đặt lệnh báo giá - 54 -

3.6.1.1 Một số thực thể liên quan - 54 -

3.6.1.2 Sơ đồ giải thuật - 56 -

3.6.2 Hủy lệnh báo giá - 57 -

3.6.2.1 Một số thực thể liên quan - 57 -

3.6.2.2 Sơ đồ giải thuậ t - 57 - 3.6.3 Sửa lệnh báo giá - 58 -

3.6.3.1 Một số thực thể liên quan - 58 -

3.6.3.2 Sơ đồ giải thuật - 59 -

CHƯƠNG 4: CÀI ĐẶT THỬ NGHIỆM VÀ ĐÁNH GIÁ HỆ THỐNG 59

-4.1 Kết quả xây dựng phần mềm - 60 -

4.1.1 Màn hình chính - 60 -

4.1.2 Đặt lệnh báo giá - 61 -

4.1.3 Khớp lệnh thủ công - 61 -

4.1.4 Sửa lệnh - 62 -

4.1.5 Đặt lệnh quảng cáo - 62 -

4.2 Kịch bản thử nghiệm - 63 - 4.2.1 Mục tiêu thử nghiệm - 63 -

4.2.2 Kịch bản - 63 -

4.3 Đánh giá kết quả - 66 -

KẾT LUẬN 68

TÀI LIỆU THAM KHẢO 69

-DANH SÁCH BẢNG BIỂU

Bảng 2 1 Danh sách các quy trình giao dịch 12

Bảng 2 2 Danh sách các thông điệp FIX 18

Bảng 2 3 Danh mục các TAG sử dụng trong FIX 26

Bảng 2 4 Danh mục các trường thông điệp đăng nhập 26

Bảng 2 5 Danh mục các trường thông điệp từ chối 27

Bảng 2 6 Danh mục các trường của thông điệp đặt lệnh báo giá 28

Bảng 2 7 Danh mục các trường thông điệp hủy lệnh 28

-Bảng 2 8 Danh mục các trường thông điệp sửa lệnh - 29 -

Bảng 3 1 Danh sách các phiên giao dịch 31

Bảng 3 2 Thông tin chứng khoán 47

Bảng 3 3 Thông tin trạng thái thị trường 48

Bảng 3 4 Thông tin lệnh bán 49

Bảng 3 5 Thông tin lệnh mua 50

Bảng 3 6 Bảng thông tin lịch sử lệnh 51

Bảng 3 7 Thông tin yêu cầu hủy lệnh báo giá 52

Bảng 3 8 Thông tin yêu cầu sửa lệnh báo giá 52

Bảng 3 9 Thông tin lệnh quảng cáo 52

Bảng 3 10 Thông tin về máy trạm kết nối đến HNX 53

Bảng 3 11 Thông tin lệnh giao dịch thỏa thuận 53

Bảng 3 12 Chi tiết khớp lệnh của hệ thống 54

Bảng 3 13 Các phươgn thức lớp StockOrderDAL 55

Bảng 3 14 Các phương thức lớp StockExchangeApp 56

-DANH MỤC CÁC HÌNH VẼ

Hình 2 1 Mô hình giao tiếp CTCK và HNX 6

Hình 2 2 Sơ đồ giai đoạn thực hiện kết nối 7

Hình 2 3 Sơ đồ giai đoạn truyền dữ liệu 8

Hình 2 4 Sơ đồ giai đoạn đóng kết nối 9

Hình 2 5 Quy trình kết nối 12

Hình 2 6 Quy trình đóng kết nối 13

Hình 2 7 Quy trình đặt lệnh báo giá 13

Hình 2 8 Quy trình hủy lệnh 14

Hình 2 9 Quy trình sửa lệnh báo giá 14

Hình 2 10 Quy trình đặt lệnh quảng cáo 15

Hình 2 11 Quy trình xóa lệnh quảng cáo chưa thực hiện 15

Hình 2 12 Quy trình đặt lệnh thỏa thuận cùng công ty 15

Hình 2 13 Đặt lệnh thỏa thuận khác công ty Bên mua đồng ý 16

-Hình 2 14 Đặt lệnh thỏa thuận khác công ty - Bên mua không đồng ý - 16 -

Hình 3 1 UC Mô hình tổng quan chức năng 36

Hình 3 2 UC Quản lý kết nối 37

Hình 3 3 UC Xử lý lệnh 37

Hình 3 4 UC Quản lý thông tin thị trường 38

Hình 3 5 Mô hình trao đổi dữ liệu giữa CTCK và HNX thực tế 39

Hình 3 6 Kiến trúc xử lý dữ liệu phần mềm mô phỏng 41

Hình 3 7 Kiến trúc phần mềm mô phỏng 45

Hình 3 8 Mô hình quan hệ dữ liệu 46

Hình 3 9 Sơ đồ khối xử lý đặt lệnh báo giá 57

Hình 3 10 Sơ đồ khối hủy lệnh báo giá 58

-Hình 3 11 Sơ đồ khối sửa lệnh báo giá - 59 -

Hình 4 1 Màn hình giao diện chính 60

Hình 4 2 Màn hình đặt lệnh báo giá 61

Hình 4 3 Màn hình khớp lệnh thủ công 62

Hình 4 4 Sửa lệnh báo giá 62 Hình 4 5 Đặt lệnh quảng cáo - 63 -

DBMS : Hệ quản trị cơ sở dữ liệu (Database Management Systems)

MỞ ĐẦU

Lý do chọn đề tài

Như chúng ta thấy, với sự phát triển mạnh mẽ về CNTT thì các hệ thống tin học nói chung và phần mềm cho lĩnh vực tài chính nói riêng đang ngày càng hiện đại bên cạnh sự đa dạng và phong phú cả về nghiệp vụ và công nghệ Với các hệ thống tài chính lớn phức tạp thường sử dụng nhiều phần mềm khác nhau tương tác với nhau, hoặc giữa các hệ thống tài chính của các doanh nghiệp giao tiếp với nhau Khi đó bài toán tích hợp giữa các hệ thống tin học tài chính khác nhau sẽ trở nên phức tạp và cấp thiết

Trước đây, khi phát triển các phần mềm tài chính các nhà cung cấp phần mềm thường tự định nghĩa giao thức riêng của họ Khi xuất hiện nhu cầu tích hợp với một hệ thống của đơn vị khác thì 2 bên phải ngồi với nhau để thống nhất lại giao thức giao tiếp giữa 2 hệ thống Phương pháp này đơn giản và hiệu quả khi số lượng phần mềm cần tích hợp là nhỏ và phần mềm các bên hoạt động ổn định Nhưng sẽ gặp hạn chế và trở nên cứng nhắc khi số lượng nhu cầu tích hợp tăng với nhiều loại phần mềm khác nhau

và có sự thay đổi nâng cấp không đồng đều Cứ mối khi có thêm một hệ thống cần tích hợp thì lại phải ngổi với nhau để điều chỉnh giao thức

Một giao thức chuẩn chung để có thể tích hợp với tất các các phần mềm sẽ giúp đơn giản và giảm chi phí rất nhiều quá trình tích hợp FIX (Financial Infomation eXchange) là một chuẩn thông điệp và giao thức chung để đáp ứng nhu cầu này trong

lĩnh vực tài chính Vì vậy tác giả đã chọn đề tài “Nghiên cứu chuẩn giao thức FIX và

ứng dụng xây dựng phần mềm mô phỏng hệ thống khớp lệnh chứng khoán của Sở giao dịch chứng khoán Hà Nội” với mục tiêu làm rõ về giao thức hiện đại này, đồng

thời ứng dụng FIX xây dựng một phần mềm ứng dụng trong thực tế phục vụ giao đoạn kiểm thử các phần mềm giao dịch chứng khoán tại Việt Nam

Mục đích nghiên cứu

Đề tài tập trung nghiên cứu về giao thức FIX là giao thức quốc tế trong việc giao tiếp giữa các hệ thống tài chính Ở Việt Nam FIX đang được áp dụng là giao thức trao đổi thông tin giữa các CTCK và trung tâm khớp lệnh - Sở giao dịch chứng khoán Hà Nội (HNX) Sau khi đã nghiên cứu về FIX tác giả sẽ xây dựng một hệ thống mô phỏng

hệ thống khớp lệnh tại HNX, hệ thống sẽ là phần mềm hỗ trợ đắc lực để thử nghiệm các giao dịch khi xây dựng các phần mềm chứng khoán tại thị trường chứng khoán Việt Nam

Đối tƣợng và phạm vi nghiên cứu

chính quốc tế và tại thị trường chứng khoán Việt Nam

 Phạm vi nghiên cứu:

• Nghiên cứu đặc tả thông điệp FIX

• Nghiên cứu về quy trình trao đổi dữ liệu giữa các CTCK và sở giao dịch chứng khoán Hà Nội (HNX)

Ý nghĩa khoa học và thực tiễn của đề tài

 Nghiên cứu đặc tả thông điệp FIX và phương thức trao đổi thông tin giữa các hệ

thống dựa trên FIX

 Nghiên cứu quy trình và nguyên tắc thực hiện trao đổi dữ liệu giữa công ty

chứng khoán và sở giao dịch chứng khoán Hà Nôi (HNX)

 Xây dựng phần mềm mô phỏng hệ thống khớp lệnh của HNX

 Xây dựng ứng dụng máy trạm phía công ty chứng khoán thực hiện kết nối và trao

đổi dữ liệu với HNX theo quy định hiện hành tại Việt Nam

 Ứng dụng của đề tài có thể áp dụng cho việc phát triển và kiểm thử các phần

mềm giao dịch chứng khoán sử dụng FIX

Kết cấu của luận văn

Ngoài phần mở đầu, danh mục ký hiệu viết tắt, mục lục, danh mục tài liệu tham khảo, phụ lục và phần kết luận, nội dung của luận văn gồm ba chương

Chương 1 Tổng quan về các giao thức trao đổi dữ liệu trong lĩnh vực tài chính

Chương này giới thiệu tổng quan các giao thức trao đổi dữ liệu giữa các hệ thống tài chính So sánh các giao thức với FIX

Chương 2 Nghiên cứu chuẩn thông điệp và giao thức FIX đang được sử dụng

tại Sở giao dịch chứng khoán Hà Nội

Chương này tập trung làm rõ nguyên lý của chuẩn giao thức FIX và nghiệp vụ trao đổi dữ liệu tại sàn giao dịch chứng khoán Hà Nội

Chương 3 Xây dựng phần mềm mô phỏng hệ thống khớp lệnh tại Sở giao dịch

chứng khoán Hà Nội

Dựa trên cở sở lý thuyết về FIX và nghiệp vụ giao dịch chứng khoán tại Việt Nam và quy địch giao dịch tại HNX, luận văn thiết kế phần mềm mô phỏng hệ thống khớp lệnh tại HNX nhằm phục vụ quá trình kiểm thử phần mềm giao dịch chứng khoán

Chương 4 Cài đặt thử nghiệm và đánh giá hệ thống

Chương này trình bày kết quả cài đặt thử nghiệm, các kịch bản thử nghiệm và đánh giá kết quả

CHƯƠNG 1: TỔNG QUAN VỀ CÁC GIAO THỨC TRAO ĐỔI DỮ LIỆU

TRONG LĨNH VỰC TÀI CHÍNH

1.1 Các giao thức trong đổi dữ liệu trong lĩnh vực tài chính

Trước đây để tích hợp các hệ thống tin học trong lĩnh vực tài chính, các công ty phát triển phần mềm tài chính thường sử dụng một trong 2 giải pháp hoặc kết hợp các giải pháp sau:

Giải pháp 1 Tự định nghĩa một giao thức phù hợp với phần mềm và nghiệp vụ

hiện có

Ưu điểm: Với cách tạo ra một giao thức riêng sẽ có ưu điểm là đơn giản và tối ưu

về hiệu năng, các thông điệp được tạo ra vừa đủ dữ liệu sát với nghiệp vụ mà phần mềm đáp ứng

Nhược điểm: Nhược điểm lớn nhất của kiểu giao thức này là mang tính đặc thù,

chỉ có phần mềm của nhà cung cấp đó sử dụng được, do đó chỉ có thể sử dụng để giao tiếp giữa các phần mềm do công ty đó cung cấp Nếu muốn tích hợp với phần mềm bên thứ 3 thì phải chỉnh sửa lại giao thức Khó khăn để tích hợp với nhiều loại phần mềm khác nhau

Giải pháp 2 Áp dụng một số chuẩn mã hóa thông điệp để định nghĩa giao thức

như chuẩn thông điệp ISO 8583, ISO 20022,

Giải pháp này được đưa ra để khắc phục các nhược điểm của giải pháp 1 với mong muốn định nghĩa các thông điệp chuẩn trong lĩnh vực tài chính để đơn giản quá trình tích hợp giữa các hệ thống

Ưu điểm: Giải pháp này đã chuẩn hóa được thông điệp trao đổi thông tin giữa

các hệ thống tích hợp giúp đơn giản hơn khi xây dựng giao thức tích hợp Hiện nay hầu hết các hệ thống Core Banking lớn đều hỗ trợ giải pháp này như T24, Intellect, Korebank, Symbols,

Nhược điểm: Mặc dù đã đưa ra được chuẩn mã hóa các thông điệp nhưng chưa

đưa ra được các quy tắc về giao thức, nên khi xây dựng giải pháp tích hợp các giao thức được tạo ra từ ISO thông điệp vẫn có thể khác nhau Do đó khi số lượng phần mềm cần tích hợp gia tăng vẫn có thể phải chỉnh sửa giao thức

Ngày nay, khi mà số lượng phần mềm tài chính gia tăng về số lượng, đa dạng về thể loại phong phú về công nghệ nếu sử dụng 1 trong 2 giải pháp trên sẽ hạn chế nhiều khi phải tích hợp với nhiều hệ thống khác nhau Do đó cần phải có những quy định về chuẩn thông điệp và giao thức chung khi trao đổi dữ liệu tài chính Bằng cách định nghĩa sẵn tất cả các loại thông tin có thể dùng khi trao đổi thông tin giữa các hệ thống tài chính FIX ra đời như một chuẩn thông điệp giao tiếp giữa các phần mềm tài chính

với nhau Bên cạnh việc định nghĩa chuẩn thông điệp FIX còn quy định về các thức bắt tay giữa các bên, các thức truyền nhận dữ liệu, duy trì kết nối và đảm bảo tính toàn vẹn

dữ liệu khi trao đổi Có thể nói FIX là một chuẩn giao thức chung cho việc trao đổi dữ liệu giữa các hệ thống tài chính đã khắc phục được nhược điểm của các giao thức truyền thống

1.2 Giới thiệu về chuẩn giao thức FIX

1.2.1 Sơ lược về chuẩn FIX

Trên thế giới hiện nay FIX đang là chuẩn thông điệp và giao thức quốc tế phổ thông cho việc giao tiếp giữa các hệ thống tài chính, đặc biệt là cho các lĩnh vực giao dịch thị trường như chứng khoán, vàng, tiền tệ, giao dịch hàng hóa, Hầu hết, các Sàn giao dịch hiện đại trên thế giới đều sử dụng FIX cho việc trao đổi với các hệ thống liên quan phục vụ cho hoạt động công nghệ thông tin Việc sử dụng chuẩn và giao thức quốc

tế tạo ra nhiều thuận lợi cho việc triển khai, tích hợp hệ thống sau này và còn phục vụ nhu cầu mở rộng kết nối với các hệ thống tài chính khác trên thế giới

Những thuận lợi chính khi lựa chọn FIX là chuẩn dữ liệu trao đổi với các hệ thống của thành viên như sau:

 Đây là chuẩn quốc tế và tương đối phổ thông, nên các qui định về cấu trúc

dữ liệu, cách thức trao đổi hoàn toàn chuẩn hóa và có nhiều tài liệu hỗ trợ cho việc tích hợp hệ thống giữa Sở và CTCK

 Chuẩn dữ liệu này tường minh và dễ hiểu

 Có nhiều đơn vị thứ ba đã phát triển sẵn các framework cho chuẩn dữ liệu này, HNX và CTCK sẽ không mất nhiều thời gian và nguồn lực để phát triển các framework đó mà có thể tận dụng và sử dụng ngay, mặc dù sẽ phải trả thêm một số chi phí khi mua các framework này

 Các hệ thống của các công ty chứng khoán hiện đại đều hỗ trợ sẵn chuẩn FIX, vì thế các CTCK khi mua các phần mềm giao dịch chứng khoán này cũng sẽ dễ dàng tích hợp với HNX

 Chuẩn FIX được nhiều Sở giao dịch trên thế giới và các đơn vị tài chính khác trên thế giới ứng dụng vì thế Sở giao dịch chứng khoán Hà Nội cũng sẽ dễ dàng tích hợp với các hệ thống đó

Chuẩn FIX có rất nhiều phiên bản từ FIX 4.0, FIX 4.1, FIX 4.2, FIX 4.3, FIX 4.4, FIX 5.0 Hiện nay FIX 4.4 đang được sử dụng rộng rãi nhất và tại Việt Nam cũng đang sử dụng chuẩn này Trong phạm vi luận văn này chúng ta chỉ đề cập đến phiên bản FIX 4.4

1.2.1 Cấu trúc của một FIX thông điệp

Mỗi thông điệp FIX bao gồm nhiều trường và được chia thành 3 phần chính:

 Message Header: : Định nghĩa loại thông điệp, độ dài, người gửi, người nhận,

thời gian gửi, số thứ tự,

 Message Body: Chứa nội dung thông tin thông điệp

 Message Trailer: Chứa thông tin kiểm tra toàn vẹn dữ liệu trên đường truyền

(chữ ký số, checksum, )

Cấu trúc mỗi trường của mỗi thông điệp FIX có dạng sau:

<TAG>=<VALUE><DELIMITER>

Trong đó:

<TAG>: Là mã số để xác định trường: có thể là số hoặc tên tường minh

<VALUE>: Là giá trị của trường

<DELIMITER>: Là dấu ngăn cách giữa các trường, đây là ký tự đặc biệt có mã

ASCII =1

Ví dụ về một thông điệp FIX:

16:12:27.374^56=HNX^369=0^553=hungld^554=123456^10=247.

8=FIX.4.4^9=77^35=A^34=1^49=052^52=20130919-CHƯƠNG 2: NGHIÊN CỨU VỀ CHUẨN MESSAGE VÀ GIAO THỨC FIX ĐANG ĐƯỢC SỬ DỤNG TẠI SỞ GIAO DỊCH CHỨNG KHOÁN HÀ NỘI

2.1 Mô hình giao tiếp giữa CTCK và HNX

Hiện nay các CTCK giao tiếp với sở giao dịch chứng khoán theo mô hình Máy trạm/Máy chủ, trong đó CTCK đóng vai trò làm Máy trạm và HNX đóng vai trò Máy chủ

Thông tin thị trường

Hình 2 1 Mô hình giao tiếp CTCK và HNX Thông tin trao đổi giữa CTCK và HNX là các gói tin có cấu trúc gồm 2 phần:

Trong đó:

 Hearder: có độ dài 4 byte, lưu độ dài của dữ liệu “Data” dưới dạng binary

 Data content: nội dung dữ liệu gửi dưới dạng string có độ dài tùy ý Quy ước ta

sẽ gọi phần Data là thông điệp (message) Thông điệp có cấu trúc tuân theo chuẩn thông điệp FIX

 Quá trình trao đổi dữ liệu giữa Máy trạm và máy chủ thông qua FIX sẽ trải qua 3 giai đoạn

 Thiết lập kết nối: Trong giai đoạn này máy trạm sẽ gửi yêu cầu kết nối đến máy

chủ Máy chủ sẽ kiểm tra để xác thực thông tin gửi đến và khôi phục dữ liệu (nếu cần), nếu thỏa mãn các điều kiện kết nối thì một kênh kết nối sẽ được thiết lập giữa Máy trạm

và Server Trong trường hợp cần khôi phục dữ liệu ngay sau khi thực hiện kết nối, máy chủ sẽ gửi thông báo chấp nhận kết nối và yêu cầu máy trạm gửi dữ liệu khôi phục

 Truyền dữ liệu: Sau khi máy chủ đồng ý kết nối và cho phép gửi dữ liệu lên, 2

bên có thể trao đổi dữ liệu Việc trao đổi dữ liệu diễn ra theo 2 chiều nhưng trong giới hạn của buffer size Buffer size là sự chênh lệch giữa số thông điệp lệnh mà Máy trạm gửi cho HNX và số lệnh mà HNX xử lý xong

 Kết thúc kết nối: Khi muốn kết thúc kết nối, cả 2 bên đều có quyền gửi yêu cầu

kết thúc kết nối cho bên kia Trong điều kiện bình thường thì phải đợi bên kia chấp nhận kêt thúc thì kết nối đó mới bị ngắt Tuy nhiên, trong các trường hợp đặc biệt (lỗi đường truyền, hoặc hết giờ, hoặc máy trạm vi phạm quy chế ) thì có thể ngắt kết nối mà không cần sự chấp thuận

2.1.1 Sơ đồ giai đoạn thiết lập kết nối

SERVER (HNX) CLIENT (CTCK)

Gửi LogonMessage

Đúng FIX massage chưa?

User/pass hợp lệ Y

Sequence CTCK = HNX Last Msg Seq Num Processed ?

Y

Gửi RejectMessage

Gửi

N

Gửi lại LogonMessage

(Đúng user/pass)

Sequence CTCK < HNX Last Msg Seq Num Processed ?

N

Gửi LogonMessage (Thành công)

N

Gửi ResendMessage N Thiết lập kết nối

Gửi lại dữ liệu

Gửi SequenceReset Message

Gửi LogoutMessage (Đóng kết nối) Kết thúc session

Y

Y

Gửi LogonMessage (Thành công)

2.1.2 Sơ đồ giai đoạn truyền dữ liệu

SERVER (HNX) CLIENT (CTCK)

Gửi DataMessage

Đúng FIX massage?

Gửi đúng SenderID?

Y

Sequence CTCK = HNX Last Msg Seq Num Processed + 1

Y

Gửi RejectMessage

Gửi

N

Gửi lại DataMessage (Đúng SenderID)

Sequence CTCK < HNX Last Msg Seq Num Processed + 1

N Gửi

ResendMessage

N Gửi lại dữ liệu

Gửi SequenceReset Message

Start

CTCK reset lại sequence và tiếp

tục gửi message

Y

Y

Gửi HeartBeat Message

2.1.3 Sơ đồ giai đoạn đóng kết nối

SERVER (HNX) CLIENT (CTCK)

Gửi LogoutMessage

Đúng FIX massage

Sequence CTCK = HNX Last Msg Seq Num Processed ?

Gửi RejectMessage N

Sequence CTCK < HNX Last Msg Seq Num Processed ?

N Gửi

ResendMessage

N

Gửi lại LogoutMessage

(đúng sequence)

Gửi SequenceReset Message

Gửi LogoutMessage (Đóng kết nối) Kết thúc session

Y

Y

N

Hình 2 4 Sơ đồ giai đoạn đóng kết nối

2.1.4 Một số quy định khi trao đổi dữ liệu của giao thức

2.1.4.1 Quy định đảm bảo tính tuần tự của thông điệp

Khi gửi thông điệp trao đổi giữa 2 hệ thống, để đảm bảo tuần tự không bị duplicate FIX sử dụng phương pháp đánh dấu thông điệp thông qua số thứ tự tại trường

34 là số sequense Theo đó mỗi khi CTCK gửi 1 thông điệp cho HNX thì số sequense lại tăng lên 1 và ngược lại khi HNX gửi thông điệp cho CTCK thì sequense lại tăng lên

1

2.1.4.2 Khôi phục dữ liệu

Căn cứ vào giá tri trường 34 của thông điệp gửi đến mà bên nhận có thể xác định đươc dữ liệu đang bị thiếu hoặc thừa Khi nhận được thông điệp từ CTCK có số thứ tự lớn hơn số thứ tự mà HNX đang chờ nhận, HNX sẽ không công nhận thông điệp này, đồng thời gửi thông điệp yêu cầu gửi công ty chứng khoán phải gửi thông điệp theo

đúng số thứ tự

Khi CTCK nhận được thông điệp từ HNX với số thứ tự cao hơn, CTCK vẫn tiếp tục nhận các thông điệp tiếp theo Đồng thời gửi thông điệp yêu cầu HNX gửi lại các thông điệp bị mất HNX sẽ gửi lại các thông điệp bị mất

Lưu ý: Việc phân biệt thông điệp thông thường và msssage gửi lại thông qua

trường PossDupFlag (Tag 43) Khi gửi lại các thông điệp bị mất thì trường PossDupFlag (Tag 43) sẽ có giá trị Y

2.1.4.3 Duy trì kết nối

Khi gửi thông điệp Logon để thiết lập session kết nối với HNX, CTCK gửi giá trị trong Tag 108 (HeartBtInt) là chu kỳ (tính bằng giây) gửi dữ liệu kiểm tra kết nối Giá trị này là do CTCK tự đặt nhưng phải lớn hơn 15s, nhỏ hơn 100 Giá trị khuyến cáo mà HNX đưa ra là 30s

Khi không có dữ liệu gửi cho HNX, CTCK phải gửi thông điệp TestRequest theo chu kỳ (giá trị trong Tag 108) Khi đó HNX sẽ gửi trả lại thông điệp Heartbeat để trả lời Nếu có dữ liệu gửi đều đều thì CTCK không phải gửi TestRequest

Nếu trong khoảng thời gian là bằng 2 lần HeartBtInt mà HNX hoặc CTCK không nhận được thông điệp thì 2 bên sẽ tự động đóng kết nối

2.2 Quy trình thực hiện trao đổi dữ liệu giữa CTCK và HNX

2.2.1 Danh mục các quy trình

Hiện nay nghiệp vụ trao đổi dữ liệu giữa các CTCK và HNX thông qua 20 quy trình thực hiện, trong đó có 5 quy trình liên quan đến thực hiện kết nối dữ liệu và 15 quy trình liên quan đến trao đổi thông tin nghiệp vụ

1 Quy trình kết nối Mô tả các bướcthiết lập kết nối giữa Gateway của

3 Quy trình reset lại số thứ tự

Mô tả các bước HNX yêu cầu CTCK reset lại số thứ tự khi số thứ tự của CTCK < số thứ tự của HNX

4 Quy trình gửi TestRequest để

kiểm tra kết nối

Mô tả các bước CTCK gửi TestRequest để kiểm tra trạng thái kết nối

5 Quy trình đóng kết nối Mô tả việc đóng kết nối giữa Gateway của CTCK

dựa trên lệnh quảng cáo

Mô tả các bước đặt lệnh thỏa thuận của 2 khách hàng cùng công ty dựa trên lệnh quảng cáo

dựa trên lệnh quảng cáo

Mô tả các bước đặt lệnh thỏa thuận của 2 khách hàng khác công ty dựa trên lệnh quảng cáo

10

Quy trình hủy lệnh thỏa

thuận của khách hàng cùng

công ty (Cancel Deal 1 Firm)

Mô tả các bước hủy lệnh thỏa thuận của 2 khách hàng cùng công ty

11

Quy trình hủy lệnh thỏa

thuận của khách hàng khác

công ty (Cancel Deal 2 Firm)

Mô tả các bước hủy lệnh thỏa thuận của 2 khách hàng khác công ty

12 Quy trình xóa lệnh thỏa thuận

đã thực hiện của khách hàng

cùng công ty

hàng cùng công ty

14 Quy trình yêu cầu gửi thông

tin thị trường Mô tả các bước gửi yêu cầu thông tin thị trường

15 Quy trình yêu cầu gửi thông

tin chứng khoán

Mô tả các bước yêu cầu gửi thông tin chứng khoán

Bảng 2 1 Danh sách các quy trình giao dịch

2.2.2 Chi tiết các quy trình liên quan đến kết nối

Các thông điệp tại lớp session sẽ sử dụng để thiết lập và duy kết nối giữa Máy trạm và Server Dưới đây là 2 quy trình cơ bản

2.2.2.1 Quy trình kết nối

Sơ đồ thực hiện

Logon (MsgType=A, MsgSeqNum =0)

Logon (MsgType=A, MsgSeqNum =0) Reject (MsgType=3, MsgSeqNum =0)

Hình 2 5 Quy trình kết nối

Mô tả:

Khi Máy trạm (CTCK) muốn kết nối đến Server (HNX) sẽ phải gửi thông điệp Logon

 MsgSeqNum = 0 nếu là kết nối đầu ngày

 MsgSeqNum = số thứ tự của thông điệp cuối cùng mà CTCK thành công đến HNX nếu là kết nối lại

 Nếu CTCK gửi thông điệp Logon có MsgSeqNum cao hơn MsgSeqNum mong đợi của HNX thì HNX vẫn đồng ý cho kết nối thành công nhưng sau đó sẽ gửi thông điệp ResendRequest yêu cầu gửi lại dữ liệu cho HNX

HNX trả lại thông điệp Logon khi đồng ý kết nối và trả về Reject nếu từ chối

2.2.2.2 Quy trình đóng kết nối

Sơ đồ thực hiện:

Logout (MessageType=5, MsgSeqNum =M

Logout (MessageType=5, MsgSeqNum =N

Hình 2 6 Quy trình đóng kết nối

Mô tả:

Khi muốn kết thúc kết nối sẽ gửi thông điệp logout, bên kia nếu đồng ý kết thúc kết nối

sẽ gửi lại thông điệp logout, và kết nối sẽ bị đóng

2.2.3 Chi tiết các quy trình liên quan đến nghiệp vụ

Phần này sẽ trình bày một số quy trình chính liên quan đến nghiệp vụ

ExecutionReport (MsgType=8, ExecType=3, OrdStatus=2(Lệnh khớp))

Reject (MsgType=3, SessionRejectReason =‟Mã lỗi reject‟)

Lệnh hợp lệ

Lệnh ko hợp lệ

ExecutionReport (MsgType=8, ExecType=4, OrdStatus=4(Lệnh hủy))

Hình 2 7 Quy trình đặt lệnh báo giá

Mô tả:

Khi muốn đặt lệnh báo giá, CTCK gửi thông điệp đặt lệnh (35=D) tới HNX Khi nhận được thông điệp đặt lệnh thì HNX sẽ kiểm tra các điều kiện thông điệp, nếu hợp lệ

sẽ gửi phản hồi bằng thông điệp ExecutionReport, nếu không hợp lệ sẽ gửi thông điệp Reject

2.2.3.3 Quy trình sửa lệnh

Sơ đồ thực hiện:

OrderCancelReplaceRequest(MessageType=G)

ExecutionReport(8, ExecType=4, OrdStatus=3(Thành công))

Hình 2 9 Quy trình sửa lệnh báo giá

2.2.3.4 Quy trình đặt lệnh quảng cáo

Sơ đồ thực hiện:

ExecutionReport(MsgType=8, ExecType=4, OrdStaus=3 )

ExecutionReport(MsgType=8, ExecType=4, OrdStaus=3 )

Forward cho các CTCK

Lệnh không hợp lệ hoặc đã deal

Hình 2 11 Quy trình xóa lệnh quảng cáo chưa thực hiện

2.2.3.6 Quy trình đặt lệnh thỏa thuận của khách hàng cùng công ty

Sơ đồ thực hiện:

NewOrderCross(MsgType=s, CrossType=1)

ExecutionReport(MsgType=8, ExecType =3, OrdStatus =2)

Hình 2 12 Quy trình đặt lệnh thỏa thuận cùng công ty

2.2.3.7 Quy trình đặt lệnh thỏa thuận của khách hàng khác công ty

Bên mua đồng ý thỏa thuận:

NewOrderCross(MsgType =s, CrossType=5)

ExecutionReport (MsgType=8, ExecType =3, OrdStatus=2)

ExecutionReport (MsgType=8, ExecType =3, OrdStatus=2)

Hình 2 13 Đặt lệnh thỏa thuận khác công ty - Bên mua đồng ý

Với thông điệp chấp nhận lệnh thỏa thuận của bên mua có 2 cách xử lý như sau:

• Sử dụng thông điệp - NewOrderCross với Tag 549 = 5 và nhập đầy đủ thông tin liên quan đến bên xác nhận (Bên Mua) và thông tin liên quan đến bên đối ứng (Bên Bán)

• Sử dụng thông điệp - NewOrderCross với Tag 549 = 5 và Phía bên xác nhận (Bên Mua) có thể chỉ nhập các thông tin liên quan đến bên xác nhận lệnh thỏa thuận (Bên Mua)

Bên mua không đồng ý thỏa thuận:

NewOrderCross(MsgType =s, CrossType=6)

ExecutionReport (MsgType=8, ExecType =4, OrdStatus=3)

ExecutionReport (MsgType=8, ExecType =4, OrdStatus=3)

Hình 2 14 Đặt lệnh thỏa thuận khác công ty - Bên mua không đồng ý

Với thông điệp từ chối lệnh thỏa thuận của bên mua có 2 cách xử lý như sau:

• Sử dụng thông điệp - NewOrderCross với Tag 549 = 6 và nhập đầy đủ thông tin liên quan đến bên xác nhận (Bên Mua) và thông tin liên quan đến bên đối ứng (Bên Bán)

• Sử dụng thông điệp - NewOrderCross với Tag 549 = 6 và Phía bên xác nhận (Bên Mua) có thể chỉ nhập các thông tin liên quan đến bên xác nhận lệnh thỏa thuận (Bên Mua)

2.3 Đặc tả các thông điệp trao đổi dữ liệu giữa CTCK và HNX

2.3.1 Danh mục các thông điệp

Đối với thị trường chứng khoán Việt Nam khi áp dụng FIX đang sử dụng 19 loại thông điệp khác nhau Cụ thể như sau:

dịch thông sàn

7 Nhập một lệnh quảng cáo

thỏa thuận vào hệ thống

vào hệ thống

13 CrossOrderCancelReques

Nhập một lệnh hủy thỏa thuận vào hệ thống

14 CrossOrderCancelReplac

Nhập một lệnh sửa thỏa thuận vào hệ thống

17 SecurityStatus HNX f Danh sách chứng khoán

khoán

Trả về thông tin lệnh đặt, lệnh khớp, lệnh hủy, lệnh sửa, trả lời lệnh thỏa thuận Bảng 2 2 Danh sách các thông điệp FIX

2.3.2 Danh mục các TAG sử dụng trong FIX

Đối với phiên bản FIX 4.4 danh mục các TAG như sau:

Mã

Kiểu

quảng cáo)

3 AdvRefID String Số hiệu lệnh của quảng cáo cần hủy (dành cho

lệnh hủy quảng cáo)

B = Buy

S = Sell

Loại lệnh quảng cáo

- N : đăng quảng cáo

- C : Hủy quảng cáo

- D : Quảng cáo đã deal (HNX định nghĩa)

- A : Quảng cáo trở lại bình thường sau khi Deal

từ quảng cáo bị huỷ (HNX định nghĩa)

8 BeginString String “FIX.4.4” (Phải là trường đầu tiên của thông

điệp) Đây là trường báo phiên bản FIX sử dụng

9 BodyLength Int Độ dài thông điệp (không tính độ dài của Tag 8,

9, 10)

10 CheckSum String

Checksum để kiểm tra tính đúng đắn của thông điệp (Phải là trường cuối cùng của thông điệp) Checksum có 3 ký tự, có ký tự <SOH> báo hiệu kết thúc thông điệp Như vậy checksum có dạng 10=NNN^

Hiện tại HNX sẽ không kiểm tra giá trị này CTCK sẽ gửi giá trị mặc định là ”000”

35 MsgType String

“A” là kiểu thông điệp Logon

“2” là kiểu thông điệp Resend Request

“4” là kiểu thông điệp ResetSequence

“0” là kiểu thông điệp Heartbeat

“1” là kiểu thông điệp TestRequest

“3” là kiểu thông điệp Reject

“5” là kiểu thông điệp Logout

“D” là kiểu thông điệp NewOrderSingle

“F” là kiểu thông điệp OrderCancelRequest

“G” là kiểu thông điệp OrderReplaceRequest

“7” là kiểu thông điệp Advertisement

“s” là kiểu thông điệp NewOrderCross

“u” là kiểu thông điệp CrossOrderCancelRequest

“h” là kiểu thông điệp thông báo phiên thị trường

“x” là kiểu thông điệp thông báo yêu cầu thông tin về trạng thái thị trường

“y” là kiểu thông điệp thông báo yêu cầu thị trường

“g” là kiểu thông điệp yêu cầu thông tin thị trường

“8” là kiểu thông điệp ExecutionReport

“f” là kiểu thông điệp thông báo trạng thái chứng khoán

“e” là thông điệp yêu cầu trạng thái chứng khoán

điệp data)

39 OrdStatus Char Trạng thái của lệnh

Loại lệnh:

2: LO 3: SO<

4: SO>

5: ATC 6: ATO I: IO K: MOK A: MAK S: SBO O: OBO T: MTL C: PLO (lệnh phiên sau giờ) P: PT (lệnh thỏa thuận)

Trong thông điệp gửi lên: số hiệu lệnh của HNX cần sửa huỷ

Cờ báo hiệu là thông điệp gửi lại theo yêu cầu

- „Y‟ = thông điệp gửi lại theo yêu cầu

- „N‟ hoặc không có = thông điệp gửi bình thường

ID người gửi

Nếu là thông điệp do HNX gửi thì giá trị là

“HNX”

50 SenderSubID String CTCK đăng quảng cáo (khi HNX gửi thông tin

quảng cáo cho các công ty khác)

8 = Cross: trả về của lệnh thỏa thuận

B = AsDefined: trả về của lệnh quảng cáo

Giải thích lý do từ chối với thông điệp Reject

Lý do Logout đối với thông điệp Logout

Mở rộng, lưu mục đích của thông điệp đối với các thông điệp khác

time

Thời gian đặt lệnh Thời gian gửi theo giờ UTC ( hay

Hình thức thanh toán:

= D là Đa phương

= E là Song phương

= 1 là Trực tiếp với chu kỳ thanh toán là T + 0

= 2 là Trực tiếp với chu kỳ thanh toán là T + 1

= 3 là Trực tiếp với chu kỳ thanh toán là T + 2

= 4 là Trực tiếp với chu kỳ thanh toán là T + 3 Hiện này HNX không kiểm tra đối chiếu chu kỳ thanh toán của lệnh

103 OrdRejReason String Mã xác định lý do từ chối lệnh

107 SecurityDesc String Mô tả thêm về chứng khoán

= CB (ConvertibleBond) Trái phiếu chuyển đổi

= GO (GeneralObligationBonds) Trái phiếu chính phủ

Time

Ngày phát hành Thời gian gửi theo giờ UTC ( hay còn gọi là GMT) theo định dạng yyyyMMdd-HH:mm:ss

326 SecurityTradingStatus int

Trạng thái chứng khoán 1: Niêm yết mới

17: bình thường 2: tạm ngừng giao dịch 19: ngừng giao dịch 24: CK bị theo dõi (HNX định nghĩa) 25: CK bị cảnh cáo(HNX định nghĩa) 26: CK họp đại hội cổ đông(HNX định nghĩa)

Khối lượng được phép mua của nhà đầu tư nước ngoài (foreign room)

Lấy thông tin phiên theo bảng hoăc theo CK :

= 1 lấy thông tin phiên theo bảng

= 2 lấy thông tin phiên theo CK

= 6 Chứng khoán đang Prolong

= 13 Kết thúc nhận lệnh của ngày giao dịch hiện tại

= 90 Thị trường đang ở trạng thái chờ nhận lệnh

Với trạng thái = 0, 2, 3, 13, 90 hệ thống sẽ không nhận lệnh

Với các trạng thái khác sẽ phụ thuộc vào Mã Trạng thái giao dịch Tag=336 để thực hiện nhận

và xử lý các loại lệnh tương ứng

341 TradSesStartTime Date

time

Thời gian bắt đầu phiên Thời gian gửi theo giờ UTC ( hay còn gọi là GMT) theo định dạng yyyyMMdd-HH:mm:ss

369 LastMsgSeqNumProce

Số thứ tự của thông điệp cuối cùng nhận

- Nếu là thông điệp từ CTCK gửi HNX: là số thứ tự của thông điệp cuối cùng mà CTCK nhận được từ HNX

- Nếu là thông điệp từ HNX gửi CTCK: là số thứ tự của thông điệp cuối cùng mà HNX nhận được từ công ty chứng khoán

372 RefMsgType String Loại thông điệp bị reject

373 SessionRejectReason Int Mã lỗi của lý do reject

548 CrossID String Số hiệu lệnh thoả thuận gửi lên

Loại lệnh thỏa thuận

1 = thỏa thuận thông thường

5 = bên mua chấp nhận thoả thuận hoặc chấp nhận huỷ thoả thuận tuỳ theo loại thông điệp (HNX định nghĩa)

6 = bên mua từ chối thoả thuận hoặc từ chối huỷ thoả thuận tuỳ theo loại thông điệp (HNX định nghĩa)

7 = xoá ngang lệnh thoả thuận khi chưa được thực hiện (HNX định nghĩa)

8 = Lệnh thỏa thuận dựa trên lệnh quảng cáo

550 CrossPrioritization Int Ưu tiên thoả thuận, mặc định luôn luôn = 0

(None)

551 OrigCrossID String Số hiệu lệnh của lệnh thoả thuận(của HNX) cần

huỷ trong trường hợp huỷ lệnh thoả thuận

4 = Cá nhân / tổ chức nước ngoài

625 TradingSessionSubID String Mã bảng giao dịch của CK

652 UnderlyingLastQty Double Khối lượng bị reject

Bảng 2 3 Danh mục các TAG sử dụng trong FIX

2.3.3 Đặc tả chi tiết các thông điệp

Mỗi thông điệp FIX gồm nhiều trường thông tin và chia làm 2 loại: Các thông tin thuộc lớp Session (thông tin quản lý kết nối) và các thông tin thuộc lớp Body (thông tin nghiệp vụ) Vì các thông tin thuộc lớp Session (phiên bản FIX, Id máy trạm gửi, ID Server nhận, .) thì thông điệp nào cũng bắt buộc nên trong luận văn chỉ mô tả các trường thông tin khác biệt

2.3.3.1 Thông điệp Logon

Mục đích: Khi công ty chứng khoán muốn kết nối đến HNX, phải gửi thông điệp

Logon tới HNX

Các trường thông tin chính của thông điệp:

2.3.3.2 Thông điệp Reject

Mục đích:

Mục đích là từ chối một thông điệp đầu kia gửi đến

Các trường thông tin chính của thông điệp:

Bảng 2 5 Danh mục các trường thông điệp từ chối

2.3.3.3 Thông điệp NewOrderSingle

Mục đích:

Mục đích để CTCK thực hiện đặt một lệnh báo giá đến HNX

Các trường thông tin chính của thông điệp:

40 OrdType Y 2

Loại lệnh:

2: LO 3: SO<

4: SO>

5: ATC 6: ATO I: IO K: MOK A: MAK S: SBO O: OBO T: MTL C: PLO (lệnh phiên sau giờ) P: PT (lệnh thỏa thuận)

Bảng 2 6 Danh mục các trường của thông điệp đặt lệnh báo giá

2.3.3.4 Thông điệp OrderCancelRequest

Mục đích: Là thông điệp mà công ty chứng khoán gửi lên HNX để hủy lệnh đã

đặt

Các trường thông tin chính của thông điệp:

Bảng 2 7 Danh mục các trường thông điệp hủy lệnh

2.3.3.5 Thông điệp OrderCancelReplaceRequest

Mục đích: Là thông điệp mà công ty chứng khoán gửi lên HNX để sửa một lệnh

báo giá đã đặt

Các trường thông tin nghiệp vụ của thông điệp:

khoán

Số hiệu lệnh của lệnh thỏa thuận cần sửa HNX sẽ gửi giá trị này trong trường OrigClOrdID của thông điệp thông báo xác nhận lệnh sửa