Каждый брокер рано или поздно просит собственное мобильное приложение. Логика понятна: клиенты живут в своих телефонах, приложение поставщика платформы несёт чужой логотип, а фирменная иконка на домашнем экране трейдера чего-то да стоит. Затем проект сталкивается с командой проверки Apple, и сроки удваиваются.
Вот что на самом деле представляют собой варианты, что должно делать приложение и где отклоняют заявки.
Три способа выпустить торговое приложение на своё имя
Первый вариант — не иметь его вовсе. Ваши клиенты скачивают приложение поставщика платформы и выбирают ваш сервер. Это ничего не стоит, не несёт риска для магазина приложений и вообще не даёт вам брендинга. Для нового брокера с небольшим объёмом бизнеса это часто правильное решение на первый год.
Второй — мобильное приложение White Label от поставщика вашей платформы, опубликованное под вашей компанией. Такое предлагают несколько провайдеров платформ. Вы получаете своё имя и цвета на проверенном торговом терминале и наследуете листинг, процесс проверки и цикл обновлений. Стоимость разработки невысока, а текущие обязательства вполне реальны.
Третий — кастомное приложение, построенное на вашем CRM и торговых API. Это единственный путь, при котором приложение может делать всё, что нужно клиенту, в одном месте: регистрировать, загружать документы, пополнять счёт, открывать новый торговый счёт и показывать баланс рядом с графиком. Но это и самый дорогой вариант, а также единственный, где все отказы — ваша ответственность.
Стоит прямо сказать о третьем варианте: для большинства брокеров торговый терминал — не то, что отличает вас от других. Трейдеры, которым важен анализ графиков, уже установили MetaTrader или cTrader и не собираются менять их на вашу версию свечного графика. По-настоящему вашей частью опыта является зона аккаунта, поэтому многие кастомные приложения занимаются онбордингом, пополнением и управлением счетом, а сам экран торговли передают приложению платформы.
Что приложение должно делать помимо отображения графиков
Разрастание объёма работ губит такие проекты, поэтому заранее решите, что из этого входит в первую версию:
- Регистрация и вход, желательно общие с вашей веб-клиентской зоной, чтобы клиент не поддерживал две разные учётные записи.
- Загрузка документов с помощью камеры телефона — это одна из главных причин, почему мобильный онбординг показывает лучшую завершённость, чем десктопный.
- Пополнения и выводы, включая те локальные методы, которые реально используются в ваших регионах.
- Список счетов, балансы, плечо и данные для входа в платформу.
- Push-уведомления о уровнях маржи, одобрении документов и статусе платежей.
Этот список описывает trader’s room в оболочке приложения, а именно так и должно быть. Если те же данные уже питают ваш веб-портал, мобильная разработка — это проект интерфейса, а не проект платформы. CRM API — это то, под что пишет код мобильный разработчик, и стоит проверить, что оно предоставляет всё из списка, прежде чем кто-либо напишет хоть строку Swift. У Prop Firm похожий список, но с другим содержанием, поскольку эквивалентный экран — это challenge dashboard с прогрессом по правилам, просадкой и статусом выплаты.
Push-уведомления заслуживают отдельного упоминания. Во многих случаях это и есть причина вообще делать приложение, потому что это единственный канал, который достаёт трейдера, не конкурируя с почтовым ящиком. Margin call, одобрение верификации и неудачные пополнения — это уведомления, которые действительно нужны клиентам, и они должны отправляться из той же notification system , которую уже использует ваш CRM, а не из отдельного инструмента, за которым никто не следит.
Как пройти проверку Apple
Четыре правила объясняют большую часть отклонений в этой категории.
- Guideline 3.2.1(viii) — первое, что стоит прочитать. Текст Apple: «Приложения, используемые для финансовой торговли, инвестирования или управления денежными средствами, должны подаваться финансовым учреждением, которое оказывает такие услуги, и должны иметь необходимые лицензии и разрешения в тех локациях, где вы делаете их доступными». На практике это означает, что учётная запись разработчика принадлежит вашей лицензированной организации, имя в учётной записи совпадает с именем в лицензии, а география доступности приложения соответствует тому, где вам действительно разрешено работать. Заявка, поданная агентством разработки от вашего имени, почти наверняка получит отказ.
- Guideline 4.3(b) касается приложений, которые «неотличимы от уже широко доступных». Фирменные варианты одного и того же торгового терминала опасно близко подходят к этой границе, именно поэтому для каждого брокера клоны хорошо известной платформы уже много лет остаются сложным путём. Защитой здесь служит то, что ваше приложение делает то, чего не делает обычное, — и это ещё один аргумент в пользу разработки зоны аккаунта, а не ещё одного экрана графиков.
- Guideline 4.2 ловит «тонкие» приложения. Если ваша заявка — это обёртка web view вокруг клиентского портала, в которой больше ничего нативного нет, ожидайте вопроса, что приложение добавляет по сравнению с мобильным сайтом. Захват документов камерой, биометрический вход и push-уведомления — это типичные ответы, и они должны быть реализованы до подачи, а не обещаны в комментариях к проверке.
- Guideline 5.1.1 требует политику конфиденциальности, в которой указано, какие данные вы собираете, как используете их, с кем делитесь и как пользователь удаляет свои данные. Apple также ожидает, что удаление аккаунта будет доступно внутри приложения. Для регулируемого брокера с обязательствами по хранению записей нужен реальный ответ: обычно это удаление аккаунта приложения плюс чёткое указание, что и как долго должно храниться по закону.
Две практические вещи, которые ускоряют проверку: дайте ревьюеру рабочие тестовые учётные данные для счёта с деньгами и открытыми позициями, а также приложите короткую запись экрана со сценарием. Ревьюеры, которые не могут пройти ваш KYC-барьер, скорее отклонят заявку, чем будут разбираться.
Вопрос встроенных покупок для Prop Firm
У Prop Firm есть дополнительная проблема. Guideline 3.1.1 требует использовать встроенные покупки для разблокировки функций или контента и прямо запрещает применять для этого собственный механизм. Является ли плата за challenge цифровым контентом — это вопрос, на который нужно получить ответ до того, как вы построите поток, а не после, потому что разница в комиссии достаточно велика, чтобы изменить unit economics.
Безопасный шаблон, который используют большинство операторов, — оставить покупку challenge на вебе, а в приложении показывать и управлять счетами, которые трейдер уже открыл. Правила Apple о ссылках на внешние покупки менялись несколько раз за последние годы и различаются по регионам, поэтому читайте актуальный текст guideline, а не пост в блоге двухлетней давности, этот материал — тоже.
Google Play
Play обычно быстрее, но у него своя бумажная часть. Любое приложение с финансовыми функциями должно заполнить декларацию Financial features в Play Console, а политика Financial Services устанавливает дополнительные требования, которые зависят от страны, включая в некоторых рынках документы о лицензировании. Заполняйте декларацию честно с первого раза, потому что исправления после отклонения идут медленнее, чем первоначальная проверка.
Вам также понадобится заполненный раздел «Безопасность данных», который соответствует вашей политике конфиденциальности, и вам следует заранее учесть требования Google к целевому уровню API, которые вынуждают выполнять техническое обновление каждый год, изменился ли ваш продукт или нет.
Еще один момент, который стоит проверить до того, как вы будете писать тексты для магазина: правила рекламы сложных спекулятивных финансовых продуктов ограничивают то, как вы можете описывать трейдинг в обоих магазинах и в рекламных объявлениях. Скриншоты, намекающие на прибыль, — надежный способ привлечь внимание модераторов.
Заложите бюджет на второй год, а не на запуск
Смета на разработку — это небольшая цифра. Каждый год появляются новые версии ОС, обязательное повышение уровня API на Android, обновления SDK от вашего поставщика платформы и цикл проверки для каждого из них. Приложение, на которое не выделен бюджет на поддержку, перестает работать примерно через восемнадцать месяцев и наносит бренду больше вреда, чем отсутствие приложения.
Если строка на поддержку не финансируется, честный ответ — это адаптивный клиентский кабинет, а не приложение. Хорошо сделанный мобильный веб-портал обеспечивает онбординг, пополнение и управление счетом со смартфона, поддерживает web push на большинстве устройств, не требует одобрения в магазине и может быть обновлен в тот же день, когда вы решите внести изменения.
Как принять решение
Посмотрите, какая доля трафика в вашем клиентском кабинете уже приходится на мобильные устройства и что именно делают эти пользователи. Если большая часть трафика — это проверка баланса и отслеживание депозитов, приложение поможет, и объем работ понятен. Если спрос исходит от отдела продаж, которому нужно что-то показать потенциальным клиентам, фирменный веб-портал решит ту же задачу за долю стоимости.
Если вы все же решите разрабатывать, сначала запустите клиентский кабинет, а торговый экран добавьте позже, если цифры это оправдают. Клиенты редко просят приложение, потому что хотят лучшие графики. Они просят его, потому что хотят, чтобы их деньги и документы были в одном тапе от них, что соответствует той картине, которую мы увидели при анализе что трейдеры на самом деле хотят от брокера.
Запросить консультацию по вашему мобильному клиентскому опыту
Получите экспертные рекомендации по выбору правильной мобильной стратегии для вашей brokerage или prop firm. Мы поможем вам оценить, что лучше соответствует вашему бизнесу, ожиданиям клиентов и операционным требованиям: нативное приложение, фирменный Trader Room или адаптивный веб-портал.
Вместе мы проанализируем текущий путь клиента и определим мобильную стратегию, рассчитанную на долгосрочную масштабируемость и удобство поддержки.
