Điều quan trọng đối với một chiến lược API thành công là nhận thức rằng Open API cũng là một sản phẩm kinh doanh thương mại chứ không chỉ là một giao diện tích hợp kỹ thuật. Do đó, việc chuyển đổi dịch vụ ngân hàng sang các API không chỉ là một dự án kỹ thuật  mà còn là bài toán kinh doanh. 

Open API trở nên ngày càng phổ biến và phát triển mạnh mẽ. Trước tiên, cần khẳng định rằng một Open API thành công phải tạo ra những giá trị:

– End-users trả phí giao dịch để sử dụng giải pháp

– Đối tác và hoặc nhà phát triển chi trả cho việc sử dụng dịch vụ/dữ liệu

– Các đối tác và ngân hàng chia sẻ doanh thu

Đồng thời, một Open API phải đáp ứng các yêu cầu:

– Giúp nhà phát triển có thể tiếp cận dễ dàng và nhanh chóng mà không cần ngân hàng hỗ trợ quá nhiều.

– Tài liệu chi tiết về các API 

– Môi trường Sandbox: Thử nghiệm các API, bao gồm mô tả chính xác nhất về những dữ liệu thử nghiệm có sẵn trong Sandbox

– Lập trình đa nền tảng SDK và các công cụ khác (ví dụ: các ứng dụng mẫu, mã nguồn mẫu…) để giảm thiểu thời gian và nỗ lực của các nhà phát triển trong việc sử dụng API.

Những câu chuyện thành công

Một số tổ chức tài chính đã thực hiện những bước đầu tiên trong quá trình phát triển hướng tới hệ sinh thái API cho Ngân hàng Mở – Open Banking như là BBVA, Crédit Agricole, Capital One, Citi, VISA, MasterCard, SWIFT và Fidor. Các ngân hàng sẽ cung cấp các API cho các dịch vụ thanh toán, nhận thông tin tài khoản hay đặt lệnh chứng khoán. Còn các công ty phát hành thẻ như VISA, MasterCard sẽ phát triển các API về ví điện tử, tìm kiếm ATM, phát hiện gian lận…

Đối với các ngân hàng, hệ sinh thái này bao gồm việc cung cấp các API cho các dịch vụ như thanh toán, nhận thông tin tài khoản, đặt lệnh chứng khoán…

Đối với các công ty thẻ như VISA và MasterCard, điều này bao gồm các dịch vụ như ví điện tử, finding an ATM, phát hiện gian lận…

BBVA được coi là lá cờ đầu cho sự phát triển của Ngân hàng mở này. Cách đây vài năm, BBVA đã tuyên bố về định vị thương hiệu mới, từ một ngân hàng truyền thống sang một nhà cung cấp phần mềm dịch vụ tài chính. 

Tiếp sau đó là các ngân hàng với khả năng cung cấp các dịch vụ ngân hàng (cơ sở hạ tầng ngân hàng được cấp phép) là cơ sở cho sự phát triển của các công ty Fintech. Ví dụ như CBW (Kansas), Solaris Bank, Wirecard Bank, Railsbank…

Đồng thời, một số Fintech cũng đang tạo ra hệ sinh thái của họ. Tiêu biểu như: Công ty WealthFront (giao dịch trực tuyến) và Venmo (chuyển tiền trực tuyến), Fidor Bank và Sum-Up (điểm bán hàng di động), Metro Bank và Zopa (cho vay trực tuyến), Moven (ngân hàng trực tuyến) và CommonBond (cho vay trực tuyến) hoặc Number26 (ngân hàng di động) và TransferWise (chuyển tiền trực tuyến)…

Tiêu chuẩn hóa Open API

Một vấn đề lớn đối với các Fintech và các công ty từ các lĩnh vực khác muốn sử dụng API của ngành dịch vụ tài chính là thiếu tiêu chuẩn hóa trong các API. Các nhà phát triển không muốn, với mỗi ngân hàng mà họ muốn kết nối, lại phải tích hợp với một API hoàn toàn khác.

Tuy nhiên, như bất kỳ quá trình chuẩn hóa nào, việc tạo ra “ngôn ngữ lập trình ứng dụng” chung sẽ có những thách thức nhất định. Nhiều bên đã tham gia, ​​cố gắng xác định một tiêu chuẩn chung và nhóm các ngân hàng lại với nhau. Những ngân hàng này tuyên bố tuân thủ tiêu chuẩn, nhưng một thỏa thuận chung về tiêu chuẩn toàn cầu (hoặc thậm chí là quốc gia) lại  không đạt được mong đợi ít nhất là trong tương lai gần.

Một số ví dụ về các ​​tiêu chuẩn phổ biến:


Một chiến lược tiếp cận thị trường nhanh chóng, tạo điều kiện cho các ngân hàng lớn phổ cập tiêu chuẩn đến nhiều nhà phát triển, tạo ra một tiêu chuẩn Ngân hàng Mở – Open Banking được công nhận rộng rãi. Hoặc việc chuẩn hóa các API tại châu Âu có thể được thực hiện thông qua các PSD2 Payment Hubs (quy định tại Chỉ thị thanh toán sửa đổi PSD2) được tổng hợp và được sử dụng bởi nhiều nhà cung cấp dịch vụ thanh toán và các Ngân hàng. 

Triển khai các API

Như đã đề cập, API là tập hợp các yêu cầu được tiêu chuẩn hóa, chi phối phương thức giao tiếp của một ứng dụng phần mềm với ứng dụng khác (ví dụ: API Google Maps, cho phép tích hợp thông tin bản đồ trong bất kỳ ứng dụng nào). 

Để tạo điều kiện thuận lợi cho việc sử dụng giao diện này, nhà cung cấp dịch vụ sẽ cung cấp một đặc tả API chính xác, thường với các chi tiết sau:

– Chi tiết của giao tiếpTruyền – nhận dữ liệu: Phương thức mà dữ liệu được truyền đi, đa số là giao thức HTTP hoặc  HTTPS.

– Trao đổi dữ liệu: định dạng của dữ liệu được trao đổi hầu hết là XML và JSON.

Một API có thể mở hoặc đóng. Open API cho phép bên thứ ba có thể được truy cập (theo các điều kiện cụ thể), trong khi API đóng chỉ có thể được truy cập trong nội bộ tổ chức.

Bên cạnh đó, một API đạt chuẩn phải đáp ứng một số yêu cầu phi chức năng như sau:

Trong thời gian thiết kế và vận hành, các API thường được hỗ trợ bởi API Gateway, cung cấp các chức năng sau:

– Quản lý khả năng hiển thị và hạn chế quyền truy cập API: Thông thường, sẽ bao gồm hỗ trợ các tiêu chuẩn ủy quyền (như SAML và OAuth 2.0) và quản lý các khóa ủy quyền (ví dụ: tạo và xác thực khóa) cho phép các bên thứ ba truy cập vào các API.

– Xác thực và mã hóa tất cả tin nhắn được gửi qua mạng

– Gắn thẻ an toàn để dễ dàng quản lý dữ liệu nhạy cảm và không nhạy cảm trong các lệnh gọi API

– Áp đặt giới hạn tốc độ và điều chỉnh động theo giới hạn sử dụng và giới hạn băng thông

– Phát hiện và ngăn chặn các cuộc tấn công qua website (SQLi, JavaScript hoặc XPath/XQuery)

– Khả năng tự đăng ký để theo dõi các API (sandbox/sản xuất)

– Tài liệu đặc tả API (chức năng, định dạng API, ví dụ yêu cầu/phản hồi, ví dụ mã về cách sử dụng API…)

– Thảo luận trên diễn đàn

– Đặc tả về sandbox (chi tiết kết nối, mô tả dữ liệu thử nghiệm…)

– Giám sát kỹ thuật: theo dõi việc sử dụng API, tỉ lệ thành công so với lỗi, độ trễ,…

– Xác định các quy tắc SLA và theo dõi xem các API có đáp ứng các SLA này hay không

– Giám sát hoạt động kinh doanh

– API Analytics: xác định các xu hướng và hành vi chính trong việc sử dụng API, hiểu sâu hơn về lưu lượng truy cập API…

– Cảnh báo: nhận thông báo khi SLA không được đáp ứng, những thay đổi  trên API được theo dõi…

Chiến lược giới thiệu các sản phẩm và dịch vụ dưới dạng Open API này không chỉ cho phép hoạt động kinh doanh của ngân hàng có thêm những cơ hội mới mà còn thúc đẩy các tổ chức CNTT tái cấu trúc, phát triển thành một tổ chức năng động hơn, nhạy bén hơn, với mục tiêu đặt khách hàng làm trung tâm.


SAVIS đồng hành cùng bạn xây dựng chiến lược Open API thành công. Liên hệ ngay với chúng tôi để được tư vấn TẠI ĐÂY!PrevBÀI TRƯỚCOpen API – Sự hợp tác đôi bên cùng có lợiBÀI TIẾP THEONgân hàng mở – Open Banking và xu hướng ngân hàng dưới dạng dịch vụ Banking as a Service (BaaS)NextSearch

Bài viết gần đây

SAVIS – V-key phối hợp tổ chức Hội thảo trực tuyến Bảo mật Giao dịch điện tử và ứng dụng di động trong nền kinh tế số

SAVIS sở hữu hệ giải pháp – dịch vụ ký số toàn diện và an toàn nhất hiện nay

SAVIS khẳng định vị thế số 1 Việt Nam về cung cấp giải pháp – dịch vụ ký số

QTSP và ký số từ xa Remote Signing mang đến lợi thế cạnh tranh lớn cho các tổ chức Tài chính – Ngân hàng Việt Nam 

Ký số từ xa loại bỏ những rủi ro về an ninh, tích hợp hệ thống cho doanh nghiệp

Chuyển đổi số

SAVIS LGSP 2.0 giành TOP 10 Sao Khuê 2020

SAVIS trình diễn Hệ giải pháp chuyển đổi số tại Triển lãm quốc tế đổi mới sáng tạo Việt Nam 2021

Tiêu chuẩn đảm bảo an toàn trong giao dịch và thanh toán điện tử ngành Ngân hàng (Phần 2)

Không có dấu thời gian, các tổ chức Tài chính – Ngân hàng đang gặp những rủi ro gì?

Tags

APIAPIsBộ TTTTchinhphudientuChuyển đổi sốchữ ký sốDấu thời gianeIDASekycgiao-dich-dien-tugiao dịch điện tửHSMKý sốký số trên thiết bị di độngký số từ xaKý đóng dấu thời gianLTVlưu trữ điện tửlưu trữ điện tử lâu dàineobankNgân hàng Mởngân hàng sốOpen APIsOpen BankingOpen DataOpen Financepsd2QTSPRemote signingrủi ro định danh trong giao dịch điện tửSao Khuê 2020savisSAVIS DX Open Banking SolutionSAVIS eArchiveSAVIS SOCsmartekycthanh-toan-dien-tuTimestampTimestampLTVTop 10 Sao Khuê 2020trustcaTrustCA Timestamptài chính-ngân hàngxác thực tài liệu điện tửđịnh danh điện tử

Theo dõi chúng tôi

Đăng ký nhận tin tức

Email

Leave a Reply

Your email address will not be published. Required fields are marked *