決済システムアーキテクチャの最適解

決済処理は長年にわたり大きく進化してきました。それほど昔ではない過去、決済指示は電話や書面で顧客から手作業で受け付けられ、検証された上で、送信のために旧式の端末に入力されていました。決済量の増加と、より迅速な取引への需要の高まりに伴い、銀行はこれらのプロセスを自動化する必要に迫られました。過去50年間で、銀行は高度な決済処理能力を構築してきました。

決済オーケストレーションプラットフォームの構築には、多くの課題が伴います。新しい決済レールの出現、決済サービスの向上に対する顧客の期待の高まり、そしてより厳格な規制要件により、銀行は決済スタックの複雑化を管理しながら、決済処理の方法をこれまで以上にコントロールしなければならなくなっています。

これらの問題を解決するための第一歩は、銀行のITスタック内における決済オーケストレーションシステムの最適な配置を決定することです。本稿では、一般的なアプローチとその利点および欠点について論じます。

決済は顧客口座からの引き落としや入金を行うものであるため、コアバンキングシステム内に直接決済機能を開発することは理にかなっています。コア内で決済を処理すれば、決済サービスと口座間で直接かつシームレスなアクセスが可能になります。

しかし、このアプローチには大きな欠点があります。決済処理の要件や銀行のスタックが進化・変化するにつれ、決済サービスも適応しなければならず、多くの場合、新しいメッセージタイプ、ルール、プロセス、統合に対応するために大規模な修正が必要となります。
‍

‍

これらの変更はすべて、銀行にとって最も重要かつ機密性の高いシステムであるコアバンキングシステムに実装しなければなりません。さらに、銀行が新しいコアシステムへの移行を決定した場合、これらすべての機能を新しいシステムで再現するという困難な作業に直面することになります。このような変更導入の難しさは、決済機能の停滞を招き、結果として銀行のコントロール能力を低下させる可能性があります。

新たな決済処理要件が登場するにつれ、それらをコアバンキングシステムに直接実装することが常に可能とは限らなくなりました。その結果、銀行はゲートウェイコネクタを通じてこれらの要件を実装する選択を強めるようになりました。これらのコネクタは、決済システムのネットワークへのアクセスを提供し、決済システムとの密接な関連性から、決済ルールやプロセスを処理するための理想的な手段となりました。多くのゲートウェイコネクタは、単なる決済システムへの接続機能を超え、複雑な決済プロセッサへと進化しています。

‍

‍

決済処理をコアシステムからゲートウェイコネクタへ移行することには利点がある一方、同様の課題も生じます。銀行は、統合を希望するすべての決済システムに対して個別のコネクタを実装しなければなりません。各コネクタは多様な銀行サービスと統合し、独自のユーザーインターフェースをサポートする必要があるため、技術スタックが複雑化し、相互運用性の可能性が低下します。

さらに、ゲートウェイコネクタは、メッセージングプロトコル、接続技術、および新たな規制要件の変更に直接さらされます。現在、決済取引の大部分はファイルベースのメッセージングを通じて行われています。しかし、クラウドコンピューティングへの移行が加速するにつれ、最新のAPIへの大幅なシフトが予想されます。このような進化は、銀行の決済処理インフラの大部分に多大な影響を与えるでしょう。

最後に、ゲートウェイコネクタは重要なシステムと見なされており、場合によっては銀行側で冗長性を確保する必要があります。これらのゲートウェイを可能な限り合理化し、オーケストレーションを一元化することで、銀行の負担とリスクの両方を軽減できます。 

‍

コアシステムもゲートウェイも決済処理を管理するための最適なソリューションとは言えないため、専用の中間層が必要となります。コアとゲートウェイの間に配置されるこの層は、さまざまな決済システムのルールや要件を処理するために特別に設計されます。このソリューションは、頻繁な変更からコアシステムを効果的に保護し、ゲートウェイコネクタを接続機能に専念させることができます。 

このソリューションを決済指示のオーケストレーションに集中させることで、決済処理のパターンや機能を一般化し、決済システム固有のコード量を削減するエキスパートシステムへと進化させることが可能になります。 このシナリオでは、銀行は単一の決済オーケストレーション層、つまり「ペイメントハブ」を導入し、すべての決済ニーズに対応することになります。 

‍

‍

ペイメントハブは、多様な決済レールを管理するための最適なソリューションであるように思われます。決済業務を単一のシステムに統合し、銀行の技術スタックを簡素化し、スキーム接続の問題をコアの決済処理タスクから切り離すことができるからです。ペイメントハブの採用は広く普及しており、さまざまなソフトウェアベンダーが複雑さ、範囲、機能の異なる製品を提供しています。

しかし、その利点にもかかわらず、レガシーなペイメントハブは、統一されたプラットフォームというよりは複数のシステムを継ぎ合わせたものであることが多く、重大な課題を抱えています。このような断片化されたアーキテクチャは、単一のシステムに見えても、多様な決済タイプの管理を複雑にします。この継ぎはぎの構成は全体的な複雑さを増大させ、効率的な運用を妨げる可能性があります。

決済処理の要件は非常に多岐にわたります。高額取引には高度な処理と時折の手動介入が必要であり、ファイルベースの手法では数日間にわたる膨大な数の取引を管理しなければなりません。また、即時決済やカード決済では、不正検知やマネーロンダリング対策（AML）システムと連携しながら、厳格なSLA（サービス品質保証）の遵守が求められます。Bacs、STEP2、FedACHなどの類似した大量ファイルベースのシステムを比較しても、多くの共通点がある一方で、明確な違いも存在します。

さらに、銀行の決済処理方法は、顧客の多様なニーズ、現地の規制、技術スタックによる制限を反映して大きく異なります。 

決済エンジンはこれらすべてのバリエーションに同時に対応しなければならず、万能なソリューションを提供しようとするベンダーにとって大きな課題となっています。古いレガシーソリューションでは、通常、複雑なパラメータ設定が必要となり、ベンダー固有の高額なカスタマイズが発生します。時間が経つにつれ、これらのシステムは柔軟性を失い、脆くなり、修正に時間とコストがかかるようになり、実装が不可能になることさえあります。その結果、銀行は決済オーケストレーションに対する制御力を失い、妥協や回避策を余儀なくされることがよくあります。

この状況は銀行を窮地に追い込んでいます。銀行は、決済処理能力を妥協するか、コストのかかる一時しのぎの対策に頼るかの選択を迫られることが頻繁にあります。一部の大手銀行は、自社でペイメントハブを開発するという困難な課題に取り組んできました。しかし、こうしたプロジェクトは高コストでリスクが高く、複雑なシステムの維持・運用という継続的な課題を銀行に負わせることになります。また、銀行の現在のニーズに過度に適応しすぎてしまい、要件が進化するにつれて拡張性が低下するリスクもあります。対照的に、製品企業が設計した優れたペイメントハブであれば、こうした考慮事項を組み込み、時間の経過とともに汎用性を高められるソリューションを構築できるはずです。 

‍

決済レールを単一のソリューションに統合することは、銀行にとって最適な戦略です。しかし、これを効果的に実現するには、単に古いシステムを新しい技術で近代化するだけでは不十分です。銀行には、決済システムの重要なコンポーネントを制御する能力が必要です。つまり、高度な技術的専門知識や貴重なリソース、時間を費やすことなく、決済オーケストレーションのプロセス（手順、順序、外部統合の数、各決済タイプの具体的なビジネスルールなど）を設計できる必要があるのです。

従来のUIベースのルールやフローオーケストレーションツールは第一歩としては有効ですが、限界もあります。理想を言えば、銀行にはシンプルで高水準なプログラミング言語へのアクセスが必要です。この言語は、決済ドメインを理解し、ウェアハウジング、マンデート管理、ルーティングディレクトリといった決済業務に不可欠なサービスとシームレスに統合できる、包括的なSDKによってサポートされるべきです。

もう一つの重要な原則は、各決済ジャーニーをプラットフォームのコアや他の決済ジャーニーから切り離し、独立したフローとして実装することです。このようなアーキテクチャを採用すれば、他のジャーニーに影響を与えたり、コアプラットフォームのアップグレードサイクルに縛られたりすることなく、個々のジャーニーを更新できます。銀行はベンダーに依存することなく、独自の判断で決済ジャーニーを調整したり、新たに開発したりできるべきです。

銀行の決済インフラを近代化するための適切なプラットフォームを選択するのは容易ではありません。選択肢を評価する際、銀行は基本的な要件や既存機能の単純な置き換え以上のものに目を向ける必要があります。今日、銀行にはこれまで以上に決済スタックを詳細に制御することが求められています。適切なシステムを導入することで、銀行は現在および将来のニーズを満たす、適応力が高く、迅速かつ堅牢な決済処理へと移行できるのです。

‍