Banking-as-a-Service jako fundament nowoczesnego fintechu

Banking-as-a-Service (BaaS) to model, w którym licencjonowany bank lub inna instytucja finansowa udostępnia swoje usługi przez API, a inna firma wbudowuje je we własny produkt. Klient widzi aplikację fintechu, jego logo i jego interfejs. Rachunek, środki i licencja zostają po stronie banku. Dzięki temu startup, platforma B2B czy sieć sklepów może zaoferować konto, kartę albo przelewy bez wieloletniej drogi do własnej licencji. To skrót. Uczciwy, ale z ceną. Firma zyskuje czas i oddaje część kontroli nad kosztami i tempem zmian. Wiele produktów, które na slajdach wyglądały na „nakładkę na API banku", w praktyce musiało zbudować własną księgę operacji, obsługę zdarzeń i procedury wyjaśniania rozbieżności. Bez nich trudno odpowiedzieć klientowi na najprostsze pytanie: gdzie są moje pieniądze?

Jako software house budujemy aplikacje dla branży finansowej i fintech, w tym integracje z operatorami płatności i zewnętrznymi API. Poniżej opisujemy Banking-as-a-Service od strony produktu i technologii: co da się na nim zbudować, jak powinna wyglądać architektura, gdzie zwykle pojawiają się problemy i jak podejść do wyboru dostawcy. Przepisy zostawiamy prawnikom. Zajmujemy się tym, co trzeba zaprojektować i zakodować.

Jak działa Banking-as-a-Service i kto za co odpowiada

W typowym układzie występują trzy strony. Pierwsza to podmiot z licencją, czyli bank albo instytucja pieniądza elektronicznego, uprawniona do przechowywania środków klientów i wydawania kart. Druga to platforma technologiczna, która opakowuje usługi banku w nowoczesne API, dokumentację i panel administracyjny. Trzecia to marka budująca produkt dla klientów końcowych. Bywa, że bank i platforma to jedna firma. Bywa też, że między nimi stoi jeszcze jeden pośrednik.

Z perspektywy marki mechanizm przypomina model biznesowy white label: ktoś wytwarza usługę, ktoś inny sprzedaje ją pod własną nazwą. Tyle że tutaj „produktem" są pieniądze klientów. Pomyłka w saldzie to nie jest zwykły błąd aplikacji.

Podział ról wygląda mniej więcej tak. Bank prowadzi rachunki, rozlicza transakcje z systemami płatniczymi i organizacjami kartowymi, a także odpowiada przed nadzorem. Platforma BaaS dostarcza API do zakładania kont, wydawania kart, zlecania przelewów i weryfikacji klientów. Fintech odpowiada za całą resztę, którą widzi klient: aplikację, rejestrację, obsługę zgłoszeń i sposób, w jaki produkt zarabia. Część obowiązków związanych z weryfikacją klientów i monitorowaniem transakcji bank zwykle przekazuje partnerowi w umowie. Zespół produktu musi więc uwzględnić je w projekcie od pierwszego dnia, a nie dopisywać przed startem. Po co to wszystko? Głównie dla czasu. Uzyskanie licencji i zbudowanie systemu bankowego to projekt na lata, a integracja z gotową platformą to projekt na miesiące. Przy produktach, które dopiero szukają swojego rynku, czas wejścia na rynek (time to market) często przesądza o tym, czy pomysł w ogóle dostanie szansę.

Co można zbudować na BaaS

Najbardziej oczywisty przypadek to konto z kartą w aplikacji mobilnej na iOS i Androida, na przykład neobank dla freelancerów albo konto dla nastolatków pod kontrolą rodzica. Takich produktów jest sporo, a konkurencja jest duża. Ciekawiej robi się tam, gdzie finanse są dodatkiem do innej usługi. Ten kierunek nazywa się embedded finance, czyli finanse wbudowane w produkt, który sam w sobie finansowy nie jest. Kilka przykładów pokazuje, jak to wygląda w praktyce. Platforma dla firm transportowych wydaje kierowcom karty paliwowe z limitami ustawianymi w panelu przewoźnika. Program do fakturowania dla małych firm prowadzi rachunek, na który wpływają płatności od kontrahentów, i od razu oznacza faktury jako zapłacone. Platforma sprzedażowa typu marketplace przechowuje środki kupującego do czasu realizacji zamówienia, a potem dzieli je między sprzedawcę i prowizję operatora. System do zarządzania najmem odkłada kaucje na osobne subkonta i zwraca je po zakończeniu umowy. Wspólny mianownik jest prosty. Firma ma już klientów i proces, w którym przepływają pieniądze. BaaS pozwala jej ten przepływ obsłużyć u siebie, zamiast odsyłać klienta do banku. Klient zyskuje wygodę. Firma - dodatkowy przychód i dane o tym, jak jej klienci płacą.

Osobną kategorią jest finansowanie. Część platform BaaS oferuje moduły kredytowe, ale ścieżkę wniosku i zasady oceny ryzyka fintech zwykle projektuje sam, bo to one odróżniają go od konkurencji. Dla Horyzont Capital, firmy udzielającej pożyczek biznesowych, zbudowaliśmy platformę, na której przedsiębiorca składa wniosek w całości online, bez telefonu do doradcy i wizyty w oddziale. Podobny problem, czyli jak zebrać komplet danych i nie zgubić klienta w połowie formularza, wraca przy cyfryzacji procesu leasingowego i przy każdym produkcie, w którym przed podpisaniem umowy trzeba kogoś zweryfikować.

Nie każdy pomysł wymaga od razu kont i kart. Jeśli firmie wystarczy przyjmowanie płatności, subskrypcje i wypłaty dla partnerów, prostszą drogą bywa operator płatności taki jak Stripe, który w części krajów oferuje też wydawanie kart i rozliczenia dla platform.

Architektura produktu fintech opartego na BaaS

Na diagramie wszystko wygląda prosto: aplikacja mobilna, backend, API dostawcy. Najczęstszy błąd polega na tym, że API dostawcy traktuje się jak własną bazę danych. Aplikacja pyta platformę BaaS o saldo przy każdym otwarciu ekranu, historię transakcji pobiera na żywo, a logikę biznesową opiera na obiektach dostawcy. Działa to, dopóki dostawca odpowiada szybko i niczego nie zmienia. Oba warunki przestają być prawdziwe szybciej, niż zakłada harmonogram projektu.

Lepszy wzorzec to własny backend jako warstwa pośrednia. W podejściu API-first najpierw projektuje się API produktu, czyli kontrakt, z którego korzystają aplikacje mobilna i webowa, a integrację z dostawcą zamyka się w osobnym module, tzw. adapterze. Aplikacja nie wie, który bank stoi za kontem. Zmiana dostawcy albo dodanie drugiego oznacza nowy adapter, a nie przepisywanie całego systemu.

Własna księga operacji (ledger)

Ledger to rejestr wszystkich operacji finansowych w produkcie, prowadzony według zasady podwójnego zapisu: każda kwota, która skądś wychodzi, gdzieś trafia. Bank prowadzi własną księgę, ale nie zna logiki produktu. Nie wie, że część środków na rachunku zbiorczym to kaucje kilku najemców ani że pieniądze z zamówienia na platformie należą się sprzedawcy dopiero po doręczeniu paczki. To wie tylko fintech.

Księga musi być odporna na awarię w połowie operacji. Obie strony księgowania zapisuje się więc w jednej transakcji bazodanowej ACID, czyli takiej, która zapisze się w całości albo wcale. Wpisów się nie poprawia i nie usuwa. Błąd koryguje się nowym zapisem, dzięki czemu po roku da się odtworzyć, co i dlaczego stało się z każdą złotówką. Takie podejście jest bliskie wzorcowi event sourcing, w którym aktualny stan konta wynika z historii zdarzeń, a nie z jednej liczby nadpisywanej przy każdej zmianie. Na tej historii opiera się codzienne uzgadnianie: system porównuje własną księgę z raportami banku i zgłasza każdą rozbieżność do wyjaśnienia, zamiast ją po cichu wyrównywać.

Zdarzenia, webhooki i powtórzone żądania

W bankowości wiele dzieje się z opóźnieniem. Autoryzacja karty w sklepie trwa sekundy, rozliczenie przychodzi po dniu lub dwóch, zwrot jeszcze później. Dostawca informuje o tych zmianach przez webhooki w aplikacji webowej, czyli automatyczne powiadomienia wysyłane na adres serwera fintechu. Powiadomienie może przyjść dwa razy, w innej kolejności niż zdarzenia albo wcale. System musi to wytrzymać i umieć sam dopytać dostawcę o brakujące dane. Druga strona tego samego problemu to idempotencja, czyli gwarancja, że powtórzone żądanie nie wykona operacji drugi raz. Każde zlecenie przelewu dostaje unikalny klucz. Jeśli połączenie zerwie się w trakcie, a aplikacja wyśle je ponownie, dostawca rozpozna duplikat. Brzmi jak detal. Bez niego klient, który na słabym zasięgu dwa razy stuknie „Wyślij", zapłaci podwójnie.

Dostawcy udostępniają środowisko testowe (sandbox) z fikcyjnymi pieniędzmi, ale rzadko odwzorowuje ono wszystkie przypadki brzegowe, takie jak częściowy zwrot, reklamacja transakcji kartowej czy opóźnione rozliczenie. Dlatego do testów automatycznych przygotowujemy własne atrapy API (stub), które pozwalają wywołać każdy scenariusz na żądanie.

Onboarding i weryfikacja klienta bez utraty chętnych

Zanim klient dostanie konto, trzeba potwierdzić jego tożsamość. Ten proces nazywa się KYC (Know Your Customer) i zwykle obejmuje zdjęcie dokumentu, selfie lub krótkie nagranie oraz sprawdzenie osoby na listach sankcyjnych. Przy firmach dochodzi weryfikacja w rejestrach i ustalenie, kto faktycznie kontroluje spółkę. Platformy BaaS często mają gotowy moduł weryfikacji albo integrację z wyspecjalizowanym dostawcą. Technicznie to kilka wywołań API. Produktowo to moment, w którym odpada najwięcej chętnych. Klient chciał konta „na już", a musi szukać dowodu i czekać na wynik. Dlatego proces onboardingu użytkownika projektujemy tak samo starannie jak główne funkcje aplikacji.

Kilka zasad sprawdza się niezależnie od branży. Na początku klient powinien zobaczyć, ile kroków czeka klienta i co będzie mu potrzebne. Postęp powinien się zapisywać, żeby można było przerwać i wrócić później na innym urządzeniu. Dane, które platforma już zna, na przykład NIP i nazwę firmy klienta B2B, można wstępnie wypełnić, tak by klient tylko je potwierdził. Najwięcej uwagi wymagają ścieżki, gdy coś idzie nie tak: odrzucone zdjęcie, weryfikacja ręczna, prośba o dodatkowy dokument. Komunikat „Wystąpił błąd" to w tym miejscu najkrótsza droga do utraty klienta. Te ekrany wymagają przemyślanego projektowania UX/UI aplikacji, a nie domyślnego szablonu dostawcy. Po założeniu konta zaczyna się codzienne bezpieczeństwo. Logowanie i zatwierdzanie płatności wymagają uwierzytelniania wieloskładnikowego (MFA), czyli potwierdzenia tożsamości co najmniej dwoma niezależnymi sposobami, na przykład hasłem i biometrią telefonu. Dobrze zaprojektowane MFA nie irytuje. Źle zaprojektowane sprawia, że klienci przestają używać aplikacji do płatności.

Jak wybrać dostawcę BaaS

Oferty platform BaaS na pierwszy rzut oka wyglądają podobnie: konta, karty, przelewy, weryfikacja klientów, wszystko przez API. Różnice wychodzą w szczegółach, najczęściej już po podpisaniu umowy. Przed decyzją sprawdzamy z klientami:

• zasięg: kraje, waluty i rodzaje kont oraz kart dostępne dziś, a nie „na roadmapie",
• jakość API i dokumentacji, wierność sandboxa oraz to, jak dostawca zapowiada zmiany i wersjonuje interfejs,
• dostęp do danych: surowe raporty rozliczeniowe potrzebne do uzgadniania księgi i możliwość eksportu pełnej historii klientów,
• strukturę: czy platforma sama ma licencję, czy pośredniczy między fintechem a bankiem, oraz jak przechowywane są środki klientów,
• model opłat: stałe opłaty miesięczne, minimalne zobowiązania, stawki za konto, kartę, transakcję i weryfikację,
• deklarowaną dostępność usługi i sposób informowania o awariach,
• warunki wyjścia, czyli co się stanie z klientami, numerami rachunków i kartami, jeśli trzeba będzie zmienić dostawcę.

Ostatni punkt najczęściej pomija się przy negocjacjach, bo wszyscy zaczynają współpracę z optymizmem. Tymczasem zależność od jednego dostawcy to klasyczne ryzyko operacyjne w firmie, które należy opisać tak samo jak ryzyko awarii serwera. Pomaga architektura z adapterem, własny ledger z pełną historią i zapisy w umowie o przekazaniu danych przy rozstaniu. Awarie też się zdarzają. Gdy platforma BaaS przestaje odpowiadać, aplikacja nie powinna pokazywać zerowego salda ani pustej historii. Lepiej wyświetlić ostatni znany stan z informacją o jego aktualności i wstrzymać tylko te operacje, które naprawdę wymagają banku. Projektowanie z myślą o wysokiej dostępności systemu (high availability) obejmuje także to, jak produkt zachowuje się, gdy zawodzi ktoś inny.

Przed podpisaniem umowy dobrze jest poprosić o dostęp do sandboxa i zbudować mały prototyp integracji: założenie konta, przelew, zwrot i obsługę kilku webhooków. Kilka dni pracy zespołu technicznego powie o dostawcy więcej niż prezentacja handlowa.

Ekonomia produktu na BaaS

Produkt finansowy może zarabiać na kilka sposobów. Przy kartach wydawca dostaje część prowizji płaconej przez sklep przy każdej transakcji (tzw. interchange) i zwykle dzieli się nią z fintechem. W Europie ta opłata jest niska, więc rzadko wystarcza jako jedyne źródło przychodu. Dochodzą abonamenty za plany premium, opłaty za przewalutowanie, marża na finansowaniu, a w embedded finance także korzyść pośrednia: klient, który ma w platformie swoje pieniądze, rzadziej z niej odchodzi. Tę retencję klienta trudniej policzyć, ale często to ona uzasadnia całą inwestycję. Po stronie kosztów są opłaty dostawcy: za aktywne konto, za wydanie i wysyłkę karty, za transakcję, za każdą weryfikację klienta. Do tego minimalne miesięczne zobowiązania, które przy małej skali potrafią przewyższyć przychody. Swoje kosztuje obsługa klienta, bo pytania o pieniądze wymagają szybkiej i kompetentnej odpowiedzi, a także straty na nadużyciach i reklamacjach transakcji.

Dlatego model biznesowy produktu liczymy przed wyborem dostawcy, a nie po nim. Dobrym ćwiczeniem jest arkusz z trzema poziomami skali, na przykład pierwszy tysiąc aktywnych klientów, kilkanaście tysięcy i kilkaset tysięcy, oraz pytanie, przy jakiej liczbie klientów przychód na jednego z nich pokrywa koszt jego obsługi. Cenniki dostawców różnią się mocno właśnie strukturą: jeden jest tani na starcie i drogi przy dużej skali, inny odwrotnie.