ガイド
UAEでのオープンファイナンスプロバイダーの設立方法
短い回答
CBUAEのオープンファイナンス規制は、ライセンスされたデータ共有およびサービス開始のための特定の枠組みを作りました。このライセンスだけでは企業が顧客の資金を保持したり、規制されたアドバイスを提供したり、データに基づいたすべての金融サービスを実行することは許可されません。製品は機能ごとのマッピングが必要です。
ライセンスリストではなく、商品マップから始めてください。誰がお金を保持し、誰が移動を開始し、誰が信用リスクを負い、どのライセンスが顧客ジャーニーの各スクリーンをサポートするかを追跡します。それから、通常の会社設立を金融サービスの承認から分離し、それに法的に代替可能なパートナーの取り決めから分離してください。商業ライセンスは決して顧客のお金を保持するための許可にはなりません。
運営モデルが法域より先に来る理由
フィンテックビジネスにおいて、決定的な質問は、誰が金銭を受け取るまたは管理するのか、誰が取引を開始するのか、どのライセンスがサービスをサポートするのか、どの顧客データにアクセスするのか、クレジット、アドバイス、または仲介が提供されているかどうかです。
フィンテックでは、同じ顧客体験を非常に異なる規制価格で構築できます。一方のバージョンはすべての機能のライセンスを保持していますが、もう一方はほとんどの機能をスポンサー機関から借りてほとんど持っていません。フィンテック風の活動説明を持つエンティティは何も決定しません。重要な質問は、会社自身がどの機能を実行し、どの機能をライセンスを持つパートナーが実行し、それぞれの選択が資本、人数、依存関係でどのくらいのコストをかけるかです。
これらのモデルの中から、最も計画に近いものを選択することから始めます：
- アカウントまたは金融データ情報サービス
- 支払いまたはサービス開始プロバイダー
- ライセンスされたプロバイダーを通じてデータを消費する分析プラットフォーム
- 規制された参加者向けのオープンファイナンスインフラストラクチャベンダー
複数のモデルが適用される場合、ほとんど普遍的なパターンは分割です：規制された機能についてのライセンスエンティティと、技術とスタッフのための運営会社 — または規制された機能を完全に運営するスポンサー機関です。この分割は官僚主義ではなく、規制された境界とその背後にあるパートナー契約を明確にするものです。
通常の会社設立が停止する場所
これらの質問を選ばれる法域または活動の前にテストしてください。なぜなら、各質問がライセンスの階層間でモデルを移動させるからです：
- データ共有およびサービス開始のライセンス
- 同意、認証および顧客コントロール
- オープンファイナンスの許可外での資金保持、アドバイス、仲介またはクレジット
- APIハブ、信頼フレームワークおよび共通インフラストラクチャへの参加
- アウトソーシング、保険、資本およびUAEの設立要件
一回のヒットは会社自体がライセンスを必要とすることを意味するわけではありません — ライセンスを持つパートナーがその機能を法的に担うことができます。それは境界に事実に基づく決定が必要であることを意味します：認可を保持するか、契約するか。ラベルゲームは他の方向でも失敗します：実際に価値を保持したりクレジットを整理したりするプラットフォームは、アプリが何と呼ばれているかに関わらず規制されます。
境界の位置を書き留めてください：社内で実行される機能、ライセンスを持つパートナーによって提供される機能、および分割を変更する可能性のあるロードマップ機能。スポンサー、規制当局、銀行はそれぞれ異なる視点でその文書を読みますので、それは一貫した物語である必要があります。
答えを変える構造上の決定
中央銀行ライセンス、金融フリーゾーンルートおよびパートナー主導モデルを比較する前に、これらの変数を修正してください。
- ライセンスされた参加者対技術ベンダー
- データタイプ、機関および顧客セグメント
- 読み取り専用の洞察対アクション開始
- 直接的な顧客関係対埋め込み型流通
- セキュリティ、同意および責任配分
顧客が契約する法人は、その製品に関して自らの権限またはスポンサーの権限で応答できなければなりません。グループ構造は、技術、知的財産およびライセンスされた機能を異なる法人に分けることができますが、それぞれが真の役割を持つ必要があります。安価なセットアップ価格を宣伝するように最適化された構造は、後にスポンサー調査の失敗や銀行のオンボーディングの摩擦として現れます。
コストとタイムライン：1つの見出し番号ではなく、層を使用する
フィンテックの予算は、モデルが必要とするライセンス階層またはスポンサーがそれを担うかのいずれかの早期の選択によって決まります。その分岐を中心に予算を層状にします：
- 法人設立: 登録、憲法書類、設立カード、ワークスペース、および移民能力。
- 権限またはスポンサーシップ：ライセンスパス — 申請作業、アドバイザー、ポリシー、監督料 — またはスポンサーのパス：パートナーの尽力、統合作業、プログラム料および収益分配。
- 規制財務資源：資本金および顧客資金に応じた保護措置が階層および会社が触れる顧客資金に比例して拡大します。
- 人とガバナンス：階層が求める管理、コンプライアンスおよびリスクの役割、加えてスポンサー契約が要求するオペレーションチーム。
- 継続的義務：監督またはプログラム料、監査、報告、税務申告およびライセンス、登録およびパートナー契約に関する更新。
タイムラインは同じ分岐に従います。パートナー主導のモデルはパートナー調査のスピードで進み、ライセンスモデルは規制当局のスピードで進みます。どちらも段階的であり — 構造決定、設立、権限またはスポンサーのオンボーディング、構築とテスト、銀行のオンボーディング、立ち上げ — 登録は最も速い段階であり、最も意味のないものです。
銀行、投資家および商業の準備
銀行およびスポンサー機関は並行して調査を行い、どちらも同じ質問から始まります：各資金の流れをカバーするライセンスは誰のものですか？オンボーディングが始まる前に以下を準備してください：
- 機能および規制許可マトリックス
- 同意およびデータフローデザイン
- APIセキュリティおよびインシデント対応計画
- 財務資源および保険の仮定
- 管理およびコンプライアンス能力
目標は、製品、パートナー契約、規制上の立場および銀行ファイル全体にわたって一貫した物語を持つことです。一貫性は不必要な質問を排除します。それはアカウント、スポンサー、権限または承認を保証するものではありません。
設立のために支払う前に回答すべき質問
- 会社はデータを読むだけなのか、それともアクションを開始するのか？
- 資金を保持したり、推奨を行ったりすることはありますか？
- 誰が顧客の同意を取得し、管理しますか？
- ライセンスを取得した参加者またはサプライヤーですか？
- ダウンストリーム機能に追加で必要な許可は何ですか？
まだ不明なことを記録し、それを確認する必要がある人を明確にします。デフォルトで採用されたライセンス階層またはスポンサー契約は — 設立パッケージがそれを暗示しているため — フィンテックが途中で再構築することになる原因です。
一般的な間違い
- APIアクセスがすべてのダウンストリーム製品を許可する前提で
- 別々の分析なしでのバンドルの助言またはクレジット
- 同意を一度きりのチェックボックスとして扱う
- 承認された接続が期待されるフレームワークにおいてスクリーンスクレイピングに基づく
設立手数料を比較することは古典的な誤りです。年初のコストと更新コスト、資本と保護、スポンサー経済、許可される機能、銀行への影響、そして立ち上げ後のティアの切り替えコストを比較してください。
VelaroZoneが評価するもの
VelaroZone のアドバイザー主導の評価は、製品マップをライセンスまたはパートナーの決定に変えます。事実に応じて、書面による計画は以下をカバーすることができます:
- このモデルに対して本当に開かれているライセンスティアとパートナー主導のルート、およびその理由。
- 機能ごとの割り当て：社内で実施されるか、スポンサーによって担われるか、または繰延べられるか。
- 立ち上げを制約する資本、保護、スタッフと銀行の依存状態。
- 設立の見出しではなく、ティアの決定に基づいて構築されたコストレイヤー。
- 専門家による確認が必要な文書、未解決の質問、および仮定。
- クライアントがルートを理解し、承認した後にのみ始まるファイリングシーケンス。
最終的な権限のショートリスト、正確な活動の選定、現在の要件、および提出経路は、実際の事実に対して確認されます。これらは決定出力であり、一般的なウェブサイトの主張ではありません。
