Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Разработка мобильного приложения для банка связывает повседневные задачи клиента с банковскими сервисами. Для первой версии важны баланс и история транзакций, безопасный вход и возможность обратиться в поддержку: клиент видит состояние счета, выполняет операцию и понимает ее результат. Состав этих функций команда согласует с банком, проверяя, какие интеграции доступны.
В статье расскажем, как устроено такое приложение, что проверить при выборе подрядчика и как складывается оценка проекта. Разберем пример сметы Purrweb и объясним, почему стоимость зависит от интеграций и состава работ.
Через банковское приложение человек получает доступ к своим счетам и услугам банка со смартфона. Когда клиент отправляет перевод, он указывает получателя и сумму в мобильном интерфейсе, а саму операцию обрабатывает серверная часть банка. Приложение связывается с ней через API (программные интерфейсы), чтобы передать запрос и показать результат.
Поэтому разработка банковского ПО охватывает больше задач, чем создание экранов для телефона: за ними работают серверные системы обработки операций. При разработке мобильного банка команда выясняет, какие из этих систем уже есть и как к ним подключить приложение. Здесь разбираем именно мобильный клиент, а запуск необанка как бизнеса рассматриваем отдельно.
Дистанционное банковское обслуживание позволяет банку проводить обычные операции онлайн, поэтому мобильный канал планируют как часть обслуживания, а не витрину услуг. По итогам 2025 года граждане получали онлайн почти 89% финансовых услуг, сообщает Банк России. Это показатель цифровизации услуг, а не доля пользователей мобильных банков.
Для первой версии важнее конкретные клиентские сценарии, чем число функций. Когда человек проверяет остаток или отправляет перевод, он рассчитывает завершить действие в приложении. Поэтому команда сначала проверяет, доступны ли все нужные операции через банковские сервисы, а затем согласует с банком, какие из них войдут в мобильный продукт.
Да, приложение может приносить банку доход, когда клиент пользуется платными банковскими услугами. Например, за обслуживание счета, международный перевод или обмен валюты банк получает комиссию. В мобильном канале человек обращается к тем же услугам, поэтому способ заработка связан с операцией и тарифом банка, а не с самим наличием приложения.
При планировании продукта банк определяет, какие услуги будут доступны клиенту со смартфона и на каких условиях. Так можно связать функции приложения с источниками дохода: перевод дает доступ к операции, а размер комиссии за нее задает тариф. При этом доход от услуги еще не означает прибыль самого мобильного продукта.
Перед тем, как нанимать команду разработчиков для банковского приложения, стоит посмотреть, как работают лидеры рынка. Например, что отличает их от конкурентов и на каких функциях они решили сфокусироваться. Мы выбрали три популярных приложения из разных регионов: из США, России и Германии.
Chime — американская финтех-компания, которая появилась в 2014 году. Банковские услуги и дебетовые карты предоставляют банки-партнеры.
В приложении Chime пользователи могут всего за пару кликов открыть бесплатную дебетовую карту или накопительный счет. Поскольку услуги предоставляют банки, все счета застрахованы FDIC (Федеральная корпорация по страхованию вкладов). Для обычных людей услуги бесплатны — Chime зарабатывает деньги с комиссии за транзакции. Ее платят владельцы торговых точек и бизнесов.
Изначально Chime прославился благодаря своему UI/UX, простому и понятному копирайтингу и минималистичной функциональности. Сейчас приложение — образец для новых проектов в сфере диджитал-банкинга.
У Т-Банка нет физических отделений, только мобильное приложение и банкоматы в крупных городах. Банк получил несколько наград за высокое качество сервиса и цифровые решения в сфере интернет-банкинга.
Цель приложения Т-Банк — упростить управление финансами. Чтобы открыть счет, пользователю нужно только скачать приложение, заполнить форму онлайн и прикрепить необходимые документы. В течение пары дней в гости приедет представитель банка, чтобы проверить личность и вручить карту.
С самого начала приложение объединяет сразу несколько продуктов и услуг. Пользователь может открыть дебетовую или кредитную карту, накопительный счет. Еще можно перевести деньги, получить кэшбэк, начать инвестировать или найти ближайший банкомат.
Со временем Т-Банк добавил на платформу развлекательные сервисы и карточки с полезным контентом. Например, пользователи могут купить билет в кинотеатр или на музыкальный фестиваль.
Банковское приложение может задавать тренды. Т-Банк был первым из онлайн-банков, кто запустил функцию «историй» на платформе.
N26 — банковское приложение из Берлина, которое в 2021 году работало в 24 европейских странах. В нем пользователи могут получить бесплатную дебетовую карту, чтобы расплачиваться за покупки и переводить деньги. За небольшую ежемесячную плату можно получить доступ к премиальным функциям.
Например, к овердрафту — тратить чуть больше, чем есть на карте — и к инвестициям. Главное преимущество продукта в том, что он на 100% онлайн. Пользователь может пользоваться безопасным мобильным банкингом, не посещая отделение и не получая письма на почту.
N26 стал конкурентом для привычных больших банков, получив более 7 миллионов новых пользователей в 2021 году. Тогда же компанию оценили в 9 млрд долларов.
Интерфейс приложения — простой и сдержанный, со своей собственной типографикой. Для логотипа дизайнеры N26 выбрали минималистичный шрифт с отрицательным пространством — свободным пространством внутри и между элементами дизайна.
Это отсылка к логотипам люкс-брендов. Компания вывела разработку приложений для мобильного банкинга на новый уровень. Мы рекомендуем изучить их сервис перед тем, как приступить к собственному проекту.
В хорошем банковском приложении клиент понимает, как выполнить операцию и что произошло с деньгами после нее. Например, перед переводом он видит получателя и сумму, а после подтверждения получает статус обработки. Чтобы такой сценарий работал, недостаточно нарисовать понятные экраны: мобильный клиент получает данные о счете и результате операции от банковских систем через API.
При этом аутентификация подтверждает личность пользователя, после чего сервер проверяет его права доступа и допустимость запроса. Даже понятная форма перевода не заменяет этих проверок, а интеграция с банковскими API связывает действие на экране с обработкой операции. Пароль или Face ID сами по себе не означают многофакторную защиту: она зависит от сочетания независимых способов проверки.
Для первой версии мобильного банка выбирают функции, с которыми клиент сможет пройти повседневный сценарий целиком. Проверить баланс недостаточно, если затем нельзя отправить перевод или узнать, почему он еще не выполнен. Ниже разбираем, какую задачу решает каждая функция и как связать действие пользователя с данными банка.
Перед платежом человек проверяет, сколько денег доступно на счете, с которого собирается платить. На главном экране баланс показывают рядом с выбранной картой, чтобы было понятно, к какому счету относится сумма. Если карт несколько, такая связь помогает сверить остаток именно там, откуда пойдут деньги.
При проектировании команда определяет, какие данные о счете приложение получит от банка и как покажет их на экране. Так клиент сможет проверить баланс перед операцией, не переходя ради этого в другой раздел.
После покупки или перевода человек сверяет списание со своими действиями. В истории транзакций он ищет операцию по дате и сумме, а по описанию понимает, была ли это оплата товара или перевод. Эти сведения работают вместе: одна сумма без контекста не объясняет, куда ушли деньги.
Поэтому команда продумывает не только порядок записей, но и то, какие данные банк передаст для каждой из них. Когда дата, сумма и описание относятся к одной операции, клиент может сопоставить ее с покупкой и найти нужный платеж.
При переводе клиенту важно проверить реквизиты до отправки денег и увидеть результат после нее. Сначала приложение показывает получателя и сумму, чтобы человек мог сверить данные, а затем запрашивает подтверждение. После отправки запроса банк обрабатывает операцию и возвращает ее статус.
По этому статусу пользователь понимает, выполнен перевод или еще находится в обработке. Так интерфейс различает два события: клиент подтвердил действие, а банк сообщил о его результате. При разработке команда связывает эти состояния с ответами банковских сервисов, чтобы отправка запроса не выглядела как уже завершенный платеж.
Когда вопрос касается конкретного платежа, клиенту нужен способ связаться с сотрудником банка из приложения. Для этого предусматривают чат или звонок: человек может обсудить спорное списание, а не искать ответ среди общих описаний услуг.
Типовые вопросы выносят в справку, чтобы клиент мог прочитать ответ без ожидания сотрудника. При этом справка не заменяет поддержку по отдельной операции. При проектировании эти способы обращения разделяют, чтобы пользователь понимал, где найти общую информацию, а где обсудить свой платеж.
Для защиты входа сочетают независимые способы проверки, а не просто добавляют еще один экран подтверждения. Пароль проверяет знание секрета, проверка владения зарегистрированным устройством относится к другому фактору. Биометрический признак, например распознавание лица, связан с самим человеком.
Поэтому один Face ID не делает вход двухфакторным: значение имеет сочетание независимых факторов в одном сценарии. Команда согласует с банком, как приложение участвует в этой проверке. Так способ входа связывают с требованиями к защите доступа, а не оценивают только по удобству экрана.
После первой версии команда может добавить игровые механики для вовлечения клиентов. Их применение разбираем в статье «геймификация в банковских приложениях».
ZoidPay: На главном экране — общий баланс и последние транзакции; IBAN создаётся при регистрации, а реквизиты и выписка убраны в дополнительное меню.
Кошелёк можно создать или импортировать по сид-фразе; мультичейн объединяет кошельки разных сетей под одной фразой.
Процесс разработки начинается с того, что команда и банк согласуют действия клиента в первой версии приложения. На их основе проектируют экраны и подключают банковские сервисы, а перед выпуском проверяют, можно ли пройти эти сценарии на iOS и Android. Так у каждого этапа появляется результат, который используют в дальнейшей работе.
В таблице показано, что команда делает на каждом этапе и что проверяет перед переходом к следующему. Запуск завершает разработку, а поддержку после него заказывают отдельно.
| Этап | Проверяемый результат |
| 1. Аналитика | Команда согласует с банком клиентские сценарии и состав первой версии, затем проверяет доступность банковских API. В результате понятно, какие операции войдут в приложение и через какие сервисы их можно выполнить. |
| 2. Проектирование | Дизайнеры готовят прототип и проверяют, как пользователь входит в приложение, смотрит баланс и отправляет перевод. По этому прототипу банк и разработчики согласуют действия на экранах до их реализации. |
| 3. Разработка | Разработчики создают клиентскую и серверную части и подключают банковские сервисы через согласованные интерфейсы. На этом этапе действия из прототипа связывают с обработкой запросов, чтобы приложение получало данные о счете и результатах операций. |
| 4. Тестирование | Команда проверяет расчеты и обработку ошибок, а также работу под нагрузкой и защиту пользовательских данных. Результат проверки показывает, какие ошибки в согласованных сценариях еще предстоит исправить перед выпуском на iOS и Android. |
| 5. Запуск и поддержка | Команда готовит релиз, а для работы после запуска согласует мониторинг операций и порядок исправления ошибок. При этом поддержку заказывают отдельно: ее объем и обязанности не включают в разработку по умолчанию. |
При выборе разработчика оценивают банковские интеграции и проекты, в которых команда работала над:
В Purrweb у нас был такой опыт: мы разработали электронный криптокошелек со многокомпонентным дашбордом и виджетами.
⬇️ Если вам интересно узнать больше о наших кейсах, читайте статью о криптокошельке Broex. Узнайте, как мы подбирали стиль для дизайна и изобретали меню выбора валют.
Калькулятор ниже дает предварительный расчет для банковского приложения на iOS и Android. Его результат помогает обсудить бюджет, но не заменяет оценку функций и интеграций конкретного проекта.
Сколько стоит разработка банковского приложения? Давайте разберемся на примере аналогичного проекта.
🚨Предупреждение: таблицу подготовила наша команда, и мы не гарантируем, что у других компаний будут такие же цены и сроки. Оценка актуальна только если вы решите работать с нами.
| Этап | Что мы делаем | Количество часов | Количество недель | Стоимость |
| Встреча с заказчиком | Обсуждаем идею вашего приложения | 1 день | – | Бесплатно |
| UI/UX дизайн | Создаем карту пользовательского путешествия, придумываем прототипы экранов и показываем вам | 170 часов | 5 недель | 477 169 руб |
| Разработка | Работаем над интерфейсом и архитектурой со стороны клиента и сервера | 1400 часов | 16 недель | 3 929 631 руб |
| QA тестирование | Ищем потенциальные баги и устраняем их | 480 часов | Одновременно с разработкой | 598 800 руб |
| Администрирование проекта | Проджект-менеджер следит, чтобы задачи выполнялись в срок | – | Одновременно с UI/UX
и разработкой |
405 438 руб |
В целом разработка банковского приложения обойдется вам в 5 411 039 рублей и займет около 4 месяцев.
Первая версия банковского приложения закрывает повседневные операции, а не весь набор банковских услуг. Опыт команды проявляется в работе с финансовым интерфейсом и безопасностью, но состав продукта зависит от готовности интеграций. Проверка банковских сервисов помогает определить границы проекта до разработки.
➡️ Планируете банковское приложение? Обсудим функции первой версии и доступность банковских сервисов. Заполните форму для бесплатной оценки проекта в течение 48 часов.
Разработка ПО для банков охватывает не только мобильный интерфейс, но и серверную часть, интеграции с банковскими системами, обработку операций и инструменты сотрудников. В этой статье рассматриваем клиентское приложение: оно подключается к существующим сервисам банка, а не заменяет весь банковский программный комплекс.
В примере оценки Purrweb из этой статьи разработка стоит 5 411 039 рублей и занимает около 4 месяцев. Это оценка конкретного состава работ, а не универсальный тариф. Бюджет другого проекта зависит от функций, готовности банковских API, требований к защите данных и объёма тестирования.
.svg)
