先日2018年６月1日に施行された改正銀行法に焦点をあてシリーズで解説してきた「変わる銀行法シリーズ」。最終回は、マネーツリーの共同創業者の一人で、Fintech協会のAPI・セキュリティ分科会の立ち上げを担当した理事として、政府と金融機関の調整も行っているマーク マクダットに、多様な角度からオープンAPIの未来についてお話を伺いました。
新たなテクノロジーを採用し全く新しい金融サービスを提供する金融機関は、「Neobank」と呼ばれることが多いです。
このNeobankという観点では、ドイツの「N26」がよい事例でしょう。Webサイトも日本で見かける銀行と異なり、ECサイトのようなシンプルなデザインを採用しています。「Pricing」というメニューをご覧になると、9.9ユーロ/月の有料サービスでは、携帯電話の盗難防止保険や旅行保険といった付加価値を提供する仕組みを用意しています。
わたしは地方銀行経営者に「消費者が望むサービスを提供すれば、人は集まる」と話してきました。現在のマイナス金利時代は預金業務も厳しい状況です。そこでN26のようなモバイルデバイスを窓口とした銀行で、クレジットカード業界のように前述の保険サービスやブランド構築に注力する金融機関が増えてきました。
国内では住信SBIネット銀行が同様の取り組みを始めました。税込み月額540円で日経Deep Oceanによる金融・経済分野の情報提供や、Visaデビットカードポイント還元率0.4%アップなど4種類のプレミアムサービスを提供します。このように金融機関は新たな収益を生み出すビジネスモデルを考える必要があります。また、顧客側も貯蓄による資産運用は難しいでしょう。だからこそ、政府もNISA(少額投資非課税制度)のように「貯蓄から投資へ」促しているのです。
現在、銀行が提供するAPIとして中心になっている参照系APIの目的は、残高や明細などの情報の収集と提供にあります。しかし、銀行が参照系API基盤を提供し、一般的な家計簿アプリ(アプリケーション)と接続しておしまい、では面白くありません。確かにAPI基盤の整備は費用が発生します。尻込みする銀行も少なくありませんが、それはAPI基盤の活用で創出できるビジネスに気づいていないからです。
銀行側にも既存の勘定系システムと、異なるシステムを連携させたいという需要がありますが、従来はSIer(システムインテグレーター)を招いて独自開発を行うのが一般的でした。そういった話を関係者から聞きますと、20世紀で発想が止まっているという印象を拭いきれません。銀行内のインフラ(基盤)が最新技術を活用していないのです。
「銀行法等の一部を改正する法律(通称: 改正銀行法)」の施行で最初に注目を集めるのは、口座情報や入出金情報を取得する参照系APIですが、既に会計ソフトや家計簿アプリで活用されています。しかし、APIの組み合わせでユニークなサービスを作るマッシュアップ(Web上に公開情報を加工・編集することで新サービスを生み出す)が重要なのです。
銀行が新サービスを構築する場合、要件定義から始まるウォーターフォール型でしたが、例えばスマートフォン用アプリに複数のフィンテック(Fintech)をはじめとしたサービスをAPIベースで組み込み拡張していくことができます。包括的な認証基盤は前提となりますが、APIを組み合わせることで、新しいビジネスの創出につながります。
三菱UFJフィナンシャル・グループは2018年5月に、今後6年間で従来型窓口の店舗を半減、店舗数は2割減とする店舗戦略を発表しました。昨年2017年も9,500人分の業務を削減する方針を明らかにしています。我々がいつも述べているのは、「銀行はネットバンキングに限らず、チャネル(店舗)としてアプリを用意すべき」だと。アプリが銀行の1チャネルとなり、多様な取り引きを実現するために、複雑なAPIによる連携は欠かせません。だからこそ、アジャイル型開発(短い開発期間単位を採用し、リスクを最小化する開発手法)を可能とするAPI基盤への投資が重要な意味を持つのです。
そして、これはわたしが未来の銀行の一つの姿として提唱している「デパート銀行」の考えにも繋がります。デパートに並んでいる商品は、デパートが自ら作り直接販売しているものではなく、アパレルやメーカーが開発かつ製造し店舗で販売しています。顧客は「このデパートなら間違いない」と考え信用して買い物をします。また、顧客対応もデパートが基本的に担当します。このように既存の金融機関は、長年培ってきた顧客基盤や信用力という資産を活用して、フィンテック(Fintech)企業などに「場」を提供できると考えています。
2018年現在、既に利用可能になってますが、現段階ではユーザー体験は疑問です。例えば、今言われている更新系APIは、まだ一部銀行側の認証を通すプロセスが発生します。もちろん認証が役立つことは否定しませんし、数十万という金額を送金する際は、確認プロセスは有用でしょう。しかしながら、すでに送金したことがある送金先に関しては、履歴などを参照してスキップする仕組みがあれば、ユーザー体験も向上します。また、更新系APIは資金移動に限ったことではありません。例えば、住所変更もあります。世間では更新系APIに対応したニュースが多く出てきており、これで完了したと勘違いしがちです。しかし、これからブラッシュアップしていく必要があるのです。
このブラッシュアップが"銀行の差別化"を生み出します。ご自身のことを振り返ると分かりやすいのですが、同じモノが2つあった場合は便利な方を選ぶでしょう。このように消費者が望んで使いたいと思えるユーザー体験が重要です。「APIを用意した」で終わるのではなく、アジャイル的にAPI基盤へ投資する必要があるのです。
課題はどのようなAPIが行内で必要とされるか銀行自身が定義していない点でしょう。今後どのような利用シーンが生まれるか分かりませんが、「拡張性のあるAPI」が重要と考えます。メガバンクならイノベーション推進室などを設ける余裕がありますが、地方銀行はベンダー製勘定システムを使うことが多いため、どのベンダーがユニークなAPI基盤を提供できるかと、銀行ではなく"ベンダー間の競争"が発生するかも知れません。
他方で非対面認証という課題も残っています。インターネットバンキングの契約率は低く、地方銀行では新規顧客の契約率は一桁という数字も珍しくありません。その理由はさまざまですが、ATMと店舗が便利すぎて不要という意見があります。
ウェブやスマートフォンアプリの「Moneytree」は、店舗を置き換えることを目的にしたものですが、口座番号と第一暗証番号があれば情報は取得できます。今まで多くの銀行APIで連携しているのはインターネットバンキングで基幹システムとの連携は多くありません。そもそもインターネットバンキングと基幹システムの直接的な連携は多くないのです。ここをインターネットバンキングではなく、基幹システムからの取得を目指しています。インターネットバンキングに依存することで、「利用できない」では面白くありません。この部分の改善を金融機関と共に取り組みたいと考えています。
先ほども述べたように、今まで多くの銀行APIはインターネットバンキングと連携しそこで管理されています。その場合、インターネットバンキングのベンダーを変えた時に問題となるのが、既存のトークンを異なるベンダーのシステム間で移行できるかという点です。つまり、ベンダーロックイン(他ベンダーのサービスやシステムへの乗り換えが困難になる状態)が発生します。「デパート銀行」という文脈で述べますと、現在デパートを運営しているビルを立て替えた際に、入居店舗と個別に契約しなければならない状態。つまり「デパートが建物と土地を所有しているか否か」です。
APIはベンダーロックインを破壊する可能性を秘めています。もちろん今日明日ではなく、10〜20年かかるかも知れません。銀行が勘定システムレベルでAPIを用意すれば、他の企業へもリソースの提供が可能となります。今までは専用線を使ってベンダー経由の情報を提供した銀行も、オープンAPIと認証システムを供えれば、ベンダー経由ではなく各企業と直接対話可能となるでしょう。
ただ、銀行自体がAPI基盤を持つのが理想ですが、現在のプラットフォーム型APIは素早い実装が可能ながらも、APIエコノミーの観点から見れば1つ落とし穴があります。銀行改正法におけるAPI実装を行う場合、契約内にトークンを動かせる権利を銀行が保有するか確認しなければなりません。トークンを自行のものとして制御できるようにすべきでしょう。
他方で、我々が銀行へ提案する際はベンダーが障壁になることもあります。詳細は割愛しますが、我々や銀行がAPI基盤の設置を望んでも、ベンダーが納入したシステムが原因で計画が頓挫することもありました。すると銀行側から見れば各企業と連携したビジネスチャンスを逃すことになります。だからこそ、銀行が自ら「企画力を強化」しなければなりません。
海外と日本の銀行を比べると顕著です。さまざま社会背景がありつつも、海外はエンジニアを育成する土壌が必要だったのでしょう。日本の銀行も保守的な姿勢では生き残れません。プログラミングを知識として備える行員を用意し、ある程度の内製を可能にすべきです。
例えば「ビジネスプロセスの中間にオープンAPIを利用すれば、A社のデータと組み合わせられる」など、仕組みを理解していれば、コードを書けなくても視点が広がります。企画部や商品開発部の方は、オープンAPIに関する知識を持った方が、多くのビジネスチャンスにつながるでしょう。ただし、基盤部分はエンジニアを雇用してでも内製化すべきです。米国では銀行を買収し、APIで収益を得るコミュニティバンクが増えており、先ほど述べたNeobankの形を実現し始めました。
多くの地方銀行は地元密着型ですが、オープンAPIの普及に伴い、物理的な距離や壁がなくなっていくのでは、と考えています。例えば九州は11の地方銀行があり、統廃合が進んでいますが、オープンAPIの活用でグループ活動を可能にすれば、各地方銀行が互いに支え合うこともできるのではないでしょうか。病院でセカンドオピニオンを行うように、九州と北海道でローン申請を可能とするなど、日本の経済全体に好影響を与えられます。
話は変わりますが、銀行の統廃合に1つの傾向があることにお気付きでしょうか。個別の行名は割愛しますが、(土地の名前を含めない)「地方性の欠落」が顕著です。この流れは地方銀行にとどまらず、信用金庫にも広がるでしょう。採算基盤の強化はもちろん、IT予算の増加はAPI開発機会を増やし、TCO(総所有コスト)の削減など、エコノミーオブスケール(規模の経済性)を実現します。
経験された方はご承知のとおり、銀行口座の作成は非常に時間がかかります。ある銀行には店舗の待ち時間対策として、長時間座っても疲れないようにソファを用意していたりします。しかし、解決はソファではなく待たせない仕組みづくりです。季節的に住所変更や名義変更で混む時期がある。であれば、APIで解決できないか、待たせないようなAPIは何のかを考え、そこに投資をするべきでしょう。
ニューヨーク州のとある銀行は、最初に仮登録として口座を開設し、5万円までしか利用できないと。その上で利用履歴が積み重なると本格的な口座になる仕組みを採用しています。口座開設の際の顧客の身元確認であるKYC(Know Your Customer: 本人確認)のトラックレコード(過去の実績や履歴)が積み重なるまではアンノウン(不明、未知)扱いです。日本にそのまま持ち込めないとは思いますが、Neobankの実現には必要だと感じます。
最後に、若年層の銀行離れを懸念する声もあります。しかし、それでも最終的に銀行の信頼性は揺るぎません。若年層も成長と共に主たる貯蓄管理先として銀行を使うと思います。金融庁から銀行免許を取得した信用は大きなブランド力となるでしょう。しかし、行員自身が感じているように銀行も変革し始めています。オープンAPIを活用して自らディスラプター(破壊者)となれれば最高です。（完)
変わる銀行法シリーズ第一回 : 「 APIとAPIエコノミー」
変わる銀行法シリーズ第二回 : 「改正銀行法と構造的転換」
変わる銀行法シリーズ第三回：「オープンAPIとセキュリティ」
当社ウェブサイトは、外部サイトへのリンクを含んでおります。リンク先サイトでの個人情報への取扱いに関しては、そのリンク先サイトでの個人情報保護方針をご確認ください。 当社の個人情報保護方針はそのリンク先サイトで提供されている内容に責任を負うものではありません。
.png)
