深入淺出：我們應該怎樣理解金管局 API 的用途、藍圖，以及對銀行業界的影響－還有，這跟我們常說的「fintech」有關嗎？

最近金融界動作頻頻 ，三間發鈔銀行推出各款紙鈔的新面貌，其中以 $1000 象徵「國際金融中心」。說起來可惜，香港作為「國際金融中心」，在「開放數據」方面仍然相當落後。

近幾年，「fintech」這個詞語在金融界甚至整個香港已經並不陌生。Fintech，就是「Finance」+ 「Technology」，兩者在本港都開始有疲弱跡象。尤其是銀行和金融界，雖說要大力推廣 fintech，但是一直未見官方和各大銀行支援的 API，以致開發者難以研發真正的技術。

不過欣慰的是，金管局在 7 月 18 日發佈了一系列銀行業開放應用程式介面（API），而且還在 2018 年 7 月 23 日開始提供開放 API。

有人可能會問：

「開放 API 有咩用呀？」

開放 API 的好處，是能夠讓第三方服務提供者（甚至是你設計的程式）與銀行系統直接溝通，把銀行功能集中於同一網站或應用程式上。例如你是一個電影 App 的開發者，你的電影網站／手機程式可以直接查詢官方最新的信用卡優惠資料，從而推薦使用者使用最合適的優惠。到以後的 API 發展成熟，開發者甚至可以設計類似 Apple Pay 或是 Pay Me 的應用程式，指示銀行轉賬或作金錢管理。

那我可以動手寫我的「PayMe」 了嗎？

2018 年 7 月這次，其實只釋出了計劃中約四分一的 API （稱之為第一階段 API）。至於令人引頸以待的交易類 API， 則定於比較後期的里程碑。

馬上想動手寫類似 PayMe 工具的開發者，或者可以考慮加入有「儲值支付工具持牌人」牌照的機構。（下文會提到）

那有甚麼 API 開放了？

總括來說，HKMA 的開放 API 主要分為兩大種類，分別是：

• 主要銀行項目（例如個人戶口、信用卡）；
• 其他業務（例如投資、保險等）

以上主要是金融管理局轄下的管理項目，至於屬於其他機構管理的金融資訊例如股票數據、強積金數據等等並未有包括在內。

這次稱之為第一階段的 API， 主要用來查詢產品和銀行資料，看起來是前導性質居多。由於金管局本身直接處理的資料並不多，要真的令這些 API 有實戰用途，要靠業界和銀行參戰。

至於全部四階段的 API 路線圖包括：

• 第一階段 – 產品資料；
• 第二階段 – 產品申請；
• 第三階段 – 帳戶資訊；
• 第四階段 – 財務交易。

（看起來像把 CRUD 分段實行，最終目標是開放網上理財的大部分 API。）

隨著金管局開放 API 框架的正式發布，金管局預期銀行會配合於 6 個月內推出第一階段及 12 至 15 個月內推出第二階段的開放 API。

實戰例子：API 究竟可以做甚麼？

說了那麼多，現在一起先睹為快，看看金管局的 API 究竟能幫助開發者做些甚麼。

第一階段： 查詢產品資料

究竟甚麼屬於產品資料？ 看一看官方網站上面的指引，其實大多數也是金管局網站本身已文字顯示的數據，現在釋出以下各個 API。大家已經可以直接拿來試玩：

• 市場數據與統計資料
• 銀行及儲值支付工具相關資訊
• 新聞稿
• 匯思
• 收銀車日程表
• 招聘

現時已開放的第一階段 API 主要是 READ ONLY 的數據 （俗稱 CD-ROM），能用作查詢產品和銀行資料。雖然實用程度不高，數據種類也有待增加，但相對令人滿頭問號的香港政府 Open data 用 XLSX 格式來「開放」 數據，HKMA 提供的 API 格式以 JSON 為回應，實在友善得多。

以類似的「流通貨幣及利率的統計數字」數據來看，政府 Open Data 只提供了 XLS 檔案，如果要做查詢的話，就要自行用程式／數據庫去處理。

Gov open data 的例子：

驟眼看，現時比較有趣的資料有：儲值支付工具持牌人紀錄冊、匯率及港匯指數、收銀車日程表等等。

除了開放 API 接口，HKMA 還提供了 API tester，例如我們想查詢現時有甚麼儲值支付工具持牌人：（所以可以去應徵寫）

接著看一看有甚麼在銀行擁有儲值支付工具牌照，我們修改一下「區段」的 parameter：

沒錯，可以看到匯豐 HSBC也有這一個牌照（所以 Payme 是合法的啦 ← 廢話）

由於各個 API 都有不同的用法和 parameter，HKMA 提供的 API docs 讀起上來尚算清晰。 另外，還提供了 JavaScript 和 Python 的基本 Sample Code。

如果用 curl 或者其他程式來 call 這個 API，會得到這樣的回應：

整理一下，比較好看的格式：

{
    "header": {
        "success": true,
        "err_code": "0000",
        "err_msg": "No error found"
    },
    "result": {
        "datasize": 13,
        "records": [{
            "name": "三三金融服務有限公司",
            "local_address": "香港九龍尖沙咀廣東道33號中港城第一座2001室",
            "licence_no": "SVF0010",
            "effective_date": "2016-11-04"
        }, {
            "name": "Alipay Financial Services (HK) Limited",
            "local_address": "香港銅鑼灣勿地臣街1號時代廣場1座26樓",
            "licence_no": "SVF0004",
            "effective_date": "2016-08-25"
        }
         .... (省略部分機構)
        {
            "name": "WeChat Pay Hong Kong Limited",
            "local_address": "香港灣仔區皇后大道東1號太古廣場三期29樓",
            "licence_no": "SVF0005",
            "effective_date": "2016-08-25"
        }]
    }
}

開發者就這樣可以用 API 回應的資料，顯示在自身的應用程式上。

或者儲值支付工具持牌人這個 API 實在太沒用了，也可以看看今次其他開放了的 API ：

這方面的 API 適合用來做資訊性的應用程式，例如匯率及港匯指數等，但相比其他機構（例如 X-rate 的 API 或者 xe 的 API 來說，實在還算是「弱雞」。

然而不少銀行也有開放一些數據資訊，例如匯豐的匯率數據。但是這些數據通常只是方便用會參考，只有圖像形式，不方便做 API call。

如果有了更多的 API，就更方便開發出便利市民的應用程式：

• 例子1：即時匯率換算計算機
• 例子2：「附近邊度有提款機」 位置導航手冊

或者你會問：What’s Next?

其中一個值得稱讚的地方是，金管局不但公開了API，而且還提供了里程碑和時間表（雖然還是有點遙遙無期）。

根據 2018 年 1 月金管局發佈的《Open API Framework 諮詢報告》，裡面談及了接下來的三個階段，以及一些技術討論：

第一階段 (已推出) – 產品資料

第一階段好像完成率只有一半半。保險箱地點及資料、銀行 ATM 資料這些最實用的資料暫時欠奉。當各大銀行提供了更多產品資訊是，就能更方便消費者對比儲蓄戶口、投資戶口等等收費和利率資料。

第二階段 (將推出) – 產品申請

第二階段的 keyword 是 「Process … opening request」，意味著用戶可以透過這階段的 API，以第三方的應用程式去遞交各種開戶申請。

現時已經有公司支援網上申請信用卡和銀行帳戶的功能，未知開放 API 會否能進一步推廣網上申請銀行服務的方便性？

第三階段（未知何時推出） – 帳戶資訊

第三階段的 keywords 是「Retrieve … account details」。跟第一階段的「Retrieve … details 」不同，這次的資料是戶口的資料，因此用戶可以透過這些 API 去查閱自己帳戶的交易紀錄、戶口資訊等。

這些 API 讓應用程式能以用戶身份查詢賬戶內的資訊，開發者從而可以開發更多貼身定制的財務管理程式。

輕輕構想一下，有這些程式也相當不錯：

• 信用卡還款提醒app：透過 API 讀取各張截數及繳款日，集中提醒用戶何時還款及還款金額；
• 信用卡財務管理：透過集中分析各張信用卡的帳單，顯示用戶消費習慣及提供財務管理提示。

第四階段（未知何時推出） – 財務交易

第四階段將完成最重點的功能 －「轉賬」。

但是究竟「轉賬」是支援同一戶口、同一銀行、還是本地所有銀行，現在還未知道。根據路線圖，第三和第四階段的預計開放日期，要留待 2018 年 Q4 討論。 就此推算，這一部分的 API 未必會在 2020 年前完成。

透過這部分的 API， 可以簽發和處理 e-Cheque、繳交帳單、處理轉賬等等；大致上可以讓用戶透過所屬銀行直接付款給朋友，可以幻想像手機就是流動的 ATM （應該不能提取現鈔吧），絕多數銀行的服務也能透過手機上去完成。

安全性

開放 API 另一個好處是能夠 standardize 安全性的規範。

由於涉及到金錢，安全性方面也用到最常用的規範：例如 X.509, TLS 等等。 至於用戶登入則要依賴銀行本身提供的方法。

總結

【TLDR】給直接跳到這一段的讀者－這次的簡單總結如下：

金管局在 7 月 18 日發佈了一系列銀行業開放應用程式介面（API），四階段的 API 路線圖包括：

• 第一階段 – 產品資料；
• 第二階段 – 產品申請；
• 第三階段 – 帳戶資訊；
• 第四階段 – 財務交易。

第一階段 API 已經 on live，主要是 READ ONLY 的數據，實用程度並不算高；
除了開放了 API 接口，HKMA 還提供了 API tester；
HKMA 提供的 API 格式，以 JSON 為回應，對開發者算是友善；
其中一個值得稱讚的地方是，不但公開了API，而且還提供了里程碑和時間表。

作為開發者來看，這些 API 也有可以改進的地方：

• 期望資料能夠更加實時，例如匯率／報告等等現在只有一個月或是一天的概覽，沒有甚麼實際可以應用的地方，或者市場上已提供更好的 API
• 希望有更多種類的資訊，起碼 ATM 位置、分行開放時間等等更貼地的資訊

到底… 開放 API 算是 fintech 嗎？

簡單來說，開放API 算是為 fintech 提供基建，就像鋪設海底電纜一樣。金管局走出的第一步，算是為業界訂好一個範例。金管局並非強制銀行參與開放 API，主要是提供政策指導方向，以及以開放 API 來提供技術上的參考。但實際推廣，則要靠各間銀行實行。

假如將來銀行業界陸續開放他們的 API，開發實用且安全的 fintech 應用程式的門檻就變得更低了。

開放 API 將會影響到金融業界的發展－ 以前真的沒有想過 QR Code 可以用來付款，誰曉得我們十年後付款模式的可能性？

關於 fintech 的更多技術細節和政策，將來金管局還要探討以下問題：

• 金管局會否先導 E-wallet 的發展？
• 怎樣為 TSP （Trust Service Provider） 提供認證？

延伸

新加坡 The Association of Banks in Singapore 就銀行 API 出版了一本《Finance-as-a-Service API Playbook》，討論設計相關 API 時要注意的細節，相信能提供不少參考價值。

Oursky 致力幫助品牌與企業家實現他們的點子。如果你正在尋找合作夥伴一起建立下一個自家數碼產品，來跟我們聊聊吧！