【速攻解説】社債プレマーケティングシステム「Biancha」と「Progmat」が連携するって、どゆこと？
こんにちは、プログラマブルな信頼を共創したい、Progmat(プログマ)の齊藤です。
2023年12月12日に、プレスリリースを発信しました。
タイトルは、「ブロックチェーンを活用した社債プレマーケティングシステム“Biancha”と“Progmat”の連携について」です。
昨日の日経電子版、今朝の日経朝刊でも報道されていた取り組みです。
プレスリリース等を実施したイベント週では、
情報解禁後いち早く正確に、背景と内容についてこちらのnoteで解説しています。
ということで、第12回目の本記事のテーマは、
「【速攻解説】社債プレマーケティングシステム「Biancha」と「Progmat」が連携するって、どゆこと？」です。
結論、デジタル債の”ライフサイクル全体”の効率化が可能に！
結論、これです☟
「プレマーケティング」を起点に、「条件決定」「アロケーション決定」までの自動化/効率化を担うのが、「Biancha」。
「発行/払込」から「償還」までを担うのが、「DBM」。
各システムと連携し、必要な当事者間で「権利移転/原簿記録」情報を共有/検証するのが「Progmat」
「Biancha」×「Progmat」×「DBM」の連携により、「デジタル債」のライフサイクル全体の自動化/効率化範囲が最大化し、「Why デジタル債？」の答えが出せる。
上記の「債券のライフサイクル」の図を念頭に置きつつ、
まずは前提/背景情報から確認していきましょう。
前提、デジタル証券/ST市場における「デジタル債」の位置づけって？
第7回から第11回まで、「セキュリティートークン(ST)/デジタル証券」編として解説してきました。(プレスリリース発信週の【速攻解説】を除く)
第11回記事でまとめたとおり、市場成長のドライバーは現時点で圧倒的に「不動産デジタル証券/ST」であり、「デジタル債」は未だ黎明期といえる現状を指摘しています。
「不動産デジタル証券/ST」に続く”次の成長ドライバー”として、「社債ST（自己募集対応含む）の裾野拡大」と「新規アセット拡大」が重要である点は、前回記事のとおりです。
”NTTデータグループ×Progmat”の「標準化インフラ」進めていませんでしたっけ？
さて、そんな「デジタル債」について、「不動産デジタル証券/ST」と比べて黎明期のままである理由＝課題は何だったでしょうか？
第9回記事では、少なくとも次の3点があるとしていました。
「不動産デジタル証券/社債」と比較して、”特典”以外に商品性そのもののオリジナリティは薄い問題（前提）
「振替債」と比較して、むしろ業務が大変になってしまうと「トライアル」を乗り越えられない問題
「流動性」がないと、「長期」「マス顧客」向けの発行ができない問題
2点目の課題の前提として、「振替債」において「振替口座簿」と連携して各種主要な業務を支えているシステム（以下、社債管理用基盤）が存在しています。
これまでの「デジタル債」では、既存の「社債管理用基盤」と「（振替口座簿の代わりである）ブロックチェーン等のシステム」とは必ずしも連携しておらず、同じような情報を双方のシステムに登録する等の大変さが発生してしまっていた、と認識しています。
第9回記事でも触れているとおり、これでは「トライアル」の次に続けるのが難しいでしょう。
ということで、それまでは「不動産デジタル証券/ST」に全集中し、「デジタル債」は静観の構えを貫いていたProgmat（当時は三菱UFJ信託銀行）が突如公開したのが、「NTTデータ様との提携」でした。
というのも、前述の「社債管理用基盤」で圧倒的なシェアを有しているのがNTTデータグループの日本電子計算様が提供しているシステム（B-Apps Online）だからでした。（NTTデータ様はProgmatの株主/パートナーでもあります）
このシステム上に「デジタル社債用機能（仮称：DBM）」を新設し、Progmatと自動連携を行うものを”デジタル債の標準化インフラ”とすることで、既存の業務/システムからの延長線上（低い移行負荷）で、「振替社債業務」よりも一層効率的に業務を行うことができるようになる、というのが提携の狙いでした。
この”デジタル債の標準化インフラ”のポンチ絵をもう一度見てみていただきたいのですが、よく見ると「DBM」の中のプロセスボックスは「発行」「期中管理」「払込」「支払」「税納付」となっています。
この「発行」プロセスの前工程(＝スコープ外)の1つが、今回の連携する新システム「Biancha」が対象とする「プレマーケティング」業務です。
社債の「プレマーケティング」業務って、なに？
さて、社債の「プレマーケティング」業務とは何でしょうか？
「プレマーケティング」とは、発行条件（主に利息水準）を適切に決定するために、引受証券会社（1社の場合もあれば、複数社の場合もある）が機関投資家の投資意向を確認するプロセスのことです。
日本国内の公募債のほとんどの案件で実施されていますが、機関投資家-証券会社-発行体で完結するプロセスであり、一般の個人の方にはなじみがないのも当然です。
「プレマーケティング」においては、機関投資家が各証券会社の営業担当者に対し投資意向（オーダー）を伝え、当該オーダー情報を証券会社間で集約することで、投資家全体の投資意向を調査しています。
こうした「プレマーケティング」のプロセスにおいては、各社に重複業務が発生している他、ヒアリングは電話やメール、チャットで（＝人手を介して）数日間連続で行われ、情報集約もエクセルにより（＝人手を介して）行われていることから、業界全体で大きな業務負担が発生しています。
そして、このプロセス自体は特に手数料も発生せず差別化要因にもならない、証券会社にとっては業務負担の割に付加価値の低いプロセスである、という点がポイントです。
「Biancha」の有無でどう変わる？
こうした「プレマーケティング」に係る業務負担を解消するためのシステムが、「Biancha」（Bid aggregation on chain）です。
「Biancha」の稼働後は、機関投資家が（各証券会社が提供する共通のフロントエンドを介して）直接的にブロックチェーンに投資意向（オーダー）を入力し、当該情報の集計データについて、発行体も（事務主幹事証券会社のフロントエンドを介して）直接的な確認が可能になります。
「Biancha」では、真正性を担保したまま情報を集約できるだけでなく、参照が認められた会社間でのみデータが共有される、という要件を満たす必要がありました。当該要件を満たすため、ブロックチェーンプラットフォームとして「Corda」が採用されています。
「Corda」は、「Progmat」のプロダクトシリーズの中では「Progmat ST」で採用されていますが、以下のような特徴があります。
（一方で「Progmat Coin」はEthereumをはじめとしたパブリックチェーンが採用されている等、プロダクト別の採用チェーンは以下の記事をご参照）
Cordaは企業間取引での利用に特化したブロックチェーンプラットフォームであり、エンドユーザーである金融機関が主導し開発されたため、金融における業務要件を満たすものとして設計されています。
特にプライバシーの面で優位性を持っており、データを全ノードで共有することはせず、必要なノード間でのみ共有するため、第三者にデータの内容を知られることがありません。
複数の中央銀行デジタル通貨（CBDC）やデジタル証券で採用された実績を有しており、日本においては、SBI R3 JapanがCordaライセンスならびに運用支援、それらに先立つ導入支援を提供しております。
ということで、「Biancha」は証券会社横断的な「プレマーケティング」の効率化を企図する大和証券様と、日本国内で「Corda」のライセンス/運用支援等を行うSBI R3 Japan様との、共同開発プロジェクトです。
「プレマーケティング」を行う複数の証券会社が利用していなければ効率化されないため、当然に大和証券様専用のシステムではなく、”共通インフラ”として各証券会社が自社ノードを立て、上下なく横連携が可能になることが想定されています。
また、現時点で「プレマーケティング」プロセスが対象になっていますが、債券のライフサイクルにおける次のプロセスである「条件決定」「アロケーション決定」まで拡張する予定です。
「Biancha×Progmat×DBM」、全部まとめるとどうなる？
前述の「Biancha」プロジェクトは、もともと「振替債」を対象に進められていました。
そんな中、「デジタル債」を対象に”標準化インフラ”構築を標榜する「Progmat」も同じ「Corda」を採用していたことから、相互運用性が期待できるため、「デジタル債」を対象にシステム間連携を行い、「デジタル債」の”ライフサイクル全体”の効率化を目指すことで合意した、というものです。
「DBM×Progmat」＋「Biancha×Progmat」＝「デジタル債インフラ全体像」ということになりますが、いったいどんな感じのイメージになるのでしょうか？
ざっくりいうと、こんな想定イメージです☟
原簿管理を担う受託金融機関は、「Progmat」ネットワークに参加する各社ノードを有する。
証券の販売を担う証券会社は、「Progmat」&「Biancha」ネットワークに参加する各社ノードを有する。
機関投資家と発行体の「発行前プロセス（＝「プレマーケティング」「条件決定」「アロケーション決定」）」は、ノードを有する証券会社のフロントエンドを介して、「Biancha」上で効率的に（かつ必要な当事者のみに限定して）処理される。
「発行前プロセス」の各種情報は、「Progmat」上の同一銘柄に関するデータセットとして、「Biancha」から真正性を担保したまま連携され、「Progmat」上の必要な当事者間で共有可能になる。
受託金融機関が入出力を行う標準的フロントシステムである「DBM」には、「Progmat」から連携を受けた各種情報が同期される。
受託金融機関は「発行後プロセス（＝「発行/払込」「期中管理」「利払い」「税納付」「償還」）」を「DBM」に対して行い、関係当事者間での「権利移転/原簿記録」共有/検証を「Progmat」が裏側で処理する。
ということで、各システムが相互に連携することで、デジタル債のライフサイクル全体をカバーし、自動化/効率化範囲を最大化することが期待されます。
これは前述のとおり、既存の「振替債」よりも商品性そのもののオリジナリティが薄い「デジタル債」が本格的に普及するうえで、「Why デジタル債？」に応える”必要条件”と考えています。
最後に
前回記事では、「不動産デジタル証券/ST」に続く”次の成長ドライバー”として、「社債ST（自己募集対応含む）の裾野拡大」と「新規アセット拡大」が重要、としていました。
今回の取り組みは、前者の「社債ST（自己募集対応含む）の裾野拡大」を実現するうえで課題となる、【「デジタル債」は「振替債」と比較して商品性そのもののオリジナリティが薄い中で、「振替債」よりも業務が大変になってしまうと「トライアル」を乗り越えられない問題】の解決に向けたものです。
具体的には、「デジタル債」のライフサイクル全体の自動化/効率化範囲を最大化することで、「振替債」対比の優位性を高め、（原簿記録のリアルタイム把握による）「ファンマーケティング」等の付加価値との相乗効果により、「Why デジタル債？」への明確な答えを用意する、ということです。
さて、2024年の”次の成長ドライバー”のもう1つは、「新規アセット拡大」でした。
「新規アセット拡大」に関する情報公開も、そう時間をおかずに発表する予定ですので、楽しみにお待ちいただけますと幸いです！
この記事が気に入ったらサポートをしてみませんか？