RFP opisuje funkcje. Prawdziwe wyzwania wdrożenia zaczynają się gdzie indziej

4 rzeczy, których nie widać w RFP na bankowość elektroniczną

W zapytaniach ofertowych dotyczących bankowości elektronicznej banki głównie funkcje widoczne dla klienta. Najczęściej są to przelewy, historia operacji, lokaty oraz płatności. Znacznie rzadziej pojawia się opis logiki wynikającej z działania systemu głównego banku, czyli core banking.

W dokumentach RFP (Request for Proposal) prawie nie widać konsekwencji regulacji PSD (Payment Services Directive) oraz PSD2 (Payment Services Directive 2). W rezultacie projekt wygląda jak wdrożenie prostego systemu do przelewów. W rzeczywistości jest to integracja z rozbudowanym środowiskiem systemów bankowych. Właśnie te elementy najczęściej powodują napięcia projektowe i zmiany zakresu w trakcie realizacji.

W tym artykule pokazuję elementy architektury systemów bankowych, które rzadko pojawiają się w zapytaniach RFP. Wyjaśniam na co zwracać uwagę podczas projektowania i wdrożenia bankowości elektronicznej. Chodzi przede wszystkim o logikę systemu core banking, regulacje płatnicze oraz procesy rozliczeniowe. To te obszary w praktyce definiują sposób działania całego systemu.

1. Bankowość elektroniczna nie jest systemem bankowym

Dla klienta bankowość internetowa i mobilna wygląda jak jedna aplikacja banku. Klient korzysta z niej w przeglądarce lub w telefonie. Z perspektywy architektury są to tylko kanały dostępu do usług banku. Kanały przyjmują dyspozycje klienta i pokazują dane o rachunku. Nie prowadzą rachunków. Nie księgują operacji. Nie przechowują stanu finansowego klienta.

Źródłem prawdy pozostaje system core banking. To w nim powstają dokumenty księgowe, tam zachodzi dekretacja operacji i tam zmieniają się salda rachunków.

Rolą bankowości elektronicznej jest jedynie prezentowanie danych z systemu głównego oraz przekazywanie dyspozycji klienta do realizacji. W praktyce oznacza to, że wdrożenie bankowości elektronicznej polega na budowie spójnej warstwy kanałowej (web i mobile), opartej na tych samych usługach integracyjnych.

Ważna jest również logika obsługi środków na rachunku. Jeśli przelew nie jest wykonywany tego samego dnia, pieniądze nie są od razu pobierane z rachunku. System zakłada blokadę środków do czasu wykonania operacji. Dopiero w dniu realizacji następuje właściwe księgowanie operacji w systemie bankowym.

PSD wprowadza także obowiązek pełnej informacji o kosztach. Przed zatwierdzeniem przelewu klient musi zobaczyć wszystkie opłaty. Dotyczy to również operacji z przewalutowaniem. System musi pokazać kurs waluty oraz całkowity koszt transakcji. PSD2 wymaga dodatkowo silnego uwierzytelniania klienta. Autoryzacja musi być powiązana z konkretną kwotą przelewu oraz odbiorcą płatności.

3. Godzina graniczna potrafi zmienić przelew z „dzisiaj” na „poniedziałek”

Jednym z najbardziej niedocenianych elementów projektów bankowości elektronicznej jest logika godzin granicznych (Cut Off Time). To ona decyduje, czy przelew złożony przez klienta zostanie przyjęty w danym dniu roboczym, czy dopiero w kolejnym. W praktyce oznacza to, że przelew złożony w piątek po godzinie granicznej może zostać formalnie przyjęty dopiero w poniedziałek.

System musi jednocześnie uwzględniać kalendarze dni roboczych oraz harmonogramy systemów rozliczeniowych. Przelewy złożone w weekend lub święto są traktowane jako przyjęte w najbliższym dniu roboczym, co wpływa zarówno na datę realizacji, jak i przewidywaną datę dostarczenia środków.

Z perspektywy klienta szczególnie problematyczna jest subtelna różnica między przelewem „na dziś” a przelewem „na poniedziałek” złożonym w weekend. W pierwszym przypadku środki mogą zostać zablokowane i operacja nie będzie już odwoływalna, w drugim jest możliwość jego anulowania. Dlatego UX bankowości elektronicznej musi jasno komunikować datę przyjęcia dyspozycji oraz konsekwencje wyboru daty realizacji.

4. EOD, czyli niewidzialne okno, które potrafi zatrzymać system

W systemach core banking funkcjonuje procedura End Of Day (EOD), która odpowiada za zmianę daty księgowej i uruchomienie procesów rozliczeniowych na koniec dnia. Proces ten może trwać kilka godzin, a w jego trakcie system główny często nie przyjmuje nowych dyspozycji finansowych.

Dodatkowym wyzwaniem jest to, że data księgowa nie zawsze odpowiada dacie kalendarzowej. W zależności od momentu uruchomienia procedury w systemie może być jeszcze „wczoraj” lub już „jutro”. Wysłanie dyspozycji z niewłaściwą datą księgową może skutkować jej odrzuceniem przez system core.

Dlatego system bankowości elektronicznej musi uwzględniać takie sytuacje w logice działania. Często oznacza to wstrzymanie przyjmowania dyspozycji, kolejkowanie operacji lub dostosowanie dat księgowych do aktualnego stanu systemu głównego. Dotyczy to również procesów wykonywanych w tle. Przykładem jest generowanie wyciągów lub synchronizacja historii operacji.

Wyzwania wdrożeń bankowości elektronicznej

W projektach bankowości elektronicznej duża część pracy dotyczy koordynacji wielu systemów działających w banku. Kanał cyfrowy musi współpracować z usługami odpowiedzialnymi za płatności, autoryzację, raportowanie oraz obsługę rachunków. Każda z tych usług posiada własne ograniczenia techniczne oraz harmonogramy działania.

W praktyce oznacza to konieczność projektowania stabilnej warstwy pośredniej pomiędzy kanałem cyfrowym a systemami banku. Warstwa ta odpowiada za spójność danych, obsługę błędów oraz kontrolę przepływu operacji między systemami. Bez niej nawet dobrze zaprojektowany interfejs użytkownika nie zapewni stabilnego działania całego rozwiązania.

Wdrożenia tego typu wymagają doświadczenia architektonicznego oraz dobrej znajomości środowiska bankowego. Szczególnie istotna jest znajomość konkretnych systemów core banking. Dostawca, który wcześniej integrował się z danym systemem, zna jego ograniczenia, niestandardowe zachowania oraz „pułapki”, często niewidoczne w dokumentacji czy materiałach RFP. Taka wiedza pozwala skrócić czas projektu i ograniczyć ryzyko problemów na etapie integracji.

Zespoły e-point realizowały projekty, w których konieczne było łączenie nowoczesnych kanałów cyfrowych z rozbudowanymi systemami banku. Doświadczenie to obejmuje projektowanie architektury integracyjnej, budowę warstw pośrednich oraz przygotowanie rozwiązań odpornych na zmienność procesów operacyjnych w banku.

Dzięki takiemu podejściu możliwe jest tworzenie bankowości elektronicznej, która działa przewidywalnie nawet w złożonym środowisku systemów finansowych.