オープンバンキングにより、サードパーティの金融サービスプロバイダーは銀行などの金融機関から顧客データにアクセスできます。顧客は自身の情報にアクセスできる人物を管理し、サードパーティとのデータ共有に同意する必要があります。アプリケーションプログラミングインターフェイス (API) を通じてアクセスされるこの共有データは、金融業界のイノベーションと競争を促進し、フィンテックや新しい金融サービスの台頭を可能にします。世界のオープンバンキング決済の総取引額は、2025 年の 400 億ドル近くから 2033 年までに 2,880 億ドルに増加すると予測されています。
安全でコンプライアンスに準拠したオープンバンキングは、事業体間で共有される機密の金融データを保護するセキュリティ基盤の上に構築されています。ここでは、API セキュリティ、識別、保護戦略など、オープンバンキングの仕組みや、顧客データがどのように保護されているかについて説明します。
この記事でわかること
現代のオープンバンキングは、従来のスクリーンスクレイピングではなく標準化、トークン化された API と OAuth 2.0 に依存しており、ユーザーが生の銀行パスワードをサードパーティと共有することは決してありません。
ユーザーは、特定の情報に対して明示的かつ期限付きの権限を付与することで自らのデータを完全に管理でき、銀行や連結されたアプリを通じてその権限を即座に取り消すことができます。
安全なオープンバンキングは、強力な顧客認証 (SCA)、転送中および保存中のエンドツーエンドの暗号化、サードパーティプロバイダーの厳格な審査を組み合わせることで、不正利用のリスクを軽減し、責任の所在を明確にします。
オープンバンキングの用途
オープンバンキングはデータ共有を促進し、顧客やビジネス向けの金融サービスを強化します。
オープンバンキングにより、次のようなさまざまな金融ツールや機能が利用可能になりました。
予算管理および貯蓄アプリ: オープンバンキングにより、ユーザーの銀行口座データを集約し、パーソナライズされた予算管理や貯蓄の推奨事項を提供するサードパーティアプリの構築が可能になりました。
より的確な信用判断とローン審査: 貸し手はオープンバンキングを通じてより多くの財務データにすばやくアクセスして分析できるため、信用判断の向上やローン承認の迅速化につながります。
パーソナライズされた銀行サービス: 金融機関は、オープンバンキングを通じてアクセスしたデータを使用して、カスタマイズされた金利など、パーソナライズされたプロダクトやサービスを顧客に提供できます。
口座からの直接決済: オープンバンキング API を使用して銀行口座から直接決済を開始し、クレジットカードなどの従来の決済システムをバイパスできるため、取引手数料を削減できる場合があります。
不正利用の検出精度の向上: リアルタイムのデータにアクセスすることで、金融機関やサービスプロバイダーは不正利用の検出能力を向上させ、不正な取引のリスクを軽減できます。
キャッシュフロー管理: ビジネスではオープンバンキングソリューションを使用して、さまざまな口座のデータを単一のプラットフォームに統合し、キャッシュフローをより正確に把握できます。
市場インサイト: ビジネスでは、オープンバンキングで利用可能になった銀行データを分析し、顧客行動、市場動向、経済状況に関するインサイトを得ることができます。
オープンバンキングの仕組み
オープンバンキングは API を使用して、銀行と認可されたサードパーティプロバイダー間で金融データを共有します。データを共有するには、さまざまなフレームワークで規制されている顧客の同意が必要です。
オープンバンキングの仕組みは次のとおりです。
銀行による標準化された API の構築: 銀行は、サードパーティプロバイダーが金融データにアクセスできる標準化された API を開発または採用します。これらの API は、データのリクエストとレスポンスの安全なゲートウェイとして機能します。
顧客による同意: 顧客は、金融データにアクセスするための明示的な同意をサードパーティプロバイダーに与えます。同意は通常、安全なインターフェイスを通じて管理され、十分な説明に基づいて明示的に行うことが法的に義務付けられています。
プロバイダーによるデータアクセスのリクエスト: 同意が得られると、サードパーティプロバイダーはオープンバンキング API を実装し、顧客の金融データへのアクセスを銀行にリクエストします。これらの API は、リクエストを安全かつ一貫して処理します。
銀行による認証とオーソリの管理: 銀行は、データにアクセスするための顧客の身元とサードパーティプロバイダーへのオーソリを検証します。このプロセスには、銀行のポータルを介したログインやその他のセキュリティチェックなどの認証ステップが含まれることがよくあります。
銀行によるデータの共有: 認証とオーソリが成功すると、銀行は API を通じてリクエストされたデータをサードパーティプロバイダーと共有します。データには、口座残高、取引履歴、決済開始機能などが含まれます。
リアルタイムでのデータの提供: API を使用することで、アプリは最新の取引であれ口座の所有権の確認であれ、顧客の銀行から直接最新のデータを取得できます。これにより、予算管理アプリや自動化されたローン承認など、多種多様な金融テクノロジーサービスが促進されます。
プロバイダーによるデータの使用: サードパーティプロバイダーはデータを使用して、財務管理、パーソナライズされた財務アドバイス、より簡素な資金調達プロセス、決済サービスなどのサービスを顧客に提供します。
顧客による継続的な同意の提供: 顧客はいつでも同意を管理したり撤回したりできます。銀行とサードパーティプロバイダーは、データを保護しプライバシーを確保するために、厳格なセキュリティ対策を遵守する必要があります。
規制当局によるルールの設定と施行: オープンバンキングは政府機関および国内法によって規制されており、それらによってセキュリティ基準、顧客の同意手順、オープンバンキングで共有できるデータの種類が規定されています。規制当局は、銀行とサードパーティプロバイダーがオープンバンキングの規制を遵守しているかを継続的に監視します。
通信の標準化: オープンバンキング API は特定の基準に従っています。つまり、さまざまな銀行やアプリで使用される「共通言語」で通信します。これにより、アプリやサービスがさまざまな銀行や金融機関とスムーズに連携できるようになります。
オープンバンキングの主要なセキュリティの課題
オープンバンキングは機密性の高い金融データが漏洩するリスクを高めるため、不正アクセスからデータを保護する高度なセキュリティ対策が必要になります。セキュリティの課題に対処するには、高度なテクノロジー、適切に設計されたセキュリティプロセス、および継続的な監視を組み合わせる必要があります。
オープンバンキングにおけるセキュリティの課題には次のようなものがあります。
顧客の同意の管理
個人の金融データは顧客が明確に同意した場合にのみアクセス可能であり、顧客はいつでもそのアクセスを取り消すことができます。
解決方法
- 同意を管理する最先端のシステムを導入する。
- データを管理するためのわかりやすいオプションを顧客に提供する。
- 一般データ保護規則 (GDPR) などの厳格なプライバシー法を遵守する。
不正アクセスに対する API のセキュリティの確保
API はデータにアクセスするための玄関口であり、不正アクセスや攻撃から保護するための十分な対策が必要です。
解決方法
- OAuth 2.0 などの最新のオーソリ方法を使用する。
- 認証に mutual Transport Layer Security (TLS) などのツールを使用して API が強化されていることを確認する。
- 使用状況を監視して、異常なアクティビティを防止し検出する。
サードパーティプロバイダーの審査と監視
サードパーティーサービスは、セキュリティレベルがそれぞれ異なります。
解決方法
- すべての外部プロバイダーのセキュリティ対策を徹底的に評価する。
- サードパーティプロバイダーを継続的に監視する。
- 高いセキュリティ基準の遵守を求める。
転送中および保存中のデータの暗号化
データは、傍受された場合に改ざんされたり読み取られたりしないよう、暗号化を施す必要があります。
解決方法
- 保存中および転送中のデータには、強力な暗号化技術を使用する。
- デジタル署名などの技術を使用して、データの整合性を定期的に確認する。
不正利用の検出
データへのアクセス回数が増えると、未知の不正利用被害に遭う可能性もあります。
解決方法
- 高度な機械学習を使用して、発生時に不正利用を発見する。
- 疑わしいアクションを監視し、迅速に対応するシステムを設定する。
法令遵守
規制の内容は地域によって異なり、時間の経過とともに変化する可能性があるため、データの処理方法にも影響が出ます。
解決方法
- 新しい法律に迅速に適応できるコンプライアンス戦略を構築する。
- チームが常に最新の要件を把握できるようにする。
- 対象地域の規制を理解する。EU とイギリスにはオープンバンキングに関する一元的な義務規定がありますが、アメリカのオープンバンキング規制は大部分が自主的かつ業界主導です。
本人確認とアクセス管理
個々のユーザーの本人確認を実施し、データへのアクセスを厳格に管理する必要があります。
解決方法
- SCA による本人確認と多要素認証 (MFA) システムを導入します。
- 厳密なアクセス制御を設定します。
- 不正な支払いまたはデータ侵害が発生した場合の法的および財務的な責任の枠組みを明確にします。たとえば、取引が不正なものであったか、(ソーシャルエンジニアリングなどを通じて) 承認されたものであったかによって、責任を負う事業体は異なります。
インシデントへの対応
問題が発生した場合でも、サービスは滞りなく提供されなければなりません。セキュリティ侵害があった場合、被害を最小限に抑えるために迅速に対処する必要があります。
解決方法
- インシデント対応計画を作成し、定期的に更新します。
- バックアップシステムが適切に配置されていることを確認します。
- 定期的にセキュリティ訓練を実施します。
オープンバンキング API のセキュリティを確保する方法
オープンバンキングにおける API セキュリティでは、銀行、サードパーティプロバイダー、顧客間のすべてのやり取りの安全性を確保し、データの整合性を維持するための多層的なシステムが求められます。
API セキュリティにおける主な考慮事項は以下のとおりです。
認証および承認
Financial-grade API (FAPI) などの認証および認可プロトコルにより、正当なユーザーとサービスのみが API にアクセスできるようになります。
OAuth 2.0: OAuth 2.0 は、認証情報の代わりにトークンを使用する認可方法です。各トークンは期間限定で特定のリソースセットへのアクセスを許可するため、トークンが盗まれるリスクを軽減できます。
OAuth: OAuth には、アプリ向けの認可コードや、サーバー間のやり取り向けのクライアント認証情報など、さまざまなシナリオにおいてトークンを取得するための方法が用意されています。
暗号化
暗号化は、データをシステム間で移動させるとき (転送時)、および保存するとき (保存時) に保護目的で適用されます。最新の強力な暗号化プロトコルを導入することで、攻撃者による傍受を防止できます。
TLS: TLS はクライアントとサーバー間でやり取りされるデータを暗号化し、転送中のデータを保護します。
AES: Advanced encryption standards (AES) がデータベースエントリやその他のデータストアに適用され、保存されているデータを保護します。
API ゲートウェイ
API ゲートウェイは、API へのトラフィックを管理・保護するためのシステムです。API ゲートウェイはリバースプロキシとして機能し、すべての API コールを受け入れ、それらを実行するために必要なサービスを集約して、適切な結果を返します。レート制限、IP ホワイトリスト、アクセス制御などもここで処理されます。ゲートウェイは、トラフィックパターンに関するインサイトを管理者に提供し、潜在的なセキュリティ脅威を警告するという役目も担っています。
安全な API 開発プラクティス
API は設計上、安全性が確保されています。開発者は、API セキュリティの啓発ドキュメントである Open Web Application Security Project (OWASP) のAPI Security Top Tenを遵守する必要があります。
入力検証: 入力検証により、SQL インジェクションやクロスサイトスクリプティング (XSS) 攻撃を防ぐことができます。
API トランザクションログの記録: API トランザクションの詳細なログを記録することで、監査が発生した場合に確実に備えることができます。
定期的なコードレビュー: 定期的なコードレビューにより、セキュリティ侵害につながる前に脆弱性を特定できます。
レート制限およびスロットリング
レート制限とスロットリングにより、API の悪用を防ぐことができます。このプロセスには、ユーザーまたはサービスが特定の期間内に行えるリクエスト数の制限が含まれます。その数が制限を超過すると、追加のリクエストは遅延またはブロックされます。スロットリングにより、負荷を管理し、トラフィックが多い状況や攻撃のシナリオでもサービスを確実に利用できる状態を維持します。
定期セキュリティ監査とペネトレーションテスト
定期セキュリティ監査とペネトレーションテストにより、API インフラのセキュリティ体制が継続的に評価されるようになります。これらのプラクティスは、標準のセキュリティプロトコルの一部であり、業界標準やコンプライアンス要件を満たしている必要があります。定期監査とペネトレーションテストを実施して、API が悪用される前に脆弱性を特定します。
異常検知・対応システム
これらのシステムは、機械学習やその他の高度な分析を活用する形で API トラフィックパターンを監視し、標準から逸脱したアクティビティに自動的にフラグを立て、セキュリティ侵害が疑われる異常なアクティビティを検出して自動で対応します。多くの場合、潜在的な脅威を迅速に隔離して緩和するために、インシデント対応メカニズムと一体になっています。
リスクベースのセキュリティ戦略を構築する方法
リスクベースのセキュリティ戦略では、さまざまな脅威の可能性とその潜在的な影響に基づき、セキュリティへの取り組みやリソースの優先順位を決定します。これにより、組織はアジリティを保ち、新たな脅威に対応し、最も必要とされる場所にリソースを集中させることができます。これは、セキュリティ予算が限られている場合や、テクノロジーの環境が急速に進化している状況において特に重要となります。
この項目では、リスクベースのセキュリティ戦略の一般的な仕組みをご紹介します。
リスクを評価する: 潜在的な影響と発生の可能性に基づいてリスクを特定し、評価します。組織の資産をマッピングし、各資産が直面する脅威を判断して、脆弱性とその脅威による潜在的な影響を評価します。脅威モデリングや脆弱性スキャンなどの手法を使用します。
リスクの優先順位付けを行う: どのリスクに早急な対応が必要か、どのリスクを監視できるか、どのリスクを許容できるかを判断します。重大度と可能性に基づいてリスクをランク付けし、影響度が高く確率の高いリスクを優先して早急に軽減します。
対策を導入する: 優先度が最も高いリスクを管理して軽減するために、最適かつ費用対効果に優れた対策を適用します。リスクに応じて、さまざまな種類の対策 (予防的、発見的、是正的など) を導入します。対策には、技術的なソリューション (ファイアウォールや暗号化など)、ポリシーと手順、トレーニングおよび啓発プログラムなどが含まれます。
セキュリティシステムを監視する: リスク管理の措置を継続的に監視し、その有効性を確保します。これには、定期的なセキュリティ監査、侵入検知システム、アクセスログやその他のセキュリティイベントの監視などが含まれる場合があります。
学習して改善する: 新たな脅威、組織の変化、あるいは継続的な監視から得られた教訓に対応して措置を調整します。監視およびレビュー段階のフィードバックを使用して、セキュリティの運用プロセスを改善します。インシデントの発生や脆弱性の特定に合わせて、リスク評価と対策を更新します。
ゼロトラストセキュリティポリシーを導入する方法
従来のセキュリティモデルでは、組織のネットワーク内にあるものはすべて信頼できると想定していますが、ゼロトラストポリシーでは信頼を一切想定しません。ゼロトラストでは、ネットワーク境界の内外を問わず、ネットワークリソースにアクセスしようとするすべての対象に対して厳格な本人確認が求められます。
ゼロトラストポリシーの一般的な導入方法は以下のとおりです。
すべてのリクエストを明示的に検証する: リクエストの送信元やアクセスするリソースにかかわらず、アクセスを許可する前にすべてのアクセスリクエストを検証する必要があります。MFA、生体認証、行動分析を使用してユーザーの本人確認を実施し、デバイスの健全性、場所、アクセス時間などの変数を考慮したコンテキストベースの認証を採用します。
最小権限のアクセスを使用する: タスクの実行に必要な最小限のアクセスレベルをユーザーとデバイスに付与することで、各ユーザーがネットワークの機密部分にさらされる機会を最小限に抑えます。これを、定期的に見直され更新される厳格なアクセス制御ポリシーとロールを通じて管理します。
ネットワークをセグメント化する: ネットワークをセグメントに分割し、ネットワーク内における攻撃者の水平移動を減らします。これにより、センシティブデータやシステムの周囲にマイクロ境界が作成され、攻撃者がアクセス権を取得してもネットワーク内を移動することが困難になります。
多層防御を実装する: 攻撃者がリソースにアクセスする際に回避しなければならない複数の防御層を実装します。ファイアウォール、侵入検知システムおよび侵入防止システム (IDS/IPS)、転送中および保存中のデータの暗号化を組み合わせて使用します。
セキュリティを監視して維持する: すべてのネットワークトラフィックとユーザーアクティビティを継続的に監視し、リアルタイムで脅威を検知して対応します。セキュリティ情報イベント管理 (SIEM) システムを使用して、異常な動作のログを分析し、関連付けます。機械学習により、通常から逸脱したパターンを認識することができます。
セキュリティを統合されたプロセスにする: 最初からあらゆる IT プロジェクトやビジネス業務において、セキュリティが重要な考慮事項であることを確実にします。全従業員に対して定期的なセキュリティトレーニングを実施し、ソフトウェア開発ライフサイクルにセキュリティを組み込みます (DevSecOps)。
セキュリティの脆弱性を特定して保護する方法
脆弱性の特定と保護には、攻撃者が悪用する可能性のあるソフトウェアとハードウェアのセキュリティホールや弱点を体系的に発見、分類、対処することが含まれます。一般的な仕組みは次のとおりです。
システムの既知の脆弱性をスキャンする: システム構成とインストール済みのソフトウェアを、既知の脆弱性データベースと比較する自動ツールを使用して、定期的な脆弱性スキャンを実施します。エシカルハッカーが脆弱性の悪用を試みるペネトレーションテストによっても、システムの弱点に関するインサイトが得られます。
調査結果を評価し、優先順位を付ける: 脆弱性が特定されたら、悪用の容易さ、悪用による潜在的な影響、システムの露出範囲などの要因に基づいて評価します。これにより、もたらされるリスクの性質と重大度に応じて、修復の取り組みの優先順位を付けることができます。
利用可能になったらすぐにパッチを適用する: ソフトウェアベンダーは脆弱性を修正するためのパッチやアップデートを提供します。セキュリティパッチ、アップデート、ホットフィックスをタイムリーに適用する体系的なプロセスを導入し、修正が利用可能になったらすぐに脆弱性に対処できるようにします。
システム構成を堅牢化する: 構成管理ツールを使用して、システムが安全に設定され、一貫して維持されていることを確認します。構成を定期的に見直して堅牢化し、攻撃対象領域を最小限に抑え、設定ミスやデフォルト設定による脆弱性を防ぎます。
未知のゼロデイ脅威から防御する: 既知の脆弱性シグネチャのみに依存しない、振る舞いベースの検知システムなどの高度な脅威検知テクノロジーを採用します。これらにより、進行中のエクスプロイトを示す可能性のある異常なアクティビティを特定して軽減し、未知の脆弱性や既存のパッチがない脆弱性から防御することができます。
サイバーセキュリティの啓発に関する従業員トレーニングを実施する: フィッシングの試みの認識、パスワードの安全な管理、定期的なソフトウェアアップデートの重要性の理解に重点を置いて、全従業員に対して継続的なサイバーセキュリティトレーニングを実施します。これにより、脆弱性を持ち込んだり悪化させたりする可能性のある人為的エラーを最小限に抑えることができます。
セキュリティの運用プロセスとコンプライアンスを監査する: 定期的なセキュリティ監査とコンプライアンスチェックを実行し、セキュリティポリシーがどの程度遵守されているかを評価して、組織のセキュリティ体制におけるギャップを特定します。これにより、セキュリティの運用プロセスが確立された基準や規制を満たしていることを確実にします。
インシデント対応計画を策定し、テストする: セキュリティ侵害が発生した場合に講じるべきステップを概説したインシデント対応計画を作成し、定期的にテストします。これには、封じ込め、根絶、復旧、インシデント後の分析のための手順を含める必要があります。
Stripe Treasury でできること
Stripe Treasury は Stripe 上で支払いと財務をまとめるため、ビジネスでは資金の受け取り、保存、送金、支出を 1 か所で行うことができます。これは、資金移動を迅速化し、財務業務の管理にかかる時間を削減したいと考えるスタートアップや成長企業向けに構築されています。また、プラットフォーム、マーケットプレイス、フィンテック企業は Treasury for platforms を使用して、ユーザーに金融サービスを提供することもできます。
Treasury では、以下が可能です。
財務業務を簡素化する: Stripe ダッシュボードから、資金、支払い、カードの利用、入金などを管理します。
資金移動の迅速化: 確定した Stripe の売上にすぐにアクセスし、Stripe を利用する他のビジネスに無料で即時送金できます。
資金の有効活用: カード利用でのキャッシュバックや、対象となる残高に対する Stripe 手数料のクレジットを獲得できます。
グローバル展開の簡素化: 複数の通貨で残高を保持し、必要なときにのみ両替して、160 カ国以上の受取人に送金できます。
財務オペレーションの自動化: エージェントを利用してキャッシュフローを分析し、設定した制限内で、請求書の支払いや資金移動、通貨の両替などのタスクを自動化します。
この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。