第三章 比較法分析：類型化各國 Open banking
第三節 業者自律模式
Digital Government）」的願景努力209。新加坡在開放銀行概念的發展上，最初係由政 府部門資料的開放，再慢慢擴及至銀行資料的開放。
新加坡財政部（Ministry of Finance, MOF）基於「透過分析、研究及應用公共 資料，為新加坡創造經濟和社會價值」的目的，2011年發布了開放資料平台
（data.gov.sg.），允許外界獲取新加坡政府70多個部門的公共資料集210。該平台也是 新加坡2010年「eGov2015」計畫的一部分，該計畫的目標是建立一個「與人民聯結」
的政府211。2013年新加坡訂定資料分享原則（Data Sharing Principles），指導政府相 關部門應該使政府公開資料易於取得、即時發布、可用於共同創作、以機器可讀的方 式分享以及盡可能保持原始資料212。同年3月新加坡政府為了解決每個政府機構都有
209 Smart Nation Singapore, TRANSCRIPT OF SPEECH BY PRIME MINISTER LEE HSIEN LOONG AT SMART NATION LAUNCH, Nov. 24 2014,
https://www.smartnation.sg/whats-new/speeches/smart-nation-launch/ (last visited: 2019/11/12).
210 Data.gov.sg, https://data.gov.sg/about (last visited: 2019/11/12).
211 Hallam Stevens, Open data, closed government: Unpacking data.gov.sg, 24(4) First Monday (electronic version: https://firstmonday.org/ojs/index.php/fm/article/view/9851/7746 ), (2019).
212 Data.gov.sg, supra note 210.
‧
一套自己驗證用戶身分的憑證造成民眾的不便213，推出Sing Pass（Singapore Personal Access）數位身分系統214，該系統由新加坡政府技術局（GovTech）管理，Sing Pass 用戶可以藉由該系統與60個政府機構進行線上交易215。在新加坡財政部與資訊通信發 展管理局（Infocomm Development Authority of Singapore, IDA）共同努力下，新加坡 於2016年05月05日發布了「MyInfo」數位平台，將新加坡民眾過去於各個政府機構填 寫的個人資料（如姓名、地址、NRIC號216）整合，民眾在線上填寫不同政府機構的 資料表時，使用SingPass登入個人Myinfo帳號即可自動匯入個人資料，不必一直手動 重複填寫217。SingPass使用者可自由決定是否使用MyInfo平台，但2017年時MyInfo與 330萬SingPass使用者帳號強制綁定，SingPass使用者無法退出此項服務，新加坡政府 技術局表示此係為了達成建立國家數位身分（national digital identity）目標的必要之 舉218。關於Myinfo可以使用的場合，其最初僅適用於政府相關服務，如供民眾申請看 護、申請國宅以及申請育兒津貼等，但後來也漸漸擴及至民間企業——2017年5月由 華僑銀行（OCBC Bank）、大華銀行（United Overseas Bank）、星展銀行（DBS Bank）
以及渣打銀行（Standard Chartered）等四家銀行先行採用於信用卡申請以及帳戶開戶 服務上，花旗銀行（Citibank）、匯豐銀行（HSBC Bank）、馬來西亞銀行（MayBank）
以及美國運通（American Express）等四家機構也在2018年上路219。
新加坡金融管理局（Monetary Authority of Singapore, MAS）於2015年成立金融 科技與創新團隊（FinTech and Innovation. Group, FTIG），該團隊主要負責制定針對
213 Kwok Quek Sin, Inside Singapore’s National Digital Identity programme, Sep. 3 2019
https://www.techradar.com/news/inside-singapores-national-digital-identity-programme (last visited:
2019/11/12).
214 類似我國的自然人憑證。
215 Sing Pass, About us, https://www.singpass.gov.sg/singpass/common/aboutus (last visited: 2019/11/12).
216 即新加坡國民身分證號。
217 Eileen Yu, Singapore government assures SingPass-MyInfo will stay secure, Sep. 30 2017,
https://www.zdnet.com/article/singapore-government-assures-singpass-myinfo-will-stay-secure/ (last visited:
2019/11/12).
218 Id.
219 Lester Hio, MyInfo access extended to local businesses, Nov. 10 2017,
https://www.straitstimes.com/singapore/myinfo-access-extended-to-local-businesses (last visited:
2019/11/12).
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
金融科技新創產業的監理政策以及發展策略，下設的四個部門也對於金融領域的支付、
大數據、人工智慧等議題進行政策制定與協助220。2016年11月，MAS以及新加坡銀 行公會（the Association of Banks in Singapore, ABS）聯合發行了《金融即服務API手 冊》（Finance-as-a-Service: API Playbook，以下簡稱《手冊》）。
第二款 《金融即服務API 手冊》
《手冊》有別於歐盟與英國的開放銀行只專注於金融相關、甚至是只有支付相 關的API，其自5636個商業流程中篩選出涵蓋銀行、保險公司、資產管理公司和政府 機構等不同領域的411個API。 這些API按照其功能被歸類成產品、市場行銷、銷售、
服務、支付以及監管等不同類型。
第一目 API標準
在架構選擇上，由於新加坡的開放資料並不限於銀行產業，《手冊》提出了API 兩種常見的架構，即SOAP以及REST兩種架構，並按照其特性說明兩種架構分別適用 於何種情形。
《手冊》指出，若提供的服務需要一定的安全性保證，SOAP有提供如
WS-Reliable Messaging之類的功能，若相關應用軟體需要管理對話狀態及上下文資訊
（contextual information），或是須要讓從伺服器端產生的中繼資料（metadata）產生 客戶端，則採用SOAP較為合適；另外，因為REST使用GET、PUT、POST和DELETE 等用語，在返回結構（return structure）並非開發人員定義的特定格式時任何瀏覽器 皆能使用，因此在頻寬和資源較為有限時可以使用REST，且若須要創建、讀取、更 新和刪除（CRUD）資料、資料緩存以及伺服器對伺服器（server to server）的服務時，
220 MAS, Fintech and Innovation Group,
https://www.mas.gov.sg/who-we-are/Organisation-Structure/Fintech-and-Innovation (last visited:
2019/11/12).
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
採用REST架構亦較為適合221。
第二目 資料標準
考量新加坡金融服務環境中許多機構都有自定義的資料格式，為了使開放資料 更加便利，新加坡政府對資料進行標準化勢在必行222。建立一個資料標準的優點在於，
在兩個（或者更多）團體希望分享資訊時，可以讓資料分享方知道什麼樣的資訊應該 如何被記錄，資料獲取方從而可以更有效利用該資料。
《手冊》認為，若新加坡建立一個資料標準，不但可以提高資料的品質以及可 信度，尚可以藉由提供對特定允許的程式碼的維護與管理，保證程式碼的恆定性，同 時也可以透過提供常見的資料元素翻譯組合，提升多對多對應（mapping）的效能223。
《手冊》中亦介紹了多種資料資料標準，包括：適用於廣泛服務以及金融資料的XBRL
（eXtensible Business Reporting Language），常見於稅務、金融主管機關與監管機構 間進行資料交換，公司財務業務報告，信用風險評估報告以及會計文獻等；OFX（Open Financial Exchange）可應用於銀行轉帳，股票、債券、基金投資，下載稅務、貸款以 及抵押等資料；ACORD XML底下的ACORD P&C XML、ACORD Life & Annuity Standard以及GRLC三種標準；以XML為基礎架構的FpML（Financial products Markup Language），常用於衍生性金融商品的資料交換並作為監管報告的資料框架；
EDIFACT （ISO 9735）是一種交換結構化資料的目錄，可應用於保險公司與政府機 構（如警察機關、監理站）交換民眾汽車詳細資料等情形；FIX（Financial Information eXchange）是一種適用於全球金融交易的資料交換標準，可以應用於交易前（如交換 市場資料及報價）、交易中如交叉訂單（cross orders）224、一籃子訂單（basket orders）
221 MAS & ABS, Finance-as-a-Service: API Playbook, Nov. 2016, at 21.
222 MAS & ABS, supra note 221, at 26.
223 Id. at 27.
224 將股票交易所中的買入訂單與以相同價格賣出的訂單相匹配，因此無需在公開市場上執行。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
225等，以及交易後如抵押品的管理；MDDL（Market Data Definition Language）常作 為交換會計、分析以及金融交易相關資料的標準；可應用於單點登入、授權服務以及 後台交易的SAML 2.0（Security Assertion Markup Language）；以XML為基礎架構的 ISO 20022，普遍適用於支付、卡片交易及證券等金融領域；為了標準化國際組織及 其成員國間的原始統計資料而創造的SDMX （Statistical Data and Metadata eXchange）；
以及HL7（Health Level 7），多供政府機構分享消費者臨床資料給金融服務公司以進 行承保、索賠處理和監測是否有詐騙行為226。
雖然《手冊》中介紹許多資料標準，但由於因為資料交換目的、應用於不同產 業或是特定區域限制等不同因素影響，其並未直接建議應該採用何種資料標準，而是 指出不同資料標準的特性以及適用的場域讓企業自行選擇。
第三目 安全標準
《手冊》中介紹了四種安全標準，包含：OAuth 2.0、OpenID Connect、SAML 2.0，
以及其推薦採納的雙重驗證（Two Factor Authentication, 2FA ）。《手冊》認為，即 便2FA驗證並非牢不可破，但由於登錄需要兩組不同的憑證，大大增加惡意第三方訪 問系統的難度；且2FA的註冊過程十分便利，確保安全性的同時也提供出色的使用者 體驗227。
但採納2FA驗證也將產生以下挑戰。首先，獲取實體令牌（physical tokens）非 常耗時，用戶可能必須花許多時間等待以獲取其擁有的敏感資料；另外，若2FA執行 中發生錯誤，如：2FA驗證過程存在漏洞，則整個安全驗證將失去效用；依賴第三方 身分驗證提供程序也可能導致漏洞，若第三方提供的物理或軟性令牌（physical or soft
225 買賣一組證券（通常是衍生性的金融商品）作為一個單位的訂單。機構投資者常發出一籃子訂單，
以便在一筆非常大的交易中只支付一次手續費。
226 MAS & ABS, supra note 221, at 30.
227 Id. at 36.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
tokens）安全性受到破壞，可能會渲染（render）個人資料，導致用戶最終不願意採 用其他身分驗證方法228。
簡言之，由於利用2FA的優點遠超過其隱含的風險，可上述風險大部分可以透 過適當管理、執行2FA機制減輕，故《手冊》仍建議採用2FA作為安全標準。
第三款 執行現況
2017年新加坡最大的銀行星展銀行（DBS）推出了API開發平台，用於其自己 的數位銀行和著名公司如AIG、麥當勞、MSIG、PropertyGuru，以及包括新創公司如 ctivpass、FoodPanda、Homage和soCash在內的共50多家公司，尋求為客戶帶來更多便 利的解決方案229。以麥當勞為例，其在新加坡每週服務約120萬人次的客戶，其使用 PayLah! payments類別下的API，增加了McDelivery用戶無現金支付的選擇，加快付款 流程230。
MAS則建立了一個金融產業API登記系統（Financial Industry API Register），
該登記會隨著各個金融機構提供其開放式API的不斷更新，涵蓋用於交易、服務、市 場行銷、產品、監管等面向的API。這些開放式API大致上可以分類為兩種類型：第 一種為交易性API（Transactional API），包含較為敏感的客戶端資料，需要用戶或合 作夥伴身分驗證；另一種則是包含非敏感性的資料，不需要、或是只須最低程度身分 驗證的資訊性API（Informational API）231。截至2018年11月，總共已有313API登記在
228 Id.
229 DBS, Reimagining banking, DBS launches world’s largest banking API developer platform, Nov. 2 2017 https://www.dbs.com/newsroom/Reimagining_banking_DBS_launches_worlds_largest_banking_API_develo per_platform (last visited:2019/11/19).
230 Id.
231 MAS, Financial Industry API Register,
https://www.mas.gov.sg/development/fintech/financial-industry-api-register (last visited:2019/11/19).
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
案232。
深究新加坡推動開放API政策的目的，其實是藉由資料的共享激勵金融創新的 發展，並非以之改變銀行業的市場競爭狀態233。
深究新加坡推動開放API政策的目的，其實是藉由資料的共享激勵金融創新的 發展，並非以之改變銀行業的市場競爭狀態233。