今日の銀行やフィンテック企業には、競合他社の動向、市場の変化、新たな規制に対し、迅速に適応する能力が求められています。時には数日、あるいは数時間という短期間での対応が必要です。
例えば、調達コストの上昇に合わせてローン商品の金利を調整したり、住宅ローンの支払い猶予を提供したり、クレジットカードの利用条件を即座に変更したりする必要が生じる場合があります。
市場環境や顧客ニーズが急速に変化する中、銀行の意思決定者は「いかにして高品質な製品を迅速に提供し、かつコストと時間の効率化を実現するか」という難題に直面しています。
クローズドボックス型システム：製品イノベーションを阻む壁
現在、多くの銀行がクローズドボックス型のレガシーシステムを利用しています。クローズドボックス型システムとは、基盤となる製品コードがベンダーによってロックされており、銀行側で製品機能を定義できないシステムを指します。一部のシステムでは限定的な設定パラメータが提供されていますが、基本的には柔軟性に欠け、市場の変化に対応することができません。
こうしたシステムは、電話や窓口での取引が主流で、当座預金、普通預金、クレジットカードといった基本的な商品だけで十分だった時代の名残です。クローズドボックス型システムでは、あらかじめ用意されたパラメータの範囲内でしか操作できないため、革新的でパーソナライズされた製品を構築することは不可能です。
クローズドボックス型システムは現代の顧客ニーズに適しておらず、以下のような点で製品イノベーションを制限しています。
- 手動による変更：レガシーなクローズドボックス型システムを利用している銀行では、製品や口座の設定を自動で一括変更することが困難です。金利や手数料の変更など、多数の口座にまたがる条件変更を行う場合、ベンダーに依頼して手動で対応してもらう必要があり、多大なコストと時間がかかります。実際、新たな規制への対応が間に合わず、製品ライン全体を廃止せざるを得なくなった銀行の事例もあります。
- ベンダーへの依存：レガシーソフトウェアのベンダーは通常、ソフトウェアの全コードベースを管理し、限られた機能のオン・オフを切り替えるスイッチを提供するのみです。コアシステムや製品システム（クレジットカード、預金、ローンなど）の管理はすべてベンダーに依存しており、銀行側は基盤となるコードにアクセスできないため、既存製品の変更や新規製品の設定を自力で行うことができません。
- サービスの信頼性：レガシーシステムでは、多くのサービスが密結合しており、相互に依存しています。そのため、システムの一部にわずかな変更を加えるだけでも（定期的なメンテナンスであれ、突発的な対応であれ）、サービス全体、あるいは広範囲にわたって影響が及ぶ可能性があります。
スマートコントラクト：銀行が自由な製品設計を可能にする「真っ白なキャンバス」
Vault Coreは、オープンボックス型のシステムという点で一線を画しています。私たちは「ユニバーサル・プロダクト・エンジン」を通じて、銀行がどのような金融商品でも自由に構築できるようにしています。このエンジンには、構築済みの金融商品ライブラリ、包括的なドキュメント、開発ツール、そして製品開発フレームワークである「スマートコントラクト」が備わっています。
スマートコントラクトを活用すれば、銀行は独自のロジックを記述し、シンプルなインターフェースを使ってゼロから製品を構築できます。銀行は迅速に製品を開発し、Thought Machineに依存することなく一括で変更を加えることが可能です。しかも、プラットフォームの重要なコードに触れるリスクは一切ありません。スマートコントラクトが製品イノベーションを促進する理由は以下の通りです。
- コントロール：Vault Coreの設定レイヤーはプラットフォームレイヤーから分離されているため、共通プラットフォームのコードをフォークすることなく、製品の変更が可能です。スマートコントラクトを使えば、銀行は独自の製品ロジックを定義し、Thought Machineに依存することなく製品の更新、複製、修正を行うことができます。
- 製品非依存：Vault Coreのプロダクトエンジンは、定義上「ユニバーサル（汎用的）」です。実行される製品の内容を問わず、また製品によって影響を受けることもありません。この意図的な設計により、クライアントはどのような構成であっても、望む製品を自由に構築することができます。
- プロダクトライブラリ：すべてのクライアントは、当座預金、普通預金、クレジット口座から、多通貨ウォレット、シャリア準拠商品まで、あらかじめ作成されたスマートコントラクトを含むグローバルなプロダクトライブラリにアクセスできます。これらはローンチ前にカスタマイズすることも、Pythonコードを使用してゼロから革新的なプロダクトを作成することも可能です。
- 機能レベルの構成可能性：クローズドボックス型のシステムとは異なり、銀行は各スマートコントラクトのパラメータを機能レベルで定義できるため、プロダクトのカスタマイズがこれまで以上に迅速に行えます。通貨、基準金利、利率、決済手数料、融資条件などはすべて、銀行がスマートコントラクト内で簡単に定義・変更できるパラメータです。
- クラス最高水準のツール：銀行は、エンドツーエンドのドキュメントとスマートコントラクト用ソフトウェア開発キット（SDK）を利用できます。これらのツールにより、銀行はスマートコントラクトの挙動をシミュレーションし、すべてのプロダクトがローンチ前に十分にテストされ、適切に設計され、高いパフォーマンスを発揮することを確認できます。
では、これは実際には何を意味するのでしょうか。
当社のクライアントであるTrust Bankの例を見てみましょう。
Trustは、構築済みのスマートコントラクトを活用してプロダクトの提供を加速させました。同銀行は、構築済みのスマートコントラクトを設定・開発することで、クレジットカード、普通預金口座、家族向け傷害保険を含む包括的な初期プロダクトセットをローンチしました。ローンチ後、Trustは顧客からのフィードバックに基づき、わずか数日でプロダクトのパラメータを調整し、新機能を追加しました。
クローズドボックス型のシステムを使用する銀行は、定義済みのプロダクトを修正する際にベンダーに依存せざるを得ません。レガシーシステムでは、プロダクトの開発に数ヶ月、あるいは数年かかることもあります。一方、TrustはThought Machineに依存することなく、はるかに速いペースでイノベーションを実現できました。
その一方で、銀行が革新的な金融商品をゼロから構築しようとするケースもあります。例えば、当社のクライアントであるC6 Bankは、計算エンジンを使用して顧客のクレジット、デビット、小切手口座の取引を監視するカーボンオフセット口座の導入を検討しました。このエンジンは、CO2排出量やそれに準ずる指標に関連して取引を監視・測定するものです。
これはすべてスマートコントラクトによって実現可能となりました。C6 BankはPythonコードのサブセットを使用して、このプロダクトをゼロから構築することができました。C6はプロダクトのロジックを定義し、CO2エンジンと提携することで、この革新的なプロダクトをローンチしました。
クローズドボックス型のシステムであれば、銀行はベンダーに新しいプロダクトの開発を依頼する必要があり、多大なコストと時間がかかっていたでしょう。また、そのプロダクトはクレジットやデビットなどの他の口座から切り離された状態となり、結果として顧客体験は低下していたはずです。銀行はベンダーに依存することなく、革新的な機能強化をプロダクトに反映させることもできませんでした。
レガシーテクノロジーの世界からの脱却
銀行テクノロジーの世界では、クローズドボックス型のシステムが主流です。これらは、銀行がわずかなプロダクト調整を行うためのローコードまたはノーコードのインターフェースを提供しますが、プロダクト構成とコア業務が密接に結びついています。このような不透明さと柔軟性の欠如は、銀行の顧客が日々より多くのことを要求し、期待する現代の世界では通用しません。
オープンボックス型の最新テクノロジーにより、銀行業務はより良い方向へと変わります。銀行は、どのように機能を構築するかを悩む必要はもうありません。ただ、構築すればよいのです。
