II. BỐ CỤC CỦA LUẬN VĂN
3.1.3. Quyết toán và đối chiếu
3.1.3.1. Quyết toán vốn
Hàng ngày, trƣớc giờ COT, mỗi bên đối chiếu số dƣ trên tài khoản thu hộ, chi hộ với NH đối tác, căn cứ vào hạn mức thanh toán đƣợc quy định cho từng thời kỳ, NH có số dƣ Nợ trên tài khoản thu hộ, chi hộ (thu hộ lớn hơn (>) chi hộ) thực hiện thanh toán vốn vào tài khoản tiền gửi thanh toán của NH đối tác tại Sở giao dịch Ngân hàng Nhà nƣớc trong ngày giao dịch. Hàng năm, vào ngày giao dịch cuối cùng của năm, 2 NH quyết toán số dƣ trên tài khoản thu hộ, chi hộ. Bên nào có số dƣ Nợ sẽ chuyển trả toàn bộ số dƣ vào tài khoản tiền gửi của NH đối tác tại Sở Giao dịch Ngân hàng Nhà nƣớc ngay trong năm đảm bảo số dƣ tài khoản thu hộ, chi hộ cuối năm bằng 0, gửi bản xác nhận doanh số và số dƣ tài khoản thu hộ, chi hộ để làm cơ sở kiểm toán, quyết toán năm.
NH phải trả vốn khi thực hiện chuyển trả vốn cho NH đối tác vào tài khoản tiền gửi tại Sở giao dịch Ngân hàng Nhà nƣớc, phải đồng thời nhập số tiền quyết toán vốn tại chƣơng trình TTĐTSP khớp đúng với số tiền trên lệnh chuyển trả vốn qua IBPS (hệ thống Thanh toán điện tử lien ngân hàng), chƣơng trình tự động tạo Điện Quyết toán vốn gửi cho NH đối tác qua Chƣơng trình TTĐTSP để xác nhận số tiền đã chuyển trả.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
3.1.3.2. Đối chiếu
Cách thức thực hiện đối chiếu
Sau giờ COT chƣơng trình TTĐTSP tự động tạo, gửi file dữ liệu đối chiếu duy nhất 1 lần; file dữ liệu đối chiếu của các lần gửi tiếp theo nếu kéo dài thời gian giao dịch đƣợc tạo, gửi thủ công tại chƣơng trình TTĐTSP, file đối chiếu sau sẽ đƣợc cập nhật toàn bộ trên file đối chiếu trƣớc. Thông tin đối chiếu bao gồm: Tổng số món/doanh của điện thành công/chi tiết số món/doanh số theo từng loại tiền tệ của điện thành công/điện lệch/điện lỗi (điện chuyển tiền, tra soát). Các thông tin đối chiếu sai đƣợc in ra, đồng thời tự động gửi sang NH đối tác để cùng kiểm tra xử lý.
Các yếu tố đối chiếu trong TTĐTSP Đối chiếu giao dịch:
Số MT_ID.
Ngày giao dịch, số tiền, loại tiền tệ. Số tham chiếu giao dịch (F20).
Mã NH phát lệnh.
Mã NH nhận lệnh.
Đối chiếu tra soát:
Số MT_ID.
Số điện thanh toán liên quan.
Xử lý các sai sót và sự cố kỹ thuật khi đối chiếu
Trong quá trình đối chiếu nếu số liệu không khớp đúng có thể xảy ra các trƣờng hợp sau:
Chênh lệch doanh số chuyển tiền phát sinh (thừa hoặc thiếu điện chuyển tiền).
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Do sự cố kỹ thuật hoặc truyền điện.
Khi phát hiện sai sót phải thông báo kịp thời cho NH đối tác để xác định nguyên nhân và có biện pháp xử lý thích hợp ngay trong ngày (trừ trƣờng hợp bất khả kháng do sự cố kỹ thuật, truyền tin).
Xử lý sai sót và sự cố kỹ thuật
Trƣờng hợp trên báo cáo điện thanh toán NH đối tác không có hoặc ngƣợc lại (thừa hoặc thiếu), mỗi NH tự kiểm tra lại các điện thanh toán đã gửi đi và nhận đƣợc để xác định nguyên nhân sai sót, lập biên bản và thống nhất cách xử lý.
Trƣờng hợp do sự cố kỹ thuật, truyền tin không đối chiếu đƣợc các điện thanh toán trong ngày. Sau thời điểm hoàn thành đối chiếu, theo quy định, các điện thanh toán đã đối chiếu khớp đúng và chƣa đối chiếu đƣợc (do sự cố kỹ thuật, truyền tin) sẽ đƣợc phân loại và phản ánh trên bảng thống kê chứng từ đi, đến. Từng NH lập và gửi Biên bản xác nhận Tổng số món/doanh số của điện thành công, chi tiết điện lệch/điện lỗi trong ngày.
3.2. Đặc tả kỹ thuật kế nối
Giao thức Message Queue
Cả 2 bên cùng chủ động gửi nhận điện qua kết nối Queue to Queue
Bên NHA cung cấp cho bên NHB: 1 Queue để có thể gửi message vào.
Bên NHB cung cấp cho bên NHA: 1 Queue để gửi message vào.
Giao thức Webservice chỉ đƣợc dùng trong trƣờng hợp điện vấn tin số dƣ tài khoản.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Bên NHA cung cấp 1 webservice nhận message từ bên NHB: Khi bên NHB cần gửi message sang bên NHA, bên NHB sẽ gọi webservice này để gửi message.
Bên NHB cung cấp 1 webservice nhận message từ bên NHA: Khi bên NHA cần gửi message sang bên NHB, bên NHA sẽ gọi webservice này để gửi message.
3.2.1. Mô hình kỹ thuật kết nối 3.2.1.1. Yêu cầu chung 3.2.1.1. Yêu cầu chung
Mỗi ngân hàng có trách nhiệm thiết lập các cơ chế bảo mật tại mỗi hệ thống Queue, Webservice nội bộ bên mình đảm bảo không làm lộ thông tin thanh toán của các ngân hàng đối tác.
Mỗi ngân hàng phải tiến hành kiểm tra, test tải với lƣợng giao dịch lớn đảm bảo việc thực hiện truyền nhận điện không bị quá tải, gián đoạn.
Các ngân hàng có trách nhiệm bảo mật khóa riêng.
Gửi message có định dạng XML, mỗi message đƣợc kí và xác thực bằng chữ ký số công cộng trên toàn bộ nội dung thẻ <BODY></BODY>
Sử dụng 2 giao thức truyền nhận dữ liệu: dùng IBM Message Queue và Webservice, trong đó:
IBM Message Queue: dùng để truyền nhận thông tin về giao dịch, không truyền thông tin vấn tin và phản hồi số dƣ tài khoản.
Webservice: chỉ dùng để thực hiện truyền thông tin vấn tin và phản hồi số dƣ tài khoản.
Sử dụng 2 đƣờng truyền Metronet tốc độ cao (2MB): một đƣờng truyền chính và một đƣờng truyền dự phòng phục vụ việc truyền nhận dữ liệu
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
3.2.1.2. Mô hinh kỹ thuật kết nối sử dụng IBM Message Queue
Chứng thực số Vùng lõi
Ngân hàng đối tác
Ứng dụng thanh toán viên
Máy chủ CSDL Vùng giáp ranh Ứng dụng truyền thông XML, Webservice Ký và xác thực chữ ký số
Thống nhất phiên bản IBM Message Queue sử dụng phiên bản mới nhất của IBM Message Queue (7.5), các bên sử dụng chung cùng một phiên bản Message Queue. Khi một bên có nhu cầu muốn nâng cấp phiên bản Message Queue, bên ngân hàng đối tác phải có trách nhiệm hỗ trợ và thống nhất việc kiểm tra, triển khai hệ thống.
Bên NHA thiết lập một Remote Queue Queue.Outbox kết nối tới
Local Queue Queue.Inbox bên NHB.
Khi bên NHA muốn gửi message sang bên NHB, bên NHB phải cung cấp các thông tin kết nối Queue cần thiết, bao gồm:
o IP/Hostname: Địa chỉ kết nối tới Queue manager.
o Port: Cổng kết nối tới Queue manager
o Receive Channel: Kênh kết nối tới Queue manager
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Bên NHA có trách nhiệm bảo mật các thông số kỹ thuật mà bên NHB cung cấp.
3.2.1.3. Mô hinh kỹ thuật kết nối sử dụng Webservice Webservice Webservice Đƣờng truyền chính Metronet 2MB WSDL Đƣờng truyền dự phòng Metronet 2MB WSDL Message Message
Bên NHA cung cấp một Webservice phục vụ vấn tin thông tin số dƣ tài khoản.
Khi bên NHB muốn gửi message sang bên NHA, bên NHA phải cung cấp các thông tin kết nối cần thiết, bao gồm:
IP/Hostname: Địa chỉ kết nối tới Webservice
Port: Công kết nối tới Webservice
File đặc tả WSDL của webservice, trong file đặc tả cung cấp hàm, thủ tục và thông tin hƣớng dẫn cách sử dụng.
Bên NHB có trách nhiệm bảo mật các thông số kỹ thuật mà bên NHA cung cấp:
Chỉ dùng một chữ ký nhân danh hệ thống của mỗi ngân hàng. Thời gian hiệu lực chứng chỉ số 3 năm.
Mỗi bên thông báo thời điểm hết hạn trƣớc tối thiểu 3 tháng. Khuyến nghị xây dựng module quản lý thời gian hết hạn chứng chỉ số trong chƣơng trình của mỗi bên.
Chỉ dùng chứng chỉ số, không sử dụng ký hiệu mật trong xác thực và chống từ chối điện.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
CA cộng cộng do đơn vị thứ 3 cung cấp, nhà cung cấp: VDC, Viettel, BkavCA.
Các ngân hàng có trách nhiệm bảo mật chứng chỉ số công cộng của mình. Nội dung ký: Toàn bộ nội dung thẻ <Header> </Header>, <BODY></BODY>
Thiết bị lƣu trữ chữ ký số công cộng là HSM
Độ dài khóa: 2048
Thuật toán băm: SHA256
Mỗi ngân hàng có trách nhiệm thiết lập các cơ chế bảo mật tại mỗi hệ thống Queue, nội bộ bên mình đảm bảo không làm lộ thông tin thanh toán của các ngân hàng đối tác.
3.2.2. Đặc tả message
Danh sách các loại giao dịch trong hệ thống Thanh toán song phƣơng
STT Mã loại giao
dịch Tên giao dịch Ghi chú
1 10300 Lênh thanh toán MT103 Theo chuẩn swift
2 19500 Điện tra soát MT195 Theo chuẩn swift
3 19600 Điện tra soát MT196 Theo chuẩn swift
4 19900 Điện thông báo MT199 Theo chuẩn swift
5 10600 Điện xin nới giờ Cut off Time Xây dựng mới
6 19700 Điện phản hồi (Reply message) Xây dựng mới
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
8 10400 Bảng kê đối chiếu Xây dựng mới
9 10500 Điện xác nhận kết quả đối chiếu Xây dựng mới
10 20100 Điện vấn tin số dƣ Xây dựng mới
11 20500 Điện phản hồi thông tin số dƣ Xây dựng mới
3.2.3. Cấu trúc message
Cấu trúc của bất kỳ message đƣợc cấu thành nhƣ sau:
Message Header Message Body Message Security
Cấu trúc của một message
<?xml version="1.0" encoding="UTF-8"?> <Data>
<Header> Message header content </Header> <Body> Message body content </Body>
<Security> Message Security content </ Security > </Data>
Một message gồm 3 phần Message Header, Message Body và Message Security trong đó:
Message Header: Chứa các thông tin chung của gói tin, nó phục vụ
cho việc lƣu vết gói tin, tìm kiếm đƣờng đi tiếp theo. Các thông tin bao gồm định danh gói tin, nơi gửi, nơi nhận, số bản ghi trao đổi. Tất cả các message đều có chung cấu trúc header, thông tin chi tiết đƣợc miêu tả ở phần sau.
Message Body: Chứa các thông tin chi tiết của từng loại dữ liệu trao
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
message sẽ có cấu trúc khác nhau, thông tin chi tiết đƣợc miêu tả ở phần sau.
Message Security: Chứa các thông tin ký số của từng loại dữ liệu
trao đổi. Tùy loại message yêu cầu ký hay không, nếu không ký thì trƣờng này để trống.
Message Header Message Body
Records(1,n)
Message Security
3.2.3.1. Cấu trúc message Header
XML TAG: Data -> Header
Tên thẻ XML Loại Độ
dài
Diễn giải Ràng
buộc
Chú thích
VERSION String 3 Phiên bản XML Bắt buộc
SENDER_CODE String 12 Mã ứng dụng gửi Bắt buộc
SENDER_NAME String 200 Tên ứng dụng gửi Bắt buộc
RECEIVER_COD E String 12 Mã ứng dụng nhận Bắt buộc RECEIVER_NA ME String 200 Tên ứng dụng nhận Bắt buộc TRAN_CODE NumSt ring 5 Mã dữ liệu VD: 10300, 19500 Bắt buộc
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn MSG_ID NumSt ring 20 Id của message gửi Bắt buộc Tran_code + sequence. MSG_REQID NumSt ring 20 Id ref của message gửi Bắt buộc SEND_DATE DateTi me Ngày gửi message Bắt buộc DD-MON- YYYY hh24:mi:ss ORIGINAL_NA ME
String 10 Tên nơi gửi
nguồn
Bắt buộc
ORIGINAL_COD E
String 100 Mã NH gửi Bắt buộc
EXPORT_DATE Dateti
me
Ngày export Tùy
chọn DD-MON- YYYY hh24:mi:ss TRAN_NUM Numbe r 5 Số lƣợng row dữ
liệu trong gói msg Bắt buộc ERROR_CODE Numbe r 2 Mã lỗi Tùy chọn
ERROR_DESC String 200 Mô tả lỗi Tùy
chọn
3.2.3.2. Yêu cầu đối với Header
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Dữ liệu Datetime theo định dạng: DD-MON-YYYY hh24:mi:ss
Ví dụ cho header <?xml version="1.0" encoding="UTF-8" ?> <DATA> <HEADER> <VERSION>1.1</VERSION> <SENDER_CODE>TTSP_KB</SENDER_CODE>
<SENDER_NAME>NH TMCP Viet Bank</SENDER_NAME> <RECEIVER_CODE>TTSP_NH</RECEIVER_CODE>
<RECEIVER_NAME>Kho bac </RECEIVER_NAME> <TRAN_CODE>103</TRAN_CODE>
<TRAN_NAME>Lenh thanh toan MT103</TRAN_NAME> <MSG_ID>1120110300427288 </MSG_ID> <MSG_REQID>1120110300427288 </MSG_REQID> <SEND_DATE>30/03/2011 10:20:19</SEND_DATE> <ORIGINAL_CODE>01201002</ORIGINAL_CODE> <ORIGINAL_NAME>Ngan hang TMCP CT Ha Noi</ORIGINAL_NAME> <EXPORT_DATE>30/03/2011 10:20:19</EXPORT_DATE> <TRAN_NUM>1</TRAN_NUM> <ERROR_CODE></ERROR_CODE> <ERROR_DESC></ERROR_DESC> </HEADER>
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn <BODY> < ROW> <DETAIL></DETAIL> </ROW> </BODY> <SECURITY> < SIGNATURE>123456789</SIGNATURE> </SECURITY> </DATA>
3.2.3.3. Cấu trúc của message body
Yêu cầu đối với body
Các Tag XML phải dùng chữ hoa
Dữ liệu Datetime theo định dạng:DD-MON-YYYY hh24:mi:ss
Các Tag XML không có dữ liệu đƣợc định nghía <TAG></TAG> ví dụ <DETAIL></DETAIL>
Với các điện thanh toán, tra soát: MT 103, MT 195, MT 196, MT 199 sử dụng TAG <SEND_DATE></SEND_DATE> làm giá trị ngày giao dịch của điện
3.3. Một số lệnh thanh toán 3.3.1. Lệnh thanh toán MT103 3.3.1. Lệnh thanh toán MT103 3.3.1.1. Quy trình xử lý
NHA tạo message MT 103 đƣợc kí chữ ký số, gửi sang ngân hàng đối tác NHB.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
NHB nhận message MT103, xác thực chữ ký số, kiểm tra các điều kiện chống trùng, kiểm tra số dƣ tài khoản, tính hợp lệ của dữ liệu.
Điện thành công sẽ đƣợc nhận vào hệ thống nội bộ để xử lý Điện không thành công sẽ lƣu lại hàng chờ xử lý.
Trong mọi trƣờng hợp, NHB phải gửi trả lại message phản hồi trạng thái thành công hoặc thất bại kèm theo mô tả trạng thái.
3.3.1.2. Luồng message
3.3.1.3. Mô tả chi tiết
STT Tên thẻ XML Kiểu DL Mô tả ý nghĩa Ràng
buộc
1 MT_ID VARCHAR2(16) Số điện thanh toán Bắt buộc
2 SEND_BAN
K VARCHAR2(11) Sender Bắt buộc
3 RECEIVE_B
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
4 CREATED_
DATE DATE Ngày giờ lập lệnh Bắt buộc
5 CREATOR VARCHAR2(25) Ngƣời lập lệnh (NHA) Bắt buộc
6 MANAGER VARCHAR2(25) Ngƣời kiểm soát điện
(NHA) Bắt buộc
7 VERIFIED_
DATE DATE
Ngày giờ kiểm soát điện
(NHA) Bắt buộc
8 SENDED_D
ATE DATE Ngày giờ truyền (NHA) Bắt buộc
9 SEND_TIME
S VARCHAR2(2) Số lần truyền điện(NHA) Bắt buộc
10 RECEIVED_
DATE DATE Ngày giờ nhận (NHA) Tùy chọn
11 PROCESS_T
IMES DATE
Thời gian NHB xử lý điện
đến (NHB) Tùy chọn
12 SEC_CODE VARCHAR2(1000
) Ký hiệu mật (NHA) Tùy chọn
13 CHK_SUM VARCHAR2(2000
) Check sum(NHA) Tùy chọn
14 STATUS_C
ODE VARCHAR2(2) Trạng thái Tùy chọn
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
Reference Number, format 16x. (***).
16 F23B VARCHAR2(4) Bank Operation Code Bắt buộc
17 F26T VARCHAR2(3) Field F26T. Transaction
Type Code Bắt buộc
18 F32AS1 DATE
Field 32A - Value Date, Curency Code, Interbank Settled Amount (subfield 1 - Value Date)
Bắt buộc
19 F32AS2 VARCHAR2(3)
Field 32A - Value Date, Curency Code, Amount (subfield 2 - Currency Code).
Bắt buộc
20 F32AS3 NUMBER(20,2)
Field 32A - Value Date, Curency Code, Amount (subfield 3 - Amount)
Bắt buộc
21 F33BS1 VARCHAR2(3) Field F33BS1. Currency Tùy chọn
22 F33BS2 NUMBER(20,2) Field F33BS2. Instructed
Amount Tùy chọn
23 F36 NUMBER(17,5) Field F36. Exchange Rate Tuỳ chọn
24 F50P1 VARCHAR2(35)
Field F50. Ordering
Customer (Account) TK ngƣời chuyển.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn 25 F50AP2 VARCHAR2(11) Field F50. Ordering Customer (BIC/BEI):khong dung Tuỳ chọn
26 F50KP2 VARCHAR2(146) Field F50. Ordering
Customer Tuỳ chọn
27 F51AP1S1 VARCHAR2(2) Field 51A. Sending
Institution Tuỳ chọn
28 F51AP1S2 VARCHAR2(35) Field 51A. Sending
Institution Tuỳ chọn
29 F51AP2 VARCHAR2(11)
Field 51A. Sending
Institution (BIC), format 4!a2!a2!c [3!c]
Tuỳ chọn
30 F52P1S1 VARCHAR2(2)
Field 52[A, D] - Ordering Institution (part 1, subfield 1 - Debit/Credit Indicator), format [/1!a]
Tuỳ chọn
31 F52P1S2 VARCHAR2(35)
Field 52[A, D] - Ordering Institution (part 1, subfield 2 - Party Identifier), format [/34x]
Tuỳ chọn
32 F52AP2 VARCHAR2(11) Field 52A - Ordering
Institution (part 2 - BIC), 8! Tuỳ chọn
33 F52DP2 VARCHAR2(146) Field 52D - Ordering
Institution (part 2 - Name
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn
and Address), format
4*35x.
34 F53P1S1 VARCHAR2(2)