ガイド
UAEのRegTech・KYC・AMLプラットフォーム：業務委託規制
短い回答
RegTech、KYC、AML のプラットフォームは、通常、それ自体として単独でライセンスを受けるものではありません。会社は通常の方法で、ドバイ経済観光局（Dubai Department of Economy and Tourism、DET）、フリーゾーン（free zone）、または金融フリーゾーン当局を通じて登録します。状況を変えるのは顧客です。ライセンスを受けた金融機関が AML/CFT の確認業務をそのプラットフォームに依拠した時点で、その機関自身の規制当局はこれを業務委託（アウトソーシング）とみなし、ベンダーではなく当該機関にその責任を負わせます。この規制当局には、UAE 中央銀行（Central Bank of the UAE、CBUAE）、ドバイ金融サービス機構（Dubai Financial Services Authority、DFSA、DIFC）、金融サービス規制局（Financial Services Regulatory Authority、FSRA、ADGM）、資本市場庁（Capital Market Authority、CMA、旧証券商品庁）、仮想資産規制局（Virtual Assets Regulatory Authority、VARA、ドバイ）が該当し得ます。進むべきルートを決めるのは、プラットフォームがソフトウェアを提供するだけなのか、それともアラートの終結、案件の解消、報告書の提出といった判断まで行うのか、という点です。
誰が判断し、適用範囲は何によって決まるか
UAE には「RegTech ライセンス」を発行する単一の規制当局は存在しません。商業活動は DET またはフリーゾーンの管轄に属します。規制上の比重は、買い手を監督する当局にかかります。銀行や両替商は CBUAE、DIFC の企業は DFSA、ADGM の企業は FSRA、資本市場関連の企業は CMA、仮想資産サービスプロバイダーは VARA の監督下にあります。各当局は、ライセンスを受けた事業体に対し、委託した機能についてのデューデリジェンスの実施と、プロバイダーに対する監査権の保持を求めています。プラットフォームが規制対象となる当事者であることはまれです。これらの規制当局がいずれ提示を求めるのは、顧客にそのプラットフォームへの責任を負わせる契約です。
これとは別に、どの金融規制当局が適用されるかにかかわらず、連邦の個人データ保護法（Personal Data Protection Law）は、「電子システムを通じて、全部または一部が、国内または国外で行われるか」にかかわらず、個人データの処理を対象とする。同法は、限定的な例外を除き、本人の同意なしに処理することを禁止し、個人に対して自己のデータの処理を訂正または制限する権利を与えている。パスポート、セルフィー、または取引履歴を扱うプラットフォームは、どのようにライセンスされていようとも、この法律のもとで個人データを処理していることになる。
購入者のコンプライアンスチームが実際に確認する事項
RegTechの販売が停滞するのは、設立ではなく調達のデューデリジェンスにおいてである。規制対象の購入者が確認したいのは次の事項である。
- 基礎となるデータがどこから来るのか、そしてプラットフォームがそれを使用する永続的な権利を持っているかどうか。
- 争いのあるケースを人がレビューするのか、それともモデルだけで判断するのか。
- データがどこでホストされ、サポートスタッフがどこにいるのか。
- 誤検知（false positive）とモデルの変更がどのように測定・記録されるのか。
- 購入者自身の規制当局がケースファイルを求めた場合、それがどうなるのか。
UAE Cyber Security Councilは、2025年に承認された5年間のNational Cybersecurity Strategy(国家サイバーセキュリティ戦略)、およびサイバーセキュリティ実務を標準化するための認証制度であるNational Cyber Security Accreditation Program(国家サイバーセキュリティ認定プログラム)を運営している。いずれもすべてのベンダーにとって必須の関門ではないが、買い手によるセキュリティレビューでは、特に生体データ(biometric data)に関わるものについて、プラットフォームがそのプログラムに対してどの位置にあるかを問われることが増えている。
商品を通じた資金と責任の流れ
RegTech 企業自身の銀行口座は、通常、最初に出てくる銀行関連の課題であり、最も単純なものです。事業にはソフトウェア企業と同様に事業用口座が必要で、銀行が求める書類も同じです（所有関係、創業者の資金の出所、そして製品が顧客データをどのように扱うかについての明確な説明）。銀行口座の開設準備を早い段階で進めておけば、口座の開設がローンチ前の最後の懸案になる事態を避けられます。
製品が純粋なソフトウェアではなくなった時点で、状況は変わります。フィンテックにおいて誰が資金を受け取り、または管理するのかを決める問いは、ここにも当てはまります。顧客資金を保有する、支払いを開始する、または与信を供与するツールは、別の規制対象の活動となり、どれほど銀行口座の開設準備を整えても、商業ライセンスがそれらを行う許可に変わることはありません。次の二つの問いは切り離して考えてください。この会社は銀行取引ができるか。そして、顧客ではなくこの会社自身が顧客の資金に触れることはあるか。後者に該当する場合は、独自の認可またはスポンサーが必要です。
所有構造、実体性、購入者が確認する役割
グループストラクチャーは、テクノロジー、知的財産、そしてライセンスを受けたいかなる機能も、それぞれが真正な役割を持つことを条件に、別個のエンティティに置くことができる。購入者の法務チームは、モデルとデータパイプラインを誰が所有しているか、契約に誰が名指しされているか、そしてスクリーニングの結果が誤っていた場合に誰が責任を負うかを尋ねる。所有構造が複数の法域にまたがる場合は、デューデリジェンスチームがそれを検証する前に、規制対象かつ複雑な所有構造として整理すること。文書化されたケースは、問いが尋ねられた後に組み立てるのではなく、裏付けとなる事業計画書に備えておくべきものである。
よくある失敗
- スクリーニングに使用するための永続的な権利を持たずに、データをスクレイピングまたは購入すること。
- ツールを、顧客が依然として所有する判断を支援するものとしてではなく、顧客を「コンプライアンス対応」にするものとして説明すること。
- データ保護法の同意および目的に関する要件を事前に検討せずに、バイオメトリックデータを使用すること。
- オフショアのレビューチームやサブプロセッサーを、契約と購入者のデューデリジェンスファイルから除外しておくこと。
設立費用を比較することが、最もよくある初期の誤りである。重要なのはルート全体のコストである。エンティティ、購入者が求めるデータライセンスやセキュリティ保証、そしてソフトウェアのみでは不十分であった場合に後からマネージドレビューのレイヤーを追加するコストである。Velarozoneは、設立費用の見出しではなく、その全体のスタックの価格を算定し、Velarozoneの仕組みが説明する方法で自らのフィーを示す。
