少し前に、金融機関APIについてお話ししました。お客さまのIDとパスワードをお預かりしなくても、より安全に銀行やクレジットカード会社のデータを取得できるようにする仕組みが、銀行やクレジットカード会社が提供するAPI(Application Programming Interface)。
APIという言葉は耳慣れないかもしれませんが、実はITの世界では相当昔から存在する仕組みであり、新しい概念ではありません。もともとは、OS(例えばWindows)の上でアプリケーションがOSの機能を効率的に利用するための仕組みとしての利用が中心でした(例えばWin32 API)。
最近では、複数のシステム間を連携させるための仕組みとしてAPIが広く一般的に活用されるようになってきました。特にここ10年間で、インターネットがさらに浸透し、その上で動作するシステム間をつなぐインターフェイスとして、REST APIと呼ばれる方式のAPIが広く普及してきたことによって、イマドキのシステムがシステム間で連携する上で不可欠なものになっています。たとえば、SMART(スマート取引取込)がMisocaやAirレジなどとデータを連携する際には、各サービスがSMARTのAPIを利用してデータをSMARTに渡すようになっています。
一方で、金融機関のシステムといえば、ほとんどの場合、インターネットとは隔絶された独自の世界に閉ざされており、それは今でも大きくは変わっていません。だからこそ、現時点で金融機関のデータを取り込もうとすれば、インターネットに向けて唯一開放された窓であるインターネットバンキングを裏技的に利用するしかありません。具体的には、前回お話しした通り、お客さまのインターネットバンキング等のIDとパスワードをお預かりした上で、SMARTが、あたかもお客さまが利用しているように(ある意味お客さまになりすまして)インターネットバンキング等にログインし、情報を取得するスクレーピングという仕組みに頼らざるを得ません。
ただ、この仕組みの場合、セキュリティに関する一定の懸念が存在します。金融機関のシステムが、インターネットとは隔絶された独自の世界に留まっている大きな理由の一つは、一般的なシステムよりも堅牢なセキュリティを実現するため。しかし現実は、お客さまが金融機関が管理しているお客さま自身のデータへのアクセスを求める中で、スクレーピングに頼らざるを得ず、結果的にセキュリティの懸念を招いてしまっています。つまり、ある意味矛盾を起こしてしまっている訳です。
そういった背景があるなかで、金融機関が自らAPIを提供することによって、より安全に金融機関のデータを取得できるようにする、あるいは金融機関にデータを渡すことができるようにしようというのが、金融機関APIが目指すところです。さらには、金融機関APIを通じ、お客さまがお客さま自身のデータをより自由に活用できるようになることによって、これまでにない利便性がもたらされることも期待されます。実際、昨年改正された銀行法では、セキュリティを確保しつつも、お客さまにとっての利便性を向上させるために、銀行に対しAPIに係る体制整備の努力義務を課しています。
ただ、現実問題としては金融機関APIの普及には一定の時間はかかるものと考えています。次回は、金融機関APIの現状についてお話ししたいと思います。
