金融データアプリケーションプログラミングインターフェイス (API) を使用すると、顧客が共有に同意した後、企業はその顧客の銀行口座情報を抽出できます。企業は、カード利用明細や無効な小切手を手動で収集する代わりに、構造化された記録 (残高、取引履歴、アカウントと金融番号など) を要求します。これらの記録は、接続と関連する同意を管理する仲介業者を通じて、顧客の金融機関から直接送られます。

2024 年の調査によると、アメリカの成人の約 11% が、金融データ API を使用してオープンバンキングの支払い取引を少なくとも 1 回実行しました。以下では、これらの接続の仕組み、利用可能なさまざまなアクセスモデル、および貸付、給与確認、アカウント集約などのビジネスプロセスにおいて結果がどのように現れるかについて説明します。

この記事でわかること

• 金融データ API は、ユーザーが直接制御する同意フローを介して、残高、取引、アカウントの詳細など、顧客の許可を得た銀行記録を返します。

• 企業は、データに求められる最新度に応じて、リアルタイム接続、定期的な更新、Webhook、過去のデータの取得の中から選択できます。

• 実装の成功は、チームがトークンの期限切れ、エラー状態、およびさまざまな銀行間で一貫性のないデータスキーマをどのように処理するかに大きく依存します。

金融データ API とは

金融データ API とは、明示的なユーザーの許可を得て、企業が顧客の銀行口座情報を取得できるようにするプログラムインターフェイスのことです。カード利用明細をメールで送信したり、金融番号を手動で入力したりするよう依頼する代わりに、リクエスト元は、接続を管理する仲介業者を介して顧客の金融機関に直接構造化データを要求します。

金融データ API の仕組み

金融データ API 接続は、以下と同じ基本的な手順に従います。

• 銀行の選択とログイン: 顧客はリストから自分の金融機関を選択し、自身の銀行の認証情報を使用してログインします。企業がそのパスワードを見たり保存したりすることはありません。

• 同意画面: 顧客は、どのような情報が要求されているか (残高、取引履歴、アカウントと金融番号など) を正確に確認し、その特定のリクエストを承認または拒否します。API プロバイダーは、後でコンプライアンスや不審請求の申し立ての解決に重要となるタイムスタンプとともに、この同意をログに記録します。

• データリクエスト: 同意が記録されると、企業のサーバーは、どのアカウントとフィールドが必要かを指定するリクエストを API に送信します。

• 構造化された応答: API がデータを返します。どちらの場合も応答は同じ形式で返されるため、アカウントを確認している企業は、大手メガバンクと地方の信用組合とで別々のコードを用意する必要はありません。

金融データ API の一般的なデータアクセスモデルとは

すべてのユースケースで同じ種類の接続が求められるわけではありません。一般的なデータアクセスモデルは以下のとおりです。

• リアルタイムの直接接続: 企業は、データが必要になったまさにその瞬間 (支払いを開始する直前の残高確認など) に API にクエリを実行します。これにより可能な限り最新の情報が得られますが、銀行のシステムが迅速に応答するかどうかに依存します。

• 定期的なデータ更新: API は、オンデマンドではなく、設定されたスケジュールで更新されたデータを抽出します。これは、数週間または数カ月にわたる支出パターンを顧客に表示し、秒単位の精度を必要としないアカウント集約ツールに最適です。

• アカウントの変更に関する Webhook: 更新を確認する代わりに、企業は何か変更があった場合 (新しい取引の記帳、同意の取り消しなど) に通知を受け取るように登録します。これにより、不要なリクエストが最小限に抑えられ、システムはイベントの発生に応じて反応できるようになります。

• 過去データの取得: 1 回のリクエストで数カ月分の過去のアクティビティが抽出され、長期間にわたる収入の安定性や支出行動を評価するために使用できます。

金融データ API はどのようなビジネスの課題を解決するか

金融データ API により、手動による確認や不確実な数値が実際の銀行記録に置き換えられます。これらのデータが役立つ領域は以下のとおりです。

• 即時の銀行口座確認: API によって返されるデータにより、マイクロデポジットの処理に何日も待つことなく、アカウントが本物であり、それを主張する人物の所有物であることが確認されます。

• 銀行振込の開始: API は、確認済みのアカウントと金融番号を使用して銀行振込を設定し、タイプミスや詳細の不一致によって発生する支払いの失敗を減らします。

• 貸付とリスク評価: API は取引履歴を抽出してキャッシュフローのパターンを評価します。これにより、貸し手は信用調査書だけでは得られない最新の状況を把握できます。

• 給与と収入の確認: 古くなったり改ざんされたりしている可能性のある給与明細に依存するのではなく、入金履歴を確認することで収入を確認できます。

• 金融口座の集約: API は複数のアカウントから残高と取引を 1 つのダッシュボードに抽出します。これは、多くの予算管理アプリが顧客に全体的な財務状況を 1 か所で表示する方法です。

• パーソナルファイナンスツール: API は分類された取引データを使用して、予算に対する支出を追跡したり、毎月のお金の行き先を把握したりするのに役立ちます。

金融データ API を使用する際の課題

これらの API のいずれかを中心に構築する前に、いくつかの制約事項を理解しておくことが重要です。以下の点に注意してください。

• データの鮮度: 定期的な更新接続では、1 日前の残高が表示される場合があります。このタイムラグは、リアルタイム支払いのオーソリなどのユースケースで意味を持つ可能性があります。

• 金融機関の対象範囲: 大手銀行は、安定したテスト済みの接続を維持する傾向があります。小規模な信用組合や地方銀行では、稼働時間の一貫性が低かったり、新しい API 機能への対応が遅かったりする場合があります。

• 同意の期限切れ: ユーザーはいつでもアクセスを取り消すことができます。つまり、データ接続が予期せず切断された場合に、顧客関係や依存する取引がどうなるかについての計画を立てる必要があります。

• コンプライアンスのオーバーヘッド: 顧客の許可を得た金融データの処理には、同意記録、データ保持、情報の保存と共有に関する独自の義務が伴います。これらのプロセスがすでに組み込まれているプロバイダーと提携することで、企業が自ら構築すべきものが減ります。

• サードパーティへの依存: サードパーティの銀行インターフェイスに依存するということは、プロバイダーの稼働時間、サポートの対応力、ロードマップに依存することを意味します。プロバイダー側でのシステム停止は、そのデータに依存するすべての利用者のシステム停止につながります。

開発者が金融データ API を実装する際の注意点

実装を成功させるには、パフォーマンス、回復力、エラー処理に重点を置いた長期的なアプローチが必要です。以下の特定の要因によって、実装がどの程度維持されるかが決まります。

認証の処理

多くの金融データ API は、顧客の当初の同意に紐付けられた OAuth-スタイルのトークンを発行します。ユーザーが銀行のパスワードを変更したり、手動でアカウントの接続を解除したりすると、これらのトークンは有効期限切れになったり、無効になったりする可能性があります。そのため、期限切れのトークンを検出し、再オーソリを促す計画を立てる必要があります。

エラー状態

銀行システムのメンテナンス、口座の閉鎖、リクエストのタイムアウトなど、発生する可能性のある各エラーについて、エンドユーザーにメッセージを送信する必要があります。金融機関側でのこのような一時的なシステム停止は、顧客の信頼を損なう可能性があります。

レート制限

金融機関は、特定のアカウントにクエリを実行できる頻度に上限を設けています。データを頻繁に抽出しすぎる企業は、スロットリングされたり、一時的にブロックされたりするリスクがあります。定期的な更新モデルや Webhook モデルが存在するのはこのためでもあり、これらにより常に確認する必要がなくなります。

データスキーマ

企業が金融データを受け取る際、スキーマは正規化されますが、それらのフィールドに入力される値が常に一貫しているとは限りません。取引の詳細は、ある銀行からは加盟店の未加工の文字列として、別の銀行からは事前クリーニングされた名前として届く場合があります。値が全体でクリーンかつ一貫していると想定するのではなく、さまざまな金融機関でテストを行う必要があります。

テスト環境

多くのプロバイダーは、実際のアカウントに触れることなく銀行接続をシミュレートするサンドボックスの認証情報を提供しています。これにより、開発者は本番の顧客データが関与する前に、エラー処理を構築してテストできます。

一部のプロバイダーは、銀行の選択、ログイン、同意を含む、直接組み込むことができる事前構築済みのフローも提供しています。プロバイダーが独自のインターフェイスを介してこれらのステップを処理する場合、企業のエンジニアリングチームは主にその後受信したトークンと情報を処理する必要があり、オーソリフロー自体を構築して保護する必要はありません。これにより、対処すべき問題の数が最小限に抑えられます。

金融データ API プラットフォームを評価する際に重要となる要素とは

プラットフォームを選択する際は、各プラットフォームがどの金融機関と接続しているか、顧客が使用する特定の銀行や信用組合にどの程度対応しているかを検討します。また、返されるデータの種類と、チームが銀行ごとに個別のロジックを記述しなくて済む程度にデータが正規化されているかどうかを確認します。

さらに、ドキュメントやサンドボックステストからエラーの表示方法まで、開発者体験についても確認します。すでに他の金融インフラにプロバイダーを使用している場合は、構築済みのシステムと連携できるプラットフォームか、それとも切り離された 2 つ目のシステムを維持する必要があるかを判断します。

Stripe Financial Connections は、幅広い金融機関におけるアカウントの確認、残高の確認、取引と本人確認のデータに対応しています。また、ホスティング型のユーザーインターフェイスによって銀行の選択と顧客の同意が処理されるため、開発者はそのフローをゼロから構築する必要がありません。

決済や請求にすでに Stripe を使用しており、Financial Connections を介してその情報を取得しているビジネスは、それらの情報を他の Stripe プロダクトに直接入力できます。たとえば、ユースケースごとに別のベンダーを導入しなくても、確認済みのアカウントデータを使用して、アメリカにおける ACH (自動手形交換所) 支払いなどの銀行振込を設定したり、取引履歴をリスク評価の決定に入力したりできます。

Stripe Financial Connections でできること

Stripe Financial Connections は、顧客の銀行口座に安全に接続し、財務データを取得できる一連の API です。これにより、革新的な金融商品とサービスの構築が可能になります。

Financial Connections でできること:

• アカウント登録を簡素化: 手動による本人確認や口座確認を必要としない、シームレスで即時の銀行口座確認プロセスを提供します。

• 豊富な財務データにアクセス: 取引残高、取引、アカウントの詳細など、顧客の銀行口座に関する包括的な情報を取得できます。

• 継続課金を自動化: 顧客が継続的な支払いのため銀行口座を安全にリンクできるようにし、決済成功率を向上させます。

• リスクマネジメントを強化: 顧客の財務データを分析して、クレジット、融資、その他の金融商品について、より多くの情報に基づき意思決定を行えます。

• 規制に準拠: Financial Connections は、本人確認 (KYC) とマネーロンダリング防止 (AML) の要件を満たすのに役立ちます。

• 自信を持ってイノベーションを起こす: 安全で信頼できる Financial Connections インフラの上に、新しい金融商品やサービスを構築できます。

Financial Connections の詳細をご覧いただくか、今すぐ始めましょう。