II. BỐ CỤC CỦA LUẬN VĂN
3.1.2.Quy trình nghiệp vụ
3.1.2.1. Tài khoản hạch toán
Tài khoản sử dụng: 5020.01.xxx (xxx: chi tiết theo từng ngân hàng), tài khoản này dùng để hạch toán các khoản thu chi hộ trong TTĐTSP.
Số dƣ Nợ: Phản ánh các khoản chi hộ lớn hơn thu hộ. Số dƣ Có: Phán ánh các khoản thu hộ lớn hơn chi hộ.
3.1.2.2. Quy trình xử lý điện
Tại NH phát lệnh:
Tại chi nhánh: Khi chấp nhận xử lý điện thanh toán của ngƣời phát lệnh, thực hiện hạch toán và chuyển hóa thành chứng từ điện tử theo quy trình nội bộ mỗi NH.
Tại Đơn vị đầu mối: Thực hiện xác thực chữ ký số công cộng trên điện thanh toán trƣớc khi truyền sang NH nhận lệnh trong TTĐTSP. Thực hiện truyền lại điện thanh toán gửi đi bị lỗi (sau khi nhận đƣợc MT197 thông báo điện lỗi từ NH nhận lệnh) theo quy trình nội bộ mỗi NH.
Tại NH nhận lệnh:
Khi nhận điện thanh toán đến từ NH đối tác, chƣơng trình TTĐTSP
tự động xác thực chữ ký số công cộng, kiểm tra các yếu tố của điện MT ID, Sent time, nội dung điện, nếu hợp lệ điện sẽ đƣợc chuyển vào hệ thống nội bộ của NH nhận lệnh.
Nếu điện đến bị lỗi, chƣơng trình TTĐTSP tự động cập nhật trạng thái điện lỗi và gửi thông báo lỗi theo mẫu TTĐTSP tới NH gửi lệnh để xử lý.
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
Đối với điện chuyển tiền trả cho ngƣời thụ hƣởng bằng CMND, trong thời gian 30 ngày kể từ khi NH nhận lệnh nhận đƣợc điện, nếu ngƣời thụ hƣởng không đến nhận tiền, NH nhận lệnh thực hiện hoàn trả lại NH phát lệnh.
3.1.2.3. Sai lầm, sự cố và xử lý
Sai sót phát hiện khi điện chuyển tiền chƣa đƣợc chuyển qua hệ thống TTĐTSP sang NH nhận lệnh: Đƣợc xử lý theo quy trình nội bộ của từng NH, sai sót phát hiện khi điện chuyển tiền đã chuyển sang NH nhận lệnh.
Đối với các điện chuyển tiền sai một trong các thông tin ngƣời thụ hƣởng: Tên, số CMND, ngày cấp, nơi cấp; Tên và số TK không khớp, NH nhận lệnh có thể tra soát hoặc hoàn trả lại NH phát lệnh. NH phát lệnh và NH nhận lệnh trực tiếp tra soát và trả lời tra soát để có đủ cơ sở pháp lý thanh toán kịp thời cho ngƣời thụ hƣởng. NH nhận lệnh thực hiện tra soát muộn nhất sau 01 ngày làm việc kể từ khi nhận điện đến hoặc ngày ngƣời thụ hƣởng xuất trình CMND khi đến nhận tiền và hoàn trả điện trong vòng tối đa 05 ngày làm việc nếu không nhận đƣợc tra soát đính chính.
Điện sai NH nhận lệnh, hoặc sai NH hƣởng (trong trƣờng hợp chỉ hạch toán ghi Có đối với những TK ngƣời thụ hƣởng mở tại chi nhánh, không hạch toán hộ chi nhánh khác): NH nhận lệnh thực hiện hoàn trả chậm nhất vào ngày làm việc tiếp theo.
Đối với các điện chuyển tiền thừa (chuyển đúp, chuyển thừa tiền) do lỗi của NH (không phải do lỗi của khách hàng chuyển tiền):
NH chuyển chịu hoàn toàn trách nhiệm đối với điện chuyển tiền thừa và có thể tạo điện tra soát gửi NH nhận lệnh đề nghị hoàn trả. Trong nội dung điện tra soát NH chuyển thừa phải ghi rõ: “Do lỗi/sự cố của
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
Ngân hàng … nên đã xẩy ra…, đề nghị Ngân hàng … hoàn trả điện số MT_ID/ngày/số tiền…”.
Trên cơ sở điện tra soát, NH nhận lệnh chủ động hoàn trả điện chuyển tiền trong vòng tối đa 03 ngày làm việc kể từ ngày nhận đƣợc đề nghị hoàn trả (nếu chƣa thanh toán cho ngƣời thụ hƣởng hoặc TK của ngƣời thụ hƣởng đủ số dƣ)/hoặc hỗ trợ tối đa việc thu hồi tiền từ ngƣời thụ hƣởng.
3.1.3. Quyết toán và đối chiếu 3.1.3.1. Quyết toán vốn 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. (adsbygoogle = window.adsbygoogle || []).push({});
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 đó: (adsbygoogle = window.adsbygoogle || []).push({});
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. (adsbygoogle = window.adsbygoogle || []).push({});
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. (adsbygoogle = window.adsbygoogle || []).push({});
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 (adsbygoogle = window.adsbygoogle || []).push({});
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>