スクリーンスクレイピングと、アプリケーションプログラミングインターフェース (API) に基づくアクセスの両方は、ビジネスが顧客の銀行口座から必要な金融データを取得するのに役立ちますが、それらを行うための根本的に異なるメカニズムを使用しています。スクリーンスクレイピングは、顧客の認証情報を使用して銀行口座にログインし、顧客自身が見るのと同じページからデータを読み取ります。API アクセスは、顧客自身の銀行のログインをルーティングし、パスワードに一切触れることなく、範囲が限定された取り消し可能なトークンを発行します。場合によっては、API ベースの接続により、成功率が最大 99.9% に向上しています。信頼性に加え、この方法は高水準のセキュリティを誇り、ユーザー体験を向上させ、ビジネスが規制に準拠し続けるのに役立ちます。
以下では、スクリーンスクレイピングと API アクセスがどのように機能するか、認証情報の保存がトークンベースのアクセスとは異なるリスクプロファイルを生み出す理由、および銀行と規制当局が API への移行をどのように加速させているかについて説明します。
この記事でわかること
従来のスクリーンスクレイピングでは顧客の銀行の認証情報を保存する必要がありますが、API アクセスでは、顧客が銀行で直接認証した後に発行される、範囲が限定された取り消し可能なトークンに依存します。
銀行がウェブサイトを変更するとスクリーンスクレイピングは機能しなくなる可能性がありますが、API は構造化されたデータをコントラクトを通じて返します。このコントラクトは、通常、銀行が意図的に更新した場合にのみ変更されます。
消費者金融保護局 (CFPB) の 1033 条規則と、イギリスおよび EU の既存のオープンバンキングの枠組みは、銀行に対し、認証情報に基づくスクレイピングから脱却し、標準化されたアクセス (多くの場合 API を意味します) へと移行するよう促しています。
金融サービスにおけるスクリーンスクレイピングとは何ですか？
スクリーンスクレイピングとは、サードパーティのサービスが顧客のユーザー名とパスワードを使用して銀行口座にログインし、顧客自身がログインしたときに銀行が表示するページから直接データを読み取ることを意味します。専用のデータチャネルはありません。サービスは顧客が使用するのと同じセッションを使用し、レンダリングされたページから直接、アカウント残高、取引履歴、および口座番号を取得します。
金融データ API はどのように機能しますか？
API ベースのアクセスは、認証情報の共有を許可されたハンドオフに置き換え、通常はオンライン承認の事実上の標準である Open Authorization (OAuth) 2.0 で実行されます。
プロセスはいくつかの明確なステップに分かれます。
リダイレクトと認証: ユーザーは銀行のログインページに直接送信され、そこで銀行のみが認識する認証情報を入力します。
同意と範囲: 銀行は、アカウント内のすべての情報への包括的なアクセスを許可するのではなく、要求元のビジネスに表示を許可するアカウント残高や取引履歴など、限定的な権限を承認するよう求めます。
トークンの発行: 承認すると、銀行は要求元のビジネスにアクセストークンを発行します。そのトークンは、限定された取り消し可能な付与を表します。
構造化データの配信: ビジネスはそのトークンを使用して銀行の API を呼び出し、JavaScript Object Notation (JSON) などのクリーンで構造化されたデータを見返りとして受け取ります。
API がスクリーンスクレイピングよりもセキュリティリスクを軽減するのはなぜですか？
スクリーンスクレイピングと API へのアクセスの最も大きな違いは、何が保存され、誰がアクセスを制御するかです。この違いが、漏えい時の影響から侵害された接続をどれだけ迅速に遮断できるかまで、それに続くほぼすべてのセキュリティ上の結果を形作ります。
認証情報の保存とトークンの発行
従来のスクリーンスクレイピングでは通常、データアグリゲーターは顧客の実際の銀行のユーザー名とパスワードを自社システムのどこかに保存する必要があり、多くの場合、顧客がサービスを利用し続ける限り保存されます。そのデータアグリゲーターのデータベースが侵害された場合、保存されたすべての認証情報セットが標的になります。
API の場合、OAuth 認証後にビジネスに渡されるアクセストークンは、範囲が限定された取り消し可能な認証情報であり、通常は期限切れになり、取引履歴の読み取り専用の表示など、承認した内容へのアクセスのみを許可します。ビジネスのシステムが侵害された場合、顧客側でパスワードをリセットしなくても、銀行レベルでトークンを遮断できます。
フルアクセスと定義されたアクセス
保存されたパスワードは、それを保持する人に、ユーザー自身がログインするのと同じ広範なアクセス権を付与します。トークンは 1 つの機能のみに制限できるため、ローンの申し込みのためにアカウント残高を確認しているビジネスが、必要のない 5 年間の取引履歴を持ち去ることはありません。完全なアクセスと定義されたアクセスの間のギャップが、銀行、規制当局、および API プロバイダーが認証情報の保存をよりリスクの高いモデルとして扱う理由の 1 つです。
スクリーンスクレイピングと API では、信頼性と拡張性にどのような違いがありますか？
スクリーンスクレイピングは、銀行独自のウェブサイトに依存するため、設計上脆弱です。銀行がログインフローを更新したり、ダッシュボードを再設計したり、新しい認証ステップを追加したりすると、古いレイアウトで構築されたスクレイパーは、エンジニアが手動で再構築するまで機能しなくなる可能性があります。このような脆弱性に加え、それが引き起こす規模の問題により、いくつかの明確な問題が生じます。
サイトへの依存: スクレイパーは銀行の HTML が一定であることを前提としているため、定期的な再設計により、データアグリゲーターに警告なしに接続が密かに切断される可能性があります。
手動でのメンテナンス: 壊れたスクレイパーは多くの場合、エンジニアが新しいレイアウトに合わせて再構築する必要があります。この作業は、何千もの銀行でそれぞれのリリーススケジュールに合わせて繰り返されます。
高い失敗率: スクレイピングベースの接続は、特に銀行がサイトの更新をプッシュした直後に、API ベースの接続よりも失敗率が有意に高くなる傾向があります。
API は、いくつかの理由から一般的に信頼性が高いと考えられています。
定義されたデータコントラクト: 銀行の API は、残高フィールドがセント単位の整数としてフォーマットされるなど、固定された構造でアカウントデータを返します。また、銀行が意図的に API を更新して通知を行わない限り、その構造が変更されることは通常ありません。
明確なエラー処理: 何かが壊れた場合、API は明示的なエラーコードを返すため、ビジネスのシステムは破損したデータや不正な形式のデータを処理するのではなく、再試行したり問題にフラグを立てたりすることができます。
直線的規模とネットワーク化された規模: オープンバンキングのインフラストラクチャーは、何千もの銀行や信用組合との直接的な関係を促進するため、一度連携するだけでビジネスはそのネットワーク全体に到達できます。しかし、スクレイピングベースのアプローチでは、リスト上のすべての銀行についてカスタムスクリプトを構築し、保守する必要があります。
スクリーンスクレイピングはユーザー体験と顧客の信頼にどのような影響を与えますか？
銀行のユーザー名とパスワードをサードパーティ製アプリに渡すには、多くの人がためらうほどの高い信頼が求められます。多くの銀行は独自のセキュリティメッセージで、銀行の独自のウェブサイト以外でログイン認証情報を決して共有しないようにユーザーに指導しています。そのため、独自のインターフェース内でまさにその操作を行うよう求めるスクレイピングベースのアプリは、疑念を抱かれる可能性があります。このようなミスマッチにより、アカウントの連携時にためらいが生じ、ユーザーが連携フローを完了しなかったり、認証情報の要求に違和感を覚えて途中で放棄したりする可能性があります。
OAuth ベースのフローでは、パスワードを銀行独自のログインページにのみ入力するため、その問題を回避できます。既知のドメイン上の使い慣れたインターフェースであり、権限の画面には共有に同意する内容が具体的に表示されます。アカウント残高や過去 90 日間の取引履歴など、具体的な項目のリストが提示され、直接承認または拒否するよう求められるため、この具体性により同意に関する心理が変わります。結果として、銀行での直接認証に基づく同意フローは、認証情報に基づく集約よりも高い完了率を達成できます。
不快な経験や、スクレイピングベースのデータアグリゲーターでの情報漏えいに関する見出しによって一度自信が揺らぐと、信頼を取り戻すのは困難です。金融プロダクトを構築するビジネスでは、認証方法自体を単なる実装の細部ではなく、信頼性の指標として扱う傾向が強まっています。
規制当局はどのようにスクリーンスクレイピングから API への移行を推進していますか？
CFPB の 1033 条規則は、連邦裁判所が予備的差し止め命令を出した後、現在一時停止されていますが、銀行などのデータプロバイダーに対し、顧客の指示によりサードパーティに顧客の金融データを利用可能にすることを義務付けるドッドフランク法の条項を施行しようとしています。この規則の意図は、顧客に対し、使用可能でポータブルな形式の自身のデータに対する法的権利を与えることです。この規則は、標準化された安全な電子転送方法を明確に推奨しており、これは実際には認証情報に基づくスクレイピングよりも API を意味することがよくあります。
多くの大規模な金融機関は、すでに何年もかけて専用の API インフラストラクチャーを構築してきました。その理由の一部は、顧客向けのウェブサイトにアクセスするスクレイパートラフィックのサポートを停止するためです。これによりサーバーの容量が圧迫され、セキュリティレビューが複雑になる可能性があります。イギリスのオープンバンキングの枠組みと EU は、この移行の初期の先例となっています。
小規模な金融機関や信用組合の多くは、大規模な銀行がすでに構築している API インフラストラクチャーをまだ備えていないため、一部のデータアグリゲーターは、API の代替手段がまだないアカウントのフォールバックとしてスクレイピングを維持しています。しかし、1033 条の施行が進み、準拠した API エンドポイントを持つ銀行が増えるにつれて、金融プロダクトを構築するビジネスにとって、スクレイピングベースの接続が廃れる前に早期に移行する理由が最も大きくなります。
Stripe Financial Connections でできること
Stripe Financial Connections は、顧客の銀行口座に安全に接続して金融データを取得し、革新的な金融プロダクトやサービスを構築できるようにする一連の API です。
Financial Connections でできること:
アカウント登録を簡素化: 手動による本人確認や口座確認を必要としない、シームレスで即時の銀行口座確認プロセスを提供します。
豊富な金融データへのアクセス: 残高、取引、アカウントの詳細など、顧客の銀行口座に関する包括的な情報を取得します。
継続課金を自動化: 顧客が継続的な支払いのため銀行口座を安全にリンクできるようにし、決済成功率を向上させます。
リスクマネジメントを強化: 顧客の財務データを分析して、クレジット、融資、その他の金融商品について、より多くの情報に基づき意思決定を行えます。
規制に準拠: Financial Connections は、本人確認 (KYC) とマネーロンダリング防止 (AML) の要件を満たすのに役立ちます。
自信を持ってイノベーションを起こす: 安全で信頼できる Financial Connections インフラの上に、新しい金融商品やサービスを構築できます。
この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。