ここからは、銀行業務におけるブロックチェーンの活用について解説します。
前章で述べたように、スマートコントラクト型のブロックチェーンであれば、比較的どのような業務でも活用できると考えられます。しかし、やはりブロックチェーンは、複数の銀行や企業間で連携されている業務形態、例えば国際送金やトレードファイナンスなどが適していると考えられます。ブロックチェーンは、複数の参加者間でのビジネスプロセスの簡素化、迅速化、自動化などを実現し、可監査性やトレーサビリティーの向上が見込めるからです。
また、複数の銀行や企業間でブロックチェーンを活用した新しい業務形態が創出されることも期待されます。
連載第3回で利用した銀行システム全体の図を利用して、各業務エリアのブロックチェーンの活用イメージを記載します。ここでは、ブロックチェーンで“実現できる”のではなく、ブロックチェーンに“適した”業務が位置付けされる代表的なエリアを記載しています(図7)。
【1】FinTechエリア
FinTech企業がブロックチェーンを活用しているケースです。現時点では、Bitcoinの仮想通貨や、Rippleの内部通貨を利用した国際送金サービスなどデジタル通貨が主な活用形態となっています。今後、他の活用形態や銀行自体が提供するデジタル通貨などのFinTechアプリケーションも徐々に増えていくと予想されます。
【2】対外系エリア
対外系エリアでの活用ケースでは、大きく分けて以下の3つに分類できると考えます(図8)。
(1)銀行と複数の取引先とでブロックチェーンネットワークを構成し、ビジネスプロセスを実現するケース
例えば、銀行と複数のサプライヤー間でブロックチェーンを活用するケースです。これにより、契約、発注、納品、支払いに関するプロセスの簡素化、迅速化、可視化、作業コスト削減を実現することが期待されます。銀行からの発注、支払いに連動してサプライチェーンに対して自動発注、自動支払いするといったことも可能になると考えられます。
(2)複数の銀行間でブロックチェーンネットワークを構成し、銀行間取引を実現するケース
例えば、手形、債権、小切手、シンジケートローンなどの銀行間の取引で、ブロックチェーンを活用するケースです。これにより、銀行間の取引において、プロセスの簡素化、迅速化、可視化、作業コスト削減を実現することが期待されます。また、本人確認やKYCなどの銀行間で共通で必要となる情報の交換にも活用可能と考えます。
(3)複数の銀行、および、複数の企業間でブロックチェーンネットワークを構成し、銀行取引を含めた複雑なビジネスプロセスを実現するケース
例えば、トレードファイナンスでは、銀行、輸出企業、運輸会社、輸入企業などの多数の参加者の間で、大量の貿易書類をやりとりする必要があり、書類の処理に多くの手間と時間を要しています。ブロックチェーンを活用することで、プロセスの簡素化、迅速化、確実性、作業コスト削減を実現することが期待されます。
【3】システム間連携エリア
システム間連携エリアでは、複数の海外拠点・複雑な組織間でデータを連携する場合などにおいて、これらを横断して、集中システムを構築・運用するオーナー部門が存在していないケースにおいて、ブロックチェーンが活用できると考えられます。例えば、海外拠点を含む複雑な組織間で連携をする場合に、プロセスの効率化、迅速化、可視化を実現できる点で効果があるでしょう。
図7の各エリアについて、報道発表されているブロックチェーンの活用事例を紹介します。なお【1】FinTechエリアにおいては、BitcoinやRippleなど有名な事例がありますので、銀行自体が実施している事例を紹介しています。現時点では、実証実験や本格的なシステム構築に着手した段階の事例が大半です。
エリア | 構成タイプ | 事例 | 参照先 |
---|---|---|---|
【1】FinTech | ― | ブロックチェーン技術などを活用した国内外為替一元化検討に関するコンソーシアムへの参加 | SBIネット銀行プレスリリース |
【2】対外系 | (1)銀行と複数の取引先とで構成 | 外部委託業者などのビジネスパートナーと銀行間での契約の管理・履行に関する実証実験 | IBMニュースリリース |
(2)複数の銀行間で構成 | 銀行間での外国為替取引におけるネッティングサービスの開発 | IBMニュースリリース | |
(3)複数の銀行、および、複数の企業間で構成 | シンガポールにおけるトレードファイナンスへの適用を目的にDBS銀行とスタンダードチャータード銀行とで協業 | DBS銀行公表記事 | |
【3】システム間連携 | ― | グローバル・カストディ業務での部門間や海外拠点間の情報連携の効率化・自動化による管理コストの削減、および処理スピードアップやレスポンスの迅速化の検証 | IBMニュースリリース |
ここからは、ブロックチェーンのシステムを構築する上での留意点について説明します。
・ブロックチェーンである必然性
「ブロックチェーンに適した業務」の章で述べたように、「ブロックチェーンでも実現できる」ではなく、「ブロックチェーンを使うと、業務面やコスト面で効果がある」業務でブロックチェーンを活用することが重要です。実際に、参加者が対等な関係となるような業務形態ではない場合、主となる参加者側で集中システムを構築し、他の参加者にサービスを提供することで十分というケースもあります。
・ブロックチェーンのネットワーク形態
「ブロックチェーンネットワークの形態」の章で記述したように、「ブロックチェーンを単一組織だけで保有するプライベート型とするのか」「特定の参加者間で保有し合うコンソーシアム型(集中管理 or 分散管理)とするのか」「誰でも保有できるようなパブリック型とするのか」業務形態に応じて最適なものを選定することが必要です。FinTechと対外系の場合は、パブリック型かコンソーシアム型、システム間連携の場合は、プライベート型が適していると考えます。
・フロントアプリケーションとの機能分担
業務形態、採用するブロックチェーンのネットワーク形態を踏まえて、ブロックチェーン側で提供すべき機能、認証単位(組織単位、ユーザー単位など)を定義し、フロントアプリケーションとブロックチェーンの機能分担を決定する必要があります。ブロックチェーン側で提供する機能を基にして、ブロックチェーンの処理形態として、スマートコントラクト型とUTXO型のどちらが適しているかを見極める必要があります。
・セキュリティ要件の充足
採用するブロックチェーンのネットワーク形態に応じて、セキュリティ要件が充足できるか評価する必要があります。ブロックチェーンは原則的に全てのデータが参加者に共有されるものですので、「匿名性・機密性・認証レベルの要件は充足できるか」「パブリック型やコンソーシアム型の場合に攻撃・不正アクセス対策は実現できるのか」などのセキュリティ要件に特に留意が必要です。
・性能要件の充足
ブロックチェーンのシステム構成で、性能要件が充足できるか評価する必要があります。「ブロックチェーンに適した業務」の章で記べたように、ブロックチェーンは、分散台帳をコンセンサスを取りながら更新していくため、非常に高いレートのトランザクションや、取引が確定するまでに非常に早い時間が要求されるケースにおいては現時点では課題があります。
また、PoW型のコンセンサス方式の場合は、取引確定までに比較的長い時間を要するので、要件を充足するか特に留意が必要です。
・可用性、災害対策要件の充足
可用性、災害対策要件が充足できるようなブロックチェーンのネットワーク形態、システム構成を検討する必要があります。「災害発生時でもブロックチェーン全体としては可用性が確保できるようなノードを遠隔地へ配置する」「業務的にシングルポイントとなる参加者が存在する場合は、その参加者のノードを複数配置する」などに留意する必要があります。
ブロックチェーンは成熟し切った技術ではないので、安全性を考慮して、どのように段階的に活用範囲を拡大していくかを検討することが重要です。例えば、「実証実験から開始する」「最初はプライベートなブロックチェーンから開始する」「データベースを併用して整合性をチェックする」といった対策が考えられます。
ブロックチェーンのみでシステムが成立するケースは少ないと考えます。参加者が銀行の場合、勘定系システムや、AML(Anti-Money Laundering)、KYC(Know Your Customer)などの不正取引防止に関するシステム、情報系システムなど、さまざまな他システムとの連携が必要となることが想定されます。
ブロックチェーンと他システムを連携させるノードを用意する場合は、ノードが業務的なシングルポイントとならないように留意が必要です。
パブリック型やコンソーシアム型のブロックチェーンネットワークの場合、ユーザー登録やブロックチェーンへの参加登録などの業務的な運用や、メンテナンス、パッチ適用などのシステム的な運用を、「複数の参加者間で、どのように合意を取って不都合なく実施するか」を検討する必要があります。
パブリック型の場合は、「各参加者が自由に実施できるようにする」のが理想です。コンソーシアム型の場合は、「システム的に合意を得るような仕組みとするか」「別の手段で合意を得るような仕組みとするか」の検討が必要です。
また、ブロックチェーンを安定的に稼働させるためには、稼働実績やサポートなど、安定したサービスを提供できるブロックチェーンのプラットフォームを選定することが必要です。
今回は「ブロックチェーンとは何か?」や、銀行業務における活用に向けた留意点について解説しました。さて、本連載は今回で最終回となります。連載を通して、銀行システムの過去、現在、そして未来に向けた話題についてお伝えしてきましたが、いかがでしたでしょうか。
若いITエンジニアを中心に「古い技術に基づいたインフラ」として誤解されがちな「銀行系システム」ですが、歴史あるシステムで採用された技術には相応の理由があり、また決して古いというだけではないことも分かっていただけたかと思います。顧客接点となるSoEとAPIで連携したり、新しいデータ解析技術が導入されたり、そして今回紹介したブロックチェーンのように既存のシステムの仕組みを大きく変えたりすることも検討されています。
FinTechの流れの中で「銀行系システム」はどうなっていくのか、今後も注目していただければと思います。
昨今、ITサービスのように変化対応力が重要な領域をSoE(Systems of Engagement)、基幹システムのように安定性が重要な領域をSoR(Systems of Record)と分けて扱う考え方が浸透してきたが、“価値あるサービス”を提供し続けるためには、SoE、SoRがそれぞれ単独で機能を果たすのではなく、耐えず連動しながらイノベーションを生み出すことが求められる。その実現に向けては、アプリケーションの開発と同時に、そのパフォーマンスを支える“ITインフラの在り方”が肝となり、ITサービス競争を勝ち抜く切り札となるのだ。では具体的に、両領域をどのように連携・改善させればいいのか――本テーマサイトでは、先進事例や動向とともに、全業種に通じる“デジタル変革の確実な進め方”を紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.