同意管理で安全性の高いエンベデッド ファイナンスを実現
Google Cloud Japan Team
※この投稿は米国時間 2022 年 1 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。
金融サービスを銀行などの金融機関以外の企業を介して利用できるようにすることをエンベデッド ファイナンス（組込型金融）といいます。たとえば、商品を購入する消費者に資金提供を行う小売業者や、銀行取引データを収集して支出パターンの分類や把握に役立つ予算管理アプリなどが該当します。金融、つまり資金管理が、小売業者や予算管理機能に組み込まれています。
この最後の例（予算管理機能への組み込み）は、エンベデッド ファイナンスのデータ交換のカテゴリに分類され、オープン バンキングと呼ばれることもあります。多くの国では、こうした能動的なデータ交換が実際に法律で義務付けられており、すべての金融機関に対して特定のオープン バンキング標準が法律で定められています。このブログ投稿の時点で、こうした法律をすでに施行している、もしくは策定中である国は約 37 か国にのぼります。
組込型金融のスキームには、3 つの主要なプレーヤーがいます。商品やサービスを提供する金融機関、その商品やサービスを利用するサードパーティ プロバイダ（TPP）、金融機関の顧客であり TPP と情報をやり取りするエンドユーザーです。
このスキームで最も重要な要素は、消費者の信頼です。消費者は、自分のデータが第三者と安全に共有され、同意した条件が簡単に理解できるものであり、いつでも好きな時にデータの共有を停止できるという点について確信を持てない場合、このスキームに参加すらしないでしょう。消費者がデータの共有を承諾することを同意と言います。
エンベデッド ファイナンスのソリューションを成功させるために必要なコンポーネント
銀行の商品やサービスは、API を介すことで他者が利用できるようになるため、API 管理プラットフォームが基礎コンポーネントになります。API 管理プラットフォームを使用すると、優れた可視性と管理性によりどこからでも API を設計、保護、分析、スケーリングできます。
次に、エンドユーザーから得た同意を管理するコンポーネントが必要です。同意の管理には、サードパーティによる特定のアクション（エンドユーザーの口座残高へのアクセスなど）が有効かどうかをエンドユーザーから得た同意に基づいて確認する機能だけでなく、 エンドユーザーが既存の同意を確認、変更、取消するためのツールや、金融機関が顧客に代わって同様のアクションを実行するためのツールの可用性の確保も含まれています。
最後に、エンドユーザーを認証して身元を確認できる Identity Platform が必要です。
Google Cloud ベースのエンベデッド ファイナンス ソリューションでは、Apigee（API 管理プラットフォーム）、Identity Platform または独自に選択した ID プラットフォーム、同意管理サービス（CMS）が使用されています。 Google Cloud は、同意管理の分野における大手プロバイダ 2 社（Clarip および CloudEntity）と提携しています。
コンポーネントの連携方法
3 つのコンポーネントのそれぞれの主な役割と担当は非常に明確ですが、コンポーネント間のインタラクションをオーケストレートする方法や、コンポーネント間で機能が重複している場合にどのコンポーネントがどの機能を実行するかについては、ある程度の柔軟性があります。
Google Cloud で以下の 2 つのインタラクション パターンをテストしました。
インタラクションパターン #1: Apigee をメイン オーケストレーターとして使用する
このインタラクション パターンでは、Apigee は同意管理サービスと ID プラットフォームの両方とやり取りして、エンドユーザー認証は ID プラットフォームへ、承認と同意は同意管理サービスへと、それぞれの役割を調整します。Apigee は、ユーザー、ユーザー ID、同意の間で「ブローカー」として機能します。
インタラクション パターン #2: 同意管理サービスで ID プラットフォームを抽象化する
このパターンでは、同意管理サービスが ID 管理プラットフォームとのやり取りをすべて管理し、ID プラットフォームが「ブローカー」として機能します。Apigee は同意管理サービスとのみやり取りします。
この 3 つのコンポーネントは、クライアント アプリとエンドユーザーの共通プールを共有します。通常は、1 つのコンポーネントがこれらのエンティティの信頼できる情報源として指定され、これらのエンティティに関する情報を必要とする他のコンポーネントは、信頼できる情報源からの情報を同期します。
ID プラットフォームは通常、エンドユーザー ID の信頼できる情報源であり、同意管理コンポーネントは、ID プラットフォームから情報を引き出すことで同期します。
同意管理サービスは、ユーザーのオプトインと現在の同意ステータスについての信頼できる情報源です。Apigee は、リクエストが届くたびに同意管理サービスに同意の有効性を確認します。あるいは、より効率を高めるため、Apigee に保存されている情報に基づいて同意に関する主な属性を検証します。同意管理サービスは、他の手段で同意が取り消された場合（たとえば、エンドユーザーが同意ダッシュボードから同意を取り消した場合）、一貫性を維持するために、同意に関連付けられたトークンを無効にするように Apigee に指示する必要があります。
クライアント アプリの場合、Apigee または同意管理コンポーネントのいずれかが信頼できる情報源として機能し、他のコンポーネントはその情報を同期します。特にオープン バンキングでは、金融機関が動的クライアント登録をサポートすることを標準で義務付けている場合が多々あります。これは、新しいクライアントが自分自身をオープン バンキング API のクライアントとして登録するために使用できるエンドポイントを持つということです。この場合、クライアントの同期を動的クライアント登録に簡単に組み込むことができます。
ここで、3 つのコンポーネントがどのように相互作用するか詳しく見ていきましょう。特に関連性の高いユーザー ジャーニーが 2 つあります。
認証 / 承認 / 同意
エンドユーザーが、あるサードパーティのアプリの使用を開始します。このアプリはエンドユーザーのデータへのアクセスを必要としており、これが典型的な消費者のクライアント ジャーニーの始まりです。サードパーティのアプリは、アプリ自体を認証して、ユーザーのデータにアクセスするための承認をリクエストする必要があります。これにより、エンドユーザーの認証と同意の付与がトリガーされます。同意の付与とは、アプリがユーザーに代わって実行するオペレーションを承認し、これらのオペレーションが実行されるアカウントのリストを確定するユーザーのプロセスです。承認はアクセス トークンで示され、アプリはこれを後続のすべてのリクエストで指定する必要があります。
これは非常に複雑なジャーニーです。可能な限り安全に進めるために多くの手順を実行しなければなりません。理解しやすいように、手順を簡略化して説明します（OIDC / FAPI の専門家のみなさん、お許しください）。
このユーザー ジャーニーの手順の概要は以下のとおりです。
エンドユーザーがアプリの使用を開始します
アプリがユーザーのデータにアクセスするための許可をリクエストします
ID プラットフォーム（IdP）がエンドユーザーを認証します
同意管理サービスがエンドユーザーから同意を取得します
アクセス トークンがアプリに対して発行され、承認されたアクセス許可やアカウントなどがカプセル化されます。アクセス トークンの寿命は通常短い（分単位で測定）ですが、更新トークンも発行されるため、アプリはこの更新トークンを使用できます。更新トークンは通常、非常に長い間（数日または数か月）使用できます。これは、エンドユーザーの認証 / 承認 / 同意プロセスを再度実行しないで新しいアクセス トークンを取得するためです。
これらの手順をオーケストレートする方法は、コンポーネント間のインタラクション パターンによって異なります。
パターン #1: Apigee がすべてのインタラクションをオーケストレートする
クライアントが許可をリクエストすると、Apigee はそのリクエストを記録し、クライアント アプリを IdP ログインページにリダイレクトします。エンドユーザーがログインすると、IdP は Apigee が IdP 構成に登録したコールバック URL に認証コードを返します。
次に、Apigee はクライアント アプリを同意管理サービスにリダイレクトし、同意フォームが表示されるようにします。ユーザーが同意を付与して必要なアクセス許可を選択し、適用するアカウントを選ぶと、同意管理サービスは、同意構成に登録されたコールバック Apigee を介して、同意のステータスで Apigee を更新します。
エンドユーザーが認証されて同意が付与されたので、Apigee は認証コードを発行し、同意に関する詳細、Identity Platform（IdP）によって発行された認証コード、IdP のエンドユーザー ID など、必要なすべての情報を関連付けられるようになりました。Apigee は、Apigee での登録時にアプリが提供したコールバック エンドポイントを介して、この認証コードをクライアント アプリに返します。
その後、アプリは認証コードをアクセス トークンと交換します。Apigee は IdP からアクセス トークンを取得し、クライアントにアクセス トークンを発行する前に同意のステータスを更新します。
パターン #2: 同意管理サービス（CMS）をアーキテクチャの中心にする
パターン #2 では、Apigee は同意管理サービスとのみ通信します。同意管理サービスはアプリの承認サーバーとして機能し、IdP とのインタラクションもすべて調整します。
クライアントが許可をリクエストすると、Apigee はそのリクエストを CMS に転送します。CMS はリクエストを記録してから、クライアント アプリを IdP ログインページにリダイレクトします。エンドユーザーがログインすると、IdP は認証コードを IdP 構成に登録されている CMS のコールバックに返します。
次に、CMS は同意フォームを表示します。ユーザーが同意を承認し、適用する必要なアクセス許可とアカウントを選択すると、同意管理サービスは、CMS 構成に登録されているコールバック Apigee を介して、認証コードを Apigee に返します。
これ以降は、上記のフローを繰り返します。Apigee は、認証コードを発行し、必要な情報をすべて関連付け、コールバック エンドポイントを介してこの認証コードをクライアント アプリに返します。その後、アプリは認証コードをアクセス トークンと交換します。Apigee は、クライアントにアクセス トークンを発行する前に、CMS からアクセス トークンを取得します。
次に、他の関連するユーザー ジャーニーを見てみましょう。
共有データへのアクセス
サードパーティのアプリの承認が完了すると、アプリはそのエンドユーザーのデータのリクエストを開始します。たとえば、アカウントのリストや特定のアカウントの残高をリクエストする場合があります。
そのリクエストが通過したら、「このサードパーティのアプリは今も承認されているか？」「リクエストされているオペレーションに対して適切な権限が与えられているか？」「関係するアカウントが、エンドユーザーによる承認済みアカウントのリストに含まれているか？」をチェックする必要があります。Apigee は、サードパーティのアプリから提示されたアクセス トークンを検査することで、こうしたチェックをすべて実行できます。
ただし、トークンを検査するだけでは実行できないチェックが 1 つあります。ユーザーが同意を付与し、アプリがユーザーのデータをリクエストするまでの間に、エンドユーザーがその同意を取り消すことに決めた場合です。これは、アプリ自体ではなく、たとえば「インターネット バンキング」サイトなどの他のチャネルからアクセスできる同意ダッシュボードで、すべてのアプリに付与された同意をすべて確認することで実行できます。アプリがユーザーデータをリクエストした場合、トークンは引き続き有効ですが、同意はすでに取り消されています。したがって、このユーザー ジャーニーでは、Apigee は同意管理サービスをチェックして、同意がまだ有効かどうかを確認します。これにより、オーバーヘッドが少し増えますが、他の方法で最小限に抑えることができます。たとえば、一般的な最適化の 1 つとして、他のチャネルから同意が取り消された場合に、同意管理サービスが Apigee に、特定の同意に関連付けられたアクセス トークンまたは更新トークンを取り消すよう依頼する方法があります。このガードレールが設定されている場合、Apigee は、アクセス トークンを検証し、トークンとともに保存されている同意情報を使用するだけで、リクエストを許可すべきかどうかを判断できます。
次の図は、Apigee と同意管理コンポーネントの間に必要なインタラクションをまとめたものです。インタラクションは、どちらのインタラクション パターンでも基本的に同じです。
次のステップ
この記事では、エンベデッド ファイナンスのソリューションを安全に成功させるための基本的な要素として、Apigee、同意管理サービス、Identity Platform について説明しました。また、これらのコンポーネントがどのように相互作用し、ユーザーの同意を一貫して利用できるようにしているのかについても確認しました。説明したインタラクション パターンはどちらも有効であり、機能することが証明されています。では、お客様に適しているのはどちらのパターンでしょうか？特定の要件、同意管理サービスの選択、ID プラットフォームの選択によって最終的な答えは異なりますが、経験則としては、複数のアプリケーション エクスペリエンス、ID システム、および同意のソースがある場合は、Apigee 中心のアーキテクチャが最適なソリューションです。中央集権機関（例: Open Banking Brazil、オーストラリアの消費者データ基準）によってオープン バンキングの実装が義務付けられている状況で同意管理サービスを検討している場合は、CloudEntity が同意管理に適しています。CloudEntity のプロダクトは Financial-grade API（FAPI）認定を受けた OpenID プロバイダであり、さまざまなオープン バンキングの標準のプロファイルを備えているためです。CloudEntity は、パターン #2 を使用して Apigee と統合します。
Clarip と CloudEntity のそれぞれのサービスの詳細と、両社のソリューションが GCP でどのように機能するかについては、以下をご覧ください。
Clarip: ユニバーサル同意管理プラットフォーム - GDPR
CloudEntity: 認定済みの大規模な OpenBanking と同意（英国、ブラジル、オーストラリア）
Apigee API 管理の詳細については、https://cloud.google.com/apigee をご覧ください。
Google のリテール バンキング向けソリューションで詳細をご確認いただくか、営業担当者までお問い合わせください。
- FSI、業界ソリューション、ソリューション アーキテクト Debora Elkin
