Европейская финтех-инфраструктура уперлась в неприятный предел: чем успешнее партнер по BaaS наращивает клиентскую базу, тем быстрее для провайдера растет комплаенс-нагрузка. Papaya 28 мая 2026 года предложила другой вариант: не записывать на свой баланс миллионы чужих пользователей, а работать на уровне самих финансовых организаций. Для финтех-команд это сигнал простой: бутылочное горлышко теперь не в API и не в красивом онбординге, а в том, кто именно считается клиентом и кто за него отвечает.
О схеме финтех-инфраструктуры рассказал Sifted Олегс Чернисевс, CTO Blackcat и один из архитекторов платформы Papaya. Его тезис звучит довольно жестко: BaaS изначально создавался не для того, чтобы одна финансовая организация обслуживала другую. Исторически модель подходила ритейлу, маркетплейсам и SaaS-сервисам, которые «арендовали» банковскую лицензию и инфраструктуру. Но когда ту же конструкцию начали применять к EMI, платежным компаниям и другим финорганизациям, провайдеру пришлось юридически отвечать за конечных пользователей, которых он не видит напрямую, не обслуживает в интерфейсе и не сопровождает в реальном времени.
Отсюда и главный сбой старой схемы. В типичном BaaS-партнерстве банк или лицензированная организация должна относиться к каждому конечному пользователю клиента как к собственному клиенту. На бумаге звучит аккуратно, на практике выходит странно: саппорт не твой, продукт не твой, поведенческие сигналы не твои, а регулятор спрашивает именно с тебя. По словам Чернисевса, в Европе это уже привело к ожидаемой реакции: часть игроков резко сократила прием новых партнеров, часть просто ушла из корреспондентского или BaaS-сегмента. Не потому, что спрос исчез, а потому, что модель комплаенса оказалась слишком дорогой и плохо масштабируемой.
Papaya предлагает развернуть ответственность в другую сторону. Она онбордит, проверяет и мониторит не конечных пользователей, а саму финансовую организацию-партнера: ее лицензию, контур управления рисками, соответствие комплаенс-процедур заявленной бизнес-модели и характер транзакций. При этом данные по конечным пользователям никуда не исчезают. Платформа получает через API те же категории информации, что и обычный BaaS-провайдер, включая идентификационные данные, историю операций и сведения об источнике средств. Но эти данные используются не для создания клиентских отношений с каждым пользователем, а для мониторинга, скоринга риска и выявления аномалий. Идея в том, чтобы не изображать контроль там, где его конструктивно нет.
В этой логике Papaya пытается решить сразу три старые боли. Первая — проблема «бумажных клиентов», когда у провайдера формально числятся пользователи, которых он не способен ни нормально обслужить, ни полноценно наблюдать. Вторая — парадокс масштаба: в BaaS рост чужой клиентской базы автоматически превращается в рост вашей регуляторной нагрузки, то есть успех партнера становится для вас источником операционного наказания. Третья — путаница для регулятора, которому все сложнее понять, где заканчивается ответственность одной организации и начинается зона другой. В новой схеме нагрузка растет вместе с числом институциональных партнеров, а не вместе с количеством их клиентов. Для бизнеса это уже выглядит не как философия, а как способ не сорвать экономику сервиса на этапе роста.
Отдельный смысл у этой модели есть для небольших финорганизаций, которые пытаются выйти на рынок ЕС. За последние годы доступ к корреспондентским услугам и к SEPA для многих EMI, платежных институтов и финтех-компаний стал заметно сложнее. Крупные банки и инфраструктурные игроки либо отступили, либо выставили условия, которые маленькому участнику не по карману. В результате возникает неприятный разрыв: лицензию получить можно, продукт собрать можно, а подключиться к платежным рельсам, от которых зависит вся экономика сервиса, уже гораздо труднее. Papaya как раз и продает закрытие этого разрыва: доступ к SEPA Credit Transfer, виртуальные IBAN, API-интеграции и встроенный комплаенс-скрининг. В самом материале также указано, что Papaya Ltd — это EMI, регулируемая Malta Financial Services Authority и имеющая прямое участие в SEPA.
Для разработчиков и продуктовых команд здесь важен не только юридический, но и архитектурный вывод. Если рынок действительно смещается от BaaS к более узким корреспондентским моделям, то ценность будет расти у тех платформ, которые умеют аккуратно разделять контуры ответственности и при этом строят достаточно глубокий data layer для риск-мониторинга. Проще говоря, выигрывает не тот, кто просто выдает еще один банковский API, а тот, кто может доказать регулятору и партнеру, зачем ему каждый кусок данных и на каком уровне он его использует. Для CTO и compliance-by-design команд это означает более тесную связку между транзакционным мониторингом, KYC-данными, скорингом и договорной моделью. Красивый фронт в финтехе по-прежнему полезен, но доступ к инфраструктуре решается в другом месте.
Главный вопрос теперь не в том, заменит ли такая схема классический BaaS целиком. Скорее рынок будет проверять, насколько устойчивой окажется модель, где контроль строится на уровне институтов, а не конечных пользователей. Если подход Papaya сработает, европейская финтех-инфраструктура может получить новый стандарт подключения к SEPA для небольших игроков. Если нет, отрасль вернется к старой привычке делать вид, что провайдер способен лично знать каждого чужого клиента. И это, мягко говоря, уже не выглядит убедительно.