Bank może mieć portal z setką funkcji, do którego klient loguje się raz na kwartał i tak robi przelew w aplikacji innego dostawcy. Problemem rzadko jest brak funkcji, a niemal zawsze to, czy klient realnie z nich korzysta. Dla dyrektora ds. cyfrowych oznacza to, że sukcesu portalu bankowości internetowej nie mierzy się listą wdrożonych modułów, tylko tym, ile spraw klient załatwia online, nie dzwoniąc i nie przychodząc do oddziału.
Z naszego doświadczenia to, co decyduje o powodzeniu, nie jest efektowne: szybkość, przewidywalność, bezpieczeństwo bez tarcia i czyste połączenie z systemami banku. Takie platformy budujemy od lat. Dla wiodącego banku z silną obecnością w regionie CEE współtworzyliśmy platformę cyfrową dla klientów korporacyjnych, spełniając bardzo wymagające oczekiwania co do konkretnych języków programowania i technologii.
Czego dziś oczekuje klient banku online?
Klient banku nie porównuje już Waszego portalu z portalem konkurencji. Porównuje go z każdą inną aplikacją, której używa codziennie, i oczekuje tego samego poziomu płynności. Logowanie ma być natychmiastowe, saldo widoczne od razu, a najczęstsza operacja osiągalna w dwóch, trzech krokach.
W bankowości korporacyjnej dochodzi do tego inna waga pojedynczej czynności. Klient detaliczny sprawdza saldo, klient korporacyjny autoryzuje wielopoziomowy przelew na dużą kwotę, zarządza uprawnieniami zespołu i pobiera dane do własnych systemów. Jeden portal musi obsłużyć oba te światy, nie upraszczając korporacyjnego i nie przytłaczając detalicznego. To napięcie między prostotą a głębią jest sednem projektowania bankowości online.
Co naprawdę decyduje o realnym użyciu portalu bankowości internetowej?
O tym, czy klient wraca, przesądzają zwykle trzy rzeczy, których nie widać w zestawieniu funkcji:
- UX dopasowany do zadania - najczęstsze operacje na wierzchu, rzadkie schowane głębiej, zero zbędnych kliknięć na krytycznej ścieżce,
- wydajność i przewidywalność - portal odpowiada tak samo szybko o 9 rano w szczycie, jak w nocy; brak „zawieszania się” przy autoryzacji,
- dostępność i WCAG - portal działa dla osób korzystających z czytników ekranu i nawigacji klawiaturą, co w bankowości jest również wymogiem zgodności,
- zaufanie - klient widzi, że jego pieniądze i dane są bezpieczne, a zabezpieczenia nie wchodzą mu w drogę przy każdym logowaniu.
Dopiero suma tych elementów zamienia „mam konto w tym banku” w „załatwiam wszystko w tym portalu”.
Jak zaprojektować architekturę portalu i jego backend?
Portal bankowości online to kilka warstw, które muszą pracować razem: frontend, który klient widzi, warstwa logiki biznesowej, integracje z systemem centralnym banku oraz warstwa bezpieczeństwa spinająca całość. Projektujemy je tak, aby dało się rozwijać jedną bez przepisywania pozostałych.
Backend takiej platformy musi być odporny i audytowalny, a nie tylko szybki. Każda operacja finansowa wymaga śladu, spójności danych i jasnej obsługi błędów, bo w banku nie ma miejsca na „przelew, który może przeszedł”. Dlatego stawiamy na architekturę modułową lub mikroserwisową tam, gdzie to uzasadnione, z czytelnym podziałem odpowiedzialności i dobrze opisanymi API. Taki fundament pozwala dokładać kanały i funkcje przez lata, a nie budować wszystkiego naraz na premierę.
Jak zadbać o bezpieczeństwo i zgodność w bankowości online?
W banku bezpieczeństwo nie jest funkcją dodatkową, tylko warunkiem istnienia portalu. Projektujemy je od początku, a nie doklejamy na końcu:
- silne uwierzytelnianie i autoryzacja (MFA, SCA) wpięte tak, by chroniły, a nie frustrowały,
- szyfrowanie danych w ruchu i w spoczynku oraz bezpieczne zarządzanie sekretami,
- pełna audytowalność operacji i dostępu, gotowa pod wymogi regulatora,
- zgodność z regulacjami sektora (m.in. PSD2, RODO, wytyczne nadzorcze) wbudowana w procesy, nie w dokumentację po fakcie.
Dla jednej z instytucji private banking od 2017 roku rozwijamy m.in. systemy bezpieczeństwa i platformy cyfrowe dla jej klientów, więc wiemy, że to właśnie ta warstwa najczęściej decyduje o tym, czy projekt w ogóle może ruszyć.
Jak zintegrować portal z systemami banku?
Portal rzadko powstaje na pustym miejscu. Zwykle musi rozmawiać z systemem centralnym, bankowością transakcyjną, systemami kartowymi, hurtownią danych i kilkunastoma usługami, które narastały przez dekady. To integracja, a nie interfejs, bywa najtrudniejszą częścią projektu.
Podchodzimy do tego od strony kontraktów i danych: ustalamy, co dokładnie portal pobiera i zapisuje, przez jakie API i z jaką gwarancją spójności. Tam gdzie systemy źródłowe są stare lub zamknięte, budujemy warstwę pośredniczącą, która izoluje portal od ich ograniczeń. Dzięki temu nowoczesny frontend nie jest zakładnikiem tempa zmian w rdzeniu banku, a jedno i drugie można rozwijać we własnym rytmie.
Jak zapewnić wydajność i skalę przy ruchu z całego banku?
Bankowość online ma szczyty: dzień wypłat, koniec miesiąca, sesja giełdowa. Platforma musi trzymać czasy odpowiedzi także wtedy, gdy loguje się połowa klientów naraz. Dbamy o to na kilku poziomach:
- skalowanie poziome usług krytycznych (konteneryzacja, orkiestracja), żeby ruch w szczycie nie kładł całości,
- optymalizacja zapytań i warstwy danych, bo to tam zwykle powstają wąskie gardła,
- cache i asynchroniczność tam, gdzie klient nie musi czekać na każdy krok w czasie rzeczywistym,
- monitoring i obserwowalność z realnymi alertami, które widać, zanim zadzwoni klient.
Celem nie jest rekord w teście obciążeniowym, tylko portal tak samo szybki w najgorszy dzień miesiąca, jak w najspokojniejszy.
Jakie kompetencje dostarczamy do projektu bankowego?
Skład dobieramy pod konkretną platformę i jej stos technologiczny, a nie według gotowego szablonu. W projektach dla banków najczęściej obsadzamy:
- architektów i backend developerów budujących rdzeń platformy i jej API,
- frontend developerów odpowiadających za portal i jego UX,
- inżynierów bezpieczeństwa pilnujących uwierzytelniania, szyfrowania i zgodności,
- specjalistów DevOps i QA, którzy odpowiadają za stabilne wdrożenia i jakość.
W bankowości liczy się też to, że dobieramy ludzi pod wymagane technologie, nawet gdy są nietypowe - jak w projekcie korporacyjnym, gdzie kluczowe były bardzo konkretne języki programowania.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z realnym, długoletnim doświadczeniem w sektorze bankowym:
- dla wiodącego banku korporacyjnego, inwestycyjnego i detalicznego z silną pozycją w CEE współtworzyliśmy platformę cyfrową dla klientów korporacyjnych, spełniając bardzo wymagające oczekiwania co do konkretnych języków programowania,
- dla wiodącej instytucji private banking i asset management od 2017 roku rozwijamy systemy wewnętrzne, bezpieczeństwa i platformy cyfrowe dla jej klientów, angażując blisko 90 specjalistów,
- łączymy frontend, backend, bezpieczeństwo i integracje w jedną, utrzymywalną całość,
- kompetencje weryfikujemy przed startem, a skład dopasowujemy do technologii i wymogów konkretnego banku.
Najczęściej realizujemy to jako dedykowane oprogramowanie budowane przez nasz zespół, a tam gdzie bank potrzebuje szybko uzupełnić konkretne kompetencje, w modelu wzmocnienia zespołu lub zespołu dedykowanego.
Od czego zacząć budowę portalu bankowości online?
Zacznij od jednej, najczęstszej sprawy klienta - przelewu, autoryzacji, wglądu w dane - i policz, ile kroków dzieli go dziś od jej załatwienia. To ćwiczenie szybciej pokazuje, gdzie tracicie realne użycie, niż kolejna lista funkcji do dołożenia. Stąd wynika zakres portalu, wymagania wobec backendu i integracji oraz role, których potrzebujecie w zespole. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Projektujesz lub rozwijasz portal i bankowość online? Porozmawiajmy - dobierzemy zespół i architekturę pod Twój bank i Twoich klientów.