参照系APIの技術的改善に関する提言

2023年8月10日
参照系API技術的改善スタディグループ

１．背景と目的

2017年5月26日、「銀行法等の一部を改正する法律」が成立し、2018年6月１日に施行された。



同法の施行により、金融機関と電子決済等代行業者（以下、「電代業者」という）は、業を行う前に賠償責任の分担や利用者情報の適正な取扱い等に関する契約を2020年5月31日までに※1金融機関と締結することが義務化され、かつ同法附則によるAPI利用の努力義務規定もあり、当該期日までに主要な金融機関と電代業者とのAPI利用に関する契約締結は、ほぼ完了した※2。
※1 新型コロナウイルス対応のため同年9月30日までの猶予期限が設けられた※2 一部銀行とはスクレイピング接続契約を締結



これにより、会計ソフトや家計簿ソフトといった電代業者のサービスユーザーは、安全かつ快適に口座情報を取得できるようになり、金融機関と電代業者の協業も進展した。



他方で、3年弱のサービス運用を経て、いくつかの技術的課題も見えてきている。



関係者でこれらの課題について一度棚卸して議論し、建設的な改善策の方向性を見出すことが、参照系API技術的改善スタディグループ（以下、本スタディグループという）の目的である。

２．議論の経過等（１）参加者



一般社団法人電子決済等代行事業者協会（会員有志、事務局）

GMOあおぞらネット銀行株式会社



住信SBIネット銀行株式会社

株式会社みんなの銀行（２）議論の経過
第１回（2022年11月8日）：事務局より論点案を提示し、技術的改善の方向性を議論

1

第２回（2023年3月2日）：事務局より提言案を提示し、技術的改善の具体策を議論
書面決議（2023年7月14日）：本提言を書面で決議

３．提言（案）本スタディグループにおいて議論を重ねた結果、参照系APIの技術的改善策として、8の方策を提言する。



これらの提言内容は、以下の３類型に分けられる。類型毎に、関係者の建設的な検討を期待したい。
《A類型》
技術的に対応可能であり、速やかな対応又は次回システム更改等における対応を期待したいもの。
《B類型》
技術的に対応可能であるが、協業等による経済的インセンティブとパッケージで検討する必要があるもの。
《C類型》
中⾧期的に関係者で対応策を検討していくべきもの。

類型毎の提言内容《A類型》(1)コール数の削減

速やかな対応、次回システム更改等 (2)AUP利用の拡大における対応(3)電代業者の体制整備・フレームワーク作り《B類型》(4)明細取得期間の延⾧

経済的インセンティブと(5)リフレッシュトークン有効期限の延⾧パッケージで検討(6)取得できる情報範囲の拡大《C類型》(7)Webhookの導入

中⾧期的に検討(8)APIの基本設計《A類型》（１）コール数の削減【現状と課題】

2



参照系APIを活用するに当たって、不必要なコール数を削減することは、金融機関、電代業者双方にとって、経済的メリットが大きいが、現状では技術的な仕様のレベルでの改善余地も大きい。

【改善策】



これまで、金融機関と電代業者が、それぞれの仕様を突き合わせて議論することで、コール数削減に繋がったケースがいくつかある。



例えば、予想していなかったAPIのエンドポイントが見つかる、明細上限に関する設定を変える等である。



このような、よくあるケースを横展開していくことで、各社の工夫を促していく取組が必要である。

その他、中⾧期的な課題も含め、具体的には以下のような対応が考えられる。
○ 金融機関■ Webhookの導入■ 1リクエストで返せる明細情報の上限引き上げ■ 明細にIDを付与し、識別可能とすることで、過去に取得した明細を再度取得する等のコールを削減■ 口座一覧や明細情報の中で残高情報も返す仕様とし、個別口座毎に残高を取るコール数を削減○ 電代業者■ 残高APIを叩いて変更がない場合、明細APIを叩かない仕様に■ 変動頻度の低い住宅ローンのような口座はコール頻度を下げる

このような対策について、システム更改等の適切なタイミングで、双方が着実に対応していくことが望まれる。

（２）AUP利用の拡大【現状と課題】

参照系APIを接続するに当たり、電代業者は金融機関のセキュリティ等に関するチェックを、定期的に（年1回が主）、個別に受ける必要がある。



各金融機関のチェックは、原則FISC（公益財団法人金融情報システムセンター）の「API接続チェックリスト」に基づいているが、個別のチェック項目も多いことから、電代業者の対応工数が膨大になっていた。



この解決策として、監査法人によるAUP（合意された手続き）の仕組みが導入された。金融機関がAUPに参加する場合、監査法人が一括して電代業者のチェックを行3

い、結果を当該金融機関に配布するため、電代業者の対応は飛躍的に効率化される。

また金融機関にとっても、電代業者の自己申告と比べて、客観性の高い第三者の監査法人が実施した結果報告書を活用することで、電代業者のシステムリスク管理態勢に係る審査の短期化・省力化が可能になる。



他方、事務局調べによると、現状AUPに参加しているのは約70金融機関であり、その他の約60金融機関は、引き続き個別チェックを実施している。

【改善策】



電代業者、金融機関双方が、AUPのメリットを理解・発信し、参加金融機関数を増やしていくことが望まれる。

（３）電代業者の体制整備・フレームワーク作り【現状と課題】



金融機関からは、API接続先の電代業者の体制が不十分であるとの声も多い。



例えば、ユーザーから金融機関に問い合わせがあった際、電代業者に繋いでも十分な対応が取られないケースや、連鎖接続先まで確認を取る必要があり、かなりの時間を要してしまったケース等が報告されている。

【改善策】



今後、参照系APIが社会インフラとなっていく上では、電代業者側でこれらのケースを精査し、十分な体制整備を行うことや、顧客に金融機関と電代業者の役割について理解いただくための取組が必要不可欠である。



また、今後連鎖接続が広がっていく中で、顧客保護のためのフレームワークをいかに作っていくか、という検討も必要である。

《B類型》（４）明細取得期間の延⾧【現状と課題】



参照系APIによって取得できる口座情報の期間は、金融機関やシステムベンダーによって様々である。

事務局調べによると、下図の通り、明細取得可能期間は3か月未満の金融機関が66%。12カ月以上は23%に留まっている。

4

これによって、顧客の利便性が損なわれているだけでなく、金融機関がトランザクションレンディング等のサービスを展開する際の障壁にもなっている。

明細取得可能期間毎の銀行口座数

【改善策】



本スタディグループとしては、明細取得可能期間は、ユーザーの利便性の観点から、最低でも18か月以上とするべきであると考えている。



これは、トランザクションレンディング（審査に12カ月以上の明細を利用することが一般的）等の新サービス活性化や、1月～12月の明細を翌年3月に取得する必要がある確定申告をスムーズに行うためという観点である。



その際には、金融機関が明細取得可能期間を延⾧するインセンティブが重要であり、明細情報を活用した新サービスの開発や、金融機関と電代業者との協業など、関係者での議論を深化させていくことや、先行事例を発信していくことが重要である。

（５）リフレッシュトークン有効期限の延⾧【現状と課題】

参照系APIにはリフレッシュトークンの有効期間が設定されており、期限が切れると、ユーザーによる再認証が必要となる。

事務局調べによると、下表のとおり有効期間は10日以内～10年と、金融機関によって様々である。

5

リフレッシュトークンの有効期間毎の銀行口座数

【改善策】



電代業側の目線としては、参照系APIを通じた口座情報の取得は、通帳の代替機能という側面が強いため、ユーザー利便性の観点から、原則無期限とすることが望ましいと考えている。



他方で仕様として無期限にすると、セキュリティの問題や、実際にはサービスを使っていないユーザーのトークンを有効にし続けることによる経済的問題も生じる。



したがって、いくつかの金融機関では、ユーザーがアクセスしている限りは、一定期間毎にリフレッシュトークンを自動的に発行し、自動延⾧する仕組みを実装している。



ただしこの手法だと、電代業者のサービス仕様により、ユーザーが実際に使っていないのに定期的に口座情報を自動更新するような場合は、経済的問題は解消しない。決算や確定申告の際のみアクティブになるユーザーを含め、実態的なアクティブユーザーにとって不便のない仕組みが必要である。



なお英国では、90日毎に電代業者がユーザーに接続継続の意向の確認を取れば、銀行側の認証は不要とされている。



このような事例も参考にしつつ、ユーザー、電代業者、金融機関それぞれから、トークンを能動的に無効化できるようにする等、建設的な仕組み作りが望まれる。

（６）取得できる情報範囲の拡大①正確な情報連携【現状と課題】

6



参照系APIで取得できる情報項目については、「銀行分野のオープン API に係る電文仕様標準」において標準項目が定められているところであるが、正確な情報連携を実現する上では、例えば以下の項目が不足している。
○ 取引明細を一意に特定できる識別ID○ アカウントの識別ID○ 明細日時（現時点では日まで）○ 取引後残高（日次会計や正確性バリデーションの際に必要）

特に、取引明細を一意に特定できる識別IDやアカウントの識別IDについては、それがないために取引が一意に特定できず、キャンセル等により明細が変更された場合や、APIで返す情報が勘定系と一致しない仕様の場合に、正確な情報連携ができなくなってしまう。

【改善策】



正確な情報連携のために、「銀行分野のオープン API に係る電文仕様標準」の更新も含め、項目の追加が望まれる。

②ユーザー利便性向上のための取得できるデータ種別の拡大【現状と課題】



ユーザー利便性の観点からも、取得できるデータ種別の拡大が必要であり、特に、家計簿サービスでは、外貨預金や住宅ローンの情報取得ニーズも強いが、当協会の調査によると、会員がAPI接続している金融機関においては、下記表に示す例のように参照系APIで取得可能なデータ種別は限定されている。
当座預金

外貨預金

住宅ローン

法人

91%

4%

―個人

16%

47%

24%

参照系APIで口座情報が取得できる金融機関の割合
【改善策】



当座預金口座は、手形や小切手の支払いのために日常的に使われており、少なくとも法人については全行で取得できることが望ましい。



個人についても、住宅ローンの数字を取得することで債務管理ができる、キャッシュレスデータを全て取得することで網羅的な資産の管理ができる等のメリットがある。



これらを含め、ユーザー目線での取得できるデータ種別の拡大が望まれる。

7

また、電代業者がサービスを提供する際、「情報が取れる銀行と取れない銀行」があると、提供できるサービスが限定されるため、なるべく金融機関毎で公開するデータ種別を統一させていくことも望まれる。

※B類型の前提となる、経済的メリットの追及



B類型に通底する本質的な課題として、これらの改善に投資するだけの費用対効果を、金融機関側で見いだせるか、という点が挙げられる。



経済的メリットの１つは、金融機関の口座保有者に対する分かりやすいメリットの提示である。既出のとおり、返金があったことの通知、入金エラーの通知等は、分かりやすい機能であるし、更にAPIの普及が進めば、明細取得期間が⾧い、トークン有効期限が⾧い等、電代業者との接続UXが良いことが、大きなユーザーメリットになると考えられる。



また、金融機関と電代業者の提携による経済的メリットの創出も、レンディング事業、法人ポータル事業、家計簿事業等々、幅広い領域で実現しつつある。このような事例を広く周知し、多くの金融機関に横展開していくことが重要である。



既存の提携に留まらず、アプリ全体のUX体験の向上、キャンペーン、新領域での提携等のアライアンス全体について、金融機関と電代業者が継続的に意見交換をしていくことが望まれる。

《C類型》（７）Webhookの導入【現状と課題】



家計簿や会計ソフト等の電代業者のサービスは、データの鮮度が重要であるため、Webhookにより口座情報が更新され次第、電代業のサービスが更新されることが理想である。

Webhookの機能は、既存の送金や手続きのメール送信と同等の機能であり、ユーザー利便性を大きく向上させるものであるとともに、口座情報が更新されたタイミン
グでのみアクセスされるため、コール数が削減され、金融機関、電代業者双方の経済的負担が最小化できる。

他方で、Webhookには技術的な課題もあり、導入できている金融機関は多くないのが現状である。具体的には以下のような課題が考えられる。
○ 情報をリアルタイムに連携する責任主体が金融機関側になるため、様々な体制整備が必要になる。
8

○ 「更新データが発生した場合」に情報を連携する場合、定義によっては更新データがかなりの数になり、時間的に偏りがある可能性もあるため、処理が詰まってしまう可能性がある。
○ 取引を必ず一意に特定する必要があるので、取引明細にユニークなキー、IDが付いていることが必須となる。
○ これらの技術的課題を乗り越えるための、経済的インセンティブが現時点では少ない。
【改善策】



これらの課題を、先進金融機関の事例の横展開等により、1つ1つ乗り越えていくことが重要である。



また電代業者からは、更新があったことだけでも通知があるとありがたい、といった声もあり、現実的なWebhookのあり方を模索することも必要である。



返金があったことの通知、入金エラーの通知等、ユーザーにとって分かりやすい機能から実装していくこと、マネタイズしやすい更新系APIの接続とWebhookを組み合わせていくこと等の工夫を、関係者で試行錯誤していくことが必要である。

（８）APIの基本設計【現状と課題】



現行の参照系APIは、IBの画面をスクレイピングからAPI化したものであり、IBの画面を操作する体験を、そのままAPI化している。いわば、IBの補完的機能として発想されたものである。



明細取得期間もリフレッシュトークンの有効期限も、「ユーザーは月1回くらいはIBにアクセスするだろう」という想定の下で、設計されている。



IBの補完機能であるため、明細にキーを付けるという発想や、Webhookで情報を連携するという発想も生まれにくい。



他方で、参照系APIが普及してくると、明細・残高確認を、更新系APIが普及すると振込まで、全て電代業者のサービスで完結し、IBには直接触らないケースも増えてくると想定される。

【改善策】

IBの延⾧で金融機関APIの改善を議論することに留まらず、金融機関APIが普及した世界におけるAPIのあり方について、更新系APIも含めてゼロベースで議論していくことが重要である。

9

４．今後の動き



本提言内容の進捗については、事務局にて定期的にモニタリングし、モニタリング内容を公表していく予定である。

具体的には、以下のような数字等について、調査・公表していく。
○ 電代業者数○ 電代業者のサービス数○ APIコール数○ AUP利用金融機関数○ 明細取得期間○ リフレッシュトークン有効期間○ APIで取得できる情報範囲○ Webhook整備銀行数○ 更新系APIの公開銀行数

以上

10