マネーフォワードの銀行連携、再開率99％超でも「完全復旧」に至らないワケ（2/3 ページ）

[斎藤健二，ITmedia]

単独では復旧できない――「電代業」という縛り

　その理由は、マネーフォワードが銀行法に基づく「電子決済等代行業者（電代業）」として連携機能を提供している点にある。

　電代業とは、利用者の委託を受けて口座の残高や明細を取得したり、送金指示を銀行に伝えたりする事業者の総称だ。銀行法などで登録が義務づけられ、各金融機関とは安全管理措置を含む接続契約を結ぶ。やりとりには、標準的に銀行が用意したAPI（外部サービスと安全につなぐ接続口）が使われる。家計簿アプリが銀行明細を自動で取り込めるのも、この枠組みのおかげだ。

　銀行法が直接定めるのは、登録と銀行との契約締結、安全管理を含む体制整備である。その契約には、安全管理が不十分だと銀行が判断すれば接続を止められるといった事項が盛り込まれる。事故時に自社の判断だけでサービスを続けられないのは、この法律と契約の枠組みによる。広報部も、再開には「自社だけの判断でサービスを継続するのではなく、接続先である金融機関に客観的な安全性を担保し、評価・納得をいただくプロセスが（契約で）義務付けられている」と説明する。

　マネーフォワード側の追加対策と第三者評価はすでに完了している。それでも一斉に再開できないのは、可否を金融機関と共同で判断するためだ。安全性の検証から再開判断まで、両者が連日協議を重ねる。

　どの段階が関門なのか。広報部は一点に絞らず、金融機関と「双方が納得の上で」進めていると述べるにとどめた。金融機関ごとに規模やセキュリティ基準、意思決定のプロセスは異なる。その違いの積み重ねが、復旧の時間差となって表れる。

　再開率が99％を超えてなお完全復旧に至らないのも、こうした事情による。大半が早期に戻っても、最後に残る数行は、各社固有の手順に沿って一つずつ合意していくほかない。

対応を分けたのは「技術」ではなく「法の枠組み」

　ここで疑問が浮かぶ。APIを使った銀行との連携を止める一方で、同社はID・パスワードを使う「スクレイピング」方式の連携を一部続けていた。認証情報を預けるスクレイピングの方が、むしろ不安ではないか。

　両者の違いはこうだ。API連携では、金融機関が用意した接続口を通じてデータをやりとりし、利用者はアプリに口座情報の取得を許可するだけでよい。IDやパスワードそのものをマネーフォワードに渡す必要はない。

　一方のスクレイピングは、預かったIDとパスワードでマネーフォワードが本人に代わって金融機関のサイトにログインし、画面の情報を読み取る。現在、銀行はおおむねAPIに移行しており、スクレイピングはAPIのない金融機関などで使われる。認証情報そのものを預ける分、利用者の不安が大きいのも無理はない。

　ただし、対応を分けたのは「APIかスクレイピングか」という技術ではない、と同社は説明する。基準は、接続先の金融機関との連携が、電子決済等代行業に関する法令・契約の枠組みに置かれているかどうかだ。枠組みの対象となる提携金融機関は、APIもスクレイピングも一律停止。対象外の金融機関は一律停止とせず、個別の協議で対応した。

　スクレイピングを続けた連携は、ID・パスワードを保管するデータベースへの侵害がないことを早期に確認できたため、利便性を損なわないよう提供を継続したという。

　では、万一預けたID・パスワードが漏れたらどうなるのか。同社によれば、スクレイピング方式で預かるのは残高・明細の取得に必要なログイン情報で、資金移動に必要な追加認証情報や乱数表などは保管していないという。

　預かったデータと認証情報は、不正アクセスを受けた環境とは切り離したサーバに暗号化して保存し、アクセスを制限している。そのうえで「お預かりしている情報だけでは、お客様の資産を動かせない構造になっている」と広報部は強調する。