Развиваем приложение для крупного банка

Оцифровали РКК, чтобы ускорить выдачу кредитов клиентам

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

Мы подключили мобильные приложения к РКК, чтобы автоматизировать дистанционную подачу заявки и добавили возможность отображения её статуса в приложении. Самой сложной частью доработки стала динамическая анкета для заявки. Сначала мы разработали основные поля, чтобы пользователь мог вернуться к анкете в дальнейшем и заполнить до конца. При этом он не начинал заполнять заявку с нуля.

Банк сформировал требования для разработки. Мы разделили анкету на 3 этапа:

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

Внедряем платёжный сервис для оплаты штрафов и налогов в приложении

Банк планировал создать многофункциональное приложение, чтобы клиенты дольше оставались в нём и могли оплачивать внешние сервисы, например, ЖКХ и налоги. Для этого мы:

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

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

Скоро: защита от мошенничества, чтобы сократить риск передачи данных непроверенным лицам

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

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

Внедрили обновления внутри приложений и выложили в доступные сторы

Мы должны были доставить приложения для пользователей другими способами. Для Android внедрили несколько решений:

• Добавили возможность скачивать APK-файл приложения на сайте банка.
• Одними из первых среди финтех-сферы опубликовали приложение на GalaxyStore и RuStore.
  Начали подготовку к публикации на Huawei App Gallery. Для этого перенесли сервисы с Google-сервисов на сервисы Huawei.
• Отказались от многих привычных функциональностей Google: платформы Firebase для разработки, оплаты через Google Pay, добавления карт лояльности в Google Pay, построения маршрутов через GoogleMaps и распознавания штрих-кодов. Интегрировали приложение с Huawei-сервисами: добавили локацию и карту, чтобы можно было искать банкоматы на устройствах Huawei.
• Добавили обновления внутри приложения на Android. Теперь пользователю не нужно переходить на сайт за каждым обновлением. Приложение само сообщает пользователю о том, что доступна новая версия. Дополнительно приложение показывает информацию, что изменилось в новой версии.

Опубликовали приложение в App Store с помощью клонов и обфускации

8 месяцев восстанавливали доступ к публикации приложения в App Store. Чтобы разработать правильную стратегию и не ошибиться, сначала обсудили и исследовали возможные подходы к решению этой задачи. Мы знали, что должны разработать приложение-клон, как делают другие банки. Вопрос был в том, как такие приложения проходят проверку App Store.

Выяснили, что разработчики при публикации приложения должны были показать, что приложение полностью соответствует заявленной функциональности. Например, если просто назвать приложение по-другому, администрация площадки в итоге всё равно увидит, что это банк под санкциями. Мы должны были продумать наполнение фейкового приложения и скрыть весь код. При этом приложение должно пройти динамическую (ручную) и статическую (автоматическую) проверку.

Этап 1. Создали приложение-клон для скрытия основного приложения

Реализовали фейковую часть приложения на Feature Flag, который управляется из одобренной Apple платформы Firebase. Мы включаем «флаг» перед проверкой приложения и оно показывает сервис для хранения дисконтных карт разных магазинов. Когда проверка пройдена, мы выключаем «флаг» и приложение превращается в банковское.

Этап 2. Обфусцировали код для прохождения проверки функциональности приложения

App Store проверяет не только соответствие контента приложения заявленному, но и основную часть кода. Поэтому мы провели обфускацию кода. Это значит, что мы «запутывали» код для внешних проверок, но оставляли при этом всю функциональность приложения. App Store не могли анализировать, как работает приложение.

Например, наши разработчики искали вручную все триггерные слова, которые не дадут пройти проверку — «банк», его название и другие. Мы переименовали каждый класс функций приложения и создали словарик для них. Так обезличили основное приложение. При этом разработали отдельное приложение на Mac OS, которое самостоятельно обфусцирует код по ключевому слову и ищет «перевод» изменённой функции. Так мы разгрузили разработчиков от рутинной работы и автоматизировали процесс.

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

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

Этап 3. Подготовка к публикации в App Store

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

1. Создали новый аккаунт разработчика для публикации приложения.
2. Согласовали, что будет в приложении при публикации. В нём должна быть вся функциональность до блокировки и все решения, которые добавили в Android-приложение после блокировки.
3. Сформировали план релизов, чтобы сократить до минимума риск новой блокировки. Сначала опубликовали фейковое приложение, затем основную функциональность ДБО и дальше запланировали скрытие приложения в сторах.
4. Запланировали стратегию информирования клиентов об использовании приложения и изменениях в нём.
   Например, мы учитывали, что пользователи могут оставить негативный комментарий и пожаловаться на фейковое приложение. Поэтому после релиза ДБО продержали приложение открытым две недели, а затем скрыли для всех регионов, кроме Грузии. Пользователей попросили поменять геолокацию и объяснили, что это поможет сохранить приложение в App Store.

Благодаря грамотной стратегии сэкономили около 2 млн руб. и 6 месяцев на разработке для банка.