基幹銀行プラットフォームの進化：ここまでの経緯次のステップは？

執筆：ニロイ・セングプタ

基幹銀行システムでは、派手な広告キャンペーンは行いません。

レガシーテクノロジーと呼ばれることが多いこれらのシステムは、日々の取引や口座の更新などを処理するミッションクリティカルなアプリケーションです。銀行は利便性と財務上の安全を約束して顧客の注意を惹いていますが、大変な作業を行っているのが基幹システムです。

これらの基幹システムはまた、銀行幹部がモダナイゼーションを図る際に障壁となりがちです。

昨今、銀行業界の変革が話題にのぼる中で、基幹システムが経営陣の不和の種となった事例が思い起こされます。この記事では、銀行が最も重要なアプリケーションのモダナイゼーションを成功させる方法を前向きに考えるために、過去を振り返ってみたいと思います。

基幹銀行システムの誕生

最も初期の基幹銀行システムが1980年代に登場すると、銀行は何世紀にもわたって行われてきた手書きの仕訳帳や台帳から脱却しました。

銀行は、大量の取引を迅速、確実、効率的に管理する機能を必要としていました。こうして第1世代の基幹銀行システム¹ が進化したことで、一元化、スピード、規模の拡大、信頼性がもたらされました。COBOL、Assembler、PL/I、JCL言語で書かれたこれらのシステムはモノリシックで、顧客、トランザクション、製品などの基本的な相互に依存するビジネスモジュールが緊密に結びついていました。

これらのアプリケーションではバッチ処理のみがサポートされ、転記は1日の終わりに行われていました。メモ転記などの回避策により、日中の残高を利用できるようにすることも可能でした。こうしたアプリケーションでは、ビジネスロジックとデータアクセスロジックが強固に絡み合っており² 、この2つを分離することは困難でした。

第2世代の基幹銀行システム

1980年代後半から1990年代前半にかけて、第2世代の基幹銀行システムは市場を地方銀行や小規模の銀行にまで拡大しました。新しい基幹銀行システムでは、より低コストのN層アーキテクチャーが導入され、リアルタイムでの処理がサポートされ、フロントエンドのビジネスロジックを中間層のビジネスロジックおよびデータアクセスロジックから分離できるようになりました。

これらのアプリケーションは通常、製品中心のアーキテクチャーであるため、製品の構築と構成が容易になり、複数の統合方法が採用されました。アプリケーションがよりシンプルで、よりパラメーター主導で設計されるようになったことから、銀行は市場投入までの期間を短縮して新しい製品、機能、価格設定を展開できるようになりました。 ³

1990年代にはインターネットの台頭により、窓口、支店銀行業務、オンラインバンキングのアプリケーションの成長に拍車がかかりました。基幹業務アプリケーションへの投資は大幅に減速し、すぐにフロントエンドシステムと基幹システムの間の統合の問題が表面化しました。

このような制約を克服するために、銀行は、サービス指向でメッセージ駆動型のミドルウェアアプリケーションを構築または購入して、フロントエンドアプリケーションとバックエンドアプリケーションをより簡単な疎結合で統合できるようにしました。IFX、FIX、FpMLなどの業界フレームワークにより、機関を横断した標準化や相互運用性の提供が試されました。

第3世代の基幹銀行システム

2010 年代、銀行はクラウド技術を使用したデジタルバンキングの導入を加速化させました。REST APIやJSONが、データ交換と統合のための一般的な技術になりました。

顧客体験を向上させる、ニッチなポイントソリューションを提供するフィンテック企業の数が増えるにつれ、銀行はフィンテック企業と提携して統合を図らなくてはならないとプレッシャーを感じるようになりました。APIとクラウドが、第1世代と第2世代の基幹銀行システムにさらなる変化を促す原動力となったのです。

従来の銀行では、ソフトウェアを最新バージョンに維持する習慣ではもはや現実的に対処できなくなるまで、レガシー基幹システムをカスタマイズして利用していました。新たなチャンスを捉えたプラットフォームベンダーは、新しいアーキテクチャーパターンと第2世代の基幹業務プラットフォーム再設計を組み合わせて、クラウド向けにプラットフォームの再設計を開始しました。⁴

これら第3世代の基幹業務アプリのほとんどは、マイクロサービスとして構築されています。コンテナ化されており、1つ以上のパブリッククラウド環境で実行でき、リアルタイムのトランザクション処理が行えるよう設計されています。マイクロサービス主導のアーキテクチャーにより、顧客とアカウントの管理、トランザクション処理、明細書、レポート作成などのビジネス機能は切り離されています。

APIは当然ながら、こうした新しい基幹システムの統合方法として好ましいもので、ほとんどのベンダーは、社内および一部のサードパーティーアプリケーションとの事前統合を提供する独自のパッケージ化されたAPIゲートウェイアプリケーションも提供して、顧客のオンボーディング、顧客サービス、資金の移動、カード管理、その他の不随するサービスなど、幅広い銀行サービスをサポートしています。⁵

次世代のコンポーザブル基幹銀行システム

過去数年で、いくつかの新しい基幹システムのベンダーが市場に参入しました。こうしたベンダーは、第3世代の基幹システムと設計面で多くの類似点を備えた次世代の基幹業務アプリケーションを提供していますが、いくつか顕著な違いもあります。次世代の基幹システムは完全にクラウドネイティブで、再設計されたコードを一切使用せずにマイクロサービスを使用してゼロから構築されています。⁶

これらのアプリケーションの中には、GolangやRUSTなどの最先端のプログラミング言語を使用し、PostgreSQLのような新しいデータベースを採用しているものもあります。さらに、一連の「ヘッドレス」APIとして提供されているため、銀行を複数のベンダーに限定しなくても、柔軟な統合を選択できるようになります。こうした設計パターンにより、アーキテクチャーのキャンバスが開放されて、銀行は古い基幹システムから完全に移行しなくても、既存の基幹システムと並行して柔軟に試せるようになることから、基幹システムは「コンポーザブル」なものとなります。⁷。

いくつかのベンダーが、製品、価格設定、請求書作成エンジン、クラウド用に構築された顧客サービスアプリケーションといったニッチなポイントソリューションを提供しています。これらのアプリケーションは、基幹銀行システム全体を置き換えるわけではありませんが、その他のクラウドベースの基幹システムと連携して動作することを意図したもので、コンポーザブル基幹エコシステムの不可欠な部分になる可能性があります。⁸

基幹銀行システムにおけるこうした最近の進歩により、銀行は新しいアプリケーションスタックと移行パターンを試すことができ、急速なイノベーションが可能になっています。

最新の基幹システムにつながる複数の方法

旧世代の基幹システムは、大量のトランザクションを効率的かつ確実に処理できるように設計されていました。新時代のシステムは機敏で柔軟性があり、多くのビジネス上の利点を提供しますが、この点では依然として旧システムに遅れをとっています。これこそが、レガシーの基幹システムがこれほど持ちこたえている最大の理由です。これまで、1度にすべてを新しいものに置き換えるのが唯一の選択肢であったため、基幹銀行業務のモダナイゼーションはハイリスクで高コストの取り組みでした。

現在では、リスク、コスト、労力を最適化できる基幹システムのモダナイゼーションの方法は複数あります。銀行は、反復可能で着実に進歩するモダナイゼーションのアプローチに従うことができます。例としては次のようなものがあります。

• クラウドネイティブの基幹システム：デジタル専用チャネルなど、より単純なサービスライン向けにクラウドネイティブの基幹システムをセットアップし、これらのアプリケーションを着実に拡張して、他のサービスラインをレガシーの基幹システムから徐々に移行します。
• 移行的アプローチ：クラウドネイティブの基幹システムの亜種ですが、ここでは銀行は、当座預金口座や融資を移行する前に、普通預金口座や譲渡性預金などのよりシンプルな商品ラインを新しい基幹システムに移行することを検討できます。あるいは、地理や購買行動に基づいていくつかの顧客セグメントを新しい基幹システムに移動し、その後、繰り返すこともできます。
• 従来の基幹システムを空洞化する：製品および価格管理、顧客管理、明細書、文書管理などのビジネス機能を基幹システムから外します。このアプローチでは、基幹業務を単純な取引台帳にまで縮小するので、銀行は空洞化されたモジュールを置き換えるマイクロサービスを構築または購入できるようになります。
• ハイブリッドアプローチ：オンプレミスのメインフレームベースの基幹システムをzCloud環境に移行することで、メインフレームとクラウドの利点を組み合わせます。この移行は、暫定的なものであったり、目標とする状態の解決策として機能したりします。このアプローチにより、銀行はクラウドの利点を損なうことなく、メインフレームからの移行を柔軟に決定できます。

銀行がどの方法を採用するにせよ、基幹銀行業務の最新化を単なるテクノロジー変革の取り組みとして扱ってはなりません。運用モデルの変更、特に業務プロセスの再設計と従業員の変更管理は、技術の変更を補完するものでなくてはなりません。

基幹銀行システムの進化は続く

基幹銀行システムの進化を見ると、これらのシステムが過去のビジネスニーズを満たすために設計、構築されきた理由とその経緯がよく分かります。ビジネスニーズが変化する中、その変化を理解することで、これらシステムをどう変えていけばいいのか、その軌跡をたどって指針を得ることができます。過去の失敗から学ぶことで、将来の革新に向けて新たな機会を特定できるのです。

ニロイ・セングプタはキンドリルの金融サービス・コンサルティング・パートナーです

¹米国の第1世代の基幹銀行システムの例：Systematics（FIS）、Hogan（DXC）、Trisyn
²例：Hoganでのプロセス制御データの利用
³例が多数：Profile（FIS）、DNAとPremier（Fiserv）、Silverlake、CoreDirector、CIF 20/20（ack Henry）、Bancs（TCS）、Finacle（Infosys）、Flexcube（Oracle）、T24（Temenos）など。
⁴過去のものから再設計されたコードはない。これにより、FinxactのGoLangのような次世代プログラミング言語としての使用など、いくつかの革新が可能になった。
⁵FISはModern Banking Platform (MBP) を導入し、TemenosはT24をTransactに変換した。Fiserv、Jack Henry、Infosys、TCS、Oracle、Finastraはいずれも、人気のある基幹業務アプリケーションのクラウドバージョンを開発した。
⁶このような統合には2種類の方法がある。FIS、Fiserv、Oracleなどは、自社の製品ポートフォリオからアプリを事前に統合し、顧客を可能な限り自社のエコシステムに固定しようとしている。一方、TCS、Infosys、Temenosなどはマーケットプレイスアプローチをとっており、APIを介して基幹システムと相互運用が可能だと認められた複数のサードパーティーアプリを提供している。
⁷これら基幹システムのベンダーは、相互運用性の認定を受け、ISO 20022やBIANなどのオープンバンキング業界のフレームワークに準拠した、サードパーティーアプリの大規模なマーケットプレイスも持っている。
⁸これらのアプリケーションの一部は、Zafin、SunTec、またはOracle RMBが提供する製品、価格設定、および請求書作成エンジンである。Savanaなどの顧客サービスおよびオンボーディングアプリケーションも、このカテゴリに含まれる。