Разработка банковского приложения: что учесть заранее

Чем банковское приложение отличается от обычного

Для многих клиентов в Ташкенте и регионах мобильный банк — главный способ общаться с банком: перевод родственникам, оплата коммунальных услуг, заявка на кредит. Поэтому разработка банковского приложения начинается не с дизайна, а с перечня рисков. Обычное приложение с багом раздражает, банковское — лишает человека денег и доверия.

Что именно делает проект особенным:

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

Вход, доступ и подтверждение операций

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

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

Защита данных и борьба с мошенничеством

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

Но деньги клиенты чаще теряют не из-за взлома систем, а из-за социальной инженерии: звонок «из банка», поддельная ссылка в мессенджере, просьба продиктовать код из SMS. Приложение может с этим помогать:

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

Надёжность и интеграции

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

Само приложение — вершина большой системы: АБС, процессинг, платёжные системы страны, скоринг, CRM, уведомления. Обычно между ними и приложением строят промежуточный слой API, который скрывает сложность внутренних систем и защищает их от прямых обращений.

Регулятор и команда

Банк обязан соблюдать требования Центрального банка Республики Узбекистан к информационной безопасности и дистанционному обслуживанию, а также закон о персональных данных, включая хранение данных на территории страны. Точный перечень требований команда получает от службы комплаенса и информационной безопасности банка до начала проектирования, а не после первой версии.

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

Интерфейс и тестирование

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

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

Когда хватит Telegram-бота

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

Принципы те же, что в банке: минимум хранимых данных, понятные подтверждения, защита от повторных списаний и предупреждение клиентов о мошенниках. Если ваша задача ближе к такому сервису, markdev поможет разобрать сценарии и собрать Telegram-бота под ваш процесс. Опишите задачу, и мы обсудим, с чего начать.