Інвестор запитав, як ваша платформа відокремлює кошти клієнтів від операційних рахунків і чи відповідають ваші open banking підключення тому стандарту, якого очікує його технічний радник. Ви знаєте, що відповідь лежить на перетині архітектури даних, шифрування та якогось пункту CBUAE (центрального банку ОАЕ), що його ви смутно пригадуєте з однієї комплаєнс-розмови. Але за це в команді ніхто не відповідає. Продукт ви зібрали з підрядними інженерами та дорожньою картою, без функції технічного керівництва, бо до цього тижня вона вам не була потрібна.
CTO as a service для фінтеху існує саме для того, щоб закрити цей розрив. Найняти штатного CTO зараз означає три-чотири місяці пошуку і частку в компанії, яку ви ніколи не закладали в cap table. Консультант віддає вам звіт, але звіт не сидить поруч, коли радник ставить уточнювальне питання, і ніхто всередині не захистить документ, якого сам не писав. Дату перегляду вже призначено. Її не перенесуть через те, що брак технічного керівництва підступив у невдалий момент.
Ось що CTO as a service для фінтеху реально робить для due diligence: до яких перевірок готує, яку роботу виконує до відкриття data room, які питання бере на себе, поки триває перегляд, і те, що більшість реклами таких послуг оминає, чого він уже не виправить так пізно.
Що інвестори перевіряють у технічному due diligence фінтеху
Інвестор рівня Series A чи Series B, який проводить technical due diligence фінтеху, прийшов не милуватися вашим кодом. Йому потрібні ризики, що стануть його проблемою після переказу грошей, а вони проявляються в трьох місцях: як ви поводитеся з даними, як складаються ваші стосунки з регулятором і як насправді працює ваша інженерна команда. Інвестор, що вже робив фінтех-угоди, знає, які питання відрізняють продукт, який можна підтримати, від того, за переписування якого доведеться платити.
Питання про архітектуру й поводження з даними
Почніть із того, де лежать чутливі дані й хто має до них доступ. Як зберігаються дані клієнтів: розділені за кожним із них чи зведені в спільний пул? Де насправді лежить PII і чи зашифровані ці дані як у стані спокою, так і під час передавання? І питання, на якому спотикаються ранні продукти: у кого ключі шифрування? У вашої команди, у хмарного провайдера чи у третьої сторони, яку доведеться розкривати? Для фінтеху, що працює з платіжними даними, відповідь на питання «хто має доступ до PII і під яким контролем» вирішує, отримаєте ви чистий перегляд чи зауваження. А зауваження лягає в term sheet як умова.
Готовність до регуляторного комплаєнсу
Ця частина залежить від вашої юрисдикції, і назвати конкретну рамку тут важливо. Фінтех з ОАЕ просять показати готовність до CBUAE open banking: чи справді ваша архітектура open banking реалізує ту модель згоди й обміну даними, яку задає рамка, і чи вписується продукт у вимоги ліцензування VARA (Дубайського органу з регулювання віртуальних активів) для його категорії. Фінтех із Нігерії питають про CBN (Центральний банк Нігерії) sandbox compliance і про те, як продукт лягає на його ліцензію. Радник хоче доказ, що архітектура вже відображає регуляцію, а не обіцянку дійти до цього згодом. Вибір місця зберігання даних вирішує, який саме пункт CBUAE до вас застосовний, і якщо цей вибір зробив підрядник заради економії, саме він може стати тим зауваженням, що загальмує раунд. Для першого інституційного раунду саме тут здобувається або втрачається технічна довіра на Series A.
Сигнали якості інженерної команди й процесів
Важливим аспектом є здоровʼя інженерної функції. Що про дисципліну релізів каже ваш CI/CD? Як розбирали минулі інциденти: із написаним постмортемом чи просто памʼятають? Чи є єдина точка відмови: один підрядник, у якого і ключі до деплою, і все те, чого він так і не задокументував? Це не абстракція. Крихкий процес інвестор читає як витрати, які він фінансуватиме після раунду, і або закладає їх у ціну угоди, або повертає вам як ризик, що треба закрити до closing.
Fintech technical due diligence, з технічним співзасновником і без нього
| Напрям due diligence | Без технічного співзасновника | CTO as a Service для fintech |
|---|---|---|
Документація архітектури | Радник запитує, чому було обрано певну базу даних або регіон, а чесна відповідь: «це обрав підрядник». | Системні діаграми та журнали рішень підготовлені ще до запиту радника. Архітектурний аудит створює документальний слід, який засновнику не довелося створювати самостійно. |
Відповідність CBUAE, CBN або VARA | Засновник знає, що відповідна нормативна база існує, але не може показати, яку саме вимогу задовольняє розробка, або чи задовольняє її взагалі. | Кожна вимога щодо open banking, sandbox або ліцензування пов’язана з компонентом, який її виконує, а прогалини визначені ще до того, як їх знаходить радник. |
Шифрування та сегрегація даних | «Наш провайдер цим займається». Ніхто не може чітко сказати, хто фактично контролює ключі. | Зберігання ключів і сегрегація даних задокументовані та можуть бути аргументовано захищені під час перевірки. |
Відповіді на додаткові запитання | Перша відповідь витримує перевірку. Друга, побудована на ній, вже ні, тому що ніхто не відпрацював ланцюжок запитань, які ставить радник. | На додаткові запитання дають прямі відповіді, зокрема чесну відповідь «відома проблема, ось план її усунення», яка виглядає переконливіше за спробу ухилитися від відповіді. |
Узгодженість data room | Діаграми завантажені один раз, заяви щодо compliance написані окремо, і з часом ці два блоки вже не зовсім відповідають один одному. | Технічні розділи залишаються актуальними та узгодженими, тому інформація, яку читає радник, і те, що засновник говорить під час зустрічі, збігаються. |
Сигнали інженерних процесів | Зрілість CI/CD та історія інцидентів існують лише в пам’яті. Єдина точка відмови залишається непоміченою, доки хтось не запитає, хто має ключі для деплою. | Прогалини в процесах визначені та розподілені на ті, що можна виправити, і ті, про які потрібно повідомити, ще до початку перевірки. |
Ймовірний результат | Проблема виявляється вже під час перевірки, потрапляє до term sheet як умова, а строки раунду зсуваються, поки її вирішують. | Про прогалини вже повідомлено, до них додано план усунення, а перевірка перетворюється на набір відповідей, які засновник вже має. |
Що CTO as a service робить до відкриття data room
Чотири-шість тижнів перед переглядом — це той час, коли ще розвʼязні проблеми встигають усунути. Фракційний CTO для фінтех-стартапу, залучений зараз, фічі не пише. Робота діагностична: скласти карту наявного, назвати те, що відповідає вимогам, і те, що ні, зібрати артефакти, які радник справді читатиме. Більшість того, що зринає на перегляді, виправно, якщо спіймати це тут, і безнадійно, якщо спіймати вже під час.
Огляд і документування архітектури
Усе починається з розбору того, що збудовано: він дає документи, які технічний радник прочитає без вас поруч. У фінтеху це огляд регуляторної архітектури, не менший за технічний: схеми мають показати, як комплаєнс-архітектура фінтеху зіставляє потоки даних із правилами, що ними керують. Схеми того, де дані рухаються й де лежать. Логи рішень, що пояснюють, чому саме ця база даних, чому цей регіон, чому ключі тут, а не там. Проста межа між тим, що архітектура має робити, і тим, чого не має. У більшості ранніх продуктів архітектура є, а паперового сліду немає, і для інвестора незадокументоване читається як некероване, хай яким надійним воно є.
Виявлення прогалин у комплаєнсі
Далі повільна частина: пройти регуляторні вимоги проти продукту, рядок за рядком. Усе сортується на три купи: відповідає, частково відповідає і те, що треба розкрити раніше, ніж це знайде інвестор. Для платформи в ОАЕ це продукт проти CBUAE open banking requirements, де кожну технічну вимогу CBUAE привʼязано до компонента, що її виконує, плюс будь-які зобовʼязання VARA в межах обсягу. Для Нігерії це відповідність CBN sandbox і його умови. За чотири тижні це не зробить усе відповідним і не вдаватиме, що зробило. Що воно дає, так це змогу зайти, знаючи кожен розрив, і це перетворює засідку на розкриття, яке контролюєте ви.
Підготовка засновника до технічних питань
Частина, яку засновники недооцінюють, остання: набути достатньої вправності, щоб вести розмову самому. Не в інженерії, а в рішеннях і в тому, чого вони коштують. Ви прийшли з банкінгу, ви вже розумієте регуляцію. Що вам потрібно, так це чітка звʼязка між конкретним архітектурним рішенням і його наслідком, щоб коли радник спитає, чому ключі лежать саме там, ви відповіли одним реченням і рушили далі. CTO поруч із вами в кімнаті. Але інвестор ще й дивиться, чи розумієте ви власний продукт.
Що CTO as a service для фінтеху бере на себе під час ревʼю
Коли радник починає ставити питання, фракційний CTO робить дві речі, і між володінням технічним наративом і керуванням звітом є реальна різниця. Консультант передає документ і йде. Технічний співзасновник лишається в розмові й відповідає на уточнення, якого документ не передбачив. У живому перегляді саме в цьому й полягає більша частина цінності. Тому технічний співзасновник для фінтеху, якого залучають під раунд, — це той, хто лишається в кімнаті.
Відповіді на технічні питання інвесторів
Питання радника рідко зупиняються на першій відповіді. Технічні питання інвесторів нарощуються одне на одне: як сегреговано кошти, потім що стається при збої звірки, потім кого підіймають по тривозі. Кожне уточнення перевіряє, чи була перша відповідь відрепетованою, чи справжньою. Фракційний CTO відпрацьовує їх напряму, у тому регістрі, якого очікує радник, і знає, коли чесна відповідь звучить як «це відоме обмеження, ось наш план і терміни», що тримається краще за захисне ухиляння.
Ведення технічних розділів data room
Технічні розділи data room мають бути точними, актуальними й узгодженими. Підготовка data room тут означає більше, ніж завантаження файлів: схеми, що збігаються з кодом, комплаєнс-твердження, що збігаються з архітектурою. CTO as a service для фінтеху веде ці розділи, щоб те, що читає радник, і те, що ви кажете в кімнаті, збігалося. Там, де вони розходяться, рутинний перегляд перетворюється на глибше копання.
Найчастіше зауваження в технічному перегляді фінтеху — це не зламана система. Це задокументоване твердження, якого архітектура не підтверджує, розбіжність між data room і продуктом. Це проблема покриття, а не інженерії.
Чого CTO as a service не виправить на етапі due diligence
Чесний облік меж викликає більше довіри, ніж ще один розділ обіцянок про можливості. Є три проблеми, яких фракційний CTO не розвʼяже за тижні до перегляду, і те, з якою з них ви стикаєтеся, підказує, готуватися чи переносити дату.
Перша — фундаментальне архітектурне рішення, що потребує перебудови. Якщо кошти клієнтів і операційні кошти живуть в одній моделі даних, що не дає чисто їх розділити, жодна документація цього не сховає: це інженерний проєкт, який міряється місяцями. Розкрийте його з правдоподібним планом усунення, а не замазуйте.
Друга — ліцензія, якої ви не подали. Фракційний CTO може зіставити ваш продукт із вимогами CBUAE, CBN чи VARA і зібрати технічні докази, потрібні для подання. Чого він не може, так це стиснути власний графік регулятора. Готова архітектура цього календаря не зрушить.
Третя — досвід, якого ще немає. Якщо інвестор хоче доказ того, як ваша система поводиться під продакшн-навантаженням, а ви його ніколи не давали, документація історії не вигадає. Фракційний CTO може назвати розрив і налаштувати, що вимірювати відсьогодні, але не створить дані з минулого, якого не було.
Якщо ви в першій чи другій категорії, технічний перегляд, можливо, не те рішення, яке варто форсувати цього кварталу. Засновник, що переставляє терміни з чітким планом усунення, залучає кошти краще за того, хто заходить у перегляд, знаючи, що попереду перебудова.
Технічний перегляд — це одне рішення, а не криза
Якщо до перегляду два тижні, зробіть спершу одне. Проженіть свій продукт через ті перевірки, якими користується радник: розділення даних, зберігання ключів і правила open banking чи sandbox вашої юрисдикції. Цей єдиний прохід скаже, у якій ви категорії. Якщо кожен розрив — це документація чи розкриття, у вас перегляд, до якого можна підготуватися. Якщо ж розрив — це перебудова чи неподана ліцензія, у вас рішення про терміни, і краще ухвалити його зараз, ніж у кімнаті.
Фінтех-засновник без внутрішнього технічного керівництва не є непідготовленим до перегляду: на цьому етапі такі майже всі. Ті, хто виходить чистим, склали карту розривів раніше за інвестора й зайшли, знаючи, що саме розкриють. У цьому й уся робота CTO as a service для фінтеху тут: зробити перегляд набором відповідей, які ви вже маєте, а не питаннями, які чуєте вперше.
Забронюйте дзвінок до відкриття data room. Фракційний CTO складе карту кожного розриву, відділить виправне від того, що треба розкрити, і перетворить перегляд на набір відповідей, які ви вже маєте.
