Open Banking od strony architektury – jak integrować bank z zewnętrznymi usługami finansowymi?

Czym jest Open Banking z perspektywy architektury IT?

Open Banking to model udostępniania określonych danych i usług bankowych uprawnionym podmiotom zewnętrznym przez kontrolowane interfejsy. W zależności od przypadku może obejmować regulowany dostęp do informacji o rachunku, inicjowanie płatności lub szerszą współpracę komercyjną z partnerami.

Z perspektywy architektury najważniejsza jest separacja. Zewnętrzne aplikacje powinny korzystać z udokumentowanych kontraktów API, a nie bezpośrednio z baz danych, wewnętrznych interfejsów core bankingu czy szczegółów implementacyjnych systemów legacy.

Kto uczestniczy w integracji Open Banking?

• ASPSP (Account Servicing Payment Service Provider) – instytucja prowadząca rachunek płatniczy i udostępniająca odpowiednie interfejsy dostępu.
• TPP (Third-Party Provider) – uprawniony dostawca zewnętrzny korzystający z określonych usług, np. AIS lub PIS.
• PSU (Payment Service User) – użytkownik korzystający z danej usługi płatniczej lub rachunku.
• Platforma API i backend banku – komponenty odpowiadające za weryfikację żądań, egzekwowanie uprawnień, operacje biznesowe i komunikację z systemami źródłowymi.

Regulowany Open Banking a komercyjne partnerstwa API

Nie każda integracja banku z fintechem jest automatycznie regulowaną usługą AIS lub PIS w rozumieniu PSD2. Bank może udostępniać również API w ramach umów komercyjnych, np. dla embedded finance lub innych usług partnerskich.

To rozróżnienie wpływa na architekturę, ponieważ wymagane profile bezpieczeństwa, procesy autoryzacji, obowiązki regulacyjne i zasady współpracy mogą być odmienne. Projektowanie należy rozpocząć od określenia konkretnego modelu usługi.

Open Banking nie oznacza także udostępniania wszystkich danych i operacji każdemu partnerowi. Dostęp musi odpowiadać zakresowi danej usługi i obowiązującym uprawnieniom.

Jakie wyzwania techniczne utrudniają integrację banku z fintechami?

Koszt integracji Open Banking często wynika ze złożoności systemów znajdujących się za API, a nie z samego endpointu. Jedno zapytanie o informacje o rachunku może angażować kilka systemów wykorzystujących różne protokoły, modele danych i mechanizmy bezpieczeństwa.

Rozproszenie danych i logiki biznesowej

Salda, historia transakcji, dane klienta i statusy płatności mogą być przechowywane w różnych komponentach. Dostawca zewnętrzny oczekuje spójnej odpowiedzi, nawet jeśli bank musi pobrać informacje z kilku źródeł.

Starsze protokoły i modele danych

Core banking może udostępniać interfejsy własnościowe lub wykorzystywać starsze formaty komunikatów. Zewnętrzne API potrzebuje natomiast stabilnego kontraktu, przewidywalnej obsługi błędów i formatów zgodnych z przyjętym standardem.

Niespójne modele autoryzacji

Uwierzytelnienie partnera nie wystarcza. Bank musi jeszcze ustalić, czy konkretna operacja jest dozwolona dla danego użytkownika, rachunku i zakresu dostępu.

Zależności wydajnościowe

Jeżeli każde żądanie API synchronicznie obciąża system legacy, ten komponent staje się wąskim gardłem. Brak limitów, timeoutów i izolacji awarii może sprawić, że problem jednego systemu wpłynie na wielu partnerów.

Trudności w diagnozowaniu błędów

Błąd widoczny po stronie fintechu może powstać w gatewayu, usłudze autoryzacyjnej, adapterze lub core bankingu. Bez identyfikatorów korelacyjnych i monitoringu całego przepływu diagnoza wymaga ręcznej współpracy wielu zespołów.

Dlatego samo wdrożenie API gateway nie rozwiązuje problemu integracji. Gateway kontroluje ruch, ale nie uzgadnia automatycznie danych biznesowych, nie zastępuje autoryzacji operacji i nie usuwa zależności od legacy.

Jak powinna wyglądać referencyjna architektura Open Banking?

Skalowalna architektura Open Banking oddziela dostęp zewnętrzny od wewnętrznych systemów bankowych. Każda warstwa ma określoną odpowiedzialność, dzięki czemu bank może zmieniać mechanizmy integracyjne bez niepotrzebnego wpływu na partnerów.

Odpowiedzialności poszczególnych warstw

Nie wszystkie warstwy muszą być osobnymi aplikacjami. Część odpowiedzialności może być połączona lub rozproszona zależnie od architektury banku i przyjętego standardu.

Najważniejsze jest wyznaczenie granic odpowiedzialności, a nie maksymalizacja liczby mikroserwisów.

Jaką rolę pełni API gateway i API management w Open Banking?

API gateway stanowi kontrolowany punkt wejścia dla ruchu zewnętrznego. API management zapewnia dodatkowo publikację, dokumentowanie, monitorowanie, wersjonowanie i zarządzanie interfejsami w całym cyklu życia.

Kluczowe funkcje API management

• Publikacja udokumentowanych endpointów i routing do właściwych usług backendowych.
• Egzekwowanie wybranych polityk dostępu i limitów ruchu.
• Zarządzanie wersjami API oraz wycofywaniem starszych interfejsów.
• Monitorowanie czasów odpowiedzi, błędów i wzorców ruchu.
• Udostępnianie dokumentacji, środowisk testowych i narzędzi dla partnerów.
• Dostarczanie metryk i logów potrzebnych podczas diagnozowania incydentów.

Dlaczego API gateway nie zastępuje autoryzacji biznesowej?

Gateway może sprawdzić, czy żądanie pochodzi od uwierzytelnionego klienta API i spełnia polityki techniczne. Nie oznacza to jednak automatycznie, że dostawca ma prawo pobrać historię transakcji konkretnego klienta lub zainicjować płatność z określonego rachunku.

Takie decyzje wymagają weryfikacji uprawnień, relacji do rachunku, reguł usługi i aktualnego stanu autoryzacji. Odpowiednie mechanizmy muszą działać również w warstwie usług biznesowych.

Pomieszanie uwierzytelniania technicznego z autoryzacją operacji zwiększa ryzyko nieuprawnionego dostępu do danych. Rozróżnienie powinno być widoczne w dokumentacji architektury i scenariuszach testowych.

Jak zaprojektować uwierzytelnianie, autoryzację i zarządzanie uprawnieniami?

Bezpieczeństwo Open Banking wymaga kilku odrębnych decyzji: kto wysyła żądanie, czy dostawca może korzystać z interfejsu, czy użytkownik przeszedł wymagany proces autoryzacji i czy konkretna operacja mieści się w dozwolonym zakresie.

Identyfikacja dostawców zewnętrznych

Bank musi identyfikować i weryfikować uprawnione podmioty zewnętrzne zgodnie z właściwym reżimem regulacyjnym i standardem interfejsu. W zależności od wymagań mogą być wykorzystywane certyfikaty, informacje o statusie dostawcy i mechanizmy bezpiecznego uwierzytelniania klientów API.

Ważne połączenie techniczne nie jest równoznaczne z uprawnieniem do wykonania dowolnej operacji.

OAuth 2.0, OpenID Connect i profile bezpieczeństwa

OAuth 2.0 może wspierać delegowaną autoryzację, a OpenID Connect zapewnia warstwę tożsamości tam, gdzie ma zastosowanie. Bardziej restrykcyjne profile, takie jak Financial-grade API (FAPI), mogą być istotne zależnie od przyjętej architektury i standardu.

Mechanizmy należy wdrażać zgodnie z odpowiednim profilem. Sama walidacja tokenu nie zastępuje sprawdzenia uprawnień biznesowych.

Strong Customer Authentication

Silne uwierzytelnianie klienta (SCA) musi być stosowane tam, gdzie wymagają tego przepisy i konkretny proces. Architektura powinna obsługiwać odpowiednią ścieżkę uwierzytelnienia z zachowaniem kontekstu operacji.

Dokładny przebieg zależy od rodzaju usługi, ewentualnych wyłączeń oraz przyjętej specyfikacji interfejsu.

Zakres dostępu, wygaśnięcie i cofnięcie uprawnień

Decyzje o dostępie mogą wymagać powiązania z konkretnym użytkownikiem, rachunkiem, usługą, operacją i okresem ważności. System musi również obsługiwać ograniczenie, wygaśnięcie i cofnięcie dostępu.

Jeżeli odpowiednie uprawnienie zostanie cofnięte, kolejne żądania muszą być oceniane według aktualnego stanu autoryzacji. Nie można polegać wyłącznie na tokenie, który nadal jest technicznie ważny.

Audyt decyzji dostępowych

Bank powinien przechowywać odpowiedni ślad zdarzeń uwierzytelnienia, decyzji autoryzacyjnych, zmian uprawnień i operacji API. Logi muszą być chronione i nie powinny niepotrzebnie ujawniać danych klientów ani danych uwierzytelniających.

Takie informacje pomagają nie tylko podczas audytu, ale również w odtwarzaniu przebiegu incydentów.

Jak połączyć Open Banking API z core bankingiem i systemami legacy?

Core banking nie zawsze był projektowany do obsługi dużej liczby zewnętrznych odbiorców API. Bezpośrednie udostępnienie jego wewnętrznych interfejsów zwiększa zależności, obciążenie operacyjne i koszt przyszłych zmian.

Bezpieczniejszym architektonicznie podejściem jest umieszczenie usług domenowych i adapterów integracyjnych pomiędzy publicznym API a systemami źródłowymi.

Usługi domenowe jako stabilna warstwa biznesowa

Usługa Open Banking realizuje określoną funkcję, np. pobranie dozwolonych informacji o rachunku lub obsługę inicjowania płatności. Operuje na pojęciach biznesowych właściwych dla API, zamiast ujawniać strukturę systemu źródłowego.

Dzięki temu kontrakt zewnętrzny może pozostać stabilny mimo zmian wewnętrznych źródeł danych.

Adaptery legacy i anti-corruption layer

Adapter tłumaczy żądania i odpowiedzi pomiędzy usługą Open Banking a systemem źródłowym. Może obsługiwać konwersję protokołów, mapowanie pól, translację błędów i wymagania konkretnego połączenia.

Anti-corruption layer dodatkowo ogranicza przenikanie modeli i pojęć legacy do nowych usług. Jest szczególnie przydatna przy etapowej modernizacji architektury.

Jednoznaczny system of record

Dla każdego udostępnianego elementu danych i operacji trzeba określić system autorytatywny. Saldo prezentowane w jednym komponencie nie musi mieć identycznego znaczenia ani momentu aktualizacji jak saldo obliczane w innym.

Bez jasnego właściciela danych odpowiedzi API mogą być niespójne. Sama transformacja nazw pól nie rozwiąże tego problemu.

Timeouty, ponowienia i awarie systemów źródłowych

Zewnętrzne API potrzebuje określonych timeoutów, zasad obsługi błędów, limitów współbieżności i izolacji awarii. Mechanizmy ponawiania żądań należy projektować ostrożnie, szczególnie dla operacji zmieniających stan lub inicjujących płatności.

W procesach płatniczych istotne są idempotencja oraz uzgadnianie statusów, aby ograniczać ryzyko podwójnego wykonania operacji lub niejednoznacznego wyniku po przekroczeniu czasu oczekiwania.

Przykład: pobieranie historii transakcji

Dostawca zewnętrzny żąda historii rachunku przez Open Banking API. Usługa domenowa sprawdza zakres dostępu, a następnie wywołuje adapter, który tłumaczy żądanie na format obsługiwany przez system źródłowy.

Adapter mapuje odpowiedź do uzgodnionego kontraktu API. Jeżeli bank później zmieni wewnętrzny komponent historii transakcji, zewnętrzny interfejs może pozostać bez zmian, o ile nowy adapter zachowa wymaganą semantykę i zachowanie.

Jakie wzorce integracyjne stosować w Open Banking?

Nie istnieje jeden wzorzec właściwy dla wszystkich operacji. Wybór zależy od wymaganego czasu odpowiedzi, możliwości systemów źródłowych, charakteru operacji oraz obowiązującej specyfikacji API.

Kiedy wybrać komunikację synchroniczną?

Wywołania synchroniczne sprawdzają się, gdy API musi zwrócić dane lub decyzję w określonym czasie. Nie powinny jednak pozwalać wolnym systemom źródłowym na nieograniczone zużywanie zasobów gatewaya i usług.

Budżety czasowe, limity współbieżności i odpowiednia obsługa błędów pomagają chronić platformę. Każdy mechanizm awaryjny musi zachować semantykę wymaganą przez API.

Kiedy pomaga przetwarzanie asynchroniczne?

Niektóre operacje wewnętrzne można rozdzielić kolejkami lub orkiestracją asynchroniczną. Pozwala to lepiej zarządzać obciążeniem i etapami procesu.

Nie oznacza to jednak dowolności w projektowaniu regulowanego interfejsu. Jeśli specyfikacja wymaga określonego modelu żądań, odpowiedzi i statusów, implementacja musi go zachować.

Jak kontrolować integracje event-driven?

Architektura zdarzeniowa może wspierać propagację zmian stanu i dopuszczone mechanizmy powiadomień. Wymaga jednak jasnego właściciela zdarzeń, obsługi duplikatów, reguł odtwarzania i monitoringu.

W finansach szczególnie ważne jest jednoznaczne znaczenie zdarzenia. Informacja o przyjęciu dyspozycji płatniczej nie jest potwierdzeniem jej ostatecznego rozliczenia.

Jak wygląda przepływ AIS i PIS w architekturze Open Banking?

Account Information Services (AIS) i Payment Initiation Services (PIS) korzystają z powiązanych mechanizmów bezpieczeństwa i integracji, ale realizują inne operacje biznesowe.

AIS – dostęp do informacji o rachunku

1. Użytkownik rozpoczyna proces dostępu do informacji o rachunku w usłudze zewnętrznej.
2. Bank weryfikuje wymagane elementy uwierzytelnienia i autoryzacji.
3. Dostawca uzyskuje dostęp w dozwolonym zakresie.
4. Żądanie trafia do Open Banking API.
5. Usługa domenowa weryfikuje uprawnienia i pobiera dane przez warstwę integracyjną.
6. Bank zwraca odpowiedź zgodną z kontraktem API i zakresem dostępu.

Architektura musi również obsługiwać wygaśnięcie i cofnięcie uprawnień. Wcześniej poprawne żądanie nie gwarantuje prawa do kolejnych odczytów.

PIS – inicjowanie płatności

1. Uprawniony dostawca przekazuje żądanie inicjowania płatności.
2. Bank weryfikuje dane i właściwe uprawnienia.
3. Użytkownik przechodzi wymagany proces autoryzacji.
4. System płatniczy przyjmuje lub przetwarza dyspozycję zgodnie z regułami.
5. API udostępnia odpowiednie informacje o statusie przewidziane kontraktem.

Należy odróżnić otrzymanie dyspozycji, przyjęcie jej do realizacji, wykonanie i ostateczne rozliczenie. Poszczególne etapy mogą mieć odmienne znaczenie i czas realizacji.

Hipotetyczny scenariusz integracji AIS

Bank chce umożliwić uprawnionemu dostawcy AIS pobieranie informacji o rachunkach klientów. Salda znajdują się w core bankingu, a historia transakcji w osobnym komponencie.

Dostawca inicjuje proces dostępu. Bank weryfikuje jego tożsamość i wymagane uprawnienia użytkownika. Żądanie przechodzi przez API gateway do usługi Open Banking, która sprawdza zakres dostępu do rachunku.

Usługa wywołuje właściwe adaptery, odbiera dane i mapuje je do kontraktu API. Bank rejestruje odpowiednie zdarzenia dostępowe i techniczne na potrzeby monitoringu oraz audytu.

Po cofnięciu dostępu kolejne żądania muszą zostać ocenione według aktualnego stanu autoryzacji. W razie niedostępności systemu źródłowego API powinno zwrócić odpowiedni błąd lub status, zamiast prezentować nieprawidłowe dane.

Przykład ma charakter hipotetyczny i nie opisuje potwierdzonego wdrożenia Edge One Solutions.

Jak zabezpieczyć Open Banking API przed nadużyciami i awariami?

Bezpieczeństwo Open Banking wykracza poza szyfrowanie transmisji i weryfikację danych uwierzytelniających. Bank musi chronić dane, egzekwować uprawnienia, ograniczać nadużycia i izolować awarie pomiędzy połączonymi systemami.

Checklista bezpieczeństwa Open Banking API

OWASP API Security Top 10

OWASP API Security Top 10 jest użytecznym punktem odniesienia przy ocenie podatności, w tym błędów autoryzacji obiektowej, uwierzytelniania i nieograniczonego zużycia zasobów.

W bankowości szczególnie istotna jest autoryzacja na poziomie obiektu. Żądanie zawierające poprawny identyfikator rachunku nie może zakończyć się sukcesem, jeżeli wywołujący nie ma prawa dostępu do tego rachunku i operacji.

PSD2, RTS i odporność operacyjna

Regulowane interfejsy Open Banking muszą uwzględniać właściwe wymagania PSD2 oraz regulacyjnych standardów technicznych dotyczących silnego uwierzytelniania i bezpiecznej komunikacji (SCA/CSC).

DORA ma znaczenie dla zarządzania ryzykiem ICT i odporności operacyjnej instytucji finansowych. Jej wymagania należy analizować łącznie z wewnętrznymi politykami architektury i zarządzania usługami.

Kontrole muszą być dopasowane do konkretnej usługi i jurysdykcji. Ogólna checklista bezpieczeństwa API nie zastępuje właściwych wymagań regulacyjnych.

Jak testować i monitorować integracje Open Banking?

Onboarding partnerów staje się droższy, gdy błędy integracyjne są wykrywane dopiero po uruchomieniu dostępu produkcyjnego. Platforma Open Banking powinna zapewniać powtarzalne testy, udokumentowane kontrakty i monitoring pozwalający diagnozować problemy między warstwami.

Testy kontraktowe i zgodności

Testy powinny weryfikować zgodność żądań, odpowiedzi, błędów i przejść stanów z przyjętą specyfikacją API. Obejmuje to formaty pól, wymagane parametry, zachowania autoryzacyjne i kompatybilność wersji.

Testy integracyjne z systemami źródłowymi

Należy sprawdzać mapowanie danych, błędy backendu, timeouty i różnice pomiędzy modelami wewnętrznymi a kontraktem zewnętrznym. Atrapy usług są przydatne podczas developmentu, ale nie zastępują odpowiednich testów z reprezentatywnym środowiskiem integracyjnym.

Testy bezpieczeństwa i scenariusze negatywne

Kluczowe przypadki obejmują niepoprawne dane uwierzytelniające, wygasły dostęp, cofnięte uprawnienia, nieautoryzowane identyfikatory rachunków, błędne żądania i przekraczanie limitów ruchu.

W przypadku płatności trzeba również testować duplikaty, niejednoznaczne wyniki po timeoutach i uzgadnianie statusów.

Testy wydajności i odporności

Bank powinien sprawdzać oczekiwane obciążenie, szczyty ruchu, degradację systemów źródłowych i zachowanie podczas odtwarzania usług. Istotne jest ustalenie, jak wolny system legacy wpływa na pozostałych odbiorców API.

Sandbox dla partnerów

Środowisko testowe z dokumentacją, przykładowymi żądaniami, danymi syntetycznymi i przewidywalnymi scenariuszami ogranicza zależność partnerów od zespołów banku podczas integracji.

Monitoring end-to-end

Metryki API należy uzupełnić distributed tracing i identyfikatorami korelacyjnymi łączącymi żądanie partnera z gatewayem, usługą domenową, adapterem i systemem źródłowym.

Logi powinny umożliwiać analizę incydentów bez zbędnego ujawniania danych rachunków i danych uwierzytelniających.

Jak rozwijać Open Banking bez zwiększania zależności od core bankingu?

Każdy nowy partner nie powinien oznaczać kolejnego bezpośredniego połączenia z systemem legacy. W przeciwnym razie rośnie liczba ścieżek integracyjnych, koszty utrzymania i trudność koordynowania zmian.

Stabilizacja kontraktów API

Partnerzy powinni zależeć od jasno zdefiniowanego zachowania interfejsu, a nie szczegółów implementacji. Wersjonowanie i polityka kompatybilności pozwalają rozwijać usługi bez wymuszania niepotrzebnych zmian po stronie odbiorców.

Oddzielenie usług domenowych od adapterów legacy

Usługi domenowe powinny reprezentować funkcje bankowe, a adaptery obsługiwać wewnętrzne protokoły i formaty. Dzięki temu wymiana systemu źródłowego nie musi oznaczać zmiany API.

Ograniczanie integracji point-to-point

Centralne zarządzanie API i wielokrotne wykorzystanie komponentów integracyjnych zmniejsza potrzebę budowania każdego połączenia od podstaw. Nie powinno jednak prowadzić do powstania jednego komponentu zawierającego całą logikę biznesową.

Etapowa modernizacja wąskich gardeł

Jeżeli komponent legacy regularnie ogranicza wydajność lub wymaga dużego nakładu ręcznych zmian, bank może modernizować go etapowo przy zachowaniu zewnętrznego kontraktu API.

Może to oznaczać wymianę adaptera, wydzielenie usługi domenowej, zastosowanie cache tam, gdzie jest dopuszczalne, lub zmianę konkretnego procesu wewnętrznego.

Open Banking jako część szerszej strategii API

Open Banking może stanowić ważny element architektury API banku, ale nie musi przejmować wszystkich zadań wewnętrznej platformy integracyjnej.

Interfejsy partnerskie i usługi wewnętrzne mogą mieć odmienne wymagania bezpieczeństwa, dostępności i cyklu życia. Ich odpowiedzialności należy określić osobno.

Jak mierzyć efektywność architektury Open Banking?

Jakość architektury warto oceniać przez efekty istotne dla IT i biznesu: szybkość onboardingu partnerów, niezawodność API, nakład pracy operacyjnej i koszt uruchamiania kolejnych usług.

Metryki należy porównywać w czasie i interpretować w kontekście. Wzrost liczby błędów autoryzacji może oznaczać próby nadużyć, błędną konfigurację partnera albo regresję po zmianie systemu.

Krótszy onboarding jest wartościowy tylko wtedy, gdy bank zachowuje wymagane kontrole bezpieczeństwa, testowania i utrzymania.

Kiedy warto zaangażować partnera technologicznego?

Architektura Open Banking wymaga współpracy zespołów backendowych, integracyjnych, bezpieczeństwa i QA. Zewnętrzny partner technologiczny może pomóc, gdy bank potrzebuje dodatkowych kompetencji lub zasobów do rozwoju platformy.

Edge One Solutions może wspierać instytucje finansowe w takich obszarach jak:

• Projektowanie i rozwój backendu oraz usług domenowych.
• Projektowanie, rozwój i integracja API.
• Budowa middleware i warstwy integracyjnej.
• Adaptery legacy i modernizacja architektury.
• Testowanie API i automatyzacja testów.
• Wsparcie zespołów software engineering i QA.

Celem jest utrzymanie kontroli banku nad architekturą przy ograniczaniu nakładu pracy wymaganego dla każdej kolejnej integracji.

Więcej o podejściu Edge One Solutions do Open Banking i integracji płatniczych.

Podsumowanie: skalowalny Open Banking zaczyna się od separacji architektonicznej

Open Banking nie powinien wymagać bezpośredniego udostępniania core bankingu zewnętrznym dostawcom ani tworzenia nowego połączenia point-to-point dla każdego fintechu.

Dobrze zaprojektowana architektura rozdziela dostęp partnerów, zarządzanie API, uwierzytelnianie, autoryzację biznesową, usługi domenowe i komunikację z systemami legacy. Dzięki temu rozwój integracji jest bardziej przewidywalny, a wewnętrzne zmiany technologiczne mają mniejszy wpływ na partnerów.

Dla CTO oznacza to możliwość lepszego zarządzania ekosystemem partnerów, większą kontrolę nad ryzykiem operacyjnym i solidniejszą podstawę do rozwijania usług finansowych bez każdorazowej ingerencji w core banking.