ガイド
UAEにおけるマネーマーケットおよび流動性管理プラットフォームの設立
短い回答
UAEのマネーマーケット・流動性プラットフォームが認可を必要とするのは、情報を表示するにとどまらず、クライアントの現金を選択し、アレンジし、移動させ、または推奨する場合です。メインランド(mainland)では、UAE中央銀行(CBUAE)が金融機関を認可し監督しています。DIFCでは、金融サービスを行う事業者にDFSAのライセンスが必要であり、ADGMではFSRAが判断します。経路を決めるのは、多くの場合、誰が商品を選び、誰が現金を管理するかであり、その商品が自らをトレジャリー・ソフトウェアと称しているかどうかではありません。
規制範囲(パリミター): CBUAE、DFSA、FSRA、そしてどちらが判断するのか
マネーマーケットまたはリクイディティプラットフォームという呼称のもとには、通常4つのいずれかが存在します。
- トレジャリー分析:金利、残高、利回りの比較を表示するのみで、クライアントの現金には一切触れません。
- 預金・ファンドのマーケットプレイス:銀行やファンドマネージャーの商品を掲載し、クライアントが注文を出せるようにします。
- 自動キャッシュスイープ:プラットフォームが運用するルールに従い、クライアントの残高が第三者の預金またはファンドへ移動します。
- 裁量型の短期運用:プラットフォーム、またはその背後にいる者が、都度の確認なしにクライアントの現金の置き場所を決定します。
どの規制当局が適用されるかは、プラットフォームがどこに設立され、どの機能を行っているかによって決まります。オンショアでは、預金の受け入れおよび預金の取次ぎはCBUAEの管轄です。DIFCのプラットフォームは、DFSAの助言、取次ぎ、資産管理制度のもとに置かれます。ADGMのプラットフォームは、同等のFSRAの制度のもとに置かれます。これらは、一つの許可に対する三つの価格帯ではなく、三つの別個の制度であり、行われる活動によってどちらが適用されるかが決まります。
データを表示するだけで、注文の流れも、裁量も、クライアントの資金もないプラットフォームは、事実関係次第では上記3つの規制のいずれにも該当しない場合があります。商品を推奨し、注文を執行し、残高を自動でスイープし、またはクライアントに代わって配分を決定した時点で、「キャッシュ・マネジメント」「トレジャリー・テック」「MML」といった呼び名にかかわらず、上記のいずれかの機能を果たしていることになります。規制当局が見るのは注文と資金の流れであり、ピッチデッキではありません。
機能ごとに分類を検証するもの
以下のそれぞれは、ある機能を単なるソフトウェアから規制対象機能へと移す可能性があり、プロダクト全体の説明によって当然に除外されると見なすのではなく、それぞれ個別に検証する必要があります。
- 公表されている利率を単に掲載するのではなく、特定の預金、ファンド、またはプロダクトを推奨またはランク付けしているか?
- 注文を発注、取次ぎ、または執行しているか、それとも、クライアントが他所で発注するための表示のみを行っているか?
- クライアントではなくプラットフォームが定めるルールに従って、残高が自動的に第三者のプロダクトへ移動するか?
- プラットフォーム、またはその背後にいる誰かが、クライアントのために配分、運用期間、または取引相手を決定しているか?
- プラットフォームは、いずれかの時点でクライアントの資金を保有しているか、または決済指示を管理しているか?
これらのテストのいずれかに該当しない機能があるからといって、プラットフォーム全体が認可を必要とするわけではありません。その機能について、他の機能とは別に分類が必要になるということです。トレジャリー・プラットフォームは、この理由から複数の事業体に分かれることが少なくありません。表示レイヤーを運営するテクノロジー企業と、取引機能を担う、別途認可を受けた事業体または認可を受けた第三者という組み合わせです。
クライアントの資金はどのように流れるか、そして銀行やカストディアンは何を確認するのか
銀行、ファンドアドミニストレーター、カストディアンはそれぞれ独自のデューデリジェンスを行い、まず規制上の位置づけを確認します。実務上重要なのは、ダッシュボードに何と書かれているかではなく、各段階でクライアントの資金がどこにあるかです。トランザクション機能を持つプラットフォームでは、資金は、関係当局の監督下にある認可済み金融機関の分離されたクライアントマネー口座に置かれ、運営者自身の資金と混合されることは決してありません。銀行やカストディアンに接触する前に、以下を準備してください。
- 注文および資金フローの図: 取引の前、中、後に資金がどこにあり、誰がそれを動かせるか。
- 上記の機能ごとの分類で、規制対象機能を明示したもの。
- プラットフォームが第三者の預金やファンドを掲載している場合の、プロダクト提供者との契約書。
- プラットフォームが利率を表示またはランク付けする場合の、利回りの算定方法および開示方法。
これは、コーポレートバンクアカウントレディネスの作業がまとめる書類です。規制上の書類、フロー図、そして銀行への申請書の間で説明が一致していることは、オンボーディングを短縮します。事業計画書で一つの説明をし、フロー図で別の説明をすることは、審査を最も早く停滞させる原因となります。
所有、実体、そして規制当局が求める役職
認可対象の機能(メインランドまたはDIFC、ADGMでの、資産のアレンジ、助言、運用)を担う事業体には、その業務に見合う、現地在住の上級役職者とコンプライアンス体制が必要です。登録住所とノミニー取締役だけでは足りません。テクノロジーと規制対象の機能が別々の事業体にある場合、実体(人員、システム、当局がその機能に課す資本)は認可を受けた側が担います。表示される設立コストを低く抑えることを主眼に設計された仕組みは、認可審査においても、その後ファイルを読むすべての銀行においても、まさにそのように受け取られます。当局や銀行に問われる前に、グループ内のどの事業体がどの義務を担うかを整理することが、規制対象および複雑な所有構造の設立業務の役割です。
この業種でよくある失敗
- それぞれの機能を個別に検証するのではなく、「キャッシュマネジメント」という呼称を、その活動が規制対象外であることの証拠として扱ってしまうこと。
- 推奨として機能するランク付けされた利回りを表示しながら、それを推奨として扱わないこと。
- それがクライアントに代わっての取次ぎまたは資産管理に該当するかどうかを事前に確認せずに、自動スイープを稼働させてしまうこと。
- 規制当局や銀行に対して、実際の運営モデルを示さず、略語(「MML」「流動性プラットフォーム」)で済ませてしまうこと。
- 規制対象機能、それが伴う資本、そしてそれがもたらす報告義務ではなく、設立費用だけでルートを比較してしまうこと。
分類から運営まで
運営モデルと規制体系が固まれば、手順は、機能の分類、事業体の選定、必要な認可、設立、銀行口座の開設の順に進み、その後にオフィス、ビザ、継続的な届出が通常業務となります。ある機能が認可を必要とする場合、その手続きは規制当局のスケジュール(申請、審査、必要に応じた面談、そして認可)に従って進み、設立日がそのままローンチ日になるわけではありません。上記のテストを通過し、認可対象の機能に該当しない場合は、通常のフィンテック設立と商業登録で進められるのが一般的です。ただし、その結論は機能を検証して得られたものであるべきで、早い答えを好んだ結果であってはなりません。費用も同様に分かれます。ソフトウェアのみの設立には通常の会社費用がかかり、取引を可能にする機能ごとに、その機能が求める資本、役職者、報告義務が加わる場合があります。これらは設立時の見出し価格ではなく、規制当局が定めます。それ以外のVelarozone サービス料は、業務委託契約書に明細として記載されます。詳しくはVelarozoneの仕組みをご覧ください。

