AWS を活用したオープンバンキング ～ データ受信企業における実装方法

2017年11月26日、オーストラリア政府は、消費者データ権 （CDR）の導入を発表しました。オーストラリア競争・消費者委員会 （ACCC）によって管理される CDR は、消費者が自分のデータをより詳細に制御し、商品とサービスの比較や乗り換えする能力を高めることを目指しています。例えば、フィンテックはオープンバンキングデータを使用することで、消費者に最も適したクレジットカードやローンを見つけやすくします。AWS パートナーである Adatree のオープンバンキングユースケースレポートには、このようなユースケースが多数記載されています。CDR によって推進される透明性は、住宅ローン、個人ローン、クレジットカード、貯蓄口座などの銀行商品の価格競争の強化につながるだけでなく、消費者データを活用する革新的な製品やサービスにつながります。

オープンバンキングは、段階的なアプローチによって開始されています。商品データは2020年6月に利用可能になりました。2020年7月1日、オーストラリア・ニュージーランド銀行、ナショナルオーストラリア銀行、ウエストパック銀行、およびオーストラリア・コモンウェルス銀行の「ビッグ4」銀行（データ所有者）は、さまざまな顧客口座でデータを使用できるようになりました。今後12か月の段階でビッグ4は、ビジネス、投資、その他のアカウントからデータを利用できるようにする必要があります。最後に、2021年7月1日、他のすべてのオーストラリアの銀行は、顧客の要求に応じて、認定された第三者（データ受信者）と個人および法人の取引データを共有することが求められます。

このブログでは、データ受信者が AWS でオープンバンキングの基礎をセットアップし、オープンバンキングのデータ受信者になるまでの時間を短縮する方法について概説します。このブログはオーストラリアの CDR に焦点を当てていますが、他の国のオープンバンキング規制についても概念とアーキテクチャを拡張することができます。

オープンバンキング エコシステム

オープンバンキングエコシステムは、データ所有者（DH）、データ受信者（DR）および CDR レジスタ（ACCC）で構成されています。顧客預金を保有する組織（認定預金取扱機関（ADI））は、CDR の下でデータ所有者になることが義務付けられています。オーストラリアには141社の ADI があります。データ所有者は顧客データと商品データの「作成者」であり、オープンバンキング API を介してデータ受信者にそのデータを利用できるようにする必要があります。データ受信者は、顧客の要求に応じてオープンバンキングデータを受信または取り込むことを ACCC が認定した組織です。次の図に示すように、ACCC は CDR レジスタの役割を果たし、データ所有者と認定データ受信者の両方の情報を保持しています。各エコシステムエンティティは、それぞれの API を実装することになっています。API の詳細はこちらをご覧ください。

ソース: ACCC GitHub repository のエコシステムダイアグラムを一部変更

データ受信者の認定プロセス

認定データ受信者（ADR）を希望する組織は、ACCC によって概説された認定プロセスを経る必要があります。同じガイドライン文書から撮影されたスクリーンショットは次のとおりです。これは、複数のフィードバックループを備えた5つのステップのエンゲージメントプロセスです。認定者が評価に満足したら、認定を申請者に通知します。プロセスの詳細については、認定ガイドラインを参照してください。

ソース: ACCC CDR 認定ガイドライン

同意管理プロセス

CDR 規制では、消費者がデータ共有を承認した場合にのみ、データ所有者は消費者データを共有することができます。同様に、消費者からデータ所有者向けの同意を持っている場合のみ、認定データ受信者はデータを要求し使用することができます。データ所有者はすべての承認を記録する必要があり、認定データ受信者はすべての同意を追跡する必要があります。

それでは、消費者が複数のデータ所有者間で自分の口座残高を確認したいときに、消費者管理フローがどのように機能するかを理解するために例を見てみましょう。

ステップ1: 消費者/ユーザーが ADR ソフトウェア製品にログインします。
ステップ 2:  ADR は同意プロセスを開始し、同意に関連する情報を要求します。例えば、どのデータ所有者であるか、どのようなデータ（個人情報、取引詳細、受取人の詳細など）であるか、いつ（一ヶ月、3ヶ月など）まで同意するか、そして同意の満了後のデータ（データの識別を解除して保持する、またはデータを削除）はどうなるかという情報です。
ステップ 3: 3 ADR は「request_uri」を取得するために、データ所有者の Pushed Authorization request（PAR）エンドポイントに対し消費者から収集したすべての情報を渡します。 request_uri パラメーターを使用すると、ADR はリクエストオブジェクト自体の代わりにリクエストオブジェクトへの参照を送信できます。
ステップ 4: 消費者は、前のステップで受信した「request_uri」と一緒に選択したデータ所有者のログインページにリダイレクトされます。消費者は既存の認証情報を使用してログインできます。データホルダーは消費者を認証し、request_uri を検証します。
ステップ 5: 認証が成功した後、データ所有者は消費者がそれぞれの ADR とのデータ共有に同意するか確認します。消費者は、データ所有者に対し自分のデータを ADR と共有することを許可します。
ステップ 6: 認証はデータ所有者によって記録され、その後、消費者は認証コードと共に ADR にリダイレクトされます。
ステップ 7: ADR は同意を記録し、同意データベースに情報を格納します。
ステップ 8: ADR はステップ6で用意された認証コードを使用し、アクセストークンを取得します。
ステップ 9: ADR はアクセストークンを使用してデータ所有者の銀行 API を呼び出し、データ所有者から関連データを取得し、内部的に管理されている消費者データベースに格納します。
*ステップ 2 ～ 9 は、消費者がアカウントを持っているデータ所有者ごとに繰り返されます。
ステップ 10: すべての銀行およびデータ受信者の取引明細書の要約に対するリクエストは、内部の消費者データベースを照会することにより情報を提供できます。

同意の取り消し

同意は、ADR ソフトウェア製品、またはデータ所有者アプリケーションのいずれかで取り消すことができます。アクセストークンは取り消され、同意に基づき ADR のデータベース上のデータが削除または非特定化されます。これは複雑なトピックですので別のブログを紹介します。データ消去リクエストの処理に関する私の AWS の同僚からのブログ記事をご覧ください。このブログに記載されているパターンは、取り消しフローの管理に使用できます。

リファレンスアーキテクチャ

認定データ受信者（ADR）は、同意管理や、データ所有者および ACCC との統合、CDR データと既存のデータを操作するためのアプリケーションロジックを構築する責任があります。これを簡素化するために、ADR は銀行統合機能や同意管理機能をビジネスロジック機能から分離できます。CDR のセキュリティ制御要件は、組織で既に使用しているものとは異なる可能性があるため、さらに既存のデータ環境と自分の CDR データ環境を分離することができます。

次のアーキテクチャは、銀行との統合、ACCC、同意管理、およびビジネスアプリケーションのホスティングに必要な基本環境に焦点を当てています。基礎部分を設定する場合は、最高レベルの分離を提供するマルチアカウントアプローチをお勧めします。同意管理アカウントは、同意管理とデータ所有者と ACCC の両方によって公開される API の統合をホストします。また、ビジネスアプリケーションアカウントは、アプリケーション固有の API と消費者データをホストします。2 つの AWS アカウントを持つと、ワークロードの分離と AWS リソースの効果的な管理につながります。これにより、データ受信者として AWS パートナーを参加させることも容易になり、ビジネスアプリケーションアカウントと簡単に統合できる同意管理アカウントの実装と管理を実現できます。

クレジット: Shane Doolan （Adatree 社 CTO）有用な情報を提供いただき感謝いたします。

次のセクションでは、アーキテクチャのいくつかの主要なコンポーネントを説明します。

• 1と2は、認定データ受信者によって開発された消費者向けアプリケーションおよびソフトウェア製品を表します。
• 3は、オープンバンキングエコシステムの他のエンティティであるデータ所有者と ACCC を表します。
• 4 は、Amazon API Gateway を使用して実装される API 管理レイヤーを表します。また、AWS Web Application Firewall と統合して、一般的なウェブ攻撃から保護することもできます。
• 5 は、プライベートサブネットでホストされている AWS Lambda を使用した同意管理関連のマイクロサービスの実装を表します。AWS Lambda はワークロードの動的な性質を満たし、サーバー管理に必要な管理作業を軽減するために選択されます。
• 6 は、消費者の同意を Amazon QLDB に保存して、同意を追跡し、時間の経過に伴う変更の完全かつ検証可能な履歴を維持できるストレージレイヤーを表します。Amazon Aurora は、同意管理に必要な設定およびデータを保存することができます。
• 7 は、プライベートサブネットでホストされている AWS Lambda を使用するアプリケーション固有のマイクロサービスを表します。
• 8 は、Amazon Aurora が銀行から取得した消費者データと集計データを格納するために使用できるストレージレイヤーを表します。データが明確に定義・構造化されるため、リレーショナルデータベースが選択されます。
• 9 は、プライベート Amazon API Gateway を表します。この API ゲートウェイは、同意管理アカウントによってホストされる API にアクセスするために、アプリケーション固有のマイクロサービスによって使用されます。この場合、プライベート API が使用されます。ソースと宛先の両方が内部であり、すべてのネットワーク呼び出しはパブリックインターネット経由ではなく AWS バックボーンで発生します。これにより、セキュリティとパフォーマンスが強化されます。
• 10は、ロギングとモニタリングに使用できる AWS サービスを表します。AWS CloudTrail、 Amazon CloudWatch、および AWS X-Ray は、アプリケーションで必要とされる可観測性を提供します。Amazon Elasticsearch Service を使用すると、すべてのログを集約してアプリケーションを監視し、Amazon Simple Notification Serviceを使用して通知を送信できます。Amazon Simple Storage Service（Amazon S3）は、ウェブまたはモバイルアプリケーションの静的コンテンツを保存するために使用できます。また、適切なライフサイクルポリシーですべてのログを保存することもできます。
• 11 は、セキュリティとコンプライアンスのために使用できる AWS サービスを表します。AWS Config を使用して ACCC によって義務付けられているセキュリティコントロールを実施し、ACCC によって指定されたセキュリティアサーションを保存するため AWS Secrets Manager を使用します。 また、データの暗号化と復号化に必要なキーを管理するため AWS Key Management Service（AWS KMS）を使用します。AWS Certification Manager を使用して、Amazon API Gateway カスタマードメインに証明書を提供します。AWS Shield は DDoS 保護に、Amazon GuardDuty はインテリジェントな脅威検出に使用できます。
• 12は、消費者データに対するさらなる洞察と分析を表します。たとえば、データ受信者はこのデータを使用して予算監視や与信決定ユースケースを構築できます。

セキュリティとコンプライアンスの管理

認定プロセスの一環として、ADR が運用する統制と AWS から継承する統制について理解することが重要です。これを責任共有モデルと呼んでいます。お客様が選択したサービス、IT 環境へのサービスの統合、および適用法規に基づいて、お客様の責任を慎重に検討することが重要です。

ACCCは、こちらにある消費者データ権適合テストスイートについて、データ所有者および認定データ受信者のガイダンスを公開しています。

まとめ

CDR はゲームチェンジャーであり、オーストラリアのオープンデータ経済への一歩です。これにより消費者は自分のデータをより詳細に制御でき、消費者向けの革新的な製品を ADR に構築することを促します。このブログでは、データ受信者を銀行と統合し、CDR データの上に革新的なユースケースを構築する方法について説明しました。リファレンスアーキテクチャは、見込みのある ADR が同意管理とビジネスアプリケーションアカウントを設定するための基礎構造を迅速に開始するのに役立ちます。この記事で取り上げているアーキテクチャは、オーストラリア CDR 体制のために設計されていますが、同意管理の基礎は同じであるため、他の国のオープンバンキング規制にも拡張することができます。ADR が独自の同意管理プラットフォームを構築する場合、AWS は迅速な構築を支援する適切なサービスを提供します。この取り組みのサポートをお探しの方には、AWS には適切なパートナーネットワークがあります。詳細については、アカウントマネージャーまたは AWS 営業チームにお問い合わせください。