勘定系基幹システムの進化ーここまでとこれから | Kyndryl

 Niloy Sengupta著

勘定系基幹システムに派手な広告キャンペーンは向いていません。

これらはしばしばレガシーテクノロジーと表現され、日々の取引や口座更新などを処理するミッションクリティカルなアプリケーションです。銀行の価値は利便性と安全性の確約にありますが、その重大な任務を担っているのは基幹システムなのです。

銀行の経営層がモダナイゼーションを目指す際にも、こうした基幹システムは障壁となりやすいです。

銀行業務のデジタル変革が話題になっている昨今、基幹システムがいかに経営層の悩みの種になっていったかを思い出すことは重要です。この記事では、銀行にとって最も重要なアプリケーションのモダナイゼーションを成功させるにはどうすればよいかを前向きに考えるために、過去を振り返ります。

勘定系基幹システムの誕生

最も初期の勘定系基幹システムが1980年代に登場したことで、それまで何世紀も続いてきた手書きの日誌や帳簿から銀行は脱却することができました。

大量の取引を迅速に、確実に、かつ効率的に管理する必要性を受けて、集中化、スピード、スケール、信頼性を提供する第1世代の勘定系システム  1  が成立しました。これらのシステムはCOBOL、Assembler、PL/I、およびJCL言語で書かれ、顧客、取引、製品と閉じた関係にあるモノリシックな構造でした。

これらのアプリケーションは、バッチ処理のみをサポートし、取引の記帳は一日の終わりに行われました。記帳などの回避策を講じることで、日中の残高確認が利用可能になっていました。このようなアプリケーションでは、ビジネスロジックとデータアクセスロジックが強く絡み合っており、それらを分離することは困難です。2

第2世代の勘定系基幹システム

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

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

1990年代におけるインターネットの普及は、窓口係や支店銀行、オンラインバンキングのアプリケーションの成長を促進しました。 一方で、勘定系基幹システムのアプリケーションへの投資は大幅に減少し、フロントエンドシステムと基幹システム間の統合に関する課題が急速に浮上しました。

こうした制約に対処するため、銀行はサービス指向およびメッセージ駆動型のミドルウェアアプリケーションを構築または購入しました。これらのアプリケーションは、フロントエンドとバックエンドのアプリケーション間での統合をよりシンプルにしました。IFX、FIX、FpMLなどの業界フレームワークは、金融機関間の標準化と相互運用性の提供を試みました。

第3世代の勘定系基幹システム

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

専門的なソリューションを提供するフィンテック企業が増える中、銀行は顧客体験を向上させるために、それらの企業と提携してシステムの統合を進める必要が出てきました。APIとクラウドは、第1世代および第2世代の勘定系基幹システムに対するさらなる変化を推し進めたのです。

歴史が長い銀行は、ソフトウェアを最新バージョンで維持する「cap currency」の意味がなくなるまで、レガシーシステムを運用し続けました。そこに商機を感じたプラットフォームベンダーは、新しいアーキテクチャーのパターンと第2世代の勘定系基幹システムにおけるプラットフォームからのリファクタリングの組み合わせを通じて、クラウド向けにプラットフォームを再設計し始めました。4

これら第3世代の基幹アプリケーションの大部分は、マイクロサービスとして構築されています。コンテナ化され、単一または複数のパブリッククラウド環境で実行でき、リアルタイムのトランザクション処理を提供するように設計されています。マイクロサービスを動かすアーキテクチャーは、顧客および口座管理、トランザクション処理、明細書、およびレポートなどのビジネス機能を切り離します。

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

次世代のコンポーザブルな勘定系基幹システム

ここ数年、いくつかの新しい勘定系基幹システムベンダーが市場に参入しました。彼らは第3世代と多くの類似点を持つ次世代の基幹システムアプリケーションを提供しています。しかし、いくつかの注目すべき相違点があるのも事実です。次世代の基幹システムは真にクラウドネイティブであり、リファクタリングされたコードを一切使用せず、マイクロサービスを使用してゼロから構築されています。6

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

一部のベンダーは、クラウド向けに構築された製品、価格設定、請求エンジン、および顧客対応アプリケーションなど、特定の用途向けのポイントソリューションを提供しています。これらのアプリケーションは、通常、勘定系基幹システム全体を完全に置き換えることはありませんが、他のクラウドベースのシステムと連携することを想定しており、コンポーザブルな基幹エコシステムとして重要な一部となることがあります。8

こうした最新の勘定系基幹システムの進歩により、銀行は急速なイノベーションを実現し、新しいアプリケーションや移行パターンを試せるようになりました。
 

最新の基幹システムに向かういくつかの方法

レガシーな基幹システムは、大量のトランザクションを効率的かつ高い信頼性で処理するように設計されています。新時代のシステムは機敏かつ柔軟で、ビジネスにおける多くのメリットを提供するものの、この面に関しては旧世代のシステムに遅れをとっています。これが、レガシーシステムが今日まで使われ続けてきた大きな理由です。かつては、勘定系システムのモダナイゼーションはハイリスクかつハイコストな取り組みで、大規模なリプレースを行うしか選択肢はありませんでした。

しかし今日では、リスクやコスト、そして労力を最適化するための基幹システムモダナイゼーションの方法が複数存在します。例えば銀行では、以下のような反復的かつ着実なモダナイゼーションへのアプローチを採用できます。

• クラウドネイティブ基幹システム： デジタル専用チャネルなど、より単純なサービス用にクラウドネイティブ基幹システムを設定し、アプリケーションを着実に拡張して、他のサービスを徐々にレガシーシステムから移行します。
• 移行アプローチ： クラウドネイティブ基幹システムの派生であり、銀行は移行実施前に貯金口座や定期預金といったシンプルな情報を移行できます。また、銀行は地理的または購買行動に則って顧客セグメントを新しいシステムに移行し、その後反復することも可能です。
• レガシー基幹システムの分離： 商品・価格管理、顧客管理、明細書、文書管理などのビジネス機能を切り離します。これにより、基幹システムはシンプルな台帳となり、銀行はその取り除かれたモジュールを置き換えるためのマイクロサービスを構築または購入できるようになります。
• ハイブリッドアプローチ： オンプレミスのメインフレームベースのシステムをzCloud環境に移行することで、メインフレームとクラウドの利点を組み合わせられます。この移行は暫定的な処置としても最終的な解決策としても有効です。これにより、銀行はクラウドのメリットを損なわずに、メインフレームからの移行をある程度柔軟に決定できるようになります。

銀行がどのような方法を採用するにせよ、勘定系基幹システムのモダナイゼーションを単なるテクノロジー変革として扱ってはなりません。特にビジネスプロセスの再設計と従業員の変更管理を含む運用モデルのアップデートは、テクノロジーの変化を受け入れるにあたって非常に重要な役割を果たします。
 

勘定系基幹システムの進化は続く

勘定系基幹システムの進化は、過去のシステムがなぜその時々のビジネスニーズに応じるために設計・構築されたか、そしてどうやってそれらが構築されたかをよく表しています。ビジネスニーズは進化します。それを理解することは、これからのシステムをどのように変えていくべきかを推し量るために非常に重要です。過去の失敗から学ぶことで、将来のイノベーションの機会を得られます。

Niloy Senguptaは、キンドリルの金融サービス・コンサルティング・パートナーです。

¹米国における第1世代の勘定系基幹システムの例：Systematics (FIS)、Hogan (DXC)、Trisyn

²例: Hoganでのプロセス制御データの使用

³例：Profile（FIS）、DNAおよびPremier（Fiserv）、Silverlake、CoreDirector、CIF 20/20（Jack 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、インフォシス、テメノスなどは、APIを通じて自社の基幹システムと相互運用可能であることが認定されたサードパーティ製アプリケーションをマーケットプレイス方式で提供しています。

⁷これらのコアベンダーは、互換性が認定され、ISO 20022やBIANなどのオープンバンキング業界のフレームワークに準拠するサードパーティアプリケーションの大規模なマーケットプレイスも有しています。

⁸これらのアプリケーションの中には、Zafin、SunTec、またはOracle RMBなどが提供する製品、価格、請求エンジンが含まれています。Savanaなどの顧客対応とオンボーディングアプリケーションもこのカテゴリーの一部です。