事業用の当座預金口座を簿記アプリに接続すると、取引が自動的に流れ込んでくる。しかし、その中間にいる企業 — あなたの代わりに銀行にログインし、取引を取得し、クリーンアップして、あなたのアプリに渡すデータアグリゲーター — の存在を目にすることはほとんどない。フィードが途切れたり、購入の半分が誤ったカテゴリに分類されたり、1週間分のアクティビティが黙って欠落したりするとき、問題は通常その中間層にあり、あなたのアプリにあるのではない。
米国では、このデータの大半を3社が動かしている：Plaid、MX、そしてFinicity（2020年以降Mastercardが保有）。中小企業を営んでいるなら、会計ソフトを選んだ瞬間にこのうちの1社を選んでいる — そして銀行フィードが不調を繰り返すなら、各アグリゲーターの得意・不得意を理解することで、アプリを乗り換えることが助けになるのか、それとも同じ問題を新しい画面に移すだけなのかが分かる。
銀行データアグリゲーターが実際にやっていること
会計アプリで「銀行を接続」をクリックすると、一連のイベントが始まる：
- 認証。 銀行の認証情報を入力する（または銀行でのOAuthリダイレクトを承認する）。アグリゲーターはあなたの口座に紐づく接続を確立する。
- 取得。 アグリゲーターは残高と取引を取得する — 理想的には銀行の直接API経由で、時にはブラウザのようにオンラインバンキングにログインして。
- エンリッチメント。
SQ *COFFEE SHOP 000123のような生の銀行明細が、加盟店名、カテゴリ、時には場所へとクリーンアップされる。 - 配信。 あなたの会計アプリは、アグリゲーターのAPIを通じて正規化されたデータを受け取る。
ステップ2と3が、3社が最も大きく異なる部分だ。取得はどの銀行が接続できるか、フィードがどれくらいの頻度で途切れるかを決める。エンリッチメントは、あなたの簿記がクリーンなカテゴリから始まるか、手作業で修正しなければならない「未分類」取引の山から始まるかを決める。
これが以前よりも重要な理由
長年にわたり、アグリゲーターは主にスクリーンスクレイピングでデータを取得していた：保存された認証情報でオンラインバンキングにログインし、ページを読み取るのだ。それは機能したが、もろかった — 銀行のウェブサイトがリニューアルされるたびに接続が壊れた — そしてあなたのパスワードが他人のサーバー上に存在することを意味した。
業界は10年にわたり、直接のトークンベースのAPI接続へと移行してきており、現在は規制がその流れを後押ししている。ドッド・フランク法第1033条に基づく消費者金融保護局（CFPB）のオープンバンキング規則は、消費者に対し、安全なインターフェースを通じて認可された第三者とデータを共有するよう銀行に指示する正式な権利を与えるもので、実質的にスクリーンスクレイピングを終わらせることになる。2024年の当初の規則は法廷で阻止され、改訂案は2026年8月にホワイトハウスの審査下に入ったため、最終的な形は依然として不確定だ — しかし方向性は一方向である。銀行とアグリゲーター間の直接契約とFinancial Data Exchange（FDX）標準は、すでに大手銀行接続の大半が機能する仕組みとなっている。
事業主としてのあなたにとって、この移行には2つの実際的な意味がある。第一に、大手銀行への接続は5年前よりも一般的に信頼性が高い。OAuthベースのAPIリンクはスクレイピングよりも壊れにくいからだ。第二に、中小銀行や信用組合 — 現代的なAPIを持つ可能性が最も低い相手 — への接続は依然としてフィードが失敗する場所であり、まさにそこがアグリゲーターのカバレッジの差が現れるところだ。
3つのアグリゲーターを並べて比較
Plaid：最も広い開発者基盤を持つデフォルト
Plaidはおそらく目にしたことのある名前だ — その接続画面は、予算管理ツールから決済サービスまで、数千のアプリ内に現れる。12,000以上の金融機関への接続を公表しており、開発者体験で有名だ：明確なドキュメント、迅速な統合、「銀行データが必要だ」から動く製品までの最短経路。
この広さにより、できるだけ多くの異なる銀行と接続することだけを優先するなら、Plaidは最も安全なデフォルトとなる。あなたの事業が変わった場所 — 地方銀行、ニッチなオンライン銀行 — で取引しているなら、Plaidはすでに対応している可能性が最も高いアグリゲーターであることが多い。
トレードオフは規模が大きくなると現れる。第三者の分析によると、Plaidの価格は接続成功あたり約0.50〜2.00ドルで、上位ティアではボリュームディスカッションが適用される — 小規模アプリには優しいモデルだが、大規模になると本格的なコストセンターになる。そしてPlaidのエンリッチメントは堅実だが、一般に最高クラスというより「良好」と見なされている：加盟店名とカテゴリは通常正しいが、乱雑で大量の取引ストリームを持つ事業では、その分類がMXよりも多くの手動修正を必要とすることがある。
MX：コミュニティバンクにルーツを持つ分類のスペシャリスト
MXはコミュニティバンクや信用組合に直接サービスを提供することから成長し、その遺産が今もその形を決めている。接続数は15,000〜16,000の範囲を公表しており、小規模機関に特に強い — まさにPlaidの接続が薄くなりがちで、Finicityのエンタープライズ重視が薄れるロングテールだ。
MXの際立った特徴はデータエンリッチメントだ。その分類エンジンは3社の中で最強と広く見なされている：よりクリーンな加盟店識別、より一貫したカテゴリ、曖昧な取引のより良い処理。会計アプリを開いて、数十の取引が「その他」や「未分類」に投げ込まれているのを見たことがあるなら、弱いエンリッチメントのコストを感じたことがあるはずだ — その一つひとつが月末のあなたの1分になる。MXの訴求点は、あなたの取引がそこにたどり着くことがより少ないということだ。
問題はアクセスだ。MXは主に銀行や大規模フィンテック向けのエンタープライズ契約を通じて販売されるため、中小企業の事業主としてMXを直接選ぶことはまれだ — あなたの会計アプリや銀行アプリがそれを選んだから使っているのだ。価格は公開されず交渉されるため、直接のコスト比較は難しい。そして米国外ではカバレッジが薄い。
Finicity：Mastercardの検証の powerhouse
2020年にMastercardが買収したFinicityは、同様の15,000以上の機関をカバーし、融資や検証のワークフローで最強の地位を占めている。収入と資産の検証のための構造化された出力は、住宅ローンや引受のプロセスに直接組み込まれ、Fannie MaeとFreddie Macによる受け入れが実際の重みを持つ。最近事業ローンや住宅ローンを申請し、明細書をアップロードする代わりに「口座をデジタルで検証する」よう求められたなら、Finicityがそのデータを動かした可能性が高い。
Mastercardの後ろ盾により、Finicityは大手銀行との直接データ共有契約の最も深いベンチも持っており、それが大手銀行接続を安定させる傾向がある。MXと同様、交渉されたエンタープライズ契約を通じて販売され、MXと同様、主に米国の話だ。
Finicityがそれほど際立たないのは、日常の簿記のための汎用取引エンリッチメントにおいてだ。それは有能だが、誰かがFinicityを選ぶ理由ではない — 検証重視のワークフローのためにFinicityを選び、簿記フィードはついてくるのだ。
正直な比較表
| 次元 | Plaid | MX | Finicity（Mastercard） |
|---|---|---|---|
| 公表機関数 | 12,000以上 | 15,000〜16,000 | 15,000〜16,000 |
| 中小銀行・信用組合の深さ | 良好 | 最強 | 良好 |
| 取引エンリッチメント品質 | 良好 | 最高 | 十分 |
| 収入・資産検証 | 利用可能 | 利用可能 | 最高（GSE承認レポート） |
| 価格モデル | 接続ごと、約0.50〜2.00ドル | 交渉によるエンタープライズ | 交渉によるエンタープライズ |
| 米国外カバレッジ | カナダ＋限定的な欧州 | 主に米国 | 主に米国 |
| 購入者 | スタートアップから大企業まで | 銀行、大規模フィンテック | 融資機関、大規模フィンテック |
機関数の数字はすべて懐疑的に見るべきだ：各プロバイダーは「接続」と「データソース」を異なる方法で数えており、どの合計もあなたの銀行が確実に接続するかどうかを示すものではない。重要なカバレッジの問いはあなた自身のものであり、契約する前に銀行名とアプリ名を組み合わせて検索し、最近の報告を確認することだ。接続は変わるからである。
信頼性：フィードが壊れる理由（そして誰の責任か）
銀行フィードの失敗は3つのバケツに分類され、そのうちあなたのアプリの責任は1つだけだ：
- 接続の切断。 銀行がログインフローを変更し、多要素認証のステップを追加し、またはAPIをローテーションすると、アグリゲーターのリンクが切れる。「銀行を再接続してください」というプロンプトが表示される。OAuthベースのAPI接続は認証情報ベースのものよりもはるかに壊れにくく、それが大手銀行でのフィードが静かに改善されてきた理由だ。
- 取引の欠落や重複。 接続は機能するがデータが間違っている：確定取引にならない保留中の請求、決して届かない週末のアクティビティ、または二重にインポートされた同じ支払い。これはアグリゲーターの取得の問題であり、最も見つけにくいものだ — 何もエラーにならず、あなたの帳簿が単に間違っているだけだから。
- 誤った分類。 取引は届くが、誤った口座に分類される。これはエンリッチメントの問題であり、日常使用でMXの優位性が最も見えるところだ。
ユーザーがアプリが「銀行に接続し続けられない」と不満を言うとき、根本的な原因は通常アグリゲーター層のバケツ1だ — だからこそ一部のアプリは、設定内で同じ銀行に対してアグリゲーターを切り替えられるようにしている。あなたのアプリが1つの接続に対してPlaid、MX、Finicityを交換可能なプロバイダーとして提供しているなら、アプリを責める前に別のものを試してほしい。別のアグリゲーターが実際にあなたの機関へのより良い接続を持っているかもしれない。
価格：請求書を見ずに支払うもの
アグリゲーターに直接支払う中小企業はほとんどない。コストは会計ソフトのサブスクリプションにバンドルされて届く — だからこそ「どのアグリゲーターが最も安いか」はあなたにとって間違った問いなのだ。正しい問いは、価格モデルがあなたのベンダーに何をするよう促すかだ。
接続ごとの価格（Plaidの公開モデル）は、接続が確立または更新されるたびにアプリベンダーに課金するため、このモデルのベンダーはフィードをより少ない頻度で更新したり、安価なプランでリンクできる口座数を制限したりする静かなインセンティブを持つ。エンタープライズ契約（MXとFinicityの世界）はプラットフォーム料金を使用量とバンドルするため、ベンダーは口座ごとの制限ではなく、全体的により高いサブスクリプションティアへと押しやられる傾向がある。
いずれにせよ、あなたは支払う。異なるのはコストが現れる場所だ：一方のモデルでは接続上限と更新頻度、他方ではより高い基本価格。「銀行口座をいくつ接続でき、フィードはどのくらいの頻度で更新されるか」は「どのアグリゲーターを使っていますか」よりも有用な問いだ — しかし今、あなたは答えが異なる理由を知っている。
これがあなたの帳簿にとって意味すること
自動フィードについての不快な真実はこれだ：それらはインポートパイプラインであり、簿記者ではない。上記の失敗モードは静かなので、すべての取引はあなたの財務記録の一部になる前に、依然として再確認が必要だ。オーナーの引出金を事業の食事代として誤分類するフィードはエラーを出さない — 誰かが気づくまで、静かにあなたの控除額を過大に報告するだけだ。
実践的なルーティンは月次の慌ただしさではなく、週次のレビューだ：
- 未分類および信頼度の低い項目を最初にスキャンする。 ほとんどのアプリはアグリゲーターが不確かだったものをフラグする。購入がまだ記憶に新しいうちに、毎週これらを片付けよう。
- フィードではなく銀行残高と照合する。 月末のチェックは「帳簿が明細書と一致するか」であり、「フィードがすべてをインポートしたか」では決してない。明細書が権威であり、フィードは便利さだ。
- 再接続前後の重複に注意する。 銀行を再リンクするたびに、重複ウィンドウを確認しよう。再接続されたフィードは二重計上取引の最大の原因だ。
帳簿をプレーンテキストで管理しているなら、同じ規律が適用される — フィード出力はあなたがレビューするドラフトエントリとなり、あなたが受け入れる真実ではない。例えば、手数料付きの同期された支払いは、純入金額ではなくその構成要素として帳簿に記録されるべきだ：
2026-10-15 * "Shopify payout #4821" "Oct 12-14 sales, fees split out"
Assets:Checking:Business 1,842.36 USD
Expenses:Fees:Payment-Processing 58.14 USD
Income:Sales -1,900.50 USD純入金を収入として記帳する代わりに、総売上と手数料を別々に記録することが、収益数値を誠実に保ち、確定申告時に手数料費用を可視化する秘訣だ。どのソフトウェアを使うにせよ、フィードが総額と手数料を分けるのに十分な詳細を提供することを主張しよう；純入金だけをインポートするフィードは、確定申告が必要とする情報を隠している。Beancountドキュメントは取引構造を詳しく説明しており、Favaはインポートされたエントリが帳簿に落ち着く前にレビューするのを簡単にする。
選び方（またはすでに持っているものをどう評価するか）
おそらくアグリゲーターを直接選ぶことはない — 会計ソフトを選び、アグリゲーターはそれに付いてくる。だから比較を購入の問いに変換しよう：
- どこで銀行取引をしているか？ 上位20行なら3社すべてがうまく接続する；エンリッチメントとアプリの機能で選ぼう。中小銀行や信用組合なら、ベンダーにどのアグリゲーターがあなたの機関を扱い、接続がどのように認証されるか（OAuthは保存された認証情報に勝る）を尋ねよう。
- 取引はどれくらい乱雑か？ 大量で、類似のベンダーが多く、現金支出が多い — エンリッチメント品質がより重要になり、MX上に構築されたアプリが有利になる。
- 借り入れをするか？ あなたのワークフローにローン申請と収入検証が含まれるなら、Finicityをバックエンドとする経路がそのステップをよりスムーズにできる。
- アプリ内でプロバイダーを切り替えられるか？ 接続ごとの切り替えを備えたマルチアグリゲーター対応は、アプリが提供できる単一の最良の信頼性機能だ。名前を挙げて求めよう。
そしてオープンバンキングの規則制定に目を光らせておこう。第1033条がどのような最終形をとるにせよ、標準化された銀行APIが脆弱な認証情報ベースのリンクを置き換え続ける — つまり、大手と中小機関の間のカバレッジの差が注視すべきものだ。あなたのフィードは大手銀行で先により信頼性が高くなり続ける。中小で取引しているなら、コミュニティバンクに最も深いルーツを持つアグリゲーターが、依然としてあなたの接続を生かし続ける可能性が最も高いものだ。
