銀行口座モニタリング規則と UAE のレグテックの機会

英国での議論は、福祉給付における不正や誤りを調べるため、銀行口座を確認したいと考える政府機関に関するものです。これは英国の法律で定められ、特定の申請者グループに対して行使される国家の権限です。UAE の民間企業に、他人の口座を調べる権利を与える同等の仕組みはありません。

英国の事例は、創業者に設計上の問いを投げかけます。モニタリングの連鎖のうち、自社はどの部分を担うのか、という問いです。銀行は義務を負っているため、取引モニタリングを実施しています。ソフトウェア会社は、それをより低コストでより正確にするツールを構築できます。しかし、データを閲覧するための銀行の権限を借りることはできません。

この線引きが規制上のルートを決定します。CBUAEのオープンファイナンス規則（C 03/2025）では、銀行のインターフェースを通じて顧客の口座データを取得する会社にはオープンファイナンスのライセンスが必要であり、銀行との契約に基づいて業務を行うベンダーは別のケースです。ピッチ資料では、ベンダー製品を規制対象の機能の言葉で説明してしまい、問題になることがよくあります。

同意・許可の管理。製品は顧客が何に同意したかを記録し、撤回を可能にし、監査証跡（audit trail）を保持します。取り扱うのは同意の記録であり、必ずしも基礎となる口座データではありません。中心的な義務が有効な同意を示すことにあるため、データ保護規則に最も近い類型です。

機関向けに販売されるモニタリングソフトウェア。実務上はデータ管理者（data controller）は銀行であり、ベンダーは銀行との契約の下で業務を行います。アクセス、保存、顧客データを用いたモデル学習、インシデント報告といった事項は、サービス契約で取り決めます。ベンダーに何らかの認可が必要かどうかは、具体的に何を行うかによって決まります。これは想定せず、関連する規制当局に確認すべき事項です。

オープンファイナンス分析。この類型では、企業が顧客の許可を得て、銀行のインターフェースを通じて顧客の口座データを読み取ります。CBUAE のオープンファイナンスの枠組みが関わるのはここであり、独自の認可が必要となる可能性が最も高いモデルです。オープンファイナンス事業者ルートに関する別のガイドが、その範囲を扱っています。

ケース管理および規制報告ツール。コンプライアンス担当チームが判断を記録するのを支援します。重要なのは、そのツールが人間の判断を記録するだけなのか、それとも自ら判断を下し始めるのかという点です。

グループは、これらのうち複数を単一のブランドの下で運営できますが、契約は異なります。

連邦個人データ保護法は、UAE 国内外で、全部または一部が電子的手段により行われる処理に適用され、越境移転について要件を定めています。UAE 内閣に付属する UAE Data Office がガイダンスを作成し、苦情を取り扱います。データ所有者は訂正を求めることができ、処理を制限または停止させることもできます。

モニタリングまたはデータ製品については、実務上、次の3点が重要です。同意は、ソフトウェアが実際にデータをどのように扱うかを十分に具体的にカバーしていなければなりません。同意の撤回は、利用規約だけでなく製品上で機能しなければなりません。また、クラウドリージョンや海外の親会社のためにUAE国外へ出るデータフローには、文書化された根拠が必要です。ライセンスを受けたオープンファイナンス提供者には、より厳格な条件が課されます。CBUAEのオープンファイナンス規則は、目的ごとに個別の同意を求め、同意の撤回は同意の付与と同じくらい容易でなければならないとしています。また、データはUAE国内に保管することを求めており、CBUAEが国外保管を承認し、かつ保管場所とその理由を告げられた顧客が書面で同意した場合に限り、例外が認められます。

所在地によって、さらに一層が加わります。UAE政府のデータ保護に関するページには、連邦法に加えて、DIFCデータ保護法（DIFC法2020年第5号）とドバイデータ法（2015年法律第26号）が掲載されています。したがって、金融フリーゾーン内の会社は、メインランド（mainland）の会社とは異なるデータ規制に服する可能性があり、双方のクライアントにサービスを提供する会社は両方の規制に服する可能性があります。連邦政府のページはこれらの相互関係を説明していないため、所在地を決定する前に、自社の構造における取り扱いをフリーゾーンの当局および関係する規制当局に確認する必要があります。

メインランド企業（mainland）は、主に UAE の銀行や法人に販売し、契約相手に地理的な制限を設けたくない事業に適しています。フリーゾーン（free zone）企業は、地域の顧客基盤を持つテクノロジー事業に適していることがありますが、それにはフリーゾーンのライセンス活動がソフトウェアおよびデータサービスに合致していること、そして契約が適切な事業体と結ばれることが条件です。

レグテック（RegTech）ベンダーにとっての実務上の検証事項は、商社の場合とは異なります。ライセンスはソフトウェア開発とデータ処理を正確に記述できるか。銀行の調達チームはその事業体を取引先として受け入れるか。スタッフはどこに勤務し、その所在地は創業チームの居住ビザのうちどれに対応しているか。データは物理的にどこでホストされるのか。

製品が規制対象のデータに触れることが後で判明し、ライセンスの事業活動を修正しなければならない場合、設立価格が低いことはほとんど意味を持ちません。まず製品の境界を確定し、その後に所在地を比較してください。この順序はVelarozoneの進め方で説明しています。

創業者は、銀行取引を会社設立後の作業とみなしがちです。この分野では、それは営業プロセスでもあります。モニタリングソフトウェアを購入する銀行も、御社自身の法人口座を開設する銀行も、一貫した全体像を確認したいと考えます。

次のような質問が想定されます。会社を誰が所有し、コードを誰が管理しているか。顧客データはどこに保管され、誰がアクセスできるか。モデルはどのようにテストされ、誤検知はどのように処理されるか。情報漏えいの後に何が起こるか。所有に関しては、CBUAEのガイダンスは、銀行が法人顧客の25%以上を所有または支配するすべての個人を特定し、確認することを求めています。誰も25%に達しない場合は、代わりに上級管理者を特定します。銀行は、製品の信頼性はそれを支えるチームの信頼性を超えないため、社員にコンプライアンスの経験があるかどうかも尋ねます。

自動アラートは特有の懸念を生みます。モデルが口座にフラグを立て、アナリストがそのフラグをそのまま受け入れる場合、その判断は事実上自動化されています。規制対象の顧客は、文書化された人間の判断を支援するツールを好みます。これを最初からワークフローに組み込むほうが、銀行に求められてから後付けするより安く済みます。

RegTechのKYC・AMLプラットフォームのルートは、モニタリングと大きく重なります。購入者は同じコンプライアンス部門であるため、同じベンダー審査が適用されます。