昨今の急激なデジタルトランスフォーメーション（DX）は、金融サービスの担い手である銀行、金融サービスの受け手である消費者、そして両者が交わる場である銀行システムのあり方に大きな影響を与えています。本稿では、日本におけるこれまでの銀行システムの変遷を振り返りながら、これからの銀行システムが顧客ニーズの変化に応え、競合に対抗するために求められるシステム要件及びNECにおける取り組みについて説明します。

1. はじめに

海外の銀行業界では、顧客ニーズの変化に応え、競合に対抗するため、FinTech企業や非金融事業者などの外部事業者と銀行との連携を促進するオープンバンク化が進展しています。オープンバンク化の流れのもとで、オープンAPIを前提としてさまざまなFinTechサービスなどを組み合わせる形態によるネオバンクやIT大手など、デジタル・ネイティブの競合相手の台頭や既存銀行によるセカンドブランドの設立が相次いでいます。

日本国内の銀行業界においても、従来の金融サービスモデル、あるいはサービス提供の主体は大きく変わりつつあり、既存の銀行においては、新しいサービスへの迅速な対応・提供ニーズが増加しています。また非金融機関においては、銀行機能の利用ニーズが増加するなど、デジタルトランスフォーメーション（DX）により銀行システムを取り巻く外部環境が大きく変容している状況にあります。

これらの銀行サービスに対する新たなニーズに応えるため、NECの技術力を駆使して外部環境の変容に対応可能なバンキングシステムの実現に向けたBanking as a Service（BaaS）への取り組みを加速しています。本稿では、これまでの銀行システムの発展の歴史を振り返りながら、変化する顧客ニーズに対応するBaaSに求められるシステム要件を説明します。

2. 銀行システムの変遷

本章では、これまでの銀行システムの変遷について順を追って説明します。

2.1 第1次オンラインシステム

1965年に稼働した三井銀行（現、三井住友銀行）の普通預金オンラインシステムが、日本最初の銀行オンラインシステムとされています。それまでの銀行システムは、主に「パンチカード」システムによるオフラインシステムでした。パンチカードを事務センターに集めて集中管理して、事務の効率化を図っていました。それがオンラインになり、元帳の更新が数十秒で完了するようになり、業務の処理効率が飛躍的に向上しました。

この世代のオンラインシステムの特徴は、「普通預金オンライン」「融資オンライン」といった単科目のオンラインシステムでした。オンライン化の直接的な目的は、個々の業務における事務処理の効率化・省力化でした。

2.2 第2次オンラインシステム

1970年代前半に、名寄せした顧客情報に基づき複数の商品の契約情報を結び付け、顧客情報の一元管理ができるシステムで複数科目を同時に処理する「総合オンラインシステム」が構築されました。更にこの世代のオンラインシステムを特徴付けるものに、振込・引落の一括処理の開始があります。この処理は、「センターカット」などと呼ばれています。振込・引落データを磁気テープで取引先から提供してもらい、処理終了後に結果を返す口座振替業務が開始・普及し始めたのも、この世代です。

また、CD/ATMの相互利用のための金融機関相互ネットワーク構築がこの時期から始まりました。この頃は、まだ都市銀行上位行・下位行、地方銀行などと業態によってネットワークが分断されてはいましたが、銀行利用者の利便性が向上しました。

2.3 第3次オンライン

1980年代後半から1990年代前半の金融自由化に伴う新商品の相次ぐ開発や、地方銀行のサービス時間の延長などをはじめとする、システムに対する要求（柔軟性や拡張性）が厳しさを増しました。そのため、既存のオンラインシステムの手直しだけでは、ITの技術革新に追い付かないことが明らかであったため、多くの銀行では、システムの仕組みを抜本的に見直し、柔軟性や拡張性を備えた新規システムを構築しました。10年ごとにシステムを全面的に刷新してきた銀行業界ですが、第3次オンラインシステムの完成によって、オンラインシステムは一応の完成を見せました。

2.4 「ハブアンドスポーク」アーキテクチャ

2000年代前半にいくつかの銀行で採用されたものに「ハブアンドスポーク」アーキテクチャがあります。個々のサブシステムのアプリケーション連携に必要なメッセージ交換を「ハブ」と呼ばれるサブシステム経由で行う方式です。個々のサブシステムを別のシステムに入れ替えたり、新たな業務を追加したりすることが、ハブシステムで吸収できるため、他のサブシステムへの影響が少なくなるというメリットがあります。

2.5 インターネット化

1990年代後半以降のインターネットの普及に伴い、オンライン化されていた銀行業務は、その後2000年代後半にかけてインターネットで利用可能になっていきました。住友銀行（現、三井住友銀行）が1997年1月にサービスを開始し、6月にはあさひ銀行（現、りそな銀行）が、翌1998年には三和銀行（現、三菱UFJ銀行）、さくら銀行（現、三井住友銀行）、富士銀行（現、みずほ銀行）が追随しました。当初は、残高照会などの資金移動を伴わないサービスのみの銀行もありましたが、順次サービスの拡充が進められ、投資信託の購入や外貨預金取引などもできるまで発展し、銀行店舗に行かなくてもほぼすべての取引ができるようになりました。

2.6 オープン化

2000年以降、いくつかの地方銀行・第二地方銀行の勘定系システムは、ハードウェア及びソフトウェアの初期費用の軽減と開発サイクルの短縮を目的に、従来のメインフレームからオープン系システムへと移行しています。独自開発ではなく、共同システムとしてオープン系システムを採用する例が多く、2003年にNECが世界で初めてUNIX環境で勘定系オンラインシステムを稼働しました。その後、2007年にはWindows Server上で稼働するシステムも登場しました。

3. これからの銀行システム

これまでの銀行システムは、安定性・堅牢性・不変性といった観点からオンプレミス環境で構築され、変化に対応する要素は個々のサブシステムとして構築されてきました。しかし、こうした既存の銀行システムのあり方では、もはやビジネス環境の急速な変化に対応することができません。デジタル時代に求められる銀行システム要件は、次の3点であると考えます^1）2）。

3.1 オープンAPIによる外部サービスとの連携性の向上

従来、銀行システムはクローズドなインタフェースでシステム間連携を行っていましたが、最近の銀行では、オープンAPIを用いて、外部企業との協業や、銀行機能・データの開放による新たな収益源を確保する事例が増加しています。外部システムと連携するシステムレイヤにAPIゲートウェイを構築し、銀行機能・データをAPI化することで、既存アプリケーションの構造を大きく変更することなく、外部企業や消費者に、APIを通じて銀行機能や銀行内の価値あるデータを公開することが可能になります。これにより銀行は、外部企業との広汎なエコシステム形成できます。

システム間連携を行うためのインタフェースでデファクトスタンダードとなったのは、Web技術を用いたAPIであるWeb APIです。APIでの一般的な形式は、アクセス対象の資源をURI（Uniform Resource Identifier）で表現し、資源に対する操作をHTTPのメソッドで要求すると、資源の状態が応答するものです。このアーキテクチャスタイルは、「REST（Representational State Transfer）」と呼ばれます。応答形式は、JSON（JavaScript Object Notation）が一般的に利用されています。また、APIの要求と応答の仕様記述の方法は、OpenAPI Specificationで標準化が図られています。このようなオープンな標準に基づくインタフェースを銀行システムが持つことによって、多様なシステムとの連携が容易になります。

3.2 マイクロサービスによるビジネス環境の変化への追従

銀行勘定系システムを継続活用することは、安定稼働や投資保護の観点から有効な手段と考えます。デジタル時代においては、銀行勘定系システムを「柔軟にチャネルや業務の追加ができるような再利用性の高いサービス」へと進化させる必要があります。そのため、階層構造の定義と機能配置を見直すとともに、各階層間連携の標準化を図ることで、疎結合型のアーキテクチャが望ましいと考えられます。この疎結合型のアーキテクチャを実現する技術が、マイクロサービスです。

銀行のビジネス戦略上、他社との差別化が必要な業務は、アプリケーションとして変化対応力が求められています。既存のアプリケーションに対して、マイクロサービスを採用したモダナイゼーションに取り組むことにより、俊敏性や柔軟性をより高めたアプリケーションの再構築が可能になります。これにより銀行は、新たなサービスや事業を迅速に立ち上げられます。

しかしながら、マイクロサービスなどの分散システムにおけるデータ整合性担保には課題があるため、それらを解決する構成が必要となります。銀行勘定系システムは複数のサービスをまたいでお金の動きを正確に管理する必要があり、データ整合性の観点からもトランザクション管理が最も重要な課題となります。この点を踏まえ、トランザクション（サービスの呼出し）のコントロールを重視し、オーケストレーションによる構成を採用する必要があると考えます。

3.3 クラウドによる柔軟なスケール

クラウドは当初、セキュリティに関する不安から銀行による利用は進みませんでした。しかし、近年はセキュリティ技術も向上し、銀行においてもシステム構築手段の1つとなっています。またオープンAPIを用いた銀行サービスの公開により、銀行システム上の取引量が今後増加することが考えられます。取引量の増大に対してオンプレミス環境でシステムリソースを事前に増強することでも対応可能ですが、多大なシステム構築費用と時間が必要です。クラウドを利用することにより、銀行は、システムリソースを必要なときに短時間で調達でき、ビジネスアイデアが具体化され、顧客にサービス提供されるまでに必要なコストや時間を削減できると期待されています。

NECは、技術力を駆使してこれら3つのシステム要件を具備し、外部環境の変容に対応可能なバンキングシステムを実現するBaaSに取り組んでいます。

4. むすび

本稿では、これまでの銀行システムの発展の歴史を振り返りながら、変化する顧客ニーズに対応するBaaSに求められるシステム要件を説明してきました。

今後、 テクノロジーの進歩に伴いデジタルトランスフォーメーションが更に進化し、銀行システム自体のあり方も変化している可能性があります。5年後、10年後の新たな銀行システムに備えるためにも、「銀行システムとは何か」を今一度問い直し続け、今後もNECの技術力を駆使して、外部環境の変容に対応可能なバンキングシステムの実現に向けたBaaSへの取り組みを継続します。

参考文献

執筆者プロフィール