Normalizacja europejskich integracji bankowych PSD2 dla platformy Account-to-Account obsługującej setki tysięcy transakcji miesięcznie.
Praca zamieniła zachowania specyficzne dla banków w spójny proces wewnętrzny bez ukrywania niepewności na granicy integracji.
~2 lata
pracy nad europejskimi integracjami bankowymi
Setki tysięcy / miesiąc
obsługiwanych miesięcznie przez platformę
01
Jeden proces płatności dla instytucji o różnej semantyce.
Każdy bank wnosił własny kontrakt, konfigurację certyfikatów, słownik błędów i interpretację statusu płatności. Ogólny adapter sukces–porażka usuwałby informacje potrzebne do bezpiecznych ponowień i wsparcia operacyjnego.
Integracje normalizowały różnice, zachowując zachowanie konkretnego banku na brzegu systemu. Mutual TLS i certyfikaty zabezpieczały komunikację platformy z instytucją.
02
Zewnętrzne API zgodne regulacyjnie, ale nie operacyjnie.
Stan początkowy
Inne statusy, błędy i reguły retry w każdym banku
Ten sam stan biznesowy mógł być przedstawiany przez banki w różny sposób. Część odpowiedzi była przejściowa, część końcowa, a inne wymagały bezpośredniego wyjaśnienia przed bezpiecznym ponowieniem.
Ograniczenia
Bezpieczeństwo i niejednoznaczność musiały być częścią projektu
PSD2 regulowało środowisko inicjowania płatności.
Mutual TLS i certyfikaty bankowe zabezpieczały komunikację platforma–bank.
Retry nie mogło tworzyć powtórnych prób płatności.
Nieznane i przejściowe statusy musiały pozostać widoczne zamiast być zgadywane.
Strategia integracji
Normalizacja kontraktu z zachowaniem dowodów specyficznych dla banku
Wspólny model upraszczał proces płatniczy, a adaptery bankowe zachowywały szczegóły potrzebne do diagnozy i decyzji, czy operację można ponowić.
Mój wkład
Integracje bankowe od analizy kontraktu do zachowania produkcyjnego.
Przez około dwa lata moja praca skupiała się niemal wyłącznie na europejskich integracjach bankowych Account-to-Account.
Projekt integracji
Tłumaczyłem kontrakty bankowe na wspólny proces płatniczy oraz projektowałem mapowanie statusów, błędów i retry.
Produkcyjne adaptery bankowe
Implementowałem integracje m.in. ze Swedbankiem, National Bank of Greece, Boursorama i CBI oraz bankami z kolejnych rynków europejskich.
Bezpieczna komunikacja z bankami
Pracowałem z Mutual TLS, certyfikatami i ograniczeniami operacyjnymi licencjonowanego środowiska PSD2.
Wolumen transakcji opisuje skalę platformy, a nie przepustowość pojedynczego adaptera. Claim bezpieczeństwa ogranicza się do Mutual TLS i certyfikatów w komunikacji platforma–bank.
Kluczowe decyzje
Semantyka błędu jako część kontraktu domenowego.
Wspólny model musiał uprościć integrację bez zacierania różnicy między stanem do ponowienia, trwałą porażką i nieznanym rezultatem.
01
Adapter dla każdego banku
Każdy kontrakt zewnętrzny pozostaje odizolowany, udostępniając platformie jeden spójny proces.
02
Jawne mapowanie statusów
Odpowiedzi banku są tłumaczone na stany wewnętrzne bez tworzenia fałszywej pewności.
03
Bezpieczny transport na granicy
Mutual TLS i certyfikaty są częścią cyklu życia integracji, a nie dodatkiem na końcu.
04
Kontrolowane retry i duplikaty
Decyzja o ponowieniu wynika ze zwróconego stanu i chroni proces przed powtórzeniem operacji.
Model dostarczania
Powtarzalna ścieżka dla instytucji, które nigdy nie są identyczne.
01
Interpretacja kontraktu banku
Mapowanie procesu płatności, certyfikatów, statusów, błędów i przypadków bez jednoznacznej odpowiedzi.
02
Implementacja i normalizacja
Budowa adaptera i tłumaczenie jego zachowania na wspólny model płatności.
03
Wzmocnienie ścieżek błędów
Weryfikacja retry, duplikatów i niejednoznacznych stanów przed kontrolowanym wdrożeniem produkcyjnym.
Zweryfikowany zakres produkcyjny
Wiele europejskich integracji w jednym procesie płatniczym.
~2 lata
bezpośredniej pracy nad europejskimi integracjami bankowymi
Setki tysięcy / miesiąc
w skali całej platformy Account-to-Account
Nie deklaruję poprawy konwersji, opóźnienia ani skuteczności transakcji, ponieważ nie ma zweryfikowanej bazy porównawczej.
Czego to dowodzi
Odpowiedzialność integracyjna w regulowanej domenie finansowej.
Projekt pokazuje bezpieczne integracje zewnętrzne, jawne modelowanie błędów i umiejętność zamiany wielu kontraktów instytucji w jeden operowalny proces wewnętrzny.
FairyDeck używa niezbędnej pamięci własnej, aby zapisać tę decyzję. Za Twoją zgodą Google Analytics mierzy wizyty, sesje i kliknięcia prowadzące do kalendarza. Osobna zgoda pozwala Google Ads odnotować wyłącznie poprawne wysłanie formularza — bez jego treści.