LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

電子決済等代行業とは何か｜銀行法が定める登録制のオープンバンキング事業

電子決済等代行業とは、銀行法第2条第17項に定められた業務で、預金者の委託を受けて銀行に対する為替取引の指図を電子情報処理組織を使って伝達する業務（いわゆる更新系）と、預金者の同意を得て口座情報を取得し提供する業務（いわゆる参照系）の2つを指します。平成30（2018）年6月1日に登録制度が施行され、国内でこの業務を営むには銀行法等に基づく金融庁への登録が必要になりました^*1*2。

本稿が扱う電子決済等代行業は、銀行の口座情報や振込機能をAPI経由で外部事業者に開放する「オープンバンキング」の中核制度です。同じく銀行接続を扱うテーマでも、事業会社の資金繰りを可視化する資金管理システム（TMS）や、クレジットカード等の決済を代行するPSP（決済代行事業者）とは規制上の位置づけが異なります。本稿では、電子決済等代行業の登録・API接続・セキュリティという領域に絞って解説します。

参照系API・更新系API｜口座情報取得と振込指図で異なる2つの接続類型

銀行法第2条第17項第2号に基づく参照系サービスは、預金者の同意を得て口座残高や入出金明細等の情報を取得し、利用者に提供する業務です。家計簿アプリや会計サービスが複数の金融機関口座を一覧表示する機能は、この参照系APIによって成り立っています。一方、同項第1号に基づく更新系サービスは、預金者の委託を受けて振込等の為替取引の指図を銀行に伝達する業務であり、給与振込や支払処理を担うサービスで利用されます^*1。

参照系と更新系では、求められるセキュリティ水準や銀行側の審査の重さが異なります。口座情報を取得するだけの参照系に対し、更新系は資金移動の指図そのものを扱うため、より厳格な認証・認可の仕組みが前提になります。自社サービスがどちらの類型に該当するか、あるいは両方を必要とするかによって、システム設計と登録手続きの内容は大きく変わってくるでしょう。

銀行API連携が広がった経緯｜全国銀行協会の検討会と銀行法改正

銀行分野のオープンAPIをめぐる制度整備は、2016年10月21日に設置された全国銀行協会「オープンAPIのあり方に関する検討会」から本格化しました。同検討会は2017年7月13日に報告書「オープン・イノベーションの活性化に向けて」を公表し、電文仕様標準や銀行法に基づくAPI利用契約の条文例を整備しています^*4。同報告書は、API利用契約における認可プロトコルとしてOAuth 2.0の採用を推奨する内容を含んでいます^*4。

これと並行して、2017年に銀行法等の一部を改正する法律が成立し、銀行がオープンAPIに係る体制整備に努める旨の努力義務が設けられました。電子決済等代行業者との連携・協働に関する方針を公表する義務も課され、銀行と電代業者の双方が制度対応を進める枠組みが整いました^*5。事業者にとっては、個々の銀行がどのようなAPI接続方針を公表しているかを確認することが、連携先選定の出発点になります。

電子決済等代行業の登録要件と銀行との契約締結

国内で電子決済等代行業を営むには、銀行法等に基づき金融庁への登録を受ける必要があります。登録を受けずに更新系・参照系のいずれかに該当する業務を営むことはできません^*2。登録に際しては、業務の実施体制や利用者保護の観点から求められる事項を満たしているかが確認されるため、公式の登録申請要領に沿った準備が必要です。

登録に加えて、電子決済等代行業者は接続先の銀行との間で契約を締結することが法令上求められています。金融庁は、この契約締結状況を定期的に公表しており、参照系サービスについては当初2020年5月31日までとされていた契約締結期限が、新型コロナウイルス感染症の影響を踏まえて同年9月30日まで延長された経緯があります^*3。銀行ごとに契約条件や審査プロセスが異なるため、複数行との連携を計画する場合は、契約締結までのリードタイムを個別に見込んでおく必要があるでしょう。

セキュリティ要件｜OAuth2.0・電文仕様標準・API接続基準

全国銀行協会の報告書は、銀行API連携における認可の枠組みとしてOAuth 2.0の採用を推奨しています^*4。これにより、利用者がID・パスワードを電代業者側のシステムへ直接渡すことなく、銀行が発行するアクセストークンを通じて限定的な権限を付与する仕組みが実現します。加えて、電文仕様標準は、口座情報や取引データの項目定義を業界内で統一し、複数の銀行に接続する事業者が個別にデータ仕様を調整する負担を軽減する目的で整備されています^*4。

実装面では、トークンの有効期限管理、通信の暗号化、アクセスログの保全といった基本的な対策に加えて、銀行ごとに公表されるAPI接続方針や技術仕様への準拠が欠かせません。セキュリティ要件は銀行側の判断や制度改正によって更新されることがあるため、自社システムを一度構築して終わりにせず、継続的に仕様変更を追跡する体制が必要になります。

システムに求められる要件｜複数行対応・障害追随・アグリゲーション・監査

家計簿・会計・給与SaaS等のサービスで銀行API連携を実用化するには、単一の銀行との接続にとどまらない設計が求められます。第一に、複数の銀行に接続するマルチバンク対応です。銀行ごとにAPI仕様や認証方式に差異があるため、共通のインターフェースへ変換するアグリゲーション基盤を用意しないと、接続先が増えるたびに個別対応の工数が膨らみます。

第二に、銀行側の仕様変更やAPI障害への追随です。銀行のシステムメンテナンスや仕様改定は事業者側の都合とは無関係に発生するため、変更を検知して迅速に対応できる運用体制が欠かせません。第三に、監査対応です。利用者の同意取得記録、アクセスログ、契約先銀行との通信履歴を一定期間保全し、必要に応じて提示できる状態を保つことが、登録事業者としての説明責任を果たすうえで重要になります。

内製構築と外注委託の比較

電子決済等代行業に対応するシステムを内製で構築する場合と、外部パートナーへ委託する場合では、必要な専門知識と対応範囲が異なります。以下の表に主な違いを整理しました。

まとめ：銀行API連携システム開発の3つの判断軸

本稿では電子決済等代行業と銀行API連携について、銀行法・金融庁・全国銀行協会の公表資料に基づいて要点を整理しました。要点は次の3つに集約されます。第一に、電子決済等代行業は参照系・更新系の2類型からなる登録制業務であり、登録に加えて接続先銀行との契約締結が法令上求められます^*1*3。第二に、OAuth2.0による認可や電文仕様標準への準拠といったセキュリティ対応は、全国銀行協会の報告書に沿って整備する必要があります^*4。第三に、複数行対応・仕様変更追随・監査対応を含むシステム運用は専門知識を要するため、内製と外注のどちらで進めるかを自社の体制と照らして判断することが重要です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：e-Gov法令検索「銀行法」第2条第17項（https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=356AC0000000059&openerCode=1）
2. *2　出典：金融庁「電子決済等代行業を営むみなさまへ」（https://www.fsa.go.jp/common/shinsei/dendai/index.html）
3. *3　出典：金融庁「銀行と電子決済等代行業者との間の契約締結の状況について」（https://www.fsa.go.jp/status/keiyakujoukyou_api/index.html）
4. *4　出典：全国銀行協会「オープンAPIのあり方に関する検討会報告書－オープン・イノベーションの活性化に向けて－」（https://www.zenginkyo.or.jp/abstract/council/openapi/）
5. *5　出典：全国銀行協会「オープンAPIって何？」（https://www.zenginkyo.or.jp/article/tag-g/9797/）

Tweet