2020 年 12 月 17, 18 日に開催された 「デジタルバンキング展」（DBX2020） での、Authlete のワークショップセミナーの録画です。
デジタルバンキングの要となるオープンAPI、そしてそのセキュリティに必須の技術仕様が「OAuth 2.0（OAuth2）」です。今日では多くの銀行が、他事業者へのAPI公開にあたり、OAuth2標準を採用しています。
しかし国内各行が個別にOAuth2対応を進めた結果、接続仕様が統一されず、API連携のハードルを上げる要因となっています。一方世界的には、金融サービスへの適用を念頭に定められたOAuth2詳細仕様である「Financial-grade API（FAP）」を共通仕様として導入し、業界一丸となってセキュリティと相互運用性を同時に高める動きにあります。
本セッションでは、FAPI認定を世界で最初に取得したAuthlete社が、OAuth2の基本から、FAPIを中心とする世界の潮流、そして今後のAPIビジネスに資するOAuth2/FAPI活用のポイントをご紹介します。
それでは、Authlete 社によるワークショップセミナーセッションを始めさせていただきたいと思います。
このセッションは、 「オープン API のセキュリティ動向: OAuth2 と金融グレード API (FAPI)」になりまして、 この 2 つの技術を中心に、 現在の状況、 どうこの 2 つの仕様に対して取り組んでいくべきかを、 ワークショップですので、ちょっと細かい部分もいろいろ出てくるかと思うんですけども、 お話をさせていただきたいと思っております。
アジェンダは、まずいわゆる銀行 API と、 その中で、OAuth 2.0 あるいは OAuth2 という言いかたをしますけれども、 この 2 つの関係についてお話ししまして、 その次に OAuth2 の、よりセキュリティが強化された仕様である、 金融グレード API (FAPI) についてお話しいたします。
3点目として、この FAPI を中心として、各世界の金融機関とか、 とくに銀行の中でどう使われているかを、 英国を中心に紹介し、 最後に、この FAPI / OAuth2 に関して、 どのように活用するか、ポイントをまとめていきます。
自己紹介ですけども、Authlete （オースリート）という会社におりまして、 OAuth2 / FAPI を実装した、 ソリューションのご提供、ご紹介等を行っています。
20 数年間、アイデンティティ管理技術、 あるいは API といったところで、 プリセールス、コンサルティング、マーケティングを主に担当しております。
さっそく内容に入ります。
まず銀行 API と OAuth2 がどう関係するかを紹介し、 とくに OAuth2 に関して、どの点に気をつけるべきかをお話しします。
まず銀行 API とは、ということで、 おそらく「銀行 API」という名前を聞かれて、思い浮かべるものは、 いくつかパターンがあるかと思います。
その中には、たとえば ATM の場所ですとか、支店の住所を公開するといった、 オープンデータ（公開可能データ）の提供があります。
あるいは金融機関・銀行のコア機能を、 API として提供する（ホワイトレーベルで提供する）といった意味での、 事業者間の機能の提供、という銀行 API があります。
3 点目として、本日とくに取り上げたいのが、 お客さまに関わるデータや機能を、 外部のサードパーティに提供する（公開する）ところでの、 銀行 API です。
具体的には、口座情報や取引履歴といった、 参照型の情報の提供から、 一方で送金や決済のような、更新系の機能提供も含めて、 銀行 API としてカテゴライズしていきます。
ちなみに右側にあるのは、ProgrammableWeb という、 銀行に限らずいろいろなオープン API、 API を使ってビジネスをしている、 事業者のデータを集めたサイトがあるんですけども、 先月見たところですと、 いま世の中に API として公開されている種類が2.4万あると言われています。
その中でいわゆるバンキングカテゴリに属している、 このサイトが決めたカテゴリなので一般的ではないかもしれないですけれど、 銀行が提供している API としては、590 種類で、 この左にあるいろいろなカテゴリーを加えたものになりますけれども、 銀行 API と言われているものは、実はいろいろ提供されている、 ということが言えるかと思います。
この、お客さまに関わるデータ機能提供で、 とくに OAuth, OAuth2, あるいは OAuth 2.0 と、 いった呼び方で、この技術が注目されています。
これが具体的にどこで使われるかというと、 まず API を公開する金融機関（銀行）があって、 その中で口座情報の参照とか、送金機能を提供するような、 API の公開があります。
この API を使うのがサードパーティ、 たとえばフィンテック事業者が提供する家計簿アプリ・送金アプリがあって、 API というと、マシンとマシンがつながるという意味では、 この 2 つがあればいいんですけども、 今回取り上げたいのは、 お客さま（エンドユーザー）が連携を制御するところです。
API を公開するところと、API を利用するところと、 その API によって提供されるデータや機能を、制御するユーザーと、 三者をつなぐものとして、いままでいろいろなしくみがあったんですけれども、 現在 OAuth2 (OAuth 2.0) が、標準的・一般的に使われています。
ポイントは、ユーザーの認可を仕様として取りこんでいる点です。
いろいろなやり方がいままであったんですけれども、 どういう技術かというと、 どういうリクエストを出してどういうレスポンスを返すか、 あるいはその後 API アクセスに必要な「アクセストークン」を、 どうやって受けわたすかまで、大枠を定めているのが、 この OAuth2 になります。
OAuth 2.0 自体、仕様が策定されたのが 2012 年で、 現状この OAuth2 が、いろいろな業種・業態での API 認可、 とくにエンドユーザーが関与した API 認可では、 標準的な技術として使われています。
それは銀行・金融機関においても例外ではなく、 たとえば国内の銀行 API の中で OAuth2 がどう位置づけられているかというと、 すでに皆さんご存知かとは思います。
3 年前、2017 年 7 月に、 「オープン API のあり方に関する検討会」で報告書が出されていて、 この中で認可プロトコル（API に対してアクセスをコントロールするためのプロトコル）としては、 OAuth 2.0 認可フレームワーク (OAuth2) を使うべき、 推奨する、とすでに言われています。
また、金融機関と API 接続先との接続チェックリストがあるんですけども、 その中でも、OAuth 2.0 のしくみを理解していること、 そしてそれに関連する項目の意味を説明できること、ということで、 かなり OAuth2 に関して、しっかり理解して、それを使いこなせることが、 チェックリストのレベルで求められている、と言えます。
と聞くと、OAuth2 は、なにかすごい定まったものがあって、 たとえば認定試験みたいなものがあって、 それを受ければ分かるようになるみたいな、 イメージを持たれるかもかもしれないですけれど、 実はそうではないんですよね。
というのは、OAuth2 は、ちょっと技術的に言いますと、 プロトコルではなく、フレームワークと呼ばれるカテゴリーのものです。
フレームワークはその通り枠組みでして、 枠組みの上にさらに詳細仕様を定めない限りは、 言い方は悪いですけど、使いものにならない、という類のものです。
その中でここにちょっと細かく書いていますけけれども、 アクセストークンのライフサイクル管理ですとか、 スコープ管理、ちょっと OAuth2 の専門用語が出てきて恐縮なんですけれども、 こういう細かいパラメーターを、 どう使いこなすか・どう制御するか、といったことを決めない限りは、 OAuth2 を実装・適用するといったことには、ならないわけです。
この詳細仕様化をどう進めるかというところで、 もちろん枠組みですので、ゼロから詳細仕様を詰めていくこともできますけれども、 詳細仕様化に必要なパーツというのは、 実は拡張仕様とか、 あるいはその使い方（プラクティス） がいろいろ出てきていて、 そのプラクティスと拡張仕様をうまく使いこなせるかどうか、といったところが、 この詳細仕様化でうまくできるかどうか、といった分かれ目になります。
とはいっても、いろいろな仕様・プラクティスが出てきていたりとか、 そもそもの「OAuth2 の枠組み」ってなんだろう、 という難しいところもあるかと思います。
その結果、もしかしたら、 これはちょっと煽り的な言い方になりますけれども、 この OAuth2 は、使ってください、推奨します、と言われているんですけれども、 実際には、銀行においてこの OAuth2 を使うことが、 実は銀行 API の普及を妨げているのではないか、 といった懸念も生まれてきます。
つまり、各銀行が個々に OAuth 2.0 仕様（枠組み）を理解して、 その上に詳細仕様化をしているけれども、 その結果として、各銀行ごとに詳細仕様の内容が実はバラバラになっていると。
あるいは、銀行によっては共通・共同利用型のサービスを利用していて、 その共同利用型サービスの中で独自の OAuth 2.0 の詳細仕様化が行われていて、 それが複数社あるわけですね。
そうすると、 その共同利用型の中ではもしかしたら共通化できてるかもしれないんですけど、 けっきょく、その事業者やベンダーが変わるとバラバラになっていると。
仕様がバラバラな状態で API を利用するのは、 サードパーティーである、例えばフィンテック事業者のようなところなので、 そのフィンテック事業者では、個々の銀行ごとに異なる詳細仕様を理解して、 そのギャップを埋めるための実装、そしてその後の運用、 という負担が発生しています。
もちろん詳細仕様化は、誰かがタダでやってくれるものではない、 個別にやった場合には、タダでやってくれるものではないので、 誰かがそのコストを負担しなくてはいけないわけですね。
現状、誰が負担しているかというと、銀行が負担している、と。
けっきょく、オープン API にとってセキュリティというのは、 必ず無くてはならないのは間違いないんですけれども、 そのセキュリティをいくらがんばっても、 そこは別になにかお金を生み出すものではないですよね。
もちろん、安心を与えるという間接的な効果はあると思うんですけども、 直接的に手数料が入るとか、 セキュリティが高いのでうちの API は高いです、みたいな言い方は、 おそらくできないと思います。
つまり、収益には直接関係しない部分でがんばらなくてはならないというのが、 ちょっと難しいところなんじゃないかと思います。
このセキュリティ部分ですね、 API も、何段階かに分けるべきではないかと考えていまして、 英国で、いまオープン API で分けられているのを見ると、 たとえば「ビジネス API」と「プレミアム API」は分けるべき、と言われています。
ビジネス API というのは各銀行によらず、 たとえば電文を共通化しましょうというレベルでの標準化。
プレミアム API は、ある銀行で、 「うちの銀行は特別なサービスを提供できるので、 他社の足並みを待たずに、 うちが先行して良い機能を API で提供して、先行者の利益を得る」と。
ビジネス API とプレミアム API は分ける。ただ、わたしから見ますと、 もう一つ、ビジネス API の下に「セキュリティ API」があるべきではないかと思います。
セキュリティ API というのは、金融機関・銀行に限らず、 高いセキュリティレベルが求められるようなサービス、 金融サービスではなく、たとえば医療サービスとか、 あるいはなにか機微な個人情報を扱うサービスとか、 いろいろあるかと思うんですけれども、 そういった、業種業態を問わずセキュリティが高いところで、 どういう手当てが必要か、は共通化すると。
その上で、たとえば日本国内であれば共通の電文を使うだとか、 イギリスでもそうですけれど、そういう、コミュニティとか地域によって共通化して、 さらにその上で、特別な API に関しては、 銀行独自で API を定義して提供していく、 というのがいいんじゃないかなと思います。
この中で、セキュリティ API の標準化はなにかないの、ということで、 すでにちょっとネタバレなところがありますけども、FAPI になります。
FAPI はなんぞや、ということでこのあと少しお話をさせていただきます。
FAPI と言っていますけれども、正式名称としては Financial-grade API、 金融グレード API という、 今日のセッションのタイトルにも入れましたけど、そういう名前になります。
OAuth2 というフレームワークを詳細仕様化するんですけど、その方向として、 金融サービスに適した詳細仕様化を行っているのが、この FAPI になります。
どこで行っているかというと、米国の OpenID ファンデーションという団体がありまして、 この中にいろいろな仕様の標準化をするワーキングループがあるんですけども、 そのひとつとして Financial-grade API ワーキンググループが設置されていて、 そのワーキングループで、銀行とか、 あるいは弊社を含めたソフトウェアベンダーとか、 あるいはセキュリティの専門家とかが集まって、 仕様の策定を行って、あるいは検討しています。
現状のステータスとしましては、この後お話しますけれども、 FAPI バージョン 1 のファイナルバージョンがいまできていて、 そのファイナルバージョンで本当に確定するかどうかというところで、 いまパブリックレビュー、 そのファイナルバージョンを公開して、 いろいろな人からのパブリックコメントを受け付けている、 レビューを受け付けているという段階になります。
このFAPI バージョン 1 には、2 つ、セキュリティーレベルに応じて仕様が書かれていて、 パート 1、パート 2 とあるんですけれども, とくに本日ご紹介差し上げたいのは、このうちパート 2、 より高度なセキュリティ対策に OAuth2 を使ってどういうことをすべきかと、 いうことが書いてあるのですけど、こちらをご紹介させていただきます。
この高度な OAuth2 セキュリティ対策とはなんぞや、どういうことを標準化しているかというと、 まず OAuth 2.0 (OAuth2) の中で、トークン（アクセストークン）という、 API を呼び出して良いよ悪いよといった判断をするための情報があります。
そのやりとりをどうやって保護するか、 途中で改ざんされたりだとか、すり替えられたりとか、 あるいはトークンを盗まれて別の人に使われてしまったりとか、 といったところは、OAuth2 の中では枠組みはあるんですけども、 その中で定められたことをやっているだけでは、実は解決できないんですね。
ちょっと細かいところで、不正授受とか不正使用とかを、 次のスライドでご紹介しますけれども、 トークンのやりとりとか、その不正利用に関しては、 OAuth2 の枠組みとはまた別のしくみを使う必要がある、と。
いままでですと、個々の銀行・金融機関のほうで、 トークンをどうやって守るかというところで、 独自にしくみを考えて、設計・実装・運用してきたかと思います。
そういった部分を、FAPI パート 2 (Advanced) という仕様の中で、 すべて標準化、必要であれば拡張仕様を策定して、それをオープン標準にするとか、 あるいは OAuth2 の使いかたに関しても、標準的な使いかたを定める、といったものになっています。
少し図を使ってお話ししますと、 左側にフィンテック事業者があって、右側に金融機関があって、 その下に攻撃者がいるといったような図になります。
フィンテック事業者から金融機関（銀行）に対して、 まず、アクセストークンをください、という要求をするんですね。
この図の中では、一番上の OAuth2 アクセス認可リクエストというのが、 フィンテック事業者から銀行に対して直接来ているような図になっています。
しかし実はこのやりとりというのは、お客さまの環境の Web ブラウザーを介して、 間接的に、技術的に言うとブラウザのリダイレクトを使って行われるかたちになります。
戻りも同様です。認可レスポンスという、実際にアクセストークンそのものではないんですけど、 アクセストークンをやりとりするための、前段階のレスポンスも、 やはりユーザーの Web ブラウザを介して行われる、と。
そうすると、OAuth2 に限らずですけれど、 やはりブラウザーはやられやすい部分ですので、 そこで、トークンのすり替えですとか、あるいは盗まれたりですとか、 改ざんといったことが、 エンドユーザーの環境によっては、起こりえます。
この部分に関して、FAPI パート 2では、 メッセージの暗号化をする、あるいは署名をつけることによって、 改ざん防止ですとか、あるいは不正なトークン授受の検知が可能になっています。
もうひとつ、トークンが正しいところに渡って、 その後またトークンが盗まれた場合にどうするかなんですけども、 その場合通常の OAuth2 だと、トークンを盗んだ人はそのままそのトークンを使えちゃうんですよね。
平たく言うと、不正利用ができると。 それをどうやって防ぐかというと、トークンを発行して受け取った人が、 そのトークンを使うときには、 私はこのトークンをもらった人です、という情報を同時に与えると。
どうやって与えるかというと、 「相互 TLS」と書いていますけれど、いわゆる PKI ベース、 証明書を使った、いわゆるクライアント認証を行って、 特定のフィンテック事業者のサーバーからしか、金融機関の API にはアクセスできない、 かつ、そのときに使うアクセストークンは、 ちゃんとクライアント証明書にひもづいているものにする、といったことが定められています。
FAPI パート 2 は、いろいろな機能が定義されているんですが、とくにこの 2 つが大きなポイントです。
この FAPI パート 2 を、なぜ銀行は使うべきか、 なぜおすすめするかというところなんですけども、 やはり OAuth2 の詳細仕様化にかかるコストというのは、 けっこうなものだと思うんですよね。
繰り返しますけれど、OAuth2 の仕様をちゃんと理解した上で、 最新の拡張仕様とかプラクティスも理解した上で、 それを実装して、また新しい仕様が出てきたら、もしかしたらそれを取り込む検討をしなければならない、と。
他の銀行との兼ね合いもあるでしょうし、 あるいはフィンテック事業者へのエデュケーションと言いますか、周知も必要になる、と。
そういうことを、自分だけでやるんじゃなくてですね、 そこを独自でやらないで、共通仕様を使うことによって、 開発・運用に費やすコストは削減できるというのが、まず 1 点。
もうひとつは、OAuth2 を使って正しく高度なセキュリティを担保するというのは、 容易ではない、と一言で言えると思うんですよね。
FAPI の場合には、この部分に関して、形式検証というものを行っていて、 FAPI を使っている限り、FAPI で定められたしくみを使っている限り、 基本的に問題は起こらない、セキュリティ的な穴はない、と証明されています。
同じことを、銀行が独自に OAuth2 の詳細仕様を組み立ててですね、 同じように形式証明するというのは、 これ自体一年くらいかかるような作業なので、たぶん難しいのではないか、と。
つまり、「うちの銀行で出している API の OAuth2 部分は完璧です」と言っても、 証拠が無いんですよね。
その部分に関して、証拠を提示できるのは、 2 つ目として大きな点かと思います。
3 点目として、この FAPI に限らずなんですけど、 OpenID Connect で出している各仕様は、 認定プログラムというのが、ペアでついています。
認定プログラムは、特定のソフトウェアやサービスに関して、 OpenID Connect や FAPI に準拠している、といったことをチェックして、 証明するものです。
これは銀行にとっては、2 つのメリットがあると思います。
ひとつは、この FAPI 準拠の有無を製品選定の基準にできる。 いくら OAuth2 で実績ありますと言っても、FAPI はちょっと…みたいな、 FAPI これからできますと言っても、認定をとっていないのに本当にできるのかは、 ちょっとわかんないわけですね。
そういう中で、ちゃんと FAPI の認定をとったソリューションの中から選べば、 FAPI の実装に関しては問題ないと言えるのは、ひとつ大きいんじゃないか、と思います。
2 点目として、認定プログラムの中で、認定テストスイートを同時に提供しています。 この認定プログラム自体は、どこかの第三者機関に、 「うちのソフトウェアのチェックしてよ」とお願いするのではなくて、 自分で認定テストスイートを実行して、自分の環境で評価して、 できました、という結果を提出するかたちなんですね。
なのでそのテストスイートを、たとえば継続的に、 銀行で回していただいて、 「うちの銀行の API は常に FAPI 準拠です」といったことを確認できる、と。 なにかデグレ（機能低下）が開発過程で起こっていたとしてもすぐに気づいて、 リリース前までには必ず直せる、と。
そういった証拠を、自行だけではなくて、サードパーティに対しても提供できる。 オープンなかたちで、うちはちゃんとできてます、と言えるのは、 3 点目のメリットかと思います。
この FAPI なんですけども、かなり、いま世界で、 銀行のセキュリティ標準として使われつつあります。
とくに一番早かったのが、英国のオープンバンキングですね。
「オープンバンキング」と、カタカナで書いていますけど、 イギリスの場合には固有名詞として Open Banking というものがあります。
この中で単になにか、オープン API やりましょう、で各行はやっているのではなくて、 銀行の上位 9 行は、必ずこれを使わなくてはいけない、と定められています。
共通のセキュリティプロファイル、 あるいは共通の API （電文の仕様、データのやりとり）、 あるいはこのあとお話しする、カスタマーエクスペリエンスに関してまで、 標準化・ガイドライン提供が行われています。
もともと上位 9 行だけだったんですけども、 現在、このオープンバンキングの枠組みに参加しているという意味では、 銀行側が、チャレンジャーバンク等も含めて 76 行、 API を利用する側は、これがすべてライブで動いているのではないんですけど、 参加している企業としては 204 社となっています。
このオープンバンキングの中で FAPI が以前から使われているんですけども、 当初は FAPI をそのまま使うということではなかったんですね。
このあたりも非常に参考になると思うんですけども、 UK 独自の事情と言いますか、銀行がついてこれないだろう、みたいなのがあって、 ちょっと FAPI をゆるめたかたちで、初めは仕様を使うということでやってました。
ただ、この FAPI の策定プロセスに、かなり UK の方が参画して、 その中で英国独自のリクワイアメントを入れていった結果、 オープン標準である FAPI をそのまま使えばいいじゃないかと、UK でも。
その結果今では、 UK オープンバンキングの中で、FAPI を使います、と。 独自の OAuth 詳細仕様は使いません、というところまで進展しています。
結果として、イギリスでオープンバンキングのプログラムに参加する中では、 FAPI ていうのが絶対使われるものになっているんですね。
このプログラム（イニシアチブ）に参加しようという事業者は、 FAPI 認定のサービスなり製品を使ってすぐに入ることもできますし、 あるいは自社で開発した API 接続のしくみ、API 提供のしくみに関しても、 FAPI をベースにチェックするかたちで、 その実装とか、どうやってやるかといったノウハウに関して、 FAPI を軸に共通化・標準化されているメリットが生まれてきています。
細かい仕様をいくつか、ここからお話ししていきます。
TPP（サードパーティー）と ASPSP（銀行）、 そして真ん中にエンドユーザーという関係があって、 1 番目にあるのが、API のオンボーディング（API を利用するための設定）です。
サードパーティーが「うちはこういう設定情報で接続しに行きます、こういう接続情報です」と登録して、 「わかりました。では、この API アクセスに必要な情報を使ってください」と返す。
お互いに設定情報を登録するところが、オンボーディングです。
その状態で、実際に API アクセスを行うのが真ん中で、 その API アクセスに関して、エンドユーザーが介在するときに、 どうやってエンドユーザーを巻き込むか、といったような、 しくみがある、と。
それぞれに関して、UK のオープンパンキングでは、仕様あるいはガイドラインを策定しています。
まず Read/Write Data Specification というのがあって、 これはいわゆる電文仕様の標準のひな型です。
口座残高の参照だとか、取引履歴の参照といった機能を提供するための、 共通のセットを定義しているものがあって、 この上にいろいろな決済手段・決済方法だとか、 あるいは参照系の細かい仕様が作られているんですけども、 この中で Security & Access Control というところで、 FAPI をどう使うかが定義されています。
この中で 1 点ご紹介差し上げたいのが、 取引単位でのアクセス認可というしくみです。
もともと、OAuth2 ですとか OpenID Connect でも、 ここまでは定義されていない、スコープ外の部分だったんですね。
UK オープンバンキングの場合には、 どの取引に対して、どう同意を取るかといったところまで、 事前に取引内容をサードパーティーから銀行に登録して、 その登録された内容に関して同意をとって、 実際に API アクセスするときには、その同意された内容の部分だけアクセスを可能とする、と。
たとえば、誰かにいくら送金するといった内容があれば、それをまず登録して、 同意をとって、 実際にペイメント API あるいは送金 API を用意して、 それを呼ぶときにはその内容でしか呼べない、 といったようなところを指定する、あるいは定義する、といったものになります。
「決済する」とかいう単位ではなくて、 個々の内容、参照系でも同じだと思うんですけども、 たとえば 90 日間、そのお客さまの口座残高を提供する、という取引内容を決めて、 その取引内容に関して同意をとって、 アカウント API やトランザクション API のような、 取引内容を確認する API に関しては、 はじめに同意した内容だけ参照する、 といったような細かな制御が可能となります。
この中でカスタマージャーニーがまた別途定義されていて、 はじめにどう登録するか、同意を取るか、実際に処理をするか、といったような、 技術的な枠組みがあって、 それをエンドユーザーにどうみせるかは、また別途カスタマージャーニーの指針として定められています。
ひとつだけご紹介すると、連携プロセスの中で、 まずサードパーティーは、 これからお客さまの情報に関してこういう処理をしますよ、と示す。
左側にある、まずコンセント（同意）を取るというプロセスです。
同意を取った上で、「わかりました。では進めてください」とエンドユーザーが指示すると、 その結果、銀行の方に画面が遷移して、 そこで、「いまこういう取引内容・処理内容が送られてきましたが、それは本当に正しいですか?」と、 ユーザーの認証とともに確認を行います。
それでユーザーが「はい、その通りです。同意します。処理を進めてください」と承認すると、 処理が終わってまたサードパーティーに戻って、 そこで「処理が完了しました」とすると。
実際処理をして、その結果を返す。
ここまで、API を 提供して、 エンドユーザーに対してどう見せるかといったところまで、 細かく定められているのも、 この UK オープンバンキングの特徴のひとつかなと思います。
他にも、銀行とサードパーティーが複数それぞれ存在する場合に、 その接続設定をどうやって簡略化するか、機械的にどうつなぐか。
人間が申込フォームに書いて、接続情報をメールで送って、みたいな世界じゃなくて、 機械的に、自動的に連携するためには、どういうやりとりが必要かと。
そこを定めている「ディレクトリ」というしくみですとか、 あるいはその銀行に対して、サードパーティー（API クライアント）が、 自動的に登録する際の、動的なクライアント登録のしくみも別途作られていて、 これも非常に興味深いところかと思います。
もしご興味があればぜひご覧いただきたいと思います。
こういった、FAPI というか、イギリスのオープンバンキングのやりかたが、 いま世界に広まりつつあります。
一番早かったのがオーストラリアです。
Consumer Data Right という、金融系に限らないんですが、 エンドユーザー（消費者）のデータを、どうやってやりとりするかというところで、 いま FAPI が標準的に使われていたりします。
そして、その近くにあるニュージーランドもです。
また最近ですと、とくに米国です。
US はかなり市場主導というか、基本的に各金融機関任せといったスタンスでやられていたんですけど、 ここにきて、銀行をまたがってセキュリティプロファイルを標準化しよう、 といった動きが出てきています。
あと弊社が実際に引き合いを受けている状況ですと、 かなり、個々の銀行で FAPI を使うといったところで、 国内に限らず、国内外の銀行からのお話をいただいている段階です。
今後として、FAPI 1（FAPI バージョン 1）ですけれども 、 来年（2021 年）の 1 月には、おそらくいまパブリックレビューにあるものが問題なく通って、 確定する、と。
いま提供されている FAPI のドラフトでも、十分だと思うんですけども、 さらに今後、確定版というかたちで、利用のハードルは下がるのかなと思います。
さらにそのあと、FAPI 2というものが予定されていて、 その中では、FAPI 1 が作られ始めて以降、 拡張仕様がいろいろでてきているのを取り込んで、 リファクタリングして、 さらにたとえば webhook という、クライアントを呼び出すしくみですとか、 あるいはグラントマネジメントという、短期間ではなく長期間の認可の管理といったものも、 新しく入る予定です。
最後に、OAuth2 と FAPI を実際どう使うかというところで、 ポイントをお話しして、締めくくりたいと思います。
FAPI をどう使うかが、 銀行 API（ユーザーが絡む API）の成否を分けるのではないか、と思います。
というのは、API は使われないと意味がない、というのは間違いないかと思うんですよね。
そのためには、API を利用する人・数を増やすか、 その取引数を増やす、ということが欠かせないと。
ここで FAPI じゃなくて独自仕様を使って、個々の銀行が独自に詳細仕様化をして、 片方の API を呼び出す側が一個一個対応しなくてはならないというのは、 本当にそうやっていて、利用者数が増えるのかなとか、取引数が増えるのかな、と。
けっこう技術的にハードルが高いよねっていうのは、あると思うんですよ。
その部分で、共通のセキュリティ API として FAPI を採用するのは、 合理的だと思うんですよね。
相互接続のハードルを下げて、 実際に自行の詳細仕様を作っていくよりは、 はるかに、運用・実装コストが下がるはずです。
そのために、FAPI に取り組むために何が必要かということで、3 点申し上げたいのは、 まず、適切な実装の選定です。
さきほど認定プログラムのお話をしましたけれども、 認定されているソリューションを使うのは、まず第一のポイントだと思います。
FAPI OpenID プロバイダーとか、FAPI-CIBA とか、 今日 CIBA の話をしてないんですけども別の認証の仕様があって、 この 2 つに対応しているといったところも、 採用しているかどうかをぜひ見ていただきたいと思います。
2点目として、FAPI でやるからって、全部ガラッと変えましょうっていうのは、 たぶんありえないと思うんですね。
なので既存の環境、たとえばすでに参照系の API を公開している銀行でも、 その環境にさらにセキュリティプロファイルを新しく入れる、 詳細仕様として標準のものを入れるにはどうすればいいか、といったところを、 考えていただくのがいいかなと思います。
具体的には、ID & アクセス管理、 たとえばインターネットバンキングでログイン機能がありますだとか、 そもそもお客さま情報を持っていますといった中で、 一方で API を提供する API ゲートウェイがあって、 さらに高いセキュリティ、高い OAuth2 セキュリティを実装するためには、 おそらくこの OAuth2 の機能というのは、外出しするか、後から付け加えられるようなしくみが、 必要となるかと思うんですね。
まるっと変えてくださいというパターンではなくて、 今の環境にうまく当てはまるかといった観点から、見ていただくのがいいかなと思います。
3 点目として、FAPI をやるからと言って、 FAPI に縛られることは決してあってはならないと思います。
もちろんセキュリティプロファイルは FAPI なんですけど、それを使うことによって、 なにか他の部分のカスタマイズ性が落ちるというのは、 たとえば UX が落ちるのは、ありえない話だと思うんですね。
あくまで OAuth2 対応だとか、 OpenID Connect 対応、 ひいては FAPI 対応といったところは、 外部の企業に任せて、 その UX をコントロールするサーバー部分は、 お客さま（銀行）自身で持つほうがいいんじゃないかなと思います。
まとめに入らせていただきますと、 まず、とくに銀行さんに申し上げたいのは、 独自に API 仕様を策定するというのは、 もちろん、「三角形」の中で「プレミアム API 」をやるのには非常にいいと思うんですね。
ただ、口座残高・取引履歴の参照、あるいは基本的な決済・送金機能とかで、 本当にそれを自前でやることが、競争優先性につながっているかは、 考えたほうがいいのではないかと思います。
2 点目として、標準仕様の中で詳細仕様化を独自にやったとしても、 それは、FAPI という形式証明されているものに、本当に勝てるのかと。
3 点目として、現状の機能はどうやって FAPI に対応できるかを、 見ていただきたいと思います。
弊社にお声がけいただければ、このあたりの知見を幅広く備えておりますし、 ソリューションもご提供差し上げておりますので、 まず何かわからないことがあれば、お声がけいただければと思います。
わたしからの発表は以上となります。 どうもありがとうございました。
