前回記事では欧州の決済サービス指令（PSD2）がもたらす新たなFintech環境について紹介しました。Fintechと金融機関の連携を促す法制度ですが、その実現手段として不可欠なのがAPI。今回は、国内の金融業界における「オープンAPI」のあり方に関する検討状況を紹介します。
全銀協とオープンAPI
全銀協とは一般社団法人全国銀行協会のこと。その名のとおり全国の銀行が加盟している団体で、正会員120行、準会員71行、特例会員１行で構成された、日本の銀行業界を代表する団体と言えます。
銀行システムと連携したFintechサービスの創出を可能とするAPIについては、金融審議会報告書「決済業務高度化に関するワーキング・グループ報告」や政府による「日本再興戦略2016」などでも言及されており、政府による推進の意図は明らかでした。
このような背景の中、全銀協がオープンAPIのあり方について検討会を設置し本格的な議論を始めたのは2016年11月。参加者は金融機関に留まらず、IT事業者、Fintech企業、学識経験者、弁護士、消費者団体、関係当局など様々なステークホルダーが集まり、産業育成と利用者保護など様々な観点からバランスの取れた議論を行ってきた模様です。
2017年3月には中間報告が公表され、検討会での議論のスコープや現時点での検討結果を確認することができます。今回はその中間報告の概要を紹介し、銀行オープンAPIの検討状況を見ていきたいと思います。
関連情報：
- 「金融審議会「決済業務等の高度化に関するワーキング・グループ」報告の公表について」、金融庁、2015年12月22日
- 「日本再興戦略 2016 ―第４次産業革命に向けて―」、首相官邸日本経済再生本部、2016年6月2日
中間報告書のポイント
中間報告書は以下のサイトで公表されています：
- 「「オープンAPIのあり方に関する検討会」（第9回）議事要旨の公表について」、一般社団法人全国銀行協会、2017年3月16日
検討会のスコープ
API標準といっても様々なレベル感がありえます。詳細に決めようとすると、標準が確定するまでFintechサービス開発が進まないことになりますし、あまり緩いと標準としての意味がありません。
そういったことを勘案し、検討会では「関係者における当面のAPI開発上の指針」をとりまとめていくとし、具体的には以下に関する検討結果を中間報告に記載しています：
- 関係者がAPIを開発するに当たって留意すべき「開発原則」
- 推奨されるAPIの基本的な仕様を定める「開発標準」
- 電文メッセージの標準的な項目やその定義等の目安を定める「電文仕様標準」
開発原則
中間報告に記載された開発原則は以下です：
- 「API利用者目線を意識したわかりやすくシンプルな設計・記述とすること」
- 「APIの種類に応じた適切なセキュリティレベルを確保すること」
- 「デファクトスタンダードや諸外国のAPI標準、国際標準規格との整合性を意識すること」
- 「仕様変更によるAPI利用者への影響をコントロールすること」
中間報告書にはこれらの原則に至った考え方も記載されており、よい方向で議論がなされてきたことがうかがえます。
これらの原則はどれも妥当なものですが、特に原則１の「わかりやすくシンプルな設計・記述」は、開発効率からの観点だけでなく、情報セキュリティ確保の面からも極めて重要です。
例えばOAuth（1.0と2.0の両方）はセキュアなアプリ連携を実現するのによく使われる技術であり、本報告書でも「推奨」となっています。しかしそれを正しく使うことは容易ではなく、誤用によってセキュリティ上欠陥ができてしまったアプリが多数見つかったことがあります。また、重要な欠陥が見つかって既に使われなくなったSSLも、それ以前からAPI仕様が煩雑で、その結果誤った利用法が多数あったことも知られています。
API仕様というのは様々なステークホルダーが参照するものです。OAuthやSSLの事例からも、「わかりやすくシンプルな設計・記述」が、サービス構築の効率化だけでなく、サービスレベルの維持、そして高いセキュリティを実現するためにも不可欠であると言えます。
SSLやOAuthの深刻な誤用に関する記載は以下が典拠です。誰もが知っている超有名企業が名指しされています。
- Eric Y. Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher, and Patrick Tague. 2014. OAuth Demystified for Mobile Application Developers. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS ’14). ACM, New York, NY, USA, 892-903. DOI: http://dx.doi.org/10.1145/2660267.2660323]
- Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, and Vitaly Shmatikov. 2012. The most dangerous code in the world: validating SSL certificates in non-browser software. In Proceedings of the 2012 ACM conference on Computer and communications security (CCS ’12). ACM, New York, NY, USA, 38-49. DOI: http://dx.doi.org/10.1145/2382196.2382204
開発標準
オープンAPIでは以下の方式を推奨するとのことです。
- アーキテクチャスタイルとしてREST
- 通信プロトコルとしてHTTPs
- データ表現形式としてJSON
- 認可プロトコルとしてOAuth2.0
電文仕様標準
ここでは、様々なレベルの標準化が考えられるものの、イノベーションを阻害せずに一定の標準化効果が見込めるとして以下の方針で進めるとしています。
APOのメッセージ上の標準的な項目およびその定義等についてのみ定め、それ以外の仕様は、APIでの連携を目指す銀行とFinTech企業等とが互いに協議のうえ任意に拡張して定めることを前提とする方法。（例：英国Open Banking Standard）
また、電文仕様標準の策定にあたっての留意事項として以下の記載があります：
「電文仕様標準」を策定する対象範囲は、複数の銀行、複数のFinTech企業等との接続を前提とする（すなわち銀行間で共通の）APIとし、当面の対象としては、預金に係る、①残高照会、②入出金明細照会、③振込とすること。
これは、FinTechサービスでの活用の優先度の高いものを対象範囲として進めるという意思表示です。応答メッセージの共通項目、パラメータ記述ルールなどを軸に検討を進めるとのことです。
セキュリティ原則と利用者保護
銀行というセンシティブな情報を扱う機関がAPI公開を行うにあたっては、セキュリティと利用者保護が極めて重要な検討観点となります。本報告書においてもこれらの観点に係る記述は分量も多いですが、とくに「API接続先の適格性」はFinTech企業にとっても重要なポイントとなります。
つまり、接続先として適格と判断されたFinTech企業をAPI接続の相手とするということですが、その手段として以下のようなプロセスを検討しています。
- API接続に先立つ事前審査を行い、
- API接続後も定期的なモニタリング
とは言え、個別銀行で接続先の適格性を独自に判断するのは負荷が高くなることも考えられます。この点については金融システム情報センター（FISC）の活動に言及しており、同センターにて「API接続先チェックリスト（仮称）」の制定に向けた検討がすでに進められていることにも注意喚起しています。
今回は全銀協の検討会の中間報告書のポイントを紹介し、日本の銀行APIに関する最新の動向を見てきました。標準を待たずに既にAPIを活用したサービスも登場していますが、標準化によってFinTechと銀行の連携による新サービスが、わたしたちの生活をより便利にしていくことに期待します。
