Dla banku PSD2 to moment, w którym systemy zbudowane na lata zamkniętej pracy muszą otworzyć się na świat przez API. Dyrektywa wymusza udostępnienie danych o rachunku i inicjowania płatności licencjonowanym podmiotom trzecim, a Open Banking zamienia to z obowiązku prawnego w realną zmianę architektury. Dla dyrektora ds. cyfrowych, architekta czy dyrektora IT oznacza to jedno: PSD2 to projekt technologiczny, nie tylko compliance’owy.
Z naszego doświadczenia najtrudniejsze nie jest zrozumienie samej dyrektywy, tylko przełożenie jej na bezpieczne, stabilne i utrzymywalne API w środowisku, w którym działa core bankowy, systemy antyfraudowe i wymogi regulatora. Nie mamy w tym obszarze publicznego case study i nie będziemy udawać, że jest inaczej. Robimy co innego, i w tym jesteśmy mocni: dostarczamy ludzi, którzy to zbudują - inżynierów z doświadczeniem w integracjach bankowych i budowie platform, wpiętych w Twój zespół w modelu wzmocnienia lub zespołu dedykowanego.
Czym jest PSD2 i Open Banking i co wymusza na banku?
PSD2 to unijna dyrektywa o usługach płatniczych, która otwiera rynek dla nowych graczy i zobowiązuje banki do współpracy z nimi. Open Banking to szersze zjawisko, które z niej wyrasta: bank przestaje być zamkniętym silosem, a staje się dostawcą usług przez interfejsy.
W praktyce dyrektywa wymusza na banku kilka rzeczy naraz:
- udostępnienie dostępu do rachunku (AIS) i inicjowania płatności (PIS) podmiotom trzecim,
- silne uwierzytelnianie klienta (SCA) tam, gdzie wymaga tego ryzyko,
- bezpieczny, udokumentowany interfejs dla podmiotów trzecich, zgodny z przyjętym standardem,
- środowisko testowe i rejestrację, żeby zewnętrzni dostawcy mogli się podłączyć.
To nie jest jednorazowa zmiana w jednym systemie, tylko nowa warstwa, którą utrzymujesz i rozwijasz razem z resztą banku.
Jak udostępnić API dla podmiotów trzecich (AIS/PIS)?
Sercem przygotowania są dwa typy usług. AIS (Account Information Service) pozwala podmiotowi trzeciemu, za zgodą klienta, odczytać dane o rachunku i transakcjach. PIS (Payment Initiation Service) inicjuje płatność bezpośrednio z konta klienta, bez pośrednictwa karty.
Budowa tych interfejsów to coś więcej niż wystawienie endpointu. Projektujemy je tak, żeby odpowiadały na realny ruch z wielu podmiotów naraz, miały jasny kontrakt i nie obciążały nadmiernie systemów źródłowych. Spinamy warstwę API z core’em bankowym przez stabilne integracje, dokładamy limitowanie ruchu i wersjonowanie, a całość osadzamy w standardzie przyjętym przez bank - tak, żeby kolejne podłączenia dostawców nie wymagały przebudowy fundamentu.
Jak działa silne uwierzytelnianie (SCA) w kontekście API?
Silne uwierzytelnianie klienta (SCA) to wymóg potwierdzenia tożsamości co najmniej dwoma niezależnymi czynnikami: czymś, co klient wie, czymś, co ma, i czymś, czym jest. W świecie API to właśnie SCA decyduje, czy otwarcie banku będzie bezpieczne, czy stanie się furtką dla nadużyć.
Wyzwanie polega na tym, żeby wpleść SCA w przepływy API bez psucia doświadczenia klienta. Realizujemy to kilkoma elementami układanki:
- przekierowania i tokeny łączące sesję klienta z żądaniem podmiotu trzeciego,
- obsługę wyłączeń z SCA tam, gdzie regulacja na to pozwala (np. niskie kwoty, zaufani odbiorcy),
- powiązanie zgody z uwierzytelnieniem, żeby klient wiedział, na co się zgadza,
- spójność z systemami antyfraudowymi, które oceniają ryzyko transakcji w tle.
Dobrze zaprojektowany SCA chroni bank i klienta, nie zamieniając każdej operacji w test cierpliwości.
Jak zadbać o bezpieczeństwo i zgody klienta?
Otwarcie banku przez API przesuwa granicę zaufania na zewnątrz, więc zarządzanie zgodami staje się osobnym komponentem, a nie przypisem. Klient musi wiedzieć, komu i na jak długo udostępnia dostęp, i móc go w każdej chwili cofnąć, a bank ten stan rejestrować, egzekwować i audytować.
Patrzymy tu na kilka warstw naraz: szyfrowanie i certyfikaty w komunikacji z podmiotami trzecimi, rejestr zgód powiązany z zakresem danych, pełną ścieżkę audytu każdego dostępu oraz monitoring wychwytujący nietypowe wzorce ruchu. Bezpieczeństwo w Open Bankingu nie jest pojedynczą funkcją, tylko cechą całej architektury - i tak je traktujemy od pierwszej linijki projektu.
Jak zaprojektować architekturę API i nimi zarządzać?
Techniczne serce PSD2 to warstwa między światem zewnętrznym a wnętrzem banku. Zwykle buduje się ją wokół bramy API (API gateway) i spójnego zarządzania cyklem życia interfejsów.
Składamy tę warstwę z elementów, które muszą ze sobą grać:
- API gateway jako punkt wejścia, uwierzytelniania i limitowania ruchu,
- mikroserwisy przekładające żądania na operacje w systemach banku,
- portal dla deweloperów z dokumentacją i środowiskiem testowym (sandbox),
- monitoring i obserwowalność, żeby widzieć ruch, błędy i wydajność w czasie rzeczywistym.
Taki fundament trzyma API w ryzach, gdy liczba podłączonych podmiotów rośnie.
Dlaczego Open Banking to szansa biznesowa, a nie tylko obowiązek?
Większość banków zaczyna od compliance, ale zatrzymanie się na tym etapie to zmarnowany potencjał. Ta sama infrastruktura, którą budujesz pod obowiązek, otwiera drogę do Banking as a Service i nowych źródeł przychodu.
Mając solidne, dobrze zarządzane API, bank może wejść głębiej: oferować usługi partnerom przez interfejsy, osadzać płatności w aplikacjach zewnętrznych firm, budować własne produkty fintechowe na swojej platformie. To kluczowa zmiana optyki - inwestycja w API przestaje być kosztem zgodności, a staje się fundamentem produktu. Dlatego architekturę warto projektować od razu z myślą o tym drugim etapie, nawet jeśli start wymusza regulacja.
Jakie kompetencje dostarczamy do projektu PSD2?
Do takiego projektu nie wystarczy jeden profil. Obsadzamy role pod konkretną specyfikę pracy, a nie “na zapas”:
- architekci rozwiązań rozumiejący integracje z core bankowym i wzorce API,
- backend developerzy (np. Java, .NET) budujący usługi AIS/PIS i logikę SCA,
- specjaliści DevOps / platform stawiający bramę API, środowiska i pipeline’y,
- inżynierowie bezpieczeństwa dbający o szyfrowanie, zgody i audyt.
Doświadczenie w budowie platform i integracji bankowych traktujemy jako warunek wejścia, nie mile widziany dodatek.
Jak szybko zespół może wejść w projekt bankowy?
Tempo bywa tu krytyczne, bo terminy regulacyjne nie negocjują. Nasz proces rekrutacji zwykle zamyka się w około trzy tygodnie, a do dwóch miesięcy wydłuża się tylko przy nietypowych wymaganiach. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc inżynierowie wchodzą w rytm pracy, przeglądy kodu i spotkania bez długiego rozruchu. W środowisku bankowym dokładamy do tego czas na procesy bezpieczeństwa i dostępy - i uwzględniamy go realnie w planie.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który wzmacnia Twój zespół ludźmi, a nie slajdami. W PSD2 i Open Bankingu nasza rola jest konkretna:
- obsadzamy role architektów, backendu, DevOps i bezpieczeństwa, dopasowane do Twojego stacku,
- budujemy warstwę API i integracje pod zarządem i standardami Twojego banku,
- wnosimy doświadczenie z platform i integracji, nie przypisując sobie cudzych wdrożeń,
- weryfikujemy kompetencje przed startem, bo w banku nie ma miejsca na próby.
Najczęściej działamy w modelu wzmocnienia zespołu lub zespołu dedykowanego, a tam gdzie potrzebny jest zamknięty zakres, jako projekt dedykowanego oprogramowania realizowany przez nasz zespół.
Od czego zacząć przygotowania do PSD2 i Open Banking?
Zacznij od jednego pytania: które usługi (AIS, PIS, SCA) i w jakim standardzie musisz udostępnić najpierw, i jak to wpina się w Twój core bankowy. Ta odpowiedź wyznacza architekturę API, wymagania bezpieczeństwa i role, których potrzebujesz w zespole. Dopiero potem warto decydować o modelu współpracy - różnice między nimi opisaliśmy w artykule o modelach współpracy IT.
Przygotowujesz bank na PSD2 i Open Banking? Porozmawiajmy - dobierzemy inżynierów i architekturę, którzy to z Tobą zbudują.