Fintech觀察 | 擅用「虛擬銀行」，銀行或許能從數位化的浪潮中殺出一條血路！

2017年11月金管會正在準備開放申請「虛擬銀行」的事宜，許多業者對於此舉也抱持樂見其成的態度，吸引業者想要申請「虛擬銀行」的特點在於，他不需要增設分行據點，就能執行銀行的金融業務，其申請門檻100億元也較成立傳統型銀行來的低許多，對於缺乏金融交易體系的業者確實是一項利多消息，但「虛擬銀行」對於既有的銀行業者是否具有潛在的競爭優勢？銀行又該如何打造「虛擬銀行」的服務模式，來強化顧客體驗呢？

我們該如何如何打造「虛擬銀行」的服務模式呢？，首先我們可以試著檢視數位銀行的商業模型，來幫助我們釐清「虛擬銀行」的角色與定位。

2016年IBM新興數位銀行調查，將數位銀行的商業模式分為四個類型：

1. 數位銀行品牌(Digital Bank Band)

2. 數位銀行通路(Digital Bank Channel)

3. 數位銀行附屬子公司(Digital Bank Subsidiary)

4. 原生數位銀行(Digital Native Bank)

我們可以使用這個分類來檢視台灣銀行發展數位銀行的樣貌，例如大家所熟悉台新Richart就屬於第一類「數位銀行品牌」，王道銀行O-Bank則屬於第四類「原生數位銀行」。

而金管會正準備開放申請的「虛擬銀行」比較像是第三種類型：「數位銀行附屬子公司」，其主要的特點在於：「虛擬銀行具有獨立後台&後勤的運作機制」

這個特點能幫助銀行重新審視傳統的金融服務流程，試著以「數位網路」的思維去打造服務體系，傳統銀行的服務架構主要是以堆疊的方式進行，實體分行是最下面一層，當自動櫃員機(ATM)、客服中心與電子化通路出現後，就一層層的往上堆疊，造成彼此的系統架構並沒有產生連結，導致各系統的資料無法進行交流彙整，當客服人員接獲顧客詢問電話時，必須開啟多個服務系統，才能解決顧客的問題。

但若採用服務導向架構(Service-Oriented Architecture，SOA)架構去設計，將每項金融服務進行模組化、物件化，並以數位網路為基底，再經由API串接，將模組化的金融功能整合於同一個服務平台之中，客服人員只要使用此整合後的服務平台，就能快速瀏覽每個系統儲存資料，即時滿足顧客需求。

傳統IT在執行項目開發時，多半是採用「瀑布法」的方式，例如我們要打造一台機器人，先有一個完整的開發藍圖，然後檢視藍圖中每個項目的可行性，然後分階段的去打造機器人的頭部、手部、腿部等部位，最後再將這些部位組合起來，完成一台機器人。

但這樣的風險在於，當你在打造完成頭部時，發現與身體的部分無法整合，又或是打造完手部後才發現，市場上的機器人已經可以使用「噴射飛拳」的功能，因此「瀑布法」雖然給開發人員一個美好的想像，但實現的成果在市場反映上並不是這麼的美好。

而「敏捷式」開發，就是希望開發人員能夠快速製作出產品原型(Prototype)，並趕緊投入市場，來測試顧客的反映程度，再來修正與微調產品原型，這樣快速迭代的方式，非常適合應用於「虛擬銀行」的體系之中，由於打造虛擬銀行的過程是採用SOA服務導向架構，各種的金融服務流程可以被轉換成各模組，就如同手機的App一般，系統開發人員只要專注於物件內容的功能，流程規劃人員只要在整合服務平台上，將所需的物件納入其中，設計出一套服務流程，就能使物件彼此產生關聯，創造出不同的金融服務模式，因此當面對顧客的市場反映時，只要重新檢視整合服務平台中，每個模組中的內容、調整服務流程的痛點，就能即時因應市場變化、滿足顧客需求，強化顧客的體驗經濟。

由於虛擬銀行是使用「純網路」的方式執行金融業務，節省銀行開設分行的成本，若採用SOA服務導向架構來開發經營，也能幫助銀行拋開既有的系統包袱，打造一套全新的服務模式，對於銀行在執行數位轉型的業務，將會有不小的幫助，但回到上述那張IBM新興數位銀行調查的圖表，我們可以發現「虛擬銀行」雖然具有獨立的產品銷售與創新的通路模式，但缺乏專屬於自己的銀行章程規範。

因此金管會若要開放申請「虛擬銀行」的服務，可能要好好規劃，未來開放虛擬銀行後，虛擬銀行的業務屬於哪個主管機關負責查核？，其發生金融消費糾紛時該遵循哪條法源？等監督事宜，才能有效控管虛擬銀行可能產生的潛在風險。