FinTech時代の銀行に求められるSoE/SoRアーキテクチャとAPI管理とは：FinTech時代、銀行系システムはどうあるべきか（3）（4/4 ページ）

[鎌田美樹夫（日本アイ・ビー・エム株式会社）, 秋元毅彦（日本アイビーエム・ソリューション・サービス株式会社），＠IT ]

FinTech時代に向けたOpenAPIの検討ポイント

　2016年7月28日、金融庁でFinTechの法整備へ向けた金融審議会「金融制度ワーキング・グループ」（第1回）が開催されました。「FinTechを進める上で、これまで想定されていなかった金融サービスの出現に機動的に対応していく」ことを趣旨とした、新たな法整備を目指すことが主な目的です。現状では、金融機関ではないIT企業などの事業者も、銀行と個人の仲介者として、資金管理や送金などのサービスに参入しやすくすることが狙いです。

　FISC（Center for Financial Industry Information Systems：金融情報システムセンター）でも、『FinTechをテーマとした有識者検討会』を2016年10月から開催することを2016年7月に発表しました。これは「FinTech」に総称される「高度ITを活用した金融サービス」の利用要請が高まっていることを受けたものです。日本の金融機関が顧客のニーズに適応しイノベーションの成果を最大限享受することを目指して、その安全対策の在り方について検討を行う予定です。

　2016年10月21日には、全銀協で「オープンAPIのあり方に関する検討会」の立ち上げが発表されました。「（セキュリティを考慮した）API仕様の標準化に関する検討」「APIの活用を促進していく上での課題への対応」「利用者保護を図りつつ、オープンAPIを推進していくために必要な法整備」などについて検討していくことになります。

　このように、行政機関や金融機関全般がFinTechやOpenAPIの活性化に向けて動き始めており、具体的にいろいろなことが定められてくると思われます。法制度面は別の機会に譲るとして、「技術的には、どのようなことが検討ポイントになるのか」を簡単に整理します。

API仕様に関する標準化

　技術的な検討ポイントの1つ目は、API仕様に関する標準化です。

　API仕様については対象取引の選定も難しいところですが、個々のフィールドの名称や型などのレベルまで具体的に定義していくと時間がかかり過ぎます。そこで、誰もが使う口座情報取得や残高照会、入出金明細照会といった取引は、どの金融機関からも共通的に取得できる項目を網羅しておき、それ以外の取引は、設計ルールやエラーコードなどのコード体系やネーミングルールなどを定める程度でもよいかもしれません。

　詳細に検討し過ぎると、時間と労力だけを要してFinTech本来の良いところである革新性やスピードが削がれかねません。まずは、プロトタイプでもいいので一度採用してみて、改善や発展を繰り返せばよいのではないでしょうか。

　一方、セキュリティや認証については具体的な仕様が必要と考えられます。IPSec、256ビット以上のHTTPS、前述したOAuth 2.0の採用が必要です。また、APIを利用しやすくするためにはREST／JSON方式の採用は必須と考えられます。

セキュリティ

　技術的な検討ポイントの2つ目は、セキュリティです。イノベーションを阻害しないことを考えると、APIに関わるセキュリティの原則を定めるには、金融機関の保守的なセキュリティ実装をベースにしない方がいいでしょう。

　金融機関とFinTech企業が協調して「利用者保護」を大原則にした具体的な取り決めを行う必要があります。FISCのプレスリリースでも説明されていましたが、APIの機能や取得する情報の重要度などに応じた、リスクベースのアプローチによる検討が望ましいと考えられます。

次回は、FinTechを実現するデータ分析について

　今回は、ポスト第3次オンライン以降の銀行を取り巻く顧客接点の変遷やIT技術の動向について触れるとともに、APIおよび「銀行システムと外部システムの連携方法」や、その課題、今後の方向性について説明しました。次回以降はFinTechを実現するデータ分析やブロックチェーンについて触れていく予定です。