Marco Poloの立ち位置 ~L/Cを使わない貿易金融ソリューション~

Marco Poloの立ち位置 ~L/Cを使わない貿易金融ソリューション~

Marco Poloの立ち位置 ~L/Cを使わない貿易金融ソリューション~

今回の記事は、「SBI R3 Japan」が公開しているMediumから転載したものです。

より様々な内容の記事に興味のある方は、是非こちらにも訪れてみてください。

⇒　SBI R3 Japan公式 Medium

～ブロックチェーンで世界を変えるための第16歩～

今回は、TradeIX（トレードアイエックス）社が提供する貿易金融ソリューションであるMarco Polo（マルコポーロ）の概要をご紹介します。

・・・

Marco Poloとは？

2017年、TradeIXはR3コンソーシアムに参加していた16行の銀行と共に、L/Cを使わない運転資金ソリューションの開発に着手しました。バイヤーとセラー間の受発注ライフサイクルにおいて、唯一真実としてのデータ（Single source of truth）を共有でき、かつ既存の銀行関係を梃子に取引リスクを低減することで、銀行がファイナンスを提供できる仕組みを目指しました。

以来、プロジェクトは継続し、ダイムラー（Daimler）とデュール（Dürr）間における支払保証のパイロット取引等、順調に実績を積み重ねています。2019年12月には、25か国70社を超える自動車会社、海運会社、銀行等のエンドユーザー340人による大規模トライアルを成功させ、発表しています。

現在では35行の銀行、20社を超える事業会社（実証実験、パイロットでご利用頂いたお客様）、7社のパートナー企業に支えられる、ブロックチェーン業界を代表するコンソーシアムへと成長しています。

・・・

そもそも貿易金融の課題は？

本題に入る前に貿易分野における課題をおさらいしておきます。

貿易取引においては二人のプレイヤーがいます。バイヤーとセラー（サプライヤー）です。バイヤーは商品を輸入しますが、確実に商品が手元に届くまで支払を遅らせたいとの思いがあります。一方セラーは商品を輸出しますが、バイヤーから入金されるまで、できれば出荷したくないとの思いがあります。

このように貿易取引に関わる二人が相反する利益を持ち合っている状態を「トレード・ジレンマ (trade dilemma)」と呼びます。ここに金融取引を司る銀行が介在する意味が生まれます。

銀行は貿易取引における第三者として、バイヤーとセラーの間に立ち、①バイヤーが確実に商品を受け取れること、②セラーが確実に入金を受けらえること、を目的に信用補完（保証）とファイナンスのサービスを提供します。

この提供方法は様々です。伝統的にはL/C（信用状）取引があります。

信用状という紙を取引関係者間で郵送して共有することで、取引の真正性を確認します。セラーが信用状通りに船積みすることで、銀行から早期に入金を受けられます。

またバイヤーは、銀行を通じて貿易書類（船荷証券）を受け取ることで、確実に商品を引き取ることができます。L/C取引は、銀行自体の信用を活用するため、取引相手の信用度が低い場合に有効であるものの、一般に手数料が高く、またやり取りに時間が掛かってしまい、「書類よりも先に商品が着いてしまう」等の課題があります。

・・・

“オープンアカウント取引”が求められる理由

このような状況の中、信用状を使わない”オープン・アカウント取引”に対する貿易金融サービスが注目されています。実は世界の貿易取引のうち80%がオープン・アカウント取引と言われています。

オープン・アカウント取引においては、信用状を使わないため、バイヤーとセラーは互いの信用に基づいて取引（送金決済）することになります。手続きが簡易であるため、L/C取引に比べて低コストというメリットがあります。

しかし、確実な入金と入荷（韻を踏んでいます）を担保する手段が取られていないため、ハイリスクな取引とも言えます。そのためオープン・アカウント取引は、基本的に”普段から付き合いのある”取引関係において行われる決済手段になります。

ここで、セラー側にはL/C取引と同じように取引リスクを抑えつつ、どうにか迅速に運転資金を調達したいニーズが出てきます。一方銀行側には、どうにかセラーのためにファイナンスを提供できないかという気持ち（ビジネスチャンスとも言えますが…）が生まれます。

信用状なしでも取引の蓋然性さえ確認できれば、ファイナンス提供の余地はあります。ただ、仮に銀行がファイナンスを提供できるとしても、セラーが小規模な事業者である場合、信用度の低さから借入金利と手数料が高くなってしまう可能性も出てきます。これらの課題をデジタルの力を活用して解決しようとするのがMarco Poloです。

・・・

なぜブロックチェーンベースが求められるか？

事業会社はグローバル化の進展とともに、世界中に拠点を持ち、世界中の銀行とお付き合いするようになりました。一方、銀行は自行の貿易金融サービスを事業会社に対し個別に提供してきたため、事業会社にとっては、”マルチバンク”でのお付き合いが煩雑となり、どう銀行関係を管理すべきかが課題となりました。これはEDIの進展に伴う多画面問題の貿易金融バージョンとも言えます。

多画面問題はどこでもありますね…

事業会社は、世界中の拠点で発生するファイナンスに対する要望を集約して一元管理したいと考えています。とはいえ、お付き合いする銀行を一つに絞り込み、銀行口座を一元化すれば良いという程、単純な話でもありません。

マルチバンクでの関係を維持しつつ、単一のプラットフォームで、資金状況を一元管理できるプラットフォームが求められているのです。

一方、ブロックチェーンは一つのアプリケーション機能を、複数のプレイヤー間で共有しつつ、機密情報であるデータは各プレイヤー間で整合性を維持した状態で保持できる技術です。この特徴が貿易金融にフィットするのです。

複数の事業会社、銀行はみんなで同じ貿易金融アプリケーションを使います。ただし、DBは別々にして、取引データは取引当事者間だけに閉じて共有するのです。

手元にあるデータを信じて良いよ！

このような構成であっても、事業会社は集中型サービスと同様にデータの一元管理は可能となります。つまり、ブロックチェーンを活用すれば、事業会社は一つのアプリケーションで、資金状況を一元管理でき、かつマルチバンクでのお付き合いもこのプラットフォーム上で完結できるようになります。

このような理由でブロックチェーン・ベースの貿易金融ソリューションは求められているのです。

・・・

Marco Poloが提供するソリューション

直近、Marco Poloが提供するサービスは2つ（下記1.と2.）、2021年Q1にリリース予定が1つ（下記3.）あります。

1. Receivable Discounting（売掛債権流動化）

いわゆるファクタリングを実現するサービスです。セラーはインボイスを銀行に送付し、銀行はファイナンスを提供します。セラーの売上債権回転日数を向上させます。

2. Payment Commitment（電子支払保証）

発注データ、船積データ、請求データを関係者間（セラー、バイヤー、セラーの銀行、バイヤーの銀行）で共有することで、取引リスクを低減させ、銀行がセラーへの支払を保証し、早期のファイナンスを提供します。

3. Supplier Pay（サプライチェーン・ファイナンス）

いわゆる”サプライチェーン・ファイナンス”を実現するサービスです。セラー（サプライヤー）はバイヤーの信用度を活用して、銀行から低金利でのファイナンスを受けられます。

それぞれについて簡単にご紹介します。

・・・

1. Receivable Discounting（売掛債権流動化）

ここではセラーとセラーの銀行である2社がプレイヤーとして参加します。セラーは取引の結果発生する売掛債権を元に、請求書（インボイス）を作成します。

これをMarco Poloを通じて、バイヤーではなく銀行に送付します。

銀行は、請求書の内容に基づき、金利（bps）と手数料を設定し、セラーに返信します。もちろんメールではなく画面を通じたワークフローになります。以上、非常にシンプルではありますが、セラーは30日、60日、90日もしくは120日の入金を待たずに早期に現金を手にすることが可能です。

なお、元となる請求書データは手でMarco Poloに打ち込むのではなく、ERPから自動連携することもできます（もうすぐ）。現在、ドイツの大手システムインテグレーターであるmsgグループが、Marco PoloとSAP（ERP）を統合させるコネクターを開発しています。これを使えばSAPを導入にしている事業会社は大規模なインターフェース開発を要せず、Marco Poloを使えるようになります。

このように、セラーと銀行間の手続きを”デジタルで完結”させることで、セラーは簡単に売掛債権の買い取り申込ができ、一方銀行は紙のインボイスと補足資料を”目視”で確認する必要なく、互いに業務に係るコストを削減することができます。

この話には少し続きがあります。将来的には以下のような使い方が可能となってくるでしょう。

このReceivable Discountingを通じて、銀行はセラーの名前、請求書にある金額等の情報をデータの形で受け取ります。銀行側でこの情報を”目視”しても良いですが、一定のルールをスマートコントラクトとしてプログラミングしておけば、人手を介さずに自動で審査対応手続きが出来てしまいます。

例えば、セラーの名前から自動的に与信を判断し、加えて一定の閾値を超えない取引金額で与信枠の範囲内あれば、自動で金利と手数料を算出し、その内容でセラー側に自動返信します。これが実現できると、セラーのUXは「ファイナンスの申し込みをすると同時に銀行から返信が来た」となります。

運転資金の調達に急ぎのセラーにとっては、非常に助かります。また銀行側においても、対応する定型業務が自動化されます、例えば毎月最大100件しか捌けなかった処理が、上限を超えて対応できるようになるでしょう。例外的な申込だけ手作業で実施するば良いのです。

このように、実は”デジタルで完結”のメリットは、単に紙がなくなるだけでなく、その後の工程における手作業も削減できるようになるのです。もちろん、現時点の実務を踏まえると、ここまでの自動化は達成できません。

セラーと銀行間で売掛債権の事前審査、債権買取の契約締結が前提として必要です。ただ、より高度のスマートコントラクトが実現された世界では、上述した一歩進んだ使い方が実現され、銀行はより多くの案件獲得に繋がっていくと考えられます。

・・・

2. Payment Commitment（電子支払保証）

次により複雑なスキームとなる支払保証をみていきます。ここでは、バイヤーとセラー、それぞれの銀行の4人のプレイヤーが登場します。

これらプレイヤー間において、①発注書データ、②船積データ、③請求書データを共有することで、取引の蓋然性を確認し合います。①②③のデータは似たような項目になります。

そこで、異なるプライヤーから提示されるこれら項目を”自動マッチング”することで、当該取引が実在し、認識相違なく合意されていると確証を得ることができます。結果、取引リスクを下げられます。銀行は単なるオープン・アカウント取引よりも確信を持って支払を保証でき、その保証に基づいてファイナンスを提供できます。

この取組みはL/C取引の代替ソリューションとして位置付けられています。L/C取引だと高い手数料および手続き完了に掛かる時間といった課題があります。

一方、オープン・アカウントでは、バイヤーの信用度に依存し過ぎており、取引リスクが高い。ちょうどこの間を取って、信用状の代わりに、発注書データ、船積データ、請求書データを使い、リスクを低減しつつ、紙ではなくデータで情報交換することで、リアルタイム性を向上させ、結果、低コストかつ早期のファインナンスを可能とします。

また、現在SWIFTが提供しているTSU(Trade Services Utility)およびBPO(Bank Payment Obligation)も、売買情報と船積情報をデータ・マッチングさせて取引の整合性を確認する仕組みでありますが、2020年12月に廃止が予定されています。この代替としてもMarco Poloは注目度が集まっています。

・・・

3. Supplier Pay（サプライチェーン・ファイナンス）

前述した売掛債権流動化（Receivable Discounting）においては、セラーの信用度がそのまま金利と手数料に反映されるため、この点、もう一歩踏み込んだ解決策が検討できそうです。ここでは、セラーとバイヤーに加えて、バイヤーの銀行が登場します。

セラーは取引先であるバイヤーの信用度を活用して、より低金利でのファイナンスを受けられないでしょうか。

アンカーバイヤーは複数のセラーから材料を仕入れ、自社で加工品・完成品を製造します。そのため、セラーが迅速かつ低金利の資金調達を実現し、サプライチェーン全体で健全経営を保てることは、バイヤーにとってもメリットがあります。

そこで、バイヤーはセラーを含めて、Marco Poloに一緒にオンボード（参加）します。そして、バイヤーとセラー間で取引する際は、バイヤーがそこで発生するインボイスを”承認”することで、信用度を付加します。

この信用度に基づいて、セラーはバイヤーの銀行からより低金利でのファイナンスを受けます。結果、セラーは売掛金回転日数を向上できます。もちろん入金データはインボイスを紐づいて簡単に消込が可能です。

なお、このスキームにおいては、ファイナンスの提供者が必ずしも銀行である必要はありません。SPV（Special Purpose Vehicle）がその役割を提供しても良いのです。SPVが、売上債権を証券化して、セカンダリーマーケットで売買してしまうことも将来的には可能となります。

・・・

Marco Poloは今後が楽しみ！

さて、Marco PoloはTradeIXが提供するプラットフォームではありますが、将来的には他社であるソフトウェア・ベンダーやシステムインテグレーターとパートナーシップを組み、他社がMarco Polo上でサービス開発できる将来像を描いています。実はMarco Poloのアーキテクチャーは、3階層で構成しており、

①ネットワークを構成する分散台帳基盤としてのCorda、

②貿易金融やサプライチェーン・マネジメントの共通プラットフォームとしてのMarco Polo

③最上位に個別機能（プロダクト）としての業務アプリ

になっています。