そろそろ、オープンAPIについて真剣に考えてみた。
<はじめに>
金融サービスの大衆化、Fintechを取り巻く環境は、この1年でかなり変わって来ていると下っ端の金融エンジニアでも感じる今日この頃。
また、本年6月には2年連続となる銀行法も改正され、各銀行にはオープンAPIの解放向けて努力義務が生じている現状もあり、今一度、関連する用語や、法案対応に向けた国内の動きについてまとめてみる。
あくまでも私はこう理解したというものですので、ご指摘等あれば是非にお願いします。
<わかっていること>
オープンAPIとOpenAPIとRestFulAPI
WEB API
Application Programming Interfaceの略称で、ソフトウェア(システム)の一部を公開し、他のソフトウェア(システム)と共有できるインタフェース(及びその仕様書)を指す。RestFul、SOAPってものがありますが、Restfulが主流ということでここではあまり語りません。(RestはAPIを設計するための概念であり、SOAPは規格というレイヤの違いがある。以外あんまり分かってない)
口座情報サービス提供者 決済指図伝達サービス提供者
参照系と更新系で海外はFintech企業のチェックの度合いを変えている模様。
オープンAPIとOpen APIととWeb APIとREST APIの違い。 - 自分の仕事を憎むには人生は余りにも短い
REST - SOAP とRESTの違いについてわかりやすく教えていただけませんでしょうか?|teratail
Swagger が OpenAPI にリネームされて Open API Initiative が誕生してた
銀行法の改定内容について
銀行目線
銀行のオープンAPIについて
認証認可
API実行時の認証認可については、OAuth2.0がスタンダートとなっているが、
OAuthは認可のみを定義したフレームワークであり、認証部分については定義していないため、
OpenIDConnect等の認証プロトコルで整理されていく?と推測。
ちなみに、オープン API のあり方に関する検討会の1月時点*2では、
仕様の標準化に関連する論点については、本年度内を目途とする報告書の取り纏めまでに考え方を整理する予定。
との記載がありまだ不明確。
実装すべきAPIや電文規格について
・オープンAPIはRestFulであるべきらしい。
・APIはある程度のグループに分けてユーザに認可をさせるべきらしい。
どの文章を見てもやはり、shouldであり。msutな実装と言うものは見当たらなかった。
イメージとしては、とりあえず責任分解だけしっかりして自己責任でよろしくと言う感じが否めない。
オープンAPIの収益性について
どの書類にも具体的には触れられていない様子。
義務or努力義務なので、銀行は開示せざるを得ないと言う状況になって開示すると言う流れなのだろう。
<関連団体/ワーキンググループから出ている書類や議事録について>
・金融庁
金融審議会の金融制度ワーキング・グループ
http://www.fsa.go.jp/singi/singi_kinyu/tosin/20161227-1.html#
・Fintech協会
認定電子決済等代行事業者協会
https://www.fintechjapan.org/resources/Documents/faj20170303.pdf
・FISC
金融機関におけるFinTechに関する有識者検討会
・政府(官邸)
日本未来投資戦略2017*4
・一般社団法人 金融ISAC
FinTechセキュリティWG