Budować czy kupić: realny koszt systemu core bankingu

Prędzej czy później każdy założyciel fintechu wycenia tę samą decyzję: zbudować system core bankingu we własnym zakresie czy wziąć licencję na gotowy i go skonfigurować. Naiwne porównanie — opłata licencyjna po jednej stronie, kilka pensji programistów po drugiej — jest niemal zawsze błędne, bo te dwie kolumny nie zawierają tych samych pozycji.

Uczciwe porównanie to całkowity koszt posiadania w całym cyklu życia produktu: budowa, stałe utrzymanie, bieżąca praca nad bezpieczeństwem i compliance oraz przychody, których nie generujesz, dopóki budujesz. Tworzymy oprogramowanie core bankingu, więc siłą rzeczy mamy w tej sprawie stanowisko — ale poniższy rachunek to ten, który sami chcielibyśmy zobaczyć, gdybyśmy byli kupującymi.

Co naprawdę oznacza „system core bankingu"

Większość szacunków „budować czy kupić" psuje się, zanim padnie pierwsza liczba, bo zakres jest zaniżony. Aplikacja bankowa, którą widzą Twoi klienci, to widoczny ułamek systemu. Core klasy produkcyjnej to cztery produkty w jednym:

• Rdzeń transakcyjny: księga podwójnego zapisu, która pozostaje zbilansowana pod współbieżnym obciążeniem, w której każde saldo wynika z księgi i jest codziennie uzgadniane z każdym dostawcą.
• Produkt dla klienta: sama aplikacja bankowa, onboarding z poziomami KYC i KYB, konta wielowalutowe, przelewy, karty — a coraz częściej także portfele krypto z prawdziwą custodią kluczy za nimi.
• Drugi produkt, którego nikt nie wycenia: operacyjny back office do kolejek compliance, monitorowania transakcji, konfiguracji opłat, raportowania i granularnych ról personelu.
• Warstwa niewidoczna: dziennik audytowy append-only, przepływy dwuskładnikowe wykraczające poza logowanie, rate limiting, odcisk urządzenia i zarządzanie kluczami, które trzyma sekrety poza kodem i bazą danych.

Ścieżka budowy: co naprawdę zawiera budżet

Realistyczna budowa wewnętrzna wymaga starszych inżynierów backendu z doświadczeniem w systemach finansowych, inżynierów frontendu, DevOps i bezpieczeństwa, QA oraz koordynacji produktowej rozumiejącej compliance. Zespoły, które osiągają jakość produkcyjną, rzadko liczą mniej niż sześć do dziesięciu osób na poziomie senior — a deficytowy profil, czyli inżynierowie, którzy już prowadzili księgi i custodię w produkcji, jest dokładnie tym, który najtrudniej zatrudnić i utrzymać.

Jeśli chodzi o harmonogram, wzorzec jest powtarzalny: rok do dwóch lat, aby osiągnąć to, co dojrzała platforma daje pierwszego dnia. Czas nie idzie na ekrany; idzie na poprawność księgi pod współbieżnością, na integracje z dostawcami, z których każda wnosi własne osobliwości sandboxa i etapy certyfikacji, na utwardzanie bezpieczeństwa i na długi ogon przypadków brzegowych, które ujawniają się dopiero przy prawdziwych klientach i prawdziwych pieniądzach.

A wydatki nie kończą się wraz ze startem. Dostawcy zmieniają API, sieci blockchain się aktualizują, regulacje się przesuwają, zależności się starzeją. Wewnętrzny core to nie projekt, który się kończy; to stały zespół, którego finansowanie bierzesz na siebie na cały czas istnienia produktu.

Koszty, które nigdy nie trafiają do arkusza

• Koszt alternatywny: każdy miesiąc spędzony na budowie księgi to miesiąc, w którym produktu nie ma na rynku. Konkurenci, którzy wzięli licencję na core, pozyskują klientów i iterują cennik, podczas gdy Ty wciąż integrujesz dostawców.
• Ryzyko kadrowe: plan budowy zakłada, że zespół, który ją zaczyna, ją skończy. Utrata jednego z dwóch inżynierów rozumiejących księgę w połowie projektu to zdarzenie harmonogramowe mierzone w miesiącach.
• Ogon poprawności: księga poprawna w 99% nie jest prawie gotowa — jest generatorem zgłoszeń do supportu, rozjazdów w uzgodnieniach i incydentów regulacyjnych. Ostatni 1% kosztuje więcej niż pierwsze 99%.
• Bezpieczeństwo jako proces: testy penetracyjne, rotacja kluczy, reagowanie na incydenty, monitoring i alertowanie — koszty cykliczne, które istnieją niezależnie od tego, czy cokolwiek pójdzie nie tak.
• Utrzymanie compliance: wygasanie dokumentów KYC, ewoluujące przepisy o kryptoaktywach, nowe obowiązki raportowe. Ta praca powtarza się co roku i nie da się jej odłożyć.
• Back office: budowy wewnętrzne notorycznie traktują narzędzia dla personelu jako dodatek, a zespół operacyjny dziedziczy konsolę SQL. Każdy regulator i audytor, który to zobaczy, każe Ci zbudować to porządnie od nowa.
• Lokalizacja: dostarczenie produktu w wielu językach z prawdziwym wsparciem right-to-left jest tanie, gdy projektuje się je od pierwszego dnia, i drogie do doklejenia, gdy produkt już stoi.

Ścieżka zakupu: za co płacisz i co pozostaje Twoje

Po stronie zakupu kolumna technologiczna jest jawna: licencja lub wynajem platformy — poważni dostawcy wyceniają moduły, chainy i języki osobno, więc rachunek podąża za tym, co faktycznie aktywujesz — plus infrastruktura, na której działa instancja. Czego zakup nie zdejmuje: Twoich licencji regulacyjnych lub umów partnerskich, Twoich umów handlowych z dostawcami, Twojego personelu operacyjnego, Twojej dystrybucji. Te koszty należą do operatora na obu ścieżkach — zakup usuwa górę inżynierii, nie biznes.

Uczciwe koszty zakupu mają kształt zależności: roadmapa nie jest w pełni Twoja, a platforma jest tak dobra, jak jej najsłabszy moduł. Środki zaradcze to rzeczy, które można zweryfikować przed podpisaniem: dedykowana instancja z własną bazą danych i własnymi zaszyfrowanymi sekretami, aby odejście od vendora było migracją, a nie negocjacją z zakładnikami; integracje dostawców trzymane za warstwą abstrakcji, aby umowy były Twoje, a dostawców dało się wymienić; licencjonowanie modułowe, aby płacić tylko za to, co włączasz; oraz dowody, że platforma obsłużyła prawdziwych klientów i prawdziwe pieniądze.

Kiedy budowa wewnętrzna jest słuszną decyzją

„Budować czy kupić" nie jest pytaniem retorycznym z gotową odpowiedzią. Budowa jest słuszna, gdy spełniony jest co najmniej jeden z warunków:

• Infrastruktura jest produktem: sprzedajesz księgę, custodię lub samą zdolność banking-as-a-service, więc jej posiadanie to istota biznesu.
• Twoja przewaga tkwi w wymaganiach, których żaden vendor nie pokrywa — nie w funkcjach, których vendorowi brakuje w tym kwartale, lecz w możliwościach strukturalnie poza tym, co robią platformy.
• Masz już zespół senior z produkcyjnym doświadczeniem w core bankingu oraz środki, by finansować go latami bez przychodów.
• Regulator lub spółka matka narzuca pełną wewnętrzną kontrolę nad stackiem jako warunek, którego nie da się negocjować.

Pięć pytań pomocnych w decyzji

• Wyróżnienie: czy jakikolwiek klient kiedykolwiek wybierze Cię dlatego, że Twoja księga jest własnej roboty? Jeśli Twoją przewagą jest produkt, dystrybucja lub cena, core to hydraulika — niezbędna, ale nie Twoja do wymyślania na nowo.
• Harmonogram: czy biznes wytrzyma rok do dwóch lat bez przychodów, podczas gdy core powstaje, na rynku, który nie czeka?
• Zespół: czy masz — lub czy realnie zatrudnisz i utrzymasz — inżynierów, którzy prowadzili w produkcji systemy przenoszące pieniądze?
• Koszt trzyletni: porównuj koszt budowy plus stały zespół utrzymaniowy z licencją plus aktywowanymi modułami w horyzoncie trzech lat — nigdy kosztu startu z kosztem startu.
• Wyjście: jak wygląda odejście na każdej ścieżce? Przy budowie wewnętrznej ryzykiem są kluczowe osoby odchodzące z wiedzą. U vendora żądaj dedykowanej instancji, własnej bazy danych i własnych kluczy — wtedy wyjście jest migracją.

Gdzie w tej decyzji plasuje się Coreza

Coreza to kolumna „kupić", zbudowana tak, by przejść powyższą checklistę: każdy klient prowadzi dedykowaną instancję na AWS z własną bazą danych i własnymi zaszyfrowanymi sekretami, każdy moduł — łącznie z chainami, językami i tokenami — jest licencjonowany osobno, więc cena podąża za tym, co aktywujesz, a integracje dostawców stoją za warstwą abstrakcji, dzięki czemu umowy handlowe pozostają Twoje.

Wersja tego core działa w produkcji w regulowanym europejskim fintechu od 2024 roku, a nowa instancja wdraża się w tygodnie: marka, moduły, języki i chainy to konfiguracja, nie inżynieria. Jeśli liczysz właśnie rachunek „budować czy kupić", do takiego porównania zapraszamy — koszt trzyletni z kosztem trzyletnim, z wypełnioną ukrytą kolumną.