Посібник покупця: white-label платформи для необанків

White-label платформа для необанку — це програмне забезпечення, на яке ви ставите свій бренд, щоб запустити банківський застосунок — рахунки, картки, перекази, іноді крипту, — не будуючи ядро з нуля. Купуючи її, ви насправді купуєте дві речі, які легко сприйняти за одну: ядро, що рухає гроші, і прикладний рівень, який бачать ваші клієнти. Це посібник, як відрізнити їх до підписання договору, бо майже кожне складне запитання про white-label платформу виявляється запитанням про те, де проходять її шви; завдання вендора — розмити цю лінію, а завдання покупця — її знайти.

Перед рішенням варто зробити п'ять зрізів: ядро проти прикладного рівня, де лежить ліцензія, наскільки глибока дизайн-система, автономна чи вбудована поставка і вибір «будувати чи купувати», що лежить під усім цим. Розгляньмо їх по черзі.

Перший зріз: ядро й прикладний рівень

Найкорисніше провести межу між тим, що має бути правильним, і тим, що має бути вашим. Помилка в ядрі коштує дорого: це реєстр із подвійним записом, рахунки й баланси, KYC та онбординг, випуск і процесинг карток, крипто- та стейблкоїн-рейки й операторська консоль над усім цим. Прикладний рівень — те, чого торкається клієнт: бренд, екрани, інформаційна архітектура, набір увімкнених функцій. Платформа, яку варто купувати, ділить одне ядро між усіма брендами й налаштовує застосунок для кожного тенанта. Оцінюйте їх за різними осями: ядро — за коректністю (чи реєстр справді з подвійним записом, чи тримається звірка, чи оператори можуть ним реально керувати); прикладний рівень — за гнучкістю, тобто наскільки бренд може відійти від еталона, перш ніж доведеться робити форк.

Де лежить ліцензія — і чи можна її відокремити

Дозвіл тримати чи переказувати гроші регулюється, і це не та сама покупка, що програма. Запитайте прямо: чи включає платформа регульований дозвіл, чи очікує, що ви принесете власний, — а якщо включає, то чия це ліцензія, в яких країнах і чи ви її прямий клієнт, чи агент. Для покупця важлива відокремленість: платформа, яка приварила своє ПЗ до єдиної ліцензії, яку не замінити, тихо вибрала за вас юрисдикцію і партнера, тоді як платформа, що трактує ліцензію як рейку, яку приносите ви, дозволяє обирати дозвіл незалежно й пізніше його змінити. Жоден варіант не хибний, але ви маєте знати, який купуєте. Protocore Pay (/products/pay) — це окремо програмний рівень: він працює поверх будь-яких регульованих рейок, які ви принесете, а жодне ПЗ не є ліцензією. Поняття, які зустрінуться в цій розмові, — EMI, платіжна установа, агент, банк-спонсор — пояснено в /glossary.

Наскільки глибока дизайн-система

Уся обіцянка white-label у тому, що застосунок виглядає як ваш, а не як переодягнена демо-версія вендора, — і ця обіцянка настільки глибока, наскільки глибока дизайн-система під нею. Поверхнева дозволяє змінити логотип і акцентний колір. Глибока відкриває справжню мову — колір, типографіку, радіус кутів, відступи, щільність, анімацію — у вигляді токенів, які читає кожен екран, тож бренд — це набір перевизначень, а не форк. Запитайте, скільки є токенів і що вони покривають, чи ті самі токени експортуються для web, native і desktop, щоб колір означав один колір усюди, і чи може дизайнер відвести тенанта далеко від еталонної збірки без змін у коді. Дизайн-система Protocore (/products/pds) — одна з готових відповідей: 144 токени та 889 утилітних класів, dark-first, радіус за замовчуванням нульовий, експорт для web, .NET і native, — але питання покупця загальне: чи дизайн-рівень — справжня система токенів, чи шар фарби поверх незмінного застосунку?

Автономний застосунок чи вбудований рівень

Поставка має дві форми. Автономний застосунок — це повноцінний банківський застосунок, який ви брендуєте й випускаєте під власним ім'ям: ваші клієнти завантажують ваш банк. Вбудований рівень — набір компонентів і потоків, який ви вбудовуєте у наявний продукт: платежі й баланси живуть усередині вашого застосунку. Вибір не про якість, а про те, де має жити грошовий досвід. Якщо банкінг — ваш продукт, потрібна автономна збірка. Якщо банкінг — функція більшого продукту (маркетплейс виплачує продавцям, платформа дає користувачам гаманець), потрібен вбудований шлях, щоб гроші жили там, де вже є ваші клієнти. Платформа, яку варто купувати, вміє обидва варіанти з одного ядра, бо ядру байдуже, чи його фронтенд — окремий застосунок, чи панель усередині чужого.

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

Будуючи ядро самостійно, ви купуєте контроль і платите роками. Коректний реєстр, процесинг карток, KYC, звірка й операторська консоль — кожне є окремим проєктом, і все це базовий мінімум, який треба пройти, перш ніж випустити хоч одну функцію, яку помітить клієнт. Купівля ядра повертає ці роки й коштує частини суверенності: ви успадковуєте чужу модель рахунку, ліміту, розрахунку. Чесно вирішити можна, спитавши, що з цього — ваш продукт, а що — інфраструктура. Інфраструктуру — розрахунки, звірку, інструменти комплаєнсу — всі роблять приблизно однаково, і саме там рідко виграють; купуйте її. Те, за що клієнти насправді обирають вас, — потоки, бренд, єдина річ, яку ви робите краще за домінанта, — це те, чому ваші інженери мають присвячувати життя. Купівля платформи — це ставка на те, що ядро — інфраструктура, а ваша відмінність живе над ним.

Ви ніколи не купуєте необанк. Ви купуєте ядро, яке сподіваєтеся мати за інфраструктуру, і прикладний рівень, який збираєтеся зробити своїм, — і вся оцінка зводиться до того, чи провів вендор цю лінію там, де провели б її ви.

П'ять напрямів, а не п'ять продуктів

Попросіть у вендора приклади — і вам часто покажуть кілька готових застосунків. Читайте їх правильно: це напрями, у яких може розвинутися те саме ядро, а не меню, з якого обирають одну позицію. Еталонне ядро однієї платформи може стояти за чистою біржею (Halcyon — стримано, угода на першому плані), чат-орієнтованим суперзастосунком (Lumen — гроші рухаються всередині розмови), застосунком з акцентом на перекази (Fern — спершу пакетні виплати та конвертація за правилами), стейблкоїн-збіркою в темній темі (Volt — сортувальник зарплати й командні картки) і мультивалютним рахунком (Meridian — баланс у EUR поряд з USDC та рахунок у BTC, куди надходять винагороди за картку). П'ять брендів, п'ять інформаційних архітектур, п'ять наборів функцій — і під кожним один реєстр, один KYC, один процесор карток. Важливе не число п'ять, а скільки тенантів здатне витримати ядро. Вендор, який каже, що продукт — це п'ять застосунків, не зрозумів власного продукту; той, хто показує п'ять, щоб довести, що шостий — дрібниця, розуміє.

Питання, що відсіюють вендорів

Короткий список питань відсікає більшість презентацій. Ядро — це одна спільна система чи форк під кожного клієнта, і коли виправлено баг, чи потрапляє виправлення до всіх тенантів одразу? Дизайн-шар дає справжні токени чи лише слот для логотипа? Чи входить у платформу регульований дозвіл, чи мені потрібно мати свій — і чи можна буде замінити його пізніше? Чи може те саме ядро постачати і окремий застосунок, і вбудований шар? Що ви вважаєте інфраструктурною «сантехнікою», а що, на вашу думку, я маю будувати сам? Відповіді розміщують вендора на мапі, яку малює цей гід: спільне ядро чи ферма форків, система токенів чи просто фарба, софт плюс моя ліцензія чи зварений в одне пакет, одна форма постачання чи дві. Повний розбір одного такого ядра — п'ять напрямів, референсний застосунок і операторська консоль за ними — на /products/pay, дизайн-система під ним — на /products/pds, а терміни — у /glossary.