Sự cần thiết phải xây dựng ứng dụng tra soát liên Ngân hàng

Một phần của tài liệu Mô hình điện toán đám mây và ứng dụng trong lĩnh vực ngân hàng (Trang 56)

Hiện tại ở Việt Nam, thanh toán qua thẻ đã trở thành nhu cầu không thể thiếu được. Với việc thanh toán qua thẻ, công việc thanh toán lương hàng tháng cho nhân viên sẽ trở nên đơn giản hơn đối với các cơ quan, doanh nghiệp. Họ sẽ không còn phải thuê nhiều nhân viên để tham gia trả tiền lương hàng tháng, họ cũng không cần phải dự trữ cũng như vận chuyển nhiều tiền mặt để đem trả lương cho nhân viên - điều đó hạn chế được rất nhiều rui ro mất tiền. Các chủ sở hữu thẻ sẽ không cần phải mang một số tiền lớn đi ra ngoài, thay vào đó họ chỉ cần cầm chiếc thẻ đi và có thể sử dụng vào việc rút tiền ở bất cứ đâu, hay sử dụng thẻ trực tiếp vào việc thanh toán. Rõ ràng là việc sử dụng thẻ ngày càng trở nên không thể thiếu đối với hầu hết mọi người.

Hiện tại, các ngân hàng đang tích cực thạm gia vào việc phát hành thẻ. Nhưng một vấn đề đặt ra là nếu các ngân hàng tự đầu tư hệ thống ATM sử dụng cho việc rút tiền thì chi phí sẽ rất lớn, mà trong khi đó không tận dụng được tối đa khả năng sử dụng của các máy ATM. Do đó, các ngân hàng đã liên kết lại thông qua những công ty làm cầu nối trung gian như Banknetvn, SMARTLINK để có thể thông qua đó, sử dụng chung một hệ thống máy ATM. Điều đó tạo sự thuận lợi rất lớn cho các ngân hàng. Tuy nhiên, việc sử dụng thông qua chung một công ty như vậy lại phát sinh ra những vấn đề mới. Đó là xảy ra tình trạng ngân hàng này sẽ thanh toán cho ngân hàng khác và như vậy có khả năng sẽ dẫn đến việc tranh chấp giữa các ngân hàng. Vì vậy đòi hỏi tổ chức phải có một trung gian để thực hiện việc thanh toán cũng như giải quyết tranh chấp khi thanh toán cho các ngân hàng.

Hiện tại, việc tranh chấp giải quyết được thực hiện một cách thủ công, qua nhiều giai đoan, bao gồm:

 Bên ngân hàng phát sinh ra giao dịch cần tra soát sẽ gửi thông tin giao dịch cần tra soát qua fax sang cho công ty trung gian (Banknetvn)

 Công ty chuyển mạch tài chính Banknetvn sẽ phân loại từng giao dịch theo các ngân hàng,kiểm tra sơ bộ, lưu giữ lại một bản copy và chuyển một bản sang cho bên ngân hàng cần phải thực hiện tra soát dạng fax

 Ngân hàng thực hiện nghĩa vụ tra soát sẽ tiến hành kiểm tra giao dịch theo yêu cầu, báo lại cho Banknetvn kết quả kiểm tra bằng văn bản fax.

 Banknetvn dựa trên kết quả kiểm tra này sẽ tổng hợp và báo lại với ngân hàng phát sinh yêu cầu dưới dạng văn bản fax.

Quá trình như trên được thực hiện sẽ làm chậm tiến trình tra soát cũng như việc tổng hợp xem xét của các bên. Chính vì nhu cầu trên, việc xây dựng hệ thống tra soát liên ngân hàng trợ giúp cho việc tra soát những giao dịch tranh chấp giữa các ngân hàng. Chương trình này cho phép bên phát sinh ra tranh chấp có thể cập nhật những thông tin về giao dịch để yêu cầu bên thanh toán hộ tra soát lại hòng tìm ra xem giao dịch đã thực hiện có đúng là thành công hay không. Ngoài ra chương trình còn trợ giúp cho bên trung gian (là bên xây dựng ứng dụng tra soát) có thể xem kết quả tra soát để hỗ trợ các bên liên quan trong quá trình tra soát khi có yêu cầu cần thiết. Chương trình cũng hỗ trợ việc xuất ra báo cáo cho các bên theo thời gian để có thể ước lượng cũng như đánh giá tổng quát về số lượng cũng như chi tiết từng giao dịch đã tra soát và những giao dịch đang trong quá trình tra soát.

Một vấn đề đặt ra rất được quan tâm đối với luận văn này là việc xây dựng ứng dụng tra soát trên đám mây có lợi ích gì so với việc xây dựng ứng dụng cài đặt tại máy chủ thông thường. Liệu những lợi ích khác biệt này mang lại có đủ để thúc đẩy việc đưa ứng dụng này lên đám mây không? Rõ ràng việc xây dựng ứng dụng trên đám mây mang lại những ý nghĩa dưới đây:

 Với việc đưa dữ liệu lên đám mây, người quản trị ứng dụng không còn phải lo tới việc bảo trì hệ thống để làm cho ứng dụng vận hành trơn tru. Công việc này sẽ được phải nhà cung cấp dịch vụ (Microsoft) đảm nhiệm.

 Công việc quản trị sao lưu phục hồi CSDL cũng được tự động hóa thực hiện, đảm bảo dữ liệu không bị mất (do được sao lưu thành 3 bản), và do đó đảm bảo ứng dụng không bị mất dữ liệu

 Tổ chức Banknetvn không phải lo tới việc đầu tư nâng cấp phần cứng. Công việc này sẽ được Microsoft thực hiện, đảm bảo cho việc ứng dụng hoạt động đúng theo yêu cầu

 Khả năng mở rộng/ thu hẹp phạm vi dịch vụ nhanh. Khi cần tăng tốc độ ứng dụng, chỉ cần khai báo cấu hình cần thay đổi trong một tệp cấu hình đã được định nghĩa sẵn. Hệ thống Windows Azure sẽ tự động cập nhật thay đổi cấu hình và sẽ khởi tạo các tham số để đáp ứng với sự thay đổi cấu hình này. Chẳng hạn, khi muốn tăng số thể hiện ứng dụng đang chạy, chỉ cần thay đổi tham số tương ứng với số lượng thể hiện trong tệp cấu hình. Khi lưu trữ trên những máy chủ của nhà cung cấp dịch vụ thông thường, muốn thay đổi cấu hình khách hàng phải làm đơn từ và ký kết khá phức tạp.

 Giảm chi phí đầu tư ban đầu do việc thanh toán tiền sử dụng dịch vụ mềm dẻo. Việc thanh toán diễn ra dựa trên nhu cầu sử dụng dịch vụ, được thực hiện dưới dạng trả sau. Điều này khác với việc lưu trữ ứng dụng trên máy chủ của nhà cung cấp dịch vụ bình thường, vì khách hàng phải ký kết hợp đồng trả tiền hàng tháng với một khoản cố định.

 Tốc độ ứng dụng cũng sẽ được cải tiến so với các ứng dụng được lưu trữ trên máy chủ của nhà cung cấp dịch vụ thông thường. Do đám mây có sử dụng kĩ thuật điện toán lưới (trong đó sử dụng công nghệ tính toán song song) lên ứng dụng đảm bảo được xử lý ở tốc độ cao. Đây là một lợi thế không nhỏ do các ứng dụng trên Internet thường bị điểm yếu về tốc độ.

3.1.2 Khảo sát phân tích nghiệp vụ

 Đối tượng sử dụng: Đối với Ngân Hàng phát hành thẻ là tra soát viên (TSV) và kiểm soát viên (KSV) của ngân hàng phát hành. Ngân hàng thanh toán có tra soát viên (TSV) và kiểm soát viên (KSV) của ngân hàng thanh toán.

 Tại TCPHT có các yêu cầu phát sinh như dưới đây:

 Nhập YCTS lần 1: TSV của các tổ chức phát hành thẻ sẽ cập nhật vào chương trình và nhập các yêu cầu tra soát. Những thông tin về yêu cầu tra soát bao gồm: Ngày giao dịch, giờ giao dịch, Mã thiết bị, Số thẻ, Số trace, Tổ chức chấp nhận thẻ (Acquirer), Tổ chức thanh toán thẻ (Issuer), Mã tra soát (theo bảng mã, tham khảo phụ lục bảng mã tra soát), Số tiền tra soát (nếu có), Ghi chú yêu cầu (nếu có). Khi lựa chọn xong các yếu tố trên, TSV sẽ tiến hành ghi lại để kết thúc nhập thông tin, chuyển tiếp sang giao dịch khác. Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm soát để các KSV có thể vào kiểm tra và chấp nhận giao dịch. Khi có thông báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch

 Nhập YCTS lần 2: Khi có trả lời tra soát lần 1, tức là khi giao dịch đã được trả lời tra soát với yêu cầu tra soát lần 1 của TSV, có thể xảy ra trường hợp giao dịch này sẽ được đưa vào tra soát lần 2. Mục đích của tra soát lần 2 là làm rõ hơn những thông tin về giao dịch lần 1, bao gồm những chứng cứ xác thực hơn để làm rõ giao dịch này trong trường hợp bên TCPHT chưa thỏa mãn với câu trả lời từ TCTTT. Khi cần yêu cầu lần 2, các TSV sẽ vào chức năng tạo yêu cầu lần 2. Khi đó những giao dịch đã trả lời lần 1 sẽ được hiện lên, bao gồm những thông tin cơ bản để xác định giao dịch. Khi tìm được đúng giao dịch cần tra soát, TSV sẽ lựa chọn:

o Mã tra soát lần 2 (theo bảng mã) o Số tiền tra soát lần 2 (nếu có) o Ghi chú yêu cầu lần 2 (nếu có)

Khi lựa chọn xong các yếu tố trên, TSV ghi lại để kết thúc, chuyển tiếp sang giao dịch khác. Những giao dịch sau sẽ không được tiến hành tra soát lần 2: o Giao dịch đã được trả lời lần 1 với mã thành công (304) hoặc hoàn trả 1

phần tiền (302).

o Giao dịch có ngày tra soát lần 2 – ngày trả lời lần 1 <=15 ngày làm việc Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm soát. Khi có thông báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch

 Kiểm soát các YCTS(chỉ có KSV mới được vào chức năng này)

KSV vào chức năng kiểm soát, tất cả các giao dịch đã được TSV nhập vào nhưng chưa được kiểm soát sẽ hiển thị ra, bao gồm các thông tin như: Tên TSV, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra soát lần 2, Số tiền tra soát lần 2 (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCTTT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. KSV kiểm soát các yếu tố của giao dịch, và chấp nhận ―đúng‖ hoặc ―sai‖ đối với yêu cầu được đưa ra.

o Giao dịch đã được chọn ―sai‖ được chuyển lại để TSV sửa

Sau khi lựa chọn ―đúng‖ hoặc ‗sai‖ xong, KSV sẽ không có quyền vào sửa lại những giao dịch này nữa.

 Kiểm tra các Trả lời Tra soát

Ngay khi người dùng truy cập vào chức năng này, các giao dịch đã được trả lời đang chờ xử lý sẽ hiện lên bao gồm các thông tin sau: Ngày Yêu cầu Tra soát lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày Trả lời Tra soát lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày Yêu cầu Tra soát lần 2, Mã tra soát lần 2, Số tiền tra soát lần 2 (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày Trả lời Tra soát lần 2, Mã trả lời lần 2, Số tiền hoàn trả lần 2 (nếu có), Ghi chú trả lời lần 2 (nếu có), Tên File attach khi trả lời lần 2 (nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCTTT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Mỗi giao dịch sau khi đã được TCPHT xử lý, người dùng sẽ tích vào nút duyệt, sau đó không hiển thị ở hàng đợi nữa (chức năng duyệt chỉ có tác dụng loại giao dịch ra khỏi hàng đợi, giúp TCPHT theo dõi, không ảnh hưởng gì đế dữ liệu trả lời của TCTTT)

 Lập báo cáo: Các loại báo cáo: (adsbygoogle = window.adsbygoogle || []).push({});

o Bảng kê chi tiết các giao dịch yêu cầu tra soát lần 1 tại TCPHT o Bảng kê chi tiết các giao dịch yêu cầu tra soát lần 2 tại TCPHT o Bảng kê chi tiết các giao dịch được trả lời tra soát lần 1 tại TCPHT o Bảng kê chi tiết các giao dịch được trả lời tra soát lần 2 tại TCPHT o Bảng kê chi tiết các giao dịch tra soát quá hạn tại TCPHT

Các tham số lựa chọn khi lập báo cáo: Từ ngày, đến ngày, TCTTT, Loại báo cáo.

 Tại TCTTT

 Nhận các yêu cầu tra soát: Ngay khi người dùng truy cập, vào chức năng này, các giao dịch đang chờ trả lời sẽ hiện lên bao gồm các thông tin sau: Ngày Yêu cầu Tra soát lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú

yêu cầu lần 1(nếu có), Ngày Trả lời Tra soát lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên file kèm theo khi trả lời lần 1 (nếu có), Ngày Yêu cầu Tra soát lần 2, Mã tra soát lần 2, Số tiền tra soát lần 2 (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Mỗi giao dịch sau khi đã được TCTTT chấp nhận tra soát sẽ được chuyển sang màn hình trả lời của TSV

 Nhập TLTS lần 1: Khi TSV vào chức năng này, những giao dịch cần được trả lời lần 1 sẽ hiện lên, bao gồm những thông tin như sau: Số ID giao dịch, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, TCPHT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Khi tìm được đúng giao dịch cần trả lời tra soát, TSV sẽ lựa chọn:

o Mã trả lời lần 1

o Số tiền hoàn trả lần 1 (nếu có) o Ghi chú trả lời lần 1 (nếu có) o Số tham chiếu giao dịch (nếu có)

Khi lựa chọn xong các yếu tố trên, lựa chọn đồng ý trả lời để kết thúc, chuyển tiếp sang giao dịch khác. Những giao dịch sau đây sẽ bị chặn:

o Giao dịch đã có RC=115 nhưng được trả lời lần 1 với mã khác mã 303. o Giao dịch đã bị ghi nợ cho TCTTT (TCTTT không được phép trả lời khi đã

quá hạn).

Tất cả các giao dịch khi đã được TSV trả lời xong sẽ được chuyển sang màn hình kiểm soát. Khi có thông báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch.

 Nhập TLTS lần 2: Khi TSV vào chức năng trả lời tra soát lần 2, những thông tin sau đây của giao dịch sẽ được hiện lên: Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Số tham chiếu giao dịch (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra soát lần 2, Số tiền tra soát (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao

dịch, Số trace, TCPHT, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. Khi tìm được đúng giao dịch cần trả lời, TSV sẽ lựa chọn:

o Mã trả lời tra soát lần 2(theo bảng mã) o Số tiền hoàn trả lần 2 (nếu có)

o Ghi chú trả lời lần 2 (nếu có) o Số tham chiếu giao dịch (nếu có)

Khi lựa chọn xong các yếu tố trên, TSV lựa chọn đồng ý để kết thúc, chuyển tiếp sang giao dịch khác. Các giao dịch sau sẽ bị chặn, có cảnh báo:

o Giao dịch đã có RC=115 nhưng được trả lời lần 1 với mã khác mã 303. o Giao dịch đã bị ghi nợ cho TCTTT (TCTTT không được phép trả lời khi đã

quá hạn)

Tất cả các giao dịch khi đã được TSV nhập xong sẽ được chuyển sang màn hình kiểm soát. Khi có thông báo sửa giao dịch, TSV vào sửa và cập nhật lại giao dịch.

 Kiểm soát các TLTS: KSV vào chức năng Kiểm soát, tất cả các giao dịch đã được TSV nhập vào nhưng chưa được kiểm soát sẽ hiển thị ra. Những thông tin sau được hiển thị lên màn hình: Tên TSV, Số ID giao dịch, Ngày YCTS lần 1, Mã tra soát lần 1, Số tiền tra soát lần 1 (nếu có), Ghi chú yêu cầu lần 1(nếu có), Ngày TLTS lần 1, Mã trả lời lần 1, Số tiền hoàn trả lần 1 (nếu có), Ghi chú trả lời lần 1 (nếu có), Tên File attach khi trả lời lần 1 (nếu có), Ngày YCTS lần 2, Mã tra soát lần 2, Số tiền tra soát lần 2 (nếu có), Ghi chú yêu cầu lần 2(nếu có), Ngày TLTS lần 2, Mã trả lời lần 2, Số tiền hoàn trả lần 2 (nếu có), Ghi chú trả lời lần 2 (nếu có), Tên File attach khi trả lời lần 2 (nếu có), Ngày giao dịch, Giờ giao dịch, Mã thiết bị, Số thẻ, Loại giao dịch, Số trace, Số tiền giao dịch, Mã trả lời (RC), Ngày xử lý. KSV kiểm soát các yếu tố của giao dịch, lựa chọn đúng hoặc sai. Giao dịch trả lời đã được chọn là đúng sẽ được chuyển về cho bên TCPHT.Giao dịch đã

Một phần của tài liệu Mô hình điện toán đám mây và ứng dụng trong lĩnh vực ngân hàng (Trang 56)