Технологические лидеры финтеха и банков Азербайджана

Банковский стек: кто отвечает за инфраструктуру

В банковском блоке источники выделяют несколько фигур. Рамиль Насибов указан как заместитель председателя Правления и член Правления Rabitabank ASC, отвечающий за технологическое направление — Chief Technology Officer. По данным публикации, он ведет технологическую трансформацию и развитие IT-инфраструктуры одного из системных банков Азербайджана.

Дмитрий Казаны назван CTO Unibank; в его профиле отмечены роли CTO и CDO, опыт в AccessBank Azerbaijan, экосистеме Leobank и проектах e-commerce, включая Umico. Его специализация описана как цифровая трансформация банковских систем, миграция платформ и построение data-driven процессов.

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

Данные, ИИ и кибербезопасность становятся частью повестки

Vesti.az сообщает, что Азербайджан более пяти лет развивает цифровую экономику, а при Министерстве экономики действует Центр анализа и координации четвертой промышленной революции — 4SİM. В материале указано, что центр координирует стратегии, инициативы и проекты и способствует внедрению ИИ в сельском хозяйстве, энергетике и социальной сфере.

Отдельно источник пишет, что под председательством Первого вице-президента Азербайджана Мехрибан Алиевой 29 июня состоялось первое заседание Совета по цифровому развитию. На нем рассматривался план мероприятий по ускорению цифрового развития на 2026–2028 годы, включающий 58 инициатив, а также дорожная карта по цифровизации, искусственному интеллекту, кибербезопасности и инновационной экосистеме.

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

Что проверять клиентам и партнерам финтех-сервисов

В публикации the-tech.kz также названы Адиль Мамедов, CTO Fominov Consulting LLC, специализирующийся на технологической стратегии, цифровых решениях и управлении инженерными процессами; Муса Эльдар, CTO Space TV, отвечающий за технологическую платформу вещания и медиа-инфраструктуру; Джавид Алиев, CTO проекта Leops, связанный с направлениями AI, данных, кибербезопасности и облачных технологий, включая Kubernetes и cloud-native; Эмиль Мехдиев, директор департамента технологий, данных и аналитики в банковском секторе Азербайджана.

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

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