近年のデジタルサービスの拡大に伴い、なりすましなどの犯罪も増加しており、あらゆる人が利用できる信頼性の高い本人確認方法の確立が急務となっています。関連する業法の改正、及びオープンAPI化の進展により、銀行が長年蓄積した本人確認済情報の外部利用が可能になってきており、NECはこれを広く利活用するための情報流通プラットフォームを提供しています。本稿では、プラットフォームの概要に触れたあと、情報を安全に流通させるためのセキュリティや可用性などの技術面での取り組み、将来の展望について紹介します。

1. はじめに

経済社会のデジタル化が急速に進展し、金融サービスをはじめとする多くのサービスが、対面ではなくデジタル技術を通じてリモートで提供されつつあります。一方で、なりすましや匿名アカウントを悪用した詐欺などの不正利用も無視できないほど増加しており、事業者には当該サービスの利用者が「実在する本人であるかどうか」をより厳格に確認することが求められています。

業法上、利用者の本人確認が厳しく求められる金融業界では、デジタル技術による利用者の利便性向上と本人確認の高度化を実現するため、2018年の犯罪収益移転防止法施行規則の改正^1）により、オンラインで完結する本人確認（eKYC：electric Know Your Customer）方法が認められました。

なかでも、改正規則6条1項1号ト（1）で定められた「銀行等への照会」（図1）は、対象とする利用者のカバレッジや銀行の有する本人確認済情報の信頼性の観点から、犯罪収益移転防止法の適用を受ける事業者に限らず、あらゆるデジタルサービスを提供する事業者の認証基盤の一助になると期待されています。NECはこれらの動きに着目し、複数の銀行への照会を可能とするマルチバンク形式の本人確認プラットフォームを製品化^2）しました（図2）。

本プラットフォームは、利用者の許諾に基づき、銀行が保有する本人確認済情報を、さまざまな事業者へ提供するデータ流通の仕組みとなります。犯罪収益移転防止法の適用を受ける事業者は、従来の郵送などを用いた顧客の現況確認の代わりに、画像などで送付された本人確認書類の記載事項と銀行の有する本人確認済情報（氏名、住所、生年月日など）を照会することで、オンラインで本人確認が可能となります。また、利用者からサービス申し込み時に入手する情報に加え、銀行が持つ情報との照合が可能になるため、利用者の情報をより正確に把握して、サービスを提供することが可能になります。

システムの観点では、本プラットフォームに接続するだけで複数銀行への照会が可能となるため、システム接続にかかわる仕様の調整や開発、テストの負荷軽減が見込めます。

2. 本プラットフォームを構成する技術要素

本プラットフォームでは、図3に示すように複数の事業者間を相互に接続し、オープンAPI（Application Programming Interface、オープンAPIはその仕様が外部の利用者に公開されているAPI）を用いて、利用者の本人確認済情報を安全、確実に流通する機能を提供します。以降の節で、対事業者接続、対銀行接続、本プラットフォームの稼働を支えるシステム基盤の3つの観点で特徴的な技術要素を詳述していきます。

2.1 対事業者接続

事業者に対しては、オープンAPI形式（REST/JSONフォーマット）にてインタフェース（以下、I/F）を公開しています。このI/F公開にあたっては、NECのWebサービス公開ソリューションである「API連携サービス（NC7000-WG）^3）」により実現しています。「API連携サービス」の特徴は以下の通りです。

本プラットフォームでは、「API連携サービス」のこれらの機能を最大限活用することで、事業者・銀行間の安全なデータ流通を実現しています（図4）。

2.1.1 接続先管理（M:N接続の実現）

本プラットフォームでは、事業者の申込内容に応じて接続可能な銀行が異なります。例えば、事業者Aは銀行A及び銀行Bから情報取得ができますが、事業者Bは銀行Bからのみ情報取得ができる、といったものです。本プラットフォームでは、本プラットフォームの契約管理システムと連動し、事業者が接続可能な銀行へのみ、適切にトランザクションを連携します。

2.1.2 銀行KYC情報連携I/F（共通I/F）

銀行ごとに異なるメッセージフォーマットを吸収し、統一された「共通I/F」として事業者へ提供します。例えば、銀行Aは郵便番号データが住所項目に含まれるのに対し、銀行Bでは郵便番号項目として別個に設定されている、などの差分が見られるケースがあります。これらI/Fの差分を本プラットフォームにて吸収することで、事業者は銀行ごとのI/F差異を考慮することなくサービスの迅速な導入が可能となります。

2.1.3 銀行KYC情報連携I/F（流量制御）

事業者ごとに接続可能数を設定することでプラットフォームへ流入するトラフィック量をコントロールします。また、本機構を用いることにより、各銀行へのシステム負荷となるバーストトラフィックの発生も抑制しています。

2.2 対銀行接続

2.2.1 利用者認証・認可

本人情報の取得にあたっては、まず、RFC6749^4）で規定されている「OAuth2.0認可フレームワーク」に則り、利用者の本人認証、並びに本人情報提供への許諾を取得します。そのうえで、利用者は自身のデータの最新性の確認を行い、企業サービス側へ本人情報の取得を指示、本プラットフォームを経由して銀行から本人情報を取得します（図5）。

2.2.2 トレーサビリティの確保

銀行から見た場合、接続元は本プラットフォームのみとなります。ただし、実際には利用者が選択した事業者側へ本人確認済情報が提供されます。したがって、事業者・本プラットフォーム・銀行間で本人確認済情報の流通に関するトレーサビリティを高めることが必要です。本プラットフォームが情報流通の中核を担っていることから、いつ、どの利用者が、どの事業者経由で、どの銀行から情報取得を行ったか、本プラットフォームにてこれら情報流通履歴の可視化を行っています。

2.3 システム基盤

本プラットフォームにおいては、本人確認済情報の流通にあたり、特にセキュリティについて十分な考慮を行い、システム基盤の構築を行っています。

2.3.1 クラウド基盤

今後のサービスの拡大に柔軟に対応できるよう、本プラットフォームではクラウド基盤を採用しています。クラウド基盤が有するセキュリティ機能の利用、また、サーバの冗長化など、サービスの安定した提供に向けた各種対策を行っています。

2.3.2 プラットフォームセキュリティ

OSレイヤからアプリケーションレイヤまで多層防御の概念を適用し、セキュリティ強度を高めています。

まず、利用企業から本プラットフォームの間、並びに本プラットフォームから銀行の間の通信は、TLS（Transport Layer Security、通信内容の暗号化などセキュリティを要求される通信を行うためのプロトコル）で保護され、経路上の盗聴や改ざんに対するリスクの低減を行っています。

また、図6に示すように、アクセス制限をはじめとし、IDS/IPS（Intrusion Detection System/ Intrusion Prevention System、システムやネットワークの脆弱性を狙った攻撃を検知/防止するセキュリティ対策）、WAF（Web Application Firewall、ウェブアプリケーションの脆弱性を悪用した攻撃からウェブアプリケーションを保護するセキュリティ対策）機能などにて、システム全体の保護を行っています。

なお、プラットフォームセキュリティについては、24時間365日の有人監視を実施、セキュリティインシデント発生時には迅速な対応を可能としています。

3. 最後に

本稿では、銀行が有する本人確認済情報をオープンAPIの形式で流通し、事業者の本人確認に利用するユースケースの技術的な取り組みを紹介しました。

今後、銀行が有する業務機能や情報はオープンAPI化の流れを受けて、さまざまな生活シーンや産業に組み込まれていくことが想定されます。また、全国銀行協会「オープンAPIのあり方に関する検討会報告書^5）」で提起されたように、他の事業者においてもオープンAPI の取り組みが進展し、銀行と事業者の間でさまざまな情報を相互にやり取りするエコシステムが形成されていくことも期待されます。

本プラットフォームにおいても、本人確認済情報と併せて銀行が有する金融資産などの顧客情報を事業者に提供したり、事業者サービスの本人認証（Authentication）向けに認証APIを拡充するニーズが確認されています。今後、安全・安心な情報活用のもと、利用者の利便性向上やサービスの拡充など、更なる活用が進むことが期待されます。

参考文献

執筆者プロフィール