多くの国で一定の利点と立法サポートがありますが、多くの銀行では、オープンAPIの概念は依然として懐疑的です。 これはロシアで特に顕著です。 ただし、このようなアプローチが決済技術のパラダイム自体の変化に寄与することを否定することは困難です。
オープンAPIコンセプトの開発は、個人からグローバル企業まで、すべてのエンドユーザーが体験できる決済業界の大きな変化の前兆です。 主な推進要因は、世界中の金融技術の開発とリアルタイム支払いへの移行、または欧州議会の指令PSD2などの新しい立法イニシアチブのいずれであっても、この方向の動きはすでに不可逆的であることを明確にしています。 この結果、アカウントに関する情報を取得し、支払いを生成および追跡するために、パブリックAPIを介して銀行システムに直接アクセスするサードパーティアプリケーションの使用がすぐに標準になります。 ただし、消費者だけがそのような変化を経験するわけではありません。 銀行自身にとっても、支払い技術との連携だけでなく、市場での位置付けの変化という点でも、深刻な結果が生じるでしょう。
アプリケーションプログラミングインターフェイス（API）-本発明は、新しいものではなく、名前で思われるほど複雑ではありません。 15〜20年前にエンタープライズシステムとサービス指向アーキテクチャ（ SOA ）の時代に最初に開発されたAPIは、外部からアクセスできず、APIとの通信を構成するために、アプリケーションを適応させるために多くの作業が必要でした。 しかし、今日、オープンAPIの出現により、このアプローチの需要はまったく新しいレベルに達しました。
オープンAPIとその前身の大きな違いは、それらが「外部」に表示され、はるかにアクセスしやすいことです。 過去10年間に観察されたプログラミングインターフェイスの出現と人気の高まりは、企業の情報技術の世界における開発者の役割の増大を証明しています。 企業でのソフトウェアの開発と実装がIT部門の主要な機能の1つであった時代、オープンAPIは、既存の製品とプラットフォームに基づいて新しいアプリケーションを取得したい一般ユーザーのレベルでの取り組みとしてほぼ登場しました。 このアプローチには独自の特徴があります。 特に、このようなインターフェイスは、Webテクノロジーに基づいて作成され、細部まで検証され、標準化された開発者に焦点を当てています。これにより、開発者はさまざまなベンダーの多くのAPIを最大限に活用し、既存のシステムに新しい機能をすばやく簡単に追加できます。
これらの品質は、ハイテク産業やソーシャルメディアなどの産業におけるコンセプトの人気の急速な成長につながっています。 そして、これらの同じ機能は、革新のための良い前提条件を作成し、場合によっては、銀行業務と支払いの分野でさえ革命を起こします。 伝統的に、銀行は、顧客が小売口座の残高を確認するか、企業に一連のクロスボーダー支払いを指示するかどうかに関係なく、顧客がサービスにアクセスするチャネルとアプリケーションを常に作成および制御してきました。 サードパーティの開発者は、オープンAPIを使用して、銀行システムにアクセスし、独自のチャネルと顧客と対話する手段を作成できます。 その結果、後者は銀行口座と取引を確認でき、銀行以外を使用して管理し、サードパーティのオペレーターポータルで管理できます。
オープンAPIの配布に寄与する要因
銀行とそのシステムに接続している第三者の両方にとって、この根本的な変化は多くの推進力によって可能になりました。 ヨーロッパおよび長期的には、おそらく全世界で、2016年に施行された2番目の指令である決済サービス指令2 （PSD2）は、銀行が第三者への口座、決済フロー、およびエンドユーザーデータへのアクセスを開くことを義務付け、触媒となりましたユーザー自身がそのようなアクセスを承認する場合。 しかし、このような立法上の変更を考慮しなくても、銀行業におけるAPIへの世界的な動きを止められない主な理由が2つあります。
1つ目は、特に中小企業向けの支払い、住宅ローン、財務管理などの分野で、金融サービスをより効率的に提供するためのイノベーションの絶え間ない流れを提供することを目的としたFintechグローバル産業の急速な形成に関連しています。 大企業を含むすべての銀行クライアントは、現在、最新の消費者向けアプリケーションおよびデバイスのレベルで、支払い、現金、および金融商品を扱うスピード、シンプルさ、および利便性を高めることに関心を持っています。 彼らにとって、どの組織がこれらのサービスを提供するかは重要ではありません-銀行またはその他。 そして、フィンテック市場の成長のおかげで、フィンテックはますます標準になりつつあります。
銀行は、顧客の獲得と維持を目的とした独自の柔軟な提案の枠組みの中で、これらのイノベーションをできるだけ早くサービスに投入することに苦労しています。 これを達成するために、彼らは特定のケースに合わせて調整された特殊なソリューションのモデルから離れて、部分的にソリューションを収集できる環境を作成し、さまざまなベンダーのコンポーネントを選択し、APIを使用してそれらを単一の全体に「接着」して、これまたはその消費者が必要とする経験。 このアプローチでは通常、SaaSプラットフォームを使用します。SaaSプラットフォームは、必要なときにそれらを使用する機能を備えた、幅広いアプリケーションを低価格で簡単かつ簡単に提供できます。 たとえば、住宅ローン計算機をウェブサイトに追加する必要がある銀行は、現在、独自のアプリケーションをゼロから作成するのではなく、APIを使用してサードパーティのソリューションを埋め込む可能性があります。
オープンAPI配布の2番目の主要なドライバーは、リアルタイムの情報とサービスの必要性の高まりです。 これには、世界中のインスタント支払いインフラストラクチャの継続的な実装も含まれます。 この傾向は、バッチトランザクションファイルを作成してFTP経由で転送する従来のモデルがこれらの目的に適していないこと、および組織とアプリケーションがリアルタイムのデータ交換を必要としていることを示唆しています。 銀行の中でこの分野のリーダーはBBVAであり、実際に銀行プラットフォーム全体をインターネットで公開し、他の組織に独自のイノベーションのためにそれを使用する機会を提供しました。 このステップは、ソフトウェアの開発と実装の分野におけるより広範な現象を反映しています。製品からプラットフォームへの移行により、問題をより迅速かつ効率的に解決でき、より包括的なアプローチを提供します。
銀行の差別化の形式の変更
支払いと銀行業務の分野における一般的な傾向を背景に、特定のレベルの進歩は地域によって異なります。 たとえば、欧州はリアルタイムの支払い処理スキームの点で最も早く前進し、北米は今やそれに追いつき始めたばかりです。 ただし、開始位置と進捗速度が異なるにもかかわらず、説明されている傾向は一般に、新しい形式の競争と銀行間のポジショニングとのグローバルな収束という一方向の動きを示しています。
歴史的に、銀行は他の銀行と競い合い、サービスの効率性とポータルの技術的有効性の点でお互いを凌tryingしようとしていました。ポータルは最近まで、ほとんどすべての場合、完全に開発および維持されていました。 今、別の状況が浮上しています。 今、彼らは差別化が他の2つの基準に基づいている新しい世界にいます。 第一に、銀行の運用サービスと手数料の主な複合体は、基本的に運用上の「エンジン」に変わり、サードパーティ企業は外部インターフェイスを統合できます。 そして第二に、オープンAPIの品質により、サードパーティ企業はこのような統合が可能になります。 このコンテキストでは、APIの「品質」は、提供できる情報の正確性、関連性、完全性に帰着します。 たとえば、クライアントはそれらを使用して、国境を越えた操作の現在の状態をリアルタイムで追跡できますか？
断片化された操作は、高品質APIの開発の障害になる可能性があります
銀行によっては、広範で高品質のリアルタイム情報を提供するオープンAPIを提供する能力が、運用部門で使用されるデータを操作するシステムとアプローチによって妨げられる場合があるためです。 銀行がさまざまなタイプの支払いに関するデータを記録するためにさまざまなシステムを使用する場合、APIを介してさまざまなサードパーティパートナーに転送するためにそれらを単一のフォームに変換することは非常に困難な作業です。 さらに、今日の支払いメッセージの価値と有用性は、主な取引に関連する商業的およびコンテキスト情報にますます依存しています。 たとえば、ヘルスケアの支払いには、それをカバーする保険会社に関する有用な情報が含まれる場合があります。
これらすべての要因により、高品質のAPIをサポートする銀行部門の能力に注意を払うことになります。 バックエンド側で支払いシステムがスパゲッティに似ている場合、フロントエンドAPIは、適切な形式でサードパーティパートナーに提示するために、データを解析および整理する必要があります。 また、この作業をリアルタイムで実行すると、タスクが非常に複雑になります。 したがって、オープンAPIを開発しようとしている銀行は、運用部門の技術的ソリューションを適切に分析し、必要な情報すべてをリアルタイムで提供できるかどうかを判断する必要があります。
障害を取り除く手段としての決済ハブ
多くの場合、彼らはこのタスクに対処しません。 これは、銀行が何らかの行動を取る必要があることを意味します。 おそらく、そのような場合、異種システムを組み合わせて、オープンAPIの要件をより完全に満たす新しいプラットフォームを作成する必要があります。 この要件は、いわゆるペイメントハブ（ ペイメントハブ ）の概念の開発に貢献し、すべてのタイプのペイメントの処理を単一のプラットフォームに転送できるようにします。 前述のSaaSの使用と組み合わせて、オープンAPI環境での支払いハブの可能性により、銀行に2つの実用的なシナリオが提供されます。
最初のオプションは、組織が支払いハブサービスを提供するシステムに必要なAPIテクノロジーを統合する場合の、内部銀行ソリューションの開発です。 このモデルは、サードパーティのエンドユーザーアプリケーションから決済ハブまでの情報チャネルを介した移動のルート全体で、注文および情報要求の処理に理想的かつリアルタイムで対処する必要があります。 銀行は、借方の承認から支払手数料の計算まで、さまざまな目的のために設計された多くの個別の小さなサービスに分割された拡張ツールセットの作成にも注力する必要があります。
2番目のオプションは、支払い取引の処理に必要なすべてのソフトウェアとハードウェアを備えたサードパーティサービスのサービスを使用することです。 サービスプロバイダーは、多数の顧客をサポートする仲介者の場合もあれば、狭い範囲の顧客に対して個別のサービスを提供する場合もあります。 オープンAPIの世界では、ソリューションはサードパーティ（またはPSD2ディレクティブ、支払いおよび請求情報サービスプロバイダーで呼び出される）が、そのようなインフラストラクチャの安全な内部APIに直接接続できるようにする必要があります。 理想的には、選択したソリューションは、「従量課金」システムの利点とクラス最高の支払い処理技術を組み合わせて、オープンAPIの世界にワンステップでアクセスできる必要があります。
明らかに、銀行がオープンAPIに関してどのようなアプローチをとるにしても、セキュリティの問題がここで主要な役割を果たすでしょう。 この点で、さまざまな業界で新しいアプローチがより普及しています。セキュリティが「保護」を意味していた場合、現代の世界では「情報の一括交換」によってのみ効果的なセキュリティを実現できます。 この根本的な変化の好例は、オープン性と共有アクセスによって高度なセキュリティが実現される革新的なブロックチェーンテクノロジーです。 したがって、APIを介したシステムの発見は特定のリスクをもたらしますが、テクノロジーの適切な選択と集団的協力を犠牲にしてこの問題を解決できます。
APIの未来に向けて
一般的に、銀行はオープンAPIの概念の開発を積極的かつ積極的に認知する必要があることが明らかになります。この技術的手法により、銀行は金融サービスと支払いの新しいエコシステムの一部となり、その中での地位を強化できるからです。 このため、銀行は将来の明確なビジョンを形成し、新しい技術形式で事業を再構築する必要があります。
オープンAPIは急速に発展しており、将来の銀行および決済サービスの基本要素の1つになっています。 銀行は今すぐビジネスに組み込みを開始する必要があります。そうしないと、今後数年のうちにキャッチアップとして行動する必要があります。
