Цифровая банковская платформа Self Cube — слой, через который банк выдаёт продукты в каналах дистанционного банковского обслуживания: интернет-банк, мобильное приложение, онбординг, платежи и сопровождение клиента живут в одном контуре. Это не отдельный сайт «поверх» учёта, а модель, где клиентский профиль, лимиты и бэк-офис связаны. Обычная витрина ДБО часто рисует экраны, а проводки и продукты остаются в разрозненных системах. Имеет смысл смотреть, отдаёт ли платформа продукт целиком — от заявки до операции — или только интерфейс. Self Cube рассчитан на первый вариант, с машиночитаемыми API и готовностью к AI-сценариям.

ДБО — дистанционное банковское обслуживание: каналы, в которых клиент открывает продукты, платит и смотрит историю без отделения. АБС — учётное ядро: счета, проводки, остатки. Платформа ДБО Self Cube не подменяет АБС и не становится «ещё одной бухгалтерской системой». Она оркестрирует цифровые продукты и каналы вокруг ядра: Temenos, Finacle, Flexcube или локальная АБС остаются источником истины по счетам, интеграция идёт через API-шлюз. Проверять нужно границу ответственности: что исполняет ядро, а что — цифровой слой. Если ждут замену АБС «под ключ», это другой класс проекта.

Обычная платформа интернет-банка заточена под экраны, маршруты и мобильный клиент. Self Cube собирает сначала возможности: микросервисы, контракты OpenAPI 3.1, OAuth 2.1, реестр сервисов и обмен событиями. Каналы не ходят в домен напрямую, только через API-шлюз. На этом же контуре можно включать AI-сценарии и агентов как участников процесса, а не как чат «сбоку». Имеет смысл сравнивать не «красивость приложения», а есть ли машиночитаемый слой продуктов, лимитов и аудита. Без него цифровой банк остаётся набором витрин, даже если UX современный.

Да. Self Cube ставится как промежуточный слой над текущей АБС: Temenos, Finacle, Flexcube и локальные ядра стыкуются через API-шлюз и шину, без обязательной замены учёта. Банк сохраняет счета и проводки там, где они уже ведутся, а в цифровой слой отдаёт онбординг, платежи, каналы и продуктовые сценарии. Срок и глубина зависят от качества существующих интерфейсов и того, какие домены выводите первыми. Имеет смысл заранее зафиксировать, какие операции остаются в ядре, а какие идут через платформу. Это снижает риск «большого взрыва» на старте.

Контур рассчитан на розничные, SME и инвестиционные банки, необанки, финтех-инфраструктуру и команды embedded finance, которым нужна платформа ДБО с API и готовностью к агентам. Это не конструктор «только для топ-10»: модули включают по объёму, а не пакетом на весь рынок сразу. Не подходит как замена АБС и как витрина без контракта API. Имеет смысл смотреть, есть ли у банка задача собрать цифровые продукты и каналы в одном слое. Если нужен только новый дизайн мобильного банка без смены сервисной модели — эффект будет слабее.

В Self Cube каналы работают с микросервисами через единый API-шлюз, контракты описаны в OpenAPI 3.1, доступ — по OAuth 2.1. Есть реестр возможностей, событийная шина и машиночитаемые интерфейсы, чтобы внутренние системы и внешние сервисы находили операции по спецификации, а не по вики. Безопасность закладывается в шлюз, идентификацию и лимиты, а не «потом на периметре». Имеет смысл проверить, не ходит ли канал в домен напрямую: это типичный долг старых ДБО. Без шлюза каждый новый канал снова тащит свои интеграции.

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

Срок задаёт ландшафт: готовность АБС, число каналов и глубина кастомизации UX, а не «коробка за неделю». На типовом плане Self Cube заложены архитектурный заход, 15 спринтов по две недели, три релиза и пилот на сотрудниках до промышленного запуска. MVP рабочего контура домена и каналов на каркасе появляется к седьмому спринту, если не рисуют уникальный интерфейс с нуля на каждый экран. Имеет смысл отдельно оценить интеграции ядра и объём миграции данных. Обещание фиксированной даты без этого разбора обычно не сходится с фактом.