API連携 (セブン銀行の事例)

日経XTECの平成30年4月19日付報道です。オープンAPIで先行する企業として、セブン銀、第一生命、JTBをあげて、この3社が外部企業のどこと接続してどんなサービスを提供しているかを簡単に紹介しています。そしてセブン銀がマイクロソフトのAzureを使って、どのような仕組みを作っているか海外送金の事例を通じて記載しています。

海外送金では、フィリッピンの大手銀BDO Unibankと提携しています。勘定系オンラインはオンプレですが、インターネットバンキング(IB)は、Azureのプライベート・クラウド上で作動しています。API関連は、スモールスタート基盤(SS基盤)として、AzureパブリッククラウドPaaS(西日本リージョン)を使っています。

SS基盤は主にアプリケーション制御と非同期処理管理などJob実行管理機能、そして顧客のスマホとの送受信を制御するAPI保護・管理機能と対顧客メッセージ送受信を制御するハブがあり、主にマイクロソフトが提供する機能を使います。SS基盤と顧客のスマホや提携銀行とは、HTTPS/JSONやSOAP/SFTPなど国際標準プロトコルで接続されます。つまり、外部との接続は標準プロトコルとPaaSで出来ているということです。わが国のオープンAPIのように、通信プロトコルに国際標準を使いながら、コテコテにビジネス・プロトコルと組み合わせて、カストマイズはしていません。送金という簡単なメッセージ交換だからできるのかも知れませんが。

(少し考えると、セブン銀のようなATMとネットチャネルしかないような銀行が、何故、一つのシステムにレガシー勘定処理とIB機能を一緒にしないのかと疑問が沸くでしょう。十数年前にそんなソリューションはなかっただけのことです。今でもないのですが。非銀行が銀行勘定系オンラインを作るには、既成のパッケージを使うしかなかったのです。ですから、従来銀行のツギハギと同じ構成になっています。すごいコストと手間です。正直なところ、クラウド使って凄いでしょう?と言われても!といったところです。)

IBとSS基盤はVPN接続です。海外送金に関わる口座情報と顧客情報をIBの中に持ち、必要に応じて勘定系の元帳と連携させます。どうも完全リアルタイムの元帳更新ではないようです。フィリッピンであれば時差がありますし、送金額に上限もありますから、割り切れるのでしょう。それと、顧客情報、IB口座情報はパブリック上に置かず、プライベート・クラウドに置いています。セキュリティ対策や何か起きた際でも即座に対応できます。

こうしたシステムをセブン銀は8ケ月で、一般的費用の半額程度で構築したといいます。新たに構築したのは、IB内の海外送金アプリとSS基盤の接続です。国内の大手IT企業に委託してオンプレで開発すると、機能を絞っても1年半〜2年、2、3億円といったところでしょうか?大手銀なら数十億円か。結論からすると、AzureのPaaSが威力を発揮したということになります。多くの銀行が今、進めているオープンAPIですと、最も単純な方式でNTTデータのANSER利用が多い。既にインタフェースがあるので初期費用はゼロ、ただし、従量制なので普及するほど割高になる、対象業務は単純な参照メッセージ交換のみです。対象業務が変わると、億単位のコストがかかるでしょう。戦略的なオープンAPIとはいえないので、制度対応APIと呼んでいます。

先程、Azureの威力と書きましたが、実は、この程度のインタフェースは海外のクラウドや業務パッケージでは当り前です。それに多くの関連コンポネントが国際標準プロトコルでOSS化されています。海外銀行が使うコアバンキング・システムの多くでも標準装備されています。海外ベンダーからすると、何故、日本ではオープンAPIの構築に大騒ぎをするのか理解できないそうです。筆者は、「すみません。お恥ずかしいのですが、日本の大手ITベンダーは英語ができないので、国際標準やOSSに疎いのです。それを出来る大手ベンダー技術者に委託すると、とても高くなるし、後で保守できないのです。日本の金融ITは、OECD相場から20年位ほど、遅れてしまいましたが、これからはもっと差が広がるでしょう。でも、お客である金融機関は今のベンダーから離れられないのです。ですから、日本で営業活動して、無駄な時間と費用を使わずに、よその国に行った方が良いですよ。」と忠告します。半分冗談ですが。

国内銀行のオープンAPIでは、外部接続も必要だが、内部APIの方が使い道が多いとする声が大です。データウェアハウスや内部データハブ基盤を高いコストをかけて作っている銀行もあります。外部接続も、対顧客のように単純なメッセージ交換や画一的な単純処理を行なうAPIもあれば、提携先の他金融機関や異業種企業との複雑なプロセス連携のAPIも必要となります。すると、オンプレ、プライベート、コミュニティ、パブリックの各システムにいかにデータとプロセスを配置するかということになります。

いろいろな業務種類やセキュリティ、トランザクション量の予測からすると、プライベート・クラウドかオンプレでやってしまった方が、長期的にはガバナンスも効き、コストも安くなるという考えも出てきます。TSUBASA共同では、FinTech基盤としてAPIとアプリケーションを共同開発しています。千葉銀行は今月16日にバージョン1を稼動させたと発表しました。これから、APIの対象や連動させるアプリケーションを追加していくのでしょう。特徴は、IB利用契約がなくても、顧客IDでFinTechサービの全てが使えるというユーザーインタフェースです。最大の要件である顧客認証が確実になります。IBシステムをこの基盤に移してしまうという考えも出てくるでしょう。

これも奇妙な話なのですが、多くの銀行はIBを法人向けと個人向けに分けて、NTTデータ、IBM、日立が提供するIBにクロスで委託しています。結果、似たようなサービスとユーザーインタフェースしか提供できません。それが問題とならないのは、IB利用者が少ないことと、顧客が多くをIBに望んでいないことがあります。ところが、スマホの普及とFinTechによる他業種との連携がその様相を変えつつあります。IBの柔軟性、処理能力、コストなどが新たな課題となってきました。

そのIBを、ベンダーに頼んでスクラッチで作ると、これが、また、極端に高い。見積りを見て「あれ、酔っぱらって見積もったの?○が二個多くないですか?」ところが、ベンダーは大真面目。テストや何やら積み上げると、そうなるのだそうです。わが国の金融ITは何がずれてしまったのか?それを改善するには何が必要なのか?オープンAPIのオープン(ベンダー)化が必要なことは確かです。

ベンダーにはこれまでの経験や社内の常識を忘れることが望まれます。昔の成功体験にこだわる上司は消してでも。ユーザーには自分でコーディングしなくても良いから、クラウドやOSSを前提としてアーキテクチャを設計できる力が必要です。銀行を辞めてでも海外に留学して勉強すべきです。銀行が、そのスキルを得るのに5年かかるとすれば、その間に海外のスピードからして、20年の遅れが30年、40年と広がることになります。セブン銀などネット専業銀行に頑張って欲しいところですが、大半のネット銀は10年以上を経過した勘定系の古いアーキテクチャに身動きがとれずにいます。ツギハギを続けざるをえません。金融行政としては、もう一度、銀行新設ブームを作り、認可の条件として、旧来のアーキテクチャやガバナンスを禁止するという方法が最も手っ取り早いようです。

                       (平成30年4月19日  島田 直貴)