text：小野 真樹 日本IBM
金融イノベーションの起爆剤
銀行OpenAPIは、従来のインターネット・バンキングに代わり、多彩なアプリケーションから資産情報を利用できるようにさせ、いわゆるフィンテック企業が金融と技術を融合させ、金融イノベーションを起こす起爆剤となった。
その背景には、2017年の銀行法改正があり、フィンテック企業は消費者が銀行へ送金指示を行ったり、口座情報を照会したりするのを代行することが認められ、消費者保護のルールが定められた。
消費者にとっての利便性をテクノロジーによって向上させた結果、単なる通帳がビッグデータによるデータ分析の恩恵を受けたり、少額投資や少額送金をスマホで簡単に実現できるようになったりして、金融取引が指一本で行える時代となった。
銀行OpenAPIの義務化とOAuth 2.0への注目
銀行OpenAPIは金融イノベーションに必要不可欠な要素であったが、2015年以前の日本ではOpenAPIの価値がよく理解されておらず、わざわざOpenAPIを用意せずともインターネット・バンキングで十分ではないかと考えられていた。
銀行OpenAPIが登場する以前のフィンテック企業は、インターネット・バンキングのWeb画面をソース解析して、ユーザーの操作をプログラムでシミュレーションし、口座の取引明細画面を表示させ、そこから取引明細部分だけを切り出して情報収集していた。その際、インターネット・バンキングにログインするためのユーザーIDとパスワードをユーザーから預かり、インターネット・バンキングへのログイン操作をシミュレーションしていた。
銀行側から見ると、インターネット・バンキングへログインするためのユーザーIDは消費者へ貸し出した鍵のようなものである。従って、鍵を勝手に第三者へ預けられてしまうことは、『なりすまし』という犯罪と見分けがつかなくなる行為であり、セキュリティ上の不安材料となっていた。
こうして、インターネット・バンキングへのフィンテック企業からのアクセス数が増大するにつれ、不安材料がますます増大していくことへの懸念から、ユーザーID、パスワードを必要としないアクセス手段としてOAuth 2.0が注目されることとなった。
OAuth 2.0はOpenAPIで利用できるアクセス制御の仕組みで、ユーザーとフィンテック企業がお互いにお互いの秘密（パスワードなど）を共有することなく、フィンテック企業がユーザーの口座情報へアクセスすることを可能にする仕組みである。
銀行OpenAPIの義務化は、ある意味OAuth 2.0の義務化と呼んでも過言ではない。そして、セキュリティ上の安全対策の結果、銀行OpenAPIが全国規模で展開することになった。
更新系のセキュリティ強化へ
現在の銀行OpenAPIは残高照会や取引明細照会などの照会系取引が主流で、振込や振替などの更新系取引については従来通りインターネット・バンキングや口座振替サービスを利用したものが主流で、銀行OpenAPIは使われていない。
この理由として現在の銀行OpenAPIは更新系取引に必要なセキュリティが満たされていないことが挙げられる。奇しくもコロナ禍で現金に触れる機会が減り、電子マネーやQR決済が普及してきたことで、取引手数料を下げる原動力となりうる銀行OpenAPIの更新系取引対応が期待されており、早期のセキュリティ強化が期待されている。
セキュリティを考える上で欧州の銀行OpenAPIの法制度（PSD2）の採用した技術が参考になる。そこで、次章ではPSD2について、日本の法制度と比較しながら紹介していく。
フィンテック企業にとって至れり尽くせり、欧州の銀行OpenAPI
欧州ではフィンテック企業は免許制となっており、フィンテック企業が希望すれば銀行は必ずOpenAPIを提供しなければならない。また、利用登録（オンボーディング）の仕組みを用意し、年中使える接続テスト環境を提供しなければならない。まさに、フィンテック企業にとっては至れり尽くせりの環境である。
この仕組みを支えているのは電子証明書の認証局の免許制と銀行OpenAPI仕様の業界団体による統一、そして、フィンテック企業の免許情報のディレクトリ・サービスである。以下ではこれらを使ったオンボーディングの仕組みについて触れる。
欧州では電子証明書にフィンテック企業の免許番号が記載されており、認証局がフィンテック企業と免許番号に虚偽がないことを確認し電子証明書に署名している。銀行はフィンテックのオンボーディングの際、この電子証明書を受け取り、電子証明書が無効化されていないか、免許番号が無効化されていないか、認証局やディレクトリ・サービスでチェックすることでほぼリアルタイムでオンボーディング申請を受理し、アクセス用のID、シークレットを発行している。
日本なら個別にフィンテック企業の登記簿を取り寄せて現住所を確認の上、直接担当者同士で面談して、お互いの電子証明書を交換して、金融庁の登録リストと照合して、という具体に色々と確認手続きが必要だが、欧州では認証局が免許制で信頼性が高くこれらの手間を省いてくれる。
日本では全国の銀行と個別に面談しなければならないが、欧州は電子証明書を使ってそういった手間を省いている。銀行へ申請するだけでオンボーディングが済むことを考えると、認証局の免許制のメリットがよくわかる。
日本と欧州の銀行OpenAPIの違い
次に、銀行OpenAPI仕様の業界団体による統一であるが、こちらは欧州でも国によって所属する団体に違いがある。欧州全域で最も普及しているのはBerlin GroupのAccess to Account (XS2A) Open Banking Frameworkである。イギリスはEUを離脱したが、PSD2には離脱前に準拠しており、国主導でOpen Banking Implementation Entity (OBIE)のOpen Banking Standardを作っている。
それぞれの団体は独自のOpenAPI仕様を作ったが、共通して言えるのはAPIを大きく3種類にして共通化したこと、また、シーケンスも共通にしたこと、そして、ペイロードをISO20022に統一したこと、通信をTLS相互認証に統一したことが挙げられる。更新系については署名も追加することで入力された情報までをセキュリティの範疇に含めている。
XS2Aはセキュリティ部分をある程度多様性を持たせており、汎用性が高い。それに対し、OBIEはFAPIに限定したため、欧州全域に普及することはなかった。OBIEのOpenAPI仕様は更新系が非同期であることに着目し、callbackを仕様に追加している点で他よりも先進的であったが、セキュリティ面でFAPIに固執してしまったことは残念である。
日本では、銀行とフィンテック企業の間で、セキュリティ・チェックシートを使って双方のセキュリティを検証し、問題なしと判断した場合のみ銀行OpenAPIへの接続が許可される。また、事故の際の責任分担や利用料は個別契約によって決定されている。銀行OpenAPIの仕様やシーケンスはOpenAPIゲートウェイ・サーバーとして採用したベンダーごとに似た傾向がある。
銀行OpenAPIのセキュリティの考え方
銀行OpenAPIは、参照系と更新系で考え方が異なっている。技術的には認証認可がOAuth 2.0、通信がTLS相互認証、アプリケーションの識別がAPIキー（クライアントID）、要求の保証は電子署名が用意されている。
参照系は情報を提供するだけなので、OAuth 2.0、TLS相互認証、APIキーが実装されている。更新系はフィンテック企業からの要求電文を保証するための電子署名が含まれる。
最近ではマルウェアなどにより、スマホやPCから認可コードが盗用されてしまうのを防止するためPKCE（Proof Key for Code Exchange）の実装を採用する例も出てきている。
OAuth 2.0で使われるアクセストークンやリフレッシュトークンの有効期限については90日とする銀行が多い。これはインターネット・バンキングで法人アカウントのパスワード有効期限が90日だったことに起因するもので、個人アカウントではパスワードを90日おきに変える人が少ないため、個人の照会系については有効期限を長くできないか取り沙汰されている。
ここで問題となるのが銀行側のトークン管理システムが保管しておかなければならないトークンの数で、有効期限が長くなればなるほどトークンの保管期間が長くなるから、その分保管する数も増えることになる。銀行OpenAPIの要求に対し毎回トークンの有効性を検査しており、保管するトークンの数が増えればそれだけ検索する対象が増えて、応答時間に影響を与えることになる。
そこで、トークン管理システムではトークンの保管期間が最小化するような工夫が必要となる。フィンテック企業からの要求頻度に合わせてトークンの有効期限を決定するのが最も都合がよい方法と言えるが、そのような工夫をしている銀行は今のところまだない。
振込APIの実現に向けて
銀行OpenAPIはインターネット・バンキングをRESTに変換して作られているものが多く、マイクロサービスを意識して作られていない。照会系はそれでもよかったが、更新系ではフィンテック企業側で非同期の結果整合性を意識したトランザクションを作る必要がある。先に紹介したBerlin GroupではSagaパターンのコレオグラフに相当するシーケンスが作られ、OBIEではSagaパターンのオーケストレーションに相当するシーケンスが作られた。
日本ではSagaパターンではなく、単純な同期処理として更新系APIを作るのが主流で非同期のシーケンスは受け入れられていない。今後振込APIを実現するためには要求電文の署名と共に、非同期シーケンスの実装が必要不可欠である。
都度振込ではパスワードだけでなく、より強固な認証を用いることが求められている。PSD2では、少額取引や事前登録先への送金については強固な認証を免除できると定められている。また、交通機関の運賃や駐車場料金の支払いでは認証が免除される。逆に、フィンテック企業ごとに不正な取引の温床となっていないかを監視し、不正な取引の割合が閾値を超えたらそのフィンテック企業からの取引は強固な認証を必須とし、免除を取り消すといったことまで定められている。銀行は不正な取引を監視する仕組みを用意し、振込依頼の電文に振込先の店舗情報まで含め取引を行うようにし、資金の流れを監視している。
日本では振込よりも、口座振替の方が普及しており、振込APIがなかなか普及してこなかった。バーコード決済やQRコード決済などの決済代行アプリでは、指紋認証だけで簡単に決済ができるようになっているが、オンライン口座振替登録時の本人確認方法の脆弱性が発覚して以降、新規の口座振替契約ができない状態が続いており、その打開策として強固な認証が改めて見直されてきている。そのためには、銀行OpenAPIと決済代行業者の認証とを一体化させた振込APIのシーケンス作りが必要不可欠である。
このように振込APIの実現には解決しなければならない課題がいくつもあり、5年経った今でも銀行OpenAPIはまだまだ発展途上である。今後も社内外のコミュニティやワーキンググループなどを通じて研究を深めていきたい。
◎参考文献
・金融庁 第3回金融審議会 金融制度WG資料「オープンAPIのあり方に関する全銀協の検討状況」2016年10月28日、田村直樹（一般社団法人全国銀行協会企画委員長、株式会社三井住友銀行常務執行役員）
https://www.fsa.go.jp/singi/singi_kinyu/financial_system/siryou/20161028/02.pdf
・全国銀行協会「オープンAPIのあり方に関する検討会」
https://www.zenginkyo.or.jp/abstract/council/openapi/
・金融情報システムセンター FinTech関連「API接続チェックリスト」
https://www.fisc.or.jp/document/fintech/index.php
・The Berlin Group「PSD2 Access to Bank Accounts」
https://www.berlin-group.org/psd2-access-to-bank-accounts
・Open Banking Implementation Entity「Open Banking Read-Write API」
https://openbankinguk.github.io/read-write-api-site3/
・TEC-J / AoT API Banking Initiative「API Mobile Banking Reference Architecture」
小野 真樹 氏
日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス ハイブリッド・クラウド・サービス
ITスペシャリスト
TEC-J Steering Committeeデジタル広報担当
インターネットやWebアプリケーションの製品スペシャリストを経て、APIマネジメントの製品スペシャリストとなり、銀行、保険、製造業界でAPIマネジメントやデジタル・サービス基盤の構築を担当してきた。また、TEC-JではFinTechやAPI Bankingのワーキング・グループに参画し、活動してきた。
＊本記事は筆者個人の見解であり、IBMの立場、戦略、意見を代表するものではありません。
当サイトでは、TEC-Jメンバーによる技術解説・コラムなどを掲載しています。
TEC-J技術記事：https://www.imagazine.co.jp/tec-j/
［i Magazine・IS magazine］
