Open Banking におけるユーザー同意の UX
背景
Authlete Inc. で事業開発を担当している岸田と申します。今現在、UX 関連の新機能のリリースを準備しており、その過程で次のブログに行き当たりました。
面白い内容でしたので、ちょっと日本語訳してみました。
英国での銀行 API 公開の取り組み（＝Open Banking）では、Open Banking を推進する団体（＝Open Banking Implementation Entity / OBIE）が UX のガイドラインを公開している事にまず驚きましたし、UX に関して各行色々と違いがあり、それを比較することで見えるものもあり面白いです。UX のプロには物足りない内容かもしれませんが、「API とか API エコノミーって何？」とかいう方にもわかりやすい内容かと思います。
（以下、翻訳）
Open Banking における同意フローの UX
2018年1月より、英国の上位9銀行（CMA 9） は、Open Banking をサポートすることが必須となりました。Open Banking は、英国の金融業界に、競争と協業をもたらすために導入されたものです。Open Banking により、サードパーティの事業者（TPP）は、銀行が保有する消費者の金融情報に（消費者の同意の元）アクセスし、新たなサービス、アプリ、技術の開発が可能となります。これまでの政府主導のイニチアチブ同様、実現させるためには多くの課題が伴います。そして、それらの多くが、技術的または消費者理解の観点から生じるものです。中でも一番の課題は、消費者の信用を獲得し、API を介して情報提供する限り、かれらの個人情報が安全に守られているということを消費者に理解してもらう点にあります。口座管理アプリ Yolt（訳者補足：日本でいう、Moneytree や Money Forward のようなアプリです）に銀行の口座を追加する際の同意モデルを例に、Open Banking が実現するとどのようなユーザーエクスペリエンスがもたらされのか、この投稿では見ていきます。
スクリーンスクレイピング vs API
これまで銀行は、TPP に対して API を提供してきませんでした。そのため、TPP は銀行のオンラインバンキングにアクセスするために必要なクレデンシャル情報（ユーザー名やパスワードなど）をユーザーから受け取り、消費者に成りすましてログインし、ユーザーの情報を抜き出し（＝スクリーンスクレイピング）ていました。このスクリーンスクレイピングは、オンラインバンキングにログインするための情報を第三者に渡してしまうため、いまだに議論の対象となっています。また、銀行がオンラインバンキングの UI を変更する度に、TPP は自身のシステムを設計しなおさないといけないため、スクリーンスクレイピングという方法は、データの堅牢性、信頼性の観点からも問題があると言えます。この方法に比べ、API 経由でデータを共有する方法は、(1) ユーザー自身がどの情報を共有しているのか把握できる、(2) より簡単にデータ共有を停止できる、(3) ログインに関する情報を共有しなくてもいい、といった点からもより安全な方法だと言えます。
Open Banking Implementation Entity による勧告
Open Banking Implementation Entity（OBIE) は、2017年10月に、Open Banking Consent Model Guidelines を公開しています。このドキュメントには、消費者が銀行口座を TPP のアプリに接続する際の UX を改善するための勧告やベストプラクティスが記されています。なお、OBIE は、2016年に英国の公正取引員会（Competition & Markets Authority、CMA）によって設立された、Open Banking を推進するための組織（会社）です。
この勧告自体は、CMA 9 の銀行に向けて書かれたものですが、API を公開し、顧客の資産管理に貢献しているチャレンジャーバングは数多く存在します。これらのチャレンジャーバンクもこの勧告を利用できるものの、その勧告に縛られているわけではないため、ユーザーの同意をとる一連のフローに差異が生じています。そのことについて、これから議論していきます。
次に示しているのは、OBIE が示している同意モデルの例です。この例では、ユーザーが自身の銀行（架空の銀行 Greenview Bank）の口座をサードパーティアプリ（架空の Fintech アプリ Tree Quote）に接続しようとしています。
図からもわかるように、OBIE によって示されている例では、ユーザーフローは3つのステージに分かれています。
- 同意（Consent）ステージ：アプリは、銀行からどの情報が必要なのか、そしてなぜ必要なのか、をユーザーに通知し、銀行に接続する事に対しての同意を求めています。ユーザーは同意するか否か選択し、同意した場合、ユーザーが自身の個人情報をコントロールできていることを理解してもらうため、この許可がいつまで続くのか（図の例では、2018年2月2日まで）を明示しています。
- 認証（Authentication）ステージ：銀行はユーザーを認証し、またユーザーに対して、ID やパスワードが TPP に渡っていないことを強調します。ユーザーが安心できるよう、このステップが TPP ではなく銀行によって行われていることが明確に顧客に伝わるようにすべきであると、OBIE は提言してます。あわせて、ユーザーにさらに信頼感を与えるため、銀行のオンラインバンキングで使われているものと同じ認証のプロセスを使うことも提案しています。
- 認可（Authorization）ステージ：銀行はどの情報をTPPに対して共有しようとしているのか、ユーザーに通知したうえで、認可してもらいます。OBIE は、「このステップは、良い意味での正の摩擦（positive friction）を生み出すはずだ」としています。
OBIE の調査 によると、（Open Banking を使うであろう人の大部分を占めるとされる）技術に詳しくない人は、透明性と安全性を求め、１と３の両方のステップがある方を好みます。一方、（対象の20％くらいを占めるとされる）技術や金融に詳しい人々は、２と３のステップを一つにしたいと思っています。そうすることで、安全性やユーザーの理解を犠牲にすることなく、スピーディーかつ効率よくプロセスを進められると考えているからです。
実際の例
OBIE による勧告は明快でよく考えられているように見えますが、TPP 側からすると大きな問題があります。それは、同意を得るための一連のフローが、ユーザーの TPP に対する印象に大きく寄与しているにもかかわらず、そのフローの一部が銀行によって行われ、TPP からはコントロールできない、という点です。TPP が提供するアプリの UX はすぐれたものになるかもしれませんが、同意のフローが面倒に見えたり信頼に足りないとユーザーが判断し、フローを途中で止めてしまうと、アプリは銀行の情報にアクセスできなくなってしまい、ユーザーからは使いものにならないアプリと評価されてしまう可能性があります。よって、この同意フローを、銀行や TPP に対して何らかの方法で標準化できれば、それはユーザーの信頼と信用を得ることに繋がるかもしれません。
この投稿の残りは、 Yolt（英国のFCA（金融行動監視機構）が承認したアプリのひとつであり、Open Banking の認定事業者でもある）を使って金融情報にアクセスする場合を例に、上記の課題について触れていきます。この投稿を書いている時点（2018年8月）において、Yolt が API 経由で接続できない銀行も存在しますが、2018年4月の段階では、RBS Group、Lloyds Banking Group、Nationwide 及び Danske Bank が接続可能であるとアナウンスされています。この投稿では、CMA 9 の銀行での API を使った例およびスクリーンスクレイピングを使った例、それぞれの場合の同意フローについてみていきつつ、チャレンジャーバンクの例についても触れていきます。
Bank of Scotland & Yolt
Lloyd Banking Group （CMA 9 に含まれる）の一行であり、Bank of Scotland (BOS) は、API を使って Yolt と連携することができます。BOS は OBIE の勧告にかなり忠実に従っているようで、フローを同意～認証～認可の３つに分けています。BOS は、「ユーザーの ID やパスワードが TPP（= Yolt）に共有されていないこと」、「有効期限が設定されていること」、「いつでも無効化できること」を明確に示し、明示的にユーザーの同意を得るようにしています。併せて、フローの中で FAQ ページへのリンクを提供することで、ユーザーが不安になった際に今どこのステージにいるのかを理解する手助けをしています。また、この同意をとるためのフロー自体、彼らのオンラインバンキングのものと非常に似たフローを採用しており、同じログイン情報、パスワード、 追加の情報（訳注：memorable information。記憶できる長さの文字列をユーザーにあらかじめ提供し、その中のいくつかの文字を入力してもらう）をユーザーに対して聞くことで、親密性と信頼性を得ることに注力しています。鍵のアイコンが見えるウェブページにリダイレクトさせることも、日頃ウェブ経由で使っているオンラインバンキングであることを強調し、信頼性を得ることに貢献していると言えます。
しかしながら、各行の同意フローの中でも、これは長い部類になってしまっています。というのは、BOS は同意確認を（TPP で行なっているにも関わらず）また実施し、またログイン処理を、「二番目の同意確認」と「最初の認証」の両方をまとめたかたちで実施するからです。「正の摩擦」を生むはずなのに、どの情報を共有するかについて3回も（しかも毎回微妙に違った形で）確認するフローとなっているため、プロセスが冗長になってしまっています。くどくかつ冗長な場合、ユーザーは情報を飛ばして読む傾向があり、重要な情報がユーザーに伝わらなかった場合、将来大きな問題につながりかねません。
BOS の同意フローは確かに OBIE の推奨に従ったものではありますが、UX は面倒なものとなってしまっており、反感を招きかねません。特に、技術的に明るいユーザーにとっては。
RBS & Yolt
CMA 9 に属する銀行のもう一行、RBS は多少効率的なフローを採用しています。BOS 同様、同意フローは同意～認証～認可の3ステップからなり、銀行のオンラインバンキングのウェブサイトを使って信頼性獲得に努めています。オンラインバンキングと同じクレデンシャル情報が求められますが、BOS と異なり、どの口座を Yolt と連携させたいのか選べるようになっています。そうすることで、ユーザーは自身の情報をよりコントロールできるようになっていますし、さほど重要でない口座を使って Open Banking を試す、といったケースも可能にしています。
また、API を使って連携している銀行向けに、Yolt 自身、同意フローの UX を高めるための機能を持ち合わせています。同意フローの中で、彼らはユーザに対し、Open Banking を使って情報共有することの意味について説明するリンクを提供しています。口座が一旦認可されると、彼らは追加のステップを使い、銀行がコントロールしている部分から、Yolt のアプリに戻ったこと、また、どの情報が共有されるのかということをユーザーに明確に伝えています（上記図における最後の画面）。こうすることで、フローの進捗の可視性を高め、ユーザーにコントロールしている感覚を与えつつ、フロー自体を完了させるための手助けもしています。
Santander & Yolt
Santander は CMA 9 のうちの１行ではありますが、2018年8月時点では、Yolt との API による連携を行っていません。ですが、ここに記されたフローは API を使って連携する場合とほとんど同じです。違いのうちの一つは、同意のステップの中で「TPP はユーザーのクレデンシャル情報にアクセスできない」という説明がないことです。実際、このフローの裏側では、TPP はユーザーに成りすましてログインし、個人情報をスクレイピングしています。しかしながら、同意や認可のステップがなく、クレデンシャル情報を提供するだけの最低限のフローとなっており、これまでの事例にくらべて最もシンプルです。ユーザーからすると、ただログインに必要な情報を入力するだけで、口座情報にアクセスできるようになります。このフローで問題なのは、TPP に対してどの情報が手渡されているのか必ずしも常に明確ではないことです。このことは、サービスに対する不信につながるかもしれませんし、しいては銀行との連係解除につながるかもしれません。
Monzo & Yolt
続く2つの事例は、チャレンジャーバンクのものです。Open Banking の対象銀行ではないため、API を公開する義務は彼らにはありませんが、公開することに明確なメリットがあると考え、Yolt とも API で連携しています。
しかし、チャレンジャーバンクである Monzo と Starling Bank の同意フローは、他の API 連携を採用している銀行のフローとは大きく異なります。彼らのフローには利点も欠点もあるでしょうが、異なるフローを採用することによって、混乱するユーザーもいるかもしれません。チャレンジャーバンクは本当に API 経由で連携しているのだろうか、ID やパスワードは TPP にわたっているのではないか、と。
Monzo も Starling Bank も認可と認証を彼らのアプリ上で行なっています。そうすることで、ステップが減り、同意フローが効率的になるものの、技術的に明るくないユーザーにとっては正の摩擦を生み出すには不十分かもしれません。Monzo は電子メールによる確認を用いたログイン処理を行なっています（訳注: いわゆる Magic Link）。また、今どのステージにいるのかユーザーに伝えています。また、度々 TPP（この例では Yolt ）の名前を示す事で、情報連携が行われている事をユーザーに通知しています。Monzo は、共有される情報の一覧については明示しているものの、いつまで情報共有されるのかについて、また、TPP がユーザーのクレデンシャル情報にはアクセスできない事については明示していません。ユーザーによっては誤解し、アプリへの不信につながるかもしれません。さらに Monzo は、フローの中の一画面で「このアプリにあなたの銀行口座へアクセスする権限を与えます」と表示しますが、これも十分な情報をユーザーに提示しているとは言えず、「この TPP はあなたになりすましてログインし、口座情報にアクセスできるようになります」という風に解釈されかねません。公開されているドキュメントを見る限り、Monzo はスクリーンスクレイピングではなく、API 経由で情報連携しているはずはありますが。これらの考察からも、最初に言及したように、API を公開する銀行の間で、異なる同意フローを採用することは、信頼低下を招き、最終的にはユーザー数の減少に繋がりかねません。
他の銀行の事例と比較した際、同意フローの安全性や透明性に疑問を持つユーザーがいるかもしれませんが、このフローは短く効率的です。ユーザーはメールアドレスを入力し、リンクをクリックするだけです。技術的に明るいユーザーにとっては、この短いフローの方がいいかもしれません。
Starling Bank & Yolt
最後の事例は、Starling Bank です。Starling Bank が最初に情報連携を PR したチャレンジャーバンクです。彼らの同意フローこれまでの事例の中でも一番短く、認証を PIN コードで行うのが特徴的です。ユーザー名、パスワードなどを使う方法に比べ、簡単で短いものとなります。ブラウザ経由でなくアプリ上で認証することも、フローの安全性向上に寄与しています。
しかし、Monzo の場合同様、いつまで情報共有が継続するのかは明示されませんし、TPP がクレデンシャル情報にアクセスできないことも明示されません。しかし、そもそも、そこまで念押しする必要があるのでしょうか？OBIE の調査結果に基づけば、大多数のユーザーにとっては必要であることは明らかですし、彼らのニーズに合わせるべきだと思います。
もう一点言及しておくべきこととして、Starling Bank は、彼らのアプリ上から簡単に情報連携を無効化できる機能を提供しています。しかし、Monzo に関しては、そのような機能を提供していません。
結論
とどのつまり、技術的な課題以外にも Open Banking 実現のためには課題が多く残されているということです。しかし、明快で効率的かつ首尾一貫した UX を作る努力を徹底することが、ユーザー獲得やエンゲージメントに寄与するでしょう。この考えは、新しいアプリやサービスを開発する TPP だけに当てはまるものではなく、TPP と協力し競争に勝ち残らなければならない銀行自体にも当てはまるものだと思います。
