Đ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ị:
- Tạo ra nguồn thu mới, thu lợi nhuận từ các API. Có nhiều hình thức khai thác API:
– 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
- Cải thiện dịch vụ và sự hài lòng của khách hàng: các API phải được thiết kế dành cho khách hàng, là dịch vụ có giá trị cho khách hàng
- Thu thập dữ liệu: Với càng nhiều dữ liệu khách hàng được thu thập, ngân hàng sẽ có được những thông tin chi tiết hơn và chất lượng hơn, từ đó họ có thể cải thiện doanh thu của mình (ví dụ: thông qua cross-selling và up-selling) cũng như chất lượng dịch vụ và sự hài lòng của khách hàng.
Đồng thời, một Open API phải đáp ứng các yêu cầu:
- Được theo dõi chi tiết và sát sao để việc sử dụng API
- Được thay đổi nhanh chóng theo yêu cầu. Tuy nhiên, định dạng API (giao diện yêu cầu và phản hồi được các đơn vị bên ngoài sử dụng) nên được thay đổi ít nhất có thể, cũng như, hỗ trợ các phiên bản trước nhằm giúp các đối tác không cần phải điều chỉnh phần mềm khi một phiên bản API mới được cập nhật/áp dụng.
- Đối tượng tiếp cận của các API, không phải cho các người dùng cuối – end-user truyền thống, mà là các công ty sáng tạo, những người có thể hợp tác cùng phát triển trong hệ sinh thái. Do đó, điều quan trọng là tạo ra một cộng đồng nhà phát triển thực sự, thường được thực hiện thông qua các sự kiện công nghệ, như ngày hội sáng tạo, hackathons, hội thảo trực tuyến… – nơi các ý tưởng về dịch vụ ngân hàng mới được kết nối với những nhà phát triển.
- Được hỗ trợ tốt thông qua các cổng thông tin dành cho nhà phát triển, cho phép mang lại trải nghiệm liền mạch nhất có thể. Một cổng thông tin như vậy sẽ cần đạt được những 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:
- Open Banking Working Group (OBWG) UK (http://theodi.org/open-bankingstandard)
- CAPS (https://www.caps-services.com/)
- Open Bank Project (https://openbankproject.com)
- Open API initiative (https://openapis.org)
- IXARIS Open Payment Ecosystem (https://www.ixaris.com)
- Open Financial Exchange (OFX) (http://www.ofx.net)
- Financial Transaction Services (FinTS) (https://www.hbcizka.de/english/)
- Banking Industry Architecture Network (BIAN) (https://bian.org)
- Berlin Group (http://www.berlingroup.org)
- W3C Web Payments Interest Group (https://www.w3.org/Payments/IG)
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:
- Bảng chức năng nào sẵn có
- Mô tả về quy trình
– 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.
- Cách API được thiết kế: Hầu hết các nguyên tắc thiết kế phổ biến được chuẩn hóa là REST (Representational State Transfer) và SOAP (Simple Object Access Protocol).
- Các điều kiện để sử dụng dịch vụ: Là quyền truy cập dữ liệu, xác định ai có quyền truy cập, dữ liệu nào có thể truy cập và cách thức đạt được mục tiêu này. Hầu hết các tiêu chuẩn phổ biến ở đây là SAML (Security Assertion Markup Language) và OAuth 2.0 (Open Authorisation).
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:
- Bảo mật: do các Open API được công khai nên thiết kế bảo mật cao là điều cần thiết để những dữ liệu bí mật không bị rò rỉ cho những đơn vị không liên quan hoặc tránh các cuộc tấn công DoS (trên các API) ảnh hưởng đến các hệ thống (quan trọng) khác của tổ chức.
- Linh hoạt để thích ứng: API phải linh hoạt để tùy chỉnh. Các lỗi trong API cần được khắc phục nhanh chóng, vì những lỗi như vậy không chỉ ảnh hưởng nội bộ mà còn tác động không nhỏ đối với các công ty đối tác bên ngoài khi sử dụng API đó.
- Dễ dàng triển khai: Ngoài sự linh hoạt, API cũng phải đảm bảo triển khai dễ dàng cho các nhà phát triển. Việc triển khai này sẽ được thực hiện mà không có sự gián đoạn về mặt thời gian và khả năng vận hành đồng thời hỗ trợ nhiều phiên bản của cùng một API.
- Tính khả dụng cao: do việc sử dụng các API rất linh hoạt nên tình trạng không khả dụng trở nên khó quản lý. Do đó, các API phải đảm bảo sẵn sàng tối đa, 24/7, trong trường hợp xảy ra sự cố không lường trước được.
- Khả năng mở rộng: vì API sẽ được sử dụng bởi nhiều bên thứ ba khác, do đó dung lượng sử dụng có thể tăng lên rất nhanh. Các API nên hỗ trợ tự động điều chỉnh (không down-time) các tài nguyên có sẵn dựa trên khả năng tải.
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:
- Định tuyến API: định tuyến các yêu cầu dựa trên nội dung, tiêu đề, danh tính của thông điệp và các yếu tố khác. Định tuyến API cũng phải hỗ trợ ưu tiên đối với các yêu cầu, dựa trên SLA được thỏa thuận với bên yêu cầu (API callers).
- Chuyển đổi & xác thực dữ liệu: yêu cầu phải được xác thực dựa theo cấu trúc và hỗ trợ chuyển đổi dữ liệu
- Công cụ đi kèm với một số trình kết nối tiêu chuẩn, cho phép API kết nối trực tiếp với các máy chủ email, cơ sở dữ liệu, hệ thống quản lý tài liệu…
- Quản lý bảo mật là chức năng quan trọng nhất của cổng API và cần đáp ứng các yêu cầu 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)
- API Repository/Registry: kho quản lý và lưu trữ tất cả các API có sẵn. Kho này cho phép tìm kiếm, xem chi tiết, quản lý API (kích hoạt/hủy kích hoạt, triển khai, quản lý truy cập), gửi thông báo khi API (phiên bản) mới được hoàn thiện…
- Cổng API: cung cấp một cổng trực tuyến an toàn cho các bên thứ 3 tích hợp, tạo ra một cộng đồng. Cổng thông tin này cần chứa:
– 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…)
- Các công cụ để dễ dàng thiết kế, xây dựng, lập tài liệu, thử nghiệm và triển khai các API (các API mới hoặc các thay đổi đối với các API hiện có)
- Giám sát và Phân tích API: bao gồm các hình thức giám sát API khác nhau như:
– 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…
- Khai thác API: cấu hình các chương trình thanh toán để kiếm tiền từ việc sử dụng API và tích hợp với hệ thống thanh toán tự động.
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
