Как отделить техническую функцию продукта от финансовой в ОАЭ: практическая проверка на примере розничных платежей

Короткий ответ

Если отвечать прямо, техническая функция продукта в примере ОАЭ отделяется от финансовой не по названию сервиса и не по формулировке на сайте, а по фактической роли в платёжной операции. В рамках регламента CBUAE по розничным платёжным услугам важен вопрос: входит ли компания во владение деньгами в рамках соответствующей платёжной услуги. Для поставщиков технических услуг источник прямо предусматривает исключение, когда провайдер не получает такого владения средствами в рамках этой услуги [1].

Но на этом нельзя останавливаться. Тот же регламент содержит и другие исключения и одновременно регулирует широкий круг розничных платёжных услуг и карточных схем [1]. Поэтому ответ «мы просто IT-компания» сам по себе ничего не доказывает. Сначала нужно разложить продукт на фактические функции, потом проверить движение денег, и только после этого обсуждать применимость исключения или необходимость дальнейшей проверки.

Когда эта статья применима

Эта статья опирается на один конкретный источник: Регламент Центрального банка ОАЭ по розничным платёжным услугам и карточным схемам [1]. Поэтому она полезна как рабочий пример именно для ОАЭ и именно в контексте розничных платежей.

Это важно проговорить сразу.

Во-первых, здесь нет универсального теста для любого программного, финансово-технологического или цифрового продукта.

Во-вторых, здесь нет вывода о лицензии конкретного бизнеса без проверки фактов.

В-третьих, авторская карта ниже — это удобный способ внутренней подготовки, а не обязательная государственная форма.

Если ваш продукт вообще не связан с розничными платёжными услугами, этот материал можно использовать только как способ думать о функциях, но не как прямой юридический ответ.

Где возникает ошибка

Проблема начинается, если команда описывает продукт языком презентации:

• мы даём инфраструктуру;
• мы только соединяем стороны;
• мы не банк;
• мы просто технический провайдер.

Для бизнеса это звучит логично. Для проверки применимости регулирования этого мало.

Регуляторный вопрос обычно устроен иначе. Нужно понять не то, как продукт продаётся клиенту, а то, что фактически происходит внутри платёжной цепочки:

• кто получает платёжную инструкцию;
• кто передаёт данные дальше;
• кто участвует в маршрутизации операции;
• возникает ли момент, когда компания юридически или фактически принимает деньги под свой контроль;
• кто отвечает за договорную связь с участниками платёжной операции.

Именно здесь техническая роль может закончиться, а финансовая — начаться.

Что источник подтверждает прямо

Из подтверждённой базы для этой темы можно опираться на три вещи.

1. Есть исключение для поставщиков технических услуг

Регламент CBUAE по розничным платёжным услугам прямо описывает исключение для поставщиков технических услуг в соответствующей части регулирования, если такой провайдер не получает владение деньгами в рамках этой платёжной услуги [1].

Это полезная точка опоры, потому что она показывает сам принцип разграничения: инфраструктурная или техническая поддержка может рассматриваться отдельно от обращения с деньгами.

2. Отсутствие владения средствами не равно автоматическому освобождению от любых вопросов

Тот же регламент перечисляет и другие исключения, включая категории вроде инструментов хранения стоимости, токенов виртуальных активов, денежных переводов и внутригрупповых операций [1].

Практический смысл здесь очень важен. Нельзя взять одну фразу про поставщиков технических услуг и превратить её в универсальное правило «если мы не трогаем деньги, регулирования нет». Источник этого не подтверждает.

Правильный вывод уже и полезнее: отсутствие владения средствами — сильный вопрос для проверки, но не автоматический финальный ответ по любому продукту.

3. Регламент охватывает широкий круг платёжных функций

Источник также подтверждает, что рамка касается широкого круга розничных платёжных услуг и карточных схем, а для отдельных моделей предусматривает требования к договорным отношениям, в том числе между эмитентами счетов и провайдерами AIS/PIS [1].

Из этого следует ещё одна практическая мысль: даже если продукт выглядит технологичным, нужно смотреть, не встроен ли он в регулируемую цепочку глубже, чем это кажется на уровне маркетингового описания.

Рабочий принцип: сначала функции, потом ярлык

Полезнее всего разбирать продукт на два слоя.

Технические функции

Это обычно то, что связано с инфраструктурой и обработкой информации:

• хостинг;
• передача данных;
• обработка интерфейсных запросов;
• техническое обслуживание терминалов или интеграций;
• программный слой, который помогает участникам обмениваться сообщениями.

Сама по себе такая роль ещё не означает, что компания обращается с деньгами.

Финансовые функции

Это уже другой слой. Сюда относятся функции, где нужно особенно внимательно смотреть на факты:

• приём денежных средств;
• хранение средств;
• перечисление средств;
• участие в выплатах;
• эквайринговая или сходная роль в цепочке расчётов;
• ситуация, где компания фактически или юридически контролирует деньги хотя бы на одном этапе операции.

Для этой статьи важно не дать лишний юридический ярлык. Поэтому безопаснее формулировать так: чем ближе функция к фактическому приёму, удержанию или контролю над деньгами, тем слабее выглядит простое объяснение «мы только технология» и тем важнее отдельная проверка применимости регулирования [1].

Авторская карта проверки: как разложить продукт по фактам

Ниже — не обязательный тест регулятора, а удобный рабочий способ для команды продукта, собственника или юриста внутри компании.

Шаг 1. Разделите продукт на отдельные функции

Не описывайте продукт одной общей фразой. Разбейте его на конкретные действия.

Например:

• интерфейс для пользователя;
• передача платёжной инструкции;
• хранение платёжных реквизитов;
• передача данных банку или иному участнику;
• формирование подтверждения;
• обработка возврата;
• расчёт комиссий;
• участие в зачислении или выплате средств.

На этом этапе задача простая: увидеть, что продукт делает по частям, а не как он называется целиком.

Шаг 2. Для каждой функции задайте один главный вопрос

Входит ли компания во владение деньгами в рамках этой функции?

Это можно раскрыть через более приземлённые подпункты:

• деньги когда-либо поступают на счёт компании;
• компания может удержать, направить или перераспределить сумму;
• деньги временно проходят через контур компании;
• клиент или партнёр видит компанию как сторону, принимающую платёж;
• без действия компании деньги не двигаются не только как данные, но и как объект контроля.

Если на все такие вопросы ответ отрицательный, а роль ограничена маршрутизацией данных или инфраструктурной поддержкой, это ближе к технической функции в логике рассматриваемого исключения [1].

Шаг 3. Сопоставьте функцию с исключениями и контекстом

Даже если владения средствами нет, работу нельзя останавливать на этом месте.

Нужно отдельно спросить:

• попадает ли модель в иной контекст, упомянутый в перечне исключений;
• не относится ли продукт к другой регулируемой функции внутри розничных платёжных услуг;
• есть ли договорная роль, которая выводит продукт из чисто технического описания.

Именно этот шаг защищает от слишком раннего вывода «деньги не держим — вопрос закрыт».

Шаг 4. Нарисуйте карту потоков

Одна диаграмма часто полезнее десяти абзацев объяснений.

Покажите:

• пользователь;
• платёжный инструмент или интерфейс;
• банк, эмитент, эквайер или иной участник цепочки;
• сам продукт;
• где проходят данные;
• где проходят деньги;
• кто и в какой момент получает контроль над каждым элементом.

Для внутренней работы полезно отдельно выделить два цвета: поток данных и поток денег. Если команда смешивает эти два маршрута, возникает путаница.

Шаг 5. Поднимите документы, а не только схему

Сильная карта всегда подтверждается документами.

Обычно полезно собрать:

• договоры с банками и партнёрами;
• соглашения об уровне сервиса и технические соглашения;
• описание расчётной цепочки;
• расчётные потоки;
• технические логи;
• пользовательские условия;
• внутреннее описание роли компании в операции.

Если компания утверждает, что не входит во владение средствами, это желательно подтверждать не лозунгом, а совокупностью документов и фактической архитектуры.

Практическая таблица для первого прохода

Ниже — простой рабочий шаблон.

Таблицу можно прокрутить по горизонтали →

Эта таблица не даёт лицензии и не снимает её. Но она быстро показывает, где у команды есть только техническое описание, а где уже начинается финансовая роль.

Гипотетический пример

Представим условный продукт в ОАЭ.

Первая версия продукта только передаёт платёжную инструкцию от пользователя к банку-партнёру. Компания не принимает деньги на свои счета, не удерживает их и не перераспределяет. Она поддерживает интерфейс, логику передачи данных и техническую доступность сервиса.

В такой конфигурации у команды есть аргумент проверить модель как техническую поддержку в логике рассматриваемого исключения [1]. Но даже здесь нужен следующий шаг: подтвердить это по договорам, карте потоков и фактической архитектуре.

Теперь представим вторую версию того же продукта. Компания по пути операции начинает принимать сумму, пусть даже кратко, в свой расчётный контур перед дальнейшим перечислением.

Вот здесь главный вопрос уже меняется. Спор идёт не о том, как назвать продукт, а о том, осталась ли его роль чисто технической. Само наличие такого момента ослабляет простое объяснение «мы только про технологии» и требует отдельной проверки применимости регулирования на более глубоком уровне [1].

Важно, что этот пример остаётся именно примером. Он не доказывает лицензионный статус конкретного продукта без детального разбора фактов.

Что полезно подготовить до разговора с консультантом или регулятором

Если вы хотите получить более предметный ответ, соберите один короткий пакет.

1. Список функций продукта

Не общая презентация для инвесторов, а перечень конкретных действий системы.

2. Карта данных и денег

Отдельно покажите, где движутся данные и где движутся деньги.

3. Роль компании на каждом этапе

Для каждого шага ответьте:

• кто действует;
• кто контролирует деньги;
• кто является стороной по договору;
• кто хранит подтверждения.

4. Договорные документы

Поднимите соглашения с банками, платёжными партнёрами, поставщиками инфраструктуры и клиентами.

5. Доказательства отсутствия владения средствами, если вы на это ссылаетесь

Это могут быть архитектурные схемы, логика расчётов, банковские условия и иные материалы, которые показывают, что продукт работает как технический слой, а не как держатель или распределитель денег.

Если вы готовите саму операционную карту продукта до регуляторного вопроса, может пригодиться и отдельный материал о том, какие операционные действия продукта описать перед проверкой лицензирования в ОАЭ.

Что эта статья сознательно не утверждает

Чтобы не сделать слишком широкий вывод, границы лучше обозначить прямо.

Эта статья не утверждает:

• что любой поставщик программного обеспечения автоматически исключён из регулирования;
• что отсутствие владения средствами всегда закрывает вопрос лицензирования;
• что один и тот же тест подходит для всех финансовых продуктов;
• что любой продукт в ОАЭ можно квалифицировать без проверки договоров, платёжных потоков и фактической архитектуры;
• что авторская карта функций заменяет юридическое заключение.

Её задача уже и практичнее: помочь команде отделить технический слой от потенциально финансового на языке фактов.

Вывод

На примере розничных платежей в ОАЭ техническая функция продукта отделяется от финансовой не названием сервиса, а вопросом о фактическом владении деньгами и общей роли в платёжной цепочке. Исключение для поставщиков технических услуг — полезная отправная точка, но не универсальное освобождение для любого цифрового продукта [1].

Практический следующий шаг простой: возьмите один продуктовый сценарий, разложите его на функции, отдельно нарисуйте поток данных и поток денег, а затем проверьте, возникает ли в какой-либо точке владение средствами. Уже после этого обсуждайте с консультантом или регулятором, насколько модель остаётся технической и какие нормы нужно проверять дальше.

Источники

[1] Центральный банк ОАЭ, Регламент о розничных платёжных услугах и карточных схемах, Circular No. 15/2021: https://centralbank.ae/media/4came3rh/2021-c-15-2021-retail-payment-services-and-card-schemes-reg_0.pdf

Дисклеймер: Материал носит общий информационный характер и не является индивидуальной юридической или регуляторной консультацией. Для вывода о лицензировании конкретного продукта в ОАЭ нужно отдельно проверить фактические платёжные потоки, договоры, архитектуру сервиса и актуальную применимость соответствующих правил.