Headless Banking i dekompozycja monolitów. Jak regulacje zmieniają architekturę bankową? 

Europejskie banki przez ostatnią dekadę intensywnie rozwijały kanały cyfrowe. Powstały dopracowane aplikacje mobilne i serwisy transakcyjne, a wiele procesów sprzedażowych oraz obsługowych zostało zautomatyzowanych. W wielu organizacjach warstwa widoczna dla klienta rozwijała się jednak szybciej niż technologiczny fundament. 

Cyfrowa fasada rosła, podczas gdy core banking często pozostawał ten sam od 15, 20, a czasem nawet 30 lat. Nowoczesne kanały skomunikowane przez API współistnieją dziś z monolitycznym backendem, który coraz trudniej rozwijać i testować, a gęsta sieć zależności dodatkowo komplikuje izolowanie awarii. 

Przez lata taki model działał wystarczająco dobrze. Obecnie coraz częściej dochodzi jednak do punktu, w którym koszt złożoności zaczyna przewyższać korzyści stabilności. 

Ważnym katalizatorem zmian są regulacje: PSD3/PSR, FiDA i DORA pozostawiają bankom wybór modelu architektury, a jednocześnie podnoszą wymagania operacyjne i zakres odpowiedzialności. W efekcie coraz większego znaczenia nabiera pytanie, jak zbudować architekturę zdolną sprostać kolejnym wymaganiom regulacyjnym i zmianom rynkowym. 

Najważniejsze informacje: 

• Architektura Headless Banking oddziela warstwę doświadczenia klienta od logiki biznesowej i danych, dzięki czemu poszczególne kanały mogą rozwijać się bardziej niezależnie. 
• Regulacje DORA, PSD3/PSR i FiDA zwiększają znaczenie odporności operacyjnej, jakości API, zarządzania zgodami, kontroli dostępu oraz możliwości śledzenia pochodzenia i wykorzystania danych. 
• Rosnąca złożoność monolitów sprawia, że nawet niewielka zmiana może wpływać na wiele powiązanych procesów. 
• O powodzeniu modernizacji decydują przede wszystkim dobrze zaprojektowane granice domen biznesowych. Mikroserwisy są jednym ze sposobów ich technicznej realizacji. 
• Podejście Strangler Fig pozwala prowadzić dekompozycję etapami i stopniowo przenosić kolejne funkcje poza system legacy. 

Bankowość przechodzi od aplikacji do platformy 

Tradycyjna architektura banku dawała się opisać prosto:  

Kanał > Aplikacja bankowa  >> Core Banking  

Przy ograniczonej liczbie kanałów taka centralizacja miała sens. Jeden system pełnił rolę Single Source of Truth, czyli „źródła prawdy”, a aplikacje pełniły funkcję relatywnie “cienkich klientów” ( z ang. thin client), czyli przede wszystkim wyświetlały dane i przekazywały działania użytkownika do core banking. 

Współczesny bank działa jednak w znacznie bardziej rozbudowanym otoczeniu. Klient korzysta z aplikacji mobilnej i serwisu webowego, kontaktuje się z bankiem przez contact center lub oddział, a część usług finansowych może otrzymywać bezpośrednio na platformach partnerów. Dochodzą do tego integracje B2B z systemami ERP klientów korporacyjnych, urządzenia IoT, chatboty czy interfejsy głosowe. 

Coraz większą rolę odgrywa też embedded finance, czyli bankowość osadzona bezpośrednio w doświadczeniach oferowanych przez inne firmy. Usługa finansowa może pojawić się podczas zakupów, w aplikacji operatora telekomunikacyjnego albo na platformie e-commerce. 

W takim środowisku bank coraz częściej działa jak platforma usługowa, której możliwości są dostępne w wielu kanałach i systemach. Ten kierunek dobrze oddaje pojęcie Headless Banking. 

Czym jest Headless Banking? 

Headless Banking przenosi na grunt bankowości podejście headless znane m.in. z e-commerce. Jego podstawą jest pełna separacja warstwy prezentacji, czyli front-endu, od logiki i danych znajdujących się po stronie back-endu. 

Warstwa frontowa obejmuje aplikacje mobilne i webowe, chatboty, voice, portale partnerów czy kanały embedded. Po stronie back-endu znajdują się domeny odpowiedzialne m.in. za klienta, płatności, kredyty, depozyty, KYC/AML, ryzyko oraz fraud. 

Kanały komunikują się z backendem wyłącznie przez API oraz zdarzenia biznesowe (eventy). Dzięki temu mogą rozwijać się niezależnie od logiki produktowej, a bank może udostępniać swoje usługi w kolejnych kanałach i ekosystemach bez konieczności przebudowy całego systemu przy każdej zmianie interfejsu lub sposobu obsługi klienta. 

Dlaczego monolit staje się problemem właśnie teraz? 

Przez lata monolit dobrze odpowiadał na potrzebę stabilności i spójności systemów bankowych, ale wraz ze wzrostem skali oraz tempa zmian jego ograniczenia stają się jednak coraz bardziej odczuwalne zarówno dla samego biznesum jak i działów IT instytucji finansowych. 

Typowy monolityczny system bankowy może liczyć miliony linii kodu i obejmować setki procesów biznesowych. Dochodzi do tego wspólny model danych, wdrożenia prowadzone w jednym cyklu oraz gęsta sieć zależności, której nikt już nie rozumie w całości. 

W takim środowisku nawet stosunkowo niewielka zmiana w procesie płatności lub obsłudze reklamacji może wpłynąć na dziesiątki innych obszarów. 

Jednocześnie organy nadzorcze zwiększają wymagania właśnie w tych obszarach, w których silnie powiązana architektura stwarza najwięcej wyzwań: 

• odporność operacyjna i izolacja awarii, 
• cyberbezpieczeństwo oraz kontrola dostępu, 
• śledzenie danych i audytowalność, 
• standaryzacja oraz jakość API, 
• zarządzanie zgodami i udostępnianiem danych. 

I tu dochodzimy do sedna – DORA, PSD3/PSR i FiDA podnoszą poprzeczkę dokładnie w tych punktach, gdzie monolit jest najbardziej kruchy.  

DORA: odporność operacyjna jako wymóg architektury 

DORA, czyli Digital Operational Resilience Act, wprowadza obowiązki związane z zarządzaniem ryzykiem ICT i raportowaniem incydentów. Obejmuje również testowanie odporności oraz kontrolę dostawców technologicznych. 

Z perspektywy architektury wymagania DORA wpływają bezpośrednio na sposób projektowania i utrzymywania systemów.  

DORA przekłada się na konieczność budowy zdolności takich jak:  

1) Fault isolation  

Awaria pojedynczego komponentu nie może „przewracać” całej bankowości. Monolit z definicji sprzyja efektowi domina; architektura domenowa pozwala budować granice awarii.  

2) Observability  

Nie chodzi już tylko o logi. Potrzebne są metryki, trace’y, monitoring techniczny i biznesowy, a także możliwość powiązania incydentu z procesem, klientem i skutkiem.  

3) Recoverability  

Zdolność odtwarzania usług wymaga planów odzyskiwania per domena i sensownych strategii Disaster Recovery (DR).

W monolicie DR często oznacza „wszystko albo nic”.  

4) Operational testing  

Testy odporności, symulacje incydentów, ćwiczenia typu chaos engineering są znacznie łatwiejsze, gdy system jest modularny, ponieważ można testować domeny niezależnie, wprowadzać mechanizmy typu circuit breaker, bulkhead, event replay.  

W praktyce wiele programów wdrożenia DORA staje się jednocześnie programami dekompozycji architektury, nawet jeśli organizacja używa wobec nich innej nazwy. 

PSD3/PSR: API jako produkt 

Regulacja PSD2 zbudowała fundament Open Banking, a przy okazji ujawniła problemy związane z nierówną jakością API czy różnymi interpretacjami standardów. Pojawiły się również kwestie bezpieczeństwa i jakości doświadczenia użytkownika. PSD3 wraz z PSR mają te obszary uporządkować i rozwinąć. 

Dla IT oznacza to przesunięcie ciężaru w stronę podejścia:  

API-first 

Najpierw projektuje się usługę, z której mogą korzystać różne kanały, takie jak web, mobile czy platformy partnerów. Dopiero później określa się, jak dana funkcja będzie wyglądać w konkretnym interfejsie. 

Product thinking dla API  

Zmienia się także sposób zarządzania samymi API. Coraz częściej bank buduje portfolio typu:  

• Payments API,  
• Customer/Identity API,  
• Consent API,  
• Credit decision API.  

Te interfejsy mają roadmapy, właścicieli produktu, mierniki jakości i SLA, jak inne produkty cyfrowe.  

Developer experience  

Interfejs funkcjonujący w większym ekosystemie potrzebuje portalu deweloperskiego i specyfikacji OpenAPI. Dochodzą do tego sandboxy, wersjonowanie, monitoring czy wsparcie. W ten sposób bank coraz bardziej przypomina dostawcę platformy. 

FiDA: otwarcie danych finansowych na skalę większą niż Open Banking 

Jeżeli regulacja PSD2 „otworzyła rachunki płatnicze”, to FiDA ma ambicję otworzyć znacznie szerszy zakres danych w kontrolowany sposób, za zgodą klienta: produkty oszczędnościowe, inwestycyjne, ubezpieczeniowe i inne elementy relacji finansowej.  

To zmienia architekturę w jeszcze głębszy sposób, bo wymusza budowę zdolności, które w wielu bankach dotąd były rozproszone lub traktowane jako poboczny temat:  

• Consent Management – centralne i przejrzyste zarządzanie zgodami,  
• Data Lineage – śledzenie pochodzenia danych i ich transformacji,  
• Data Governance – odpowiedzialność domen za dane i ich jakość,  
• Fine-grained access control – precyzyjne uprawnienia per atrybut / zakres / cel,  
• API monetization – możliwość tworzenia modeli przychodowych na danych i usługach.  

FiDA wykracza więc poza obszar integracji. Przesuwa bank w stronę organizacji, która musi umieć zarządzać danymi jak aktywem rynkowym. 

Domeny biznesowe są ważniejsze niż sam wybór mikroserwisów 

W wielu transformacjach popełnia się błąd utożsamiania modernizację z „przejściem na mikroserwisy”. Tymczasem mikroserwisy to tylko technika wdrożenia. Kluczowe jest coś innego, mianowicie dobrze zaprojektowane granice domen.  

Nowoczesna transformacja bankowa opiera się na: 

Domain-Driven Design (DDD) 

Podejście, w którym architekturę systemu projektuje się wokół rzeczywistych obszarów biznesowych. Pozwala to zidentyfikować domeny takie jak Payments, Cards, Customer, Loans, Fraud czy Treasury i przypisać im konkretne funkcje oraz odpowiedzialności. 

Bounded Context 

Każda domena ma własny model danych i odpowiedzialność. To redukuje zależności i konflikty zmian.  

Event-Driven Architecture 

Architektura oparta na zdarzeniach biznesowych przekazywanych pomiędzy systemami. Przykładowo zdarzenie „Customer Updated” może zostać wykorzystane przez CRM, AML, Fraud czy Marketing. W ten sposób można ograniczyć bezpośrednie integracje punkt-punkt, zmniejszyć sprzężenia między systemami i usprawnić rozwój kolejnych funkcji. 

Jak wygląda docelowa architektura banku jako platformy? 

Docelowa architektura coraz częściej przyjmuje układ warstwowy. Poszczególne części systemu mają jasno określone role, a kanały klienckie są oddzielone od logiki domenowej i infrastruktury integracyjnej. 

1. Warstwa kanałów obejmuje mobile, web, oddziały, contact center oraz embedded finance.

2. Warstwa doświadczenia (Experience Layer) odpowiada za realizację kanałów cyfrowych poprzez komponenty takie jak BFF (Backend for Frontend), Experience API oraz orkiestrację ścieżek użytkownika (Journey Orchestration).

3. Warstwa platformowa dostarcza wspólne usługi, takie jak IAM (Identity and Access Management), observability, bezpieczeństwo, zarządzanie API (API Management) oraz zarządzanie zgodami (Consent Management).

4. Warstwa domenowa skupia kluczowe domeny biznesowe, takie jak Płatności (Payments), Kredyty (Lending), Klient (Customer) i Depozyty (Deposits), wraz z funkcjami wspierającymi zgodność regulacyjną, np. przeciwdziałanie praniu pieniędzy (Anti-Money Laundering, AML).

5. Warstwa danych obejmuje rozwiązania takie jak ODS (Operational Data Store), Lakehouse oraz Event Store.

6. Warstwa integracyjna zapewnia komunikację pomiędzy domenami i systemami z wykorzystaniem API, Event Mesh oraz platform zdarzeniowych, takich jak Kafka.

To model znacznie bliższy Big Tech niż tradycyjnemu bankowi opartemu o pojedynczy centralny system. Przejście do tego modelu może odbywać się etapami, z wykorzystaniem istniejącego core banking i stopniowym przenoszeniem kolejnych elementów poza legacy.

Jak etapowo dekomponować monolit? Strangler Fig w praktyce 

Dekompozycja całego systemu podczas jednego projektu wiąże się z dużym ryzykiem. Podstawowe procesy bankowe muszą działać również w czasie wieloletniej modernizacji, dlatego praktycznym rozwiązaniem jest podejście Strangler Fig. 

Polega ono na stopniowym „obrastaniu” monolitu nowymi komponentami: 

1. Warstwa API Gateway przed monolitem porządkuje dostęp, polityki bezpieczeństwa i monitoring. 
2. Oddzielenie warstwy kanałów uniezależnia UI od logiki core. 
3. Nowe funkcje powstają poza monolitem, szczególnie w obszarach, w których biznes potrzebuje większej szybkości zmian. 
4. Kolejne domeny są migrowane etapami, z jasno określonymi granicami. 
5. Legacy jest stopniowo wygaszane, kiedy jego funkcje przejmują nowe komponenty. 

Dzięki takiemu podejściu transformacja może przebiegać bez odczuwalnych zmian po stronie klienta, a koszty i ryzyko rozkładają się w czasie. 

Największa zmiana jest biznesowa, nie technologiczna  

Headless Banking wykracza poza zmianę architektury. Oznacza zmianę modelu działania banku, który może dostarczać usługi finansowe także poza własną aplikacją, np. w systemach partnerów, procesach zakupowych czy systemach wykorzystywanych przez klientów biznesowych. DORA, PSD3/PSR i FiDA dodatkowo zwiększają znaczenie architektury modularnej opartej na API, domenach i zdarzeniach oraz sprawnego zarządzania danymi. 

Dlatego modernizacja systemów coraz częściej staje się częścią szerszego pytania o przyszłość banku: jak zbudować organizację zdolną do adaptacji przez kolejne lata, mimo rosnących wymagań regulacyjnych i szybkich zmian rynkowych? W tym kontekście dekompozycja monolitów przestaje być projektem IT. Staje się elementem strategii przetrwania i wzrostu europejskiej bankowości w nowej erze regulacyjno-platformowej.  

Jeśli taki kierunek jest częścią planowanej transformacji, porozmawiaj z ekspertami Univio o podejściu dopasowanym do obecnej architektury i celów biznesowych banku. 

Poniżej zebraliśmy odpowiedzi na najczęściej pojawiające się pytania na temat headless banking.

FAQ 

Czym jest Headless Banking? 

Headless Banking to podejście architektoniczne, w którym warstwa prezentacji jest oddzielona od logiki biznesowej i danych. Kanały takie jak aplikacja mobilna, web czy platforma partnera komunikują się z backendem przez API oraz zdarzenia biznesowe. Dzięki temu mogą rozwijać się bardziej niezależnie od systemów core. 

Dlaczego banki dekomponują systemy monolityczne? 

Wraz ze wzrostem liczby zależności nawet niewielkie zmiany w monolicie mogą wpływać na wiele procesów. Dekompozycja pozwala wydzielać domeny i ograniczać sprzężenia między nimi. Ułatwia też izolowanie awarii oraz rozwijanie poszczególnych obszarów w różnym tempie. 

Jak DORA wpływa na architekturę bankową? 

DORA zwiększa znaczenie odporności operacyjnej, monitorowania systemów, odtwarzalności usług oraz testowania odporności. Architektura modularna ułatwia budowanie granic awarii i niezależne testowanie poszczególnych domen. 

Jak działa Strangler Fig w modernizacji systemów bankowych? 

Strangler Fig polega na stopniowym budowaniu nowych komponentów wokół istniejącego monolitu. Kolejne funkcje i domeny są przenoszone do nowej architektury etapami, a komponenty legacy wygasza się w miarę przejmowania ich funkcji przez nowe rozwiązania.