APIとは何か、なぜ貸し手に欠かせないのか

システム同士が話すための取り決め

バーゼル銀行監督委員会は、2019年のオープンバンキングとAPIに関する報告で、APIを、ソフトウェアのプログラムが互いにやり取りするための一連のルールと仕様と定義しています。実際には、一方のシステムが、例えば顧客の身分証の番号と照会の目的のような要求を、取り決めた形式で送り、もう一方のシステムが、例えば信用情報の報告や誤りを知らせるメッセージのような応答を、取り決めた形式で返します。どちらの側も、相手の内部がどう作られているかを知る必要はなく、取り決めに従うだけで足ります。

この分離があるからこそ、貸し手は他の部分を作り直さずに1つの部分を変えることができます。台帳を入れ替えても、新しい台帳が同じ要求に同じ方法で応えるかぎり、審査エンジンは動き続けることができます。

貸し手がAPIを使う場面

デジタル貸付プラットフォームの構成の講座では、1件の貸付を部品から部品へと追いました。部品の間、そして貸し手と外部の間のほとんどすべての段階が、APIの呼び出しです。1件の貸付についての実務的な一覧を示します。

• 本人確認：申込者の身分証を、本人確認のサービスに照らして確認します。
• 信用情報：申込者の信用情報を信用情報機関に照会します。
• 共有されたデータ：申込者が共有に同意した銀行口座のデータを受け取ります。
• 審査：申込みを、顧客の受け入れのシステムから審査エンジンに渡し、結果を受け取ります。
• お金：貸付金の送金を指示し、返済のたびに通知を受け取ります。
• 提携先：別のサービスの中で貸付を提供する場合に、提携先のアプリから申込みを受け取ります。

APIが置き換えたもの

APIの前は、第三者はしばしばスクリーン・スクレイピングによって銀行のデータを集めていました。バーゼルの報告は、スクリーン・スクレイピングを、自動化されたスクリプトを使って、あるアプリケーションに表示されたデータ項目を集めることと説明し、スクリーン・スクレイピングには、顧客が銀行のログインの認証情報を第三者に渡す必要があると指摘しています。報告は、こうした手法を顧客にとって安全でないとしています。そして、APIのほうが共有するデータの種類と範囲をよりよく管理でき、第三者とやり取りするより安全な方法だと銀行が認識しつつあると述べています。

オープンバンキング：顧客が許可するデータ

APIは、顧客のデータが、それを持つ銀行の外に出ることも可能にします。バーゼルの報告は、オープンバンキングを、顧客が許可したデータを、銀行が第三者の開発者や企業と共有し活用することと定義しています。報告は、各法域に大きく3つの手法があることを見出しました。顧客が許可したデータの共有を銀行に義務づける規範的な手法で、例にはタイが含まれます。指針や推奨される標準を示す促進的な手法で、例にはシンガポールが含まれます。そして明示的な規制も指針もない市場主導の手法で、例には米国が含まれます。2026年の国際決済銀行の論文は、2024年までに95の法域が、何らかの形のオープンバンキングまたはオープンファイナンスの政策の枠組みを設けていたと報告しています。

貸し手にとっての関心は与信にあります。同じ国際決済銀行の論文は、英国についての研究を引いて、オープンバンキングによって中小企業がノンバンクの貸し手と新たな与信の関係を結べるようになったと報告しています。この講座の第2回では、こうしたデータの共有がどう機能し、顧客の同意が何を対象としなければならないのかを見ます。

審査はどれだけ待たされるのか

外部への呼び出しはどれも、審査に待ち時間を加えます。そして呼び出しの並べ方によって、その長さが決まります。互いに依存する呼び出しは順に行わなければなりませんが、依存しない呼び出しは同時に行うことができます。

順に行う呼び出しの待ち時間 ＝ それぞれの応答時間の合計。同時に行う呼び出しの待ち時間 ＝ それぞれの応答時間のうち最も長いもの。

計算例（数字は説明のためのものです）：本人確認は2秒、信用情報機関は3秒、銀行データのサービスは5秒で応答します。3つの呼び出しを順に行うと10秒かかります。本人確認が済んだあとに、信用情報機関と銀行データの呼び出しを同時に行えるなら、待ち時間は2秒に、3秒と5秒のうち長いほうを加えた7秒です。この設計の選択は速さだけの問題ではありません。本人確認が済む前に信用情報機関に照会すれば、名乗っているとおりの人物ではないかもしれない人のために、ある人のデータを信用情報機関に送ることになるからです。

どの接続もリスクでもある

バーゼルの報告は、接続には利点だけでなくリスクも伴うことを明確にしています。報告は、データの共有によってサイバー攻撃を受けうる範囲が広がること、特に銀行が契約関係を持たない場合には第三者の監督が限られうること、取引が不正であったり誤っていたりしたときに、銀行、第三者、さらにその先の第四者のどの当事者が責任を負うのかが常に明確とは限らないこと、そして責任の規制が確立している場合でも銀行は評判のリスクに直面しうることを見出しています。また、世界的に採用されたAPIの標準はないことも指摘しています。

デジタル貸付プラットフォームの構成の講座の第6回では、第三者が運営するどの部品についても、貸し手が責任を負い続けることを見ました。APIの接続は、その責任が最初に試される場所であることが少なくありません。この講座の第4回では接続をどう安全に保つかを、第5回ではそれをどう運用するかを扱います。