Open banking i integracja API · partner inżynieryjny
Integracja API open banking,
zaprojektowana jako warstwa, którą posiadasz na własność.
TrustChange projektuje i wdraża integrację API open banking dla instytucji PSP, EMI, neobanków, banków i licencjonowanych VASP działających na rynku UE. Budujemy adaptery dostawców, cykl życia zgód, przepływy SCA, ścieżkę inicjowania płatności oraz uzgadnianie danych w księdze jako dedykowany kod pod Twoją marką — a nie licencję SaaS z opłatą za każde wywołanie. Otrzymujesz warstwę API integracji bankowej, którą Twoi inżynierowie mogą rozwijać, Twój zespół ryzyka może nadzorować, a Twój audytor — odczytać.
- Inżynierowie z UE
- Wdrożenia zgodne z PSD2
- Ślad audytowy zgód
- Przechowywanie danych zgodne z RODO
Co tutaj oznacza „integracja open banking”
Integracja API bankowego bez uzależnienia od agregatora
Większość wyszukiwań dotyczących open banking i integracji API prowadzi do pojedynczego agregatora działającego na licencji. My traktujemy agregatorów jako opcję — jeden adapter spośród wielu — i budujemy warstwę ponad nimi, dzięki czemu to Twój produkt jest właścicielem powierzchni integracji. Adaptery można dodawać, wymieniać lub łączyć, bez konieczności przepisywania kodu produktu, który działa na wyższym poziomie.
Zastanawiasz się, czy zbudować, opakować czy zastąpić istniejącą integrację? Zacznij od Doradztwo CTO. Szyny kart i PSP znajdziesz na inżynierii bramek płatniczych. Szczegóły uzgadniania (reconciliation) znajdziesz na rozwoju księgi płatności i uzgadniania.
Podsystemy
Trzy podsystemy w każdej integracji API open banking, którą budujemy
Open banking to nie jedna usługa. To informacje o rachunku, inicjowanie płatności oraz maszyna stanów zgody, która je łączy. Budujemy wszystkie trzy elementy jako jeden produkt, w jednej architekturze, z jednym zespołem odpowiedzialnym za całość.
-
01
Informacje o rachunku (AIS)
Zagregowany dostęp odczytu do rachunków bankowych klienta — salda, transakcje i dane rachunku ze wszystkich banków i agregatorów, które wybierzesz.
- Zbieranie i odnawianie zgód
- Agregacja wielu banków
- Normalizacja transakcji
-
02
Inicjowanie płatności (PIS)
Inicjuj przelewy SEPA, SEPA Instant oraz krajowe płatności pay-by-bank bezpośrednio z poziomu Twojego produktu, z odpytywaniem o status i uzgadnianiem w Twojej księdze.
- SCA: przekierowanie / rozłączone / wbudowane
- Idempotentne przesyłanie
- Odpytywanie o status i webhooki
-
03
Zgody, tokeny i cykl życia
Maszyna stanów zgody, jakiej oczekuje Twój regulator — udzielona, odnowiona, odwołana, wygasła — wraz ze śladem audytowym dla każdego użytkownika, każdego banku i każdego zakresu.
- Wersjonowanie zgód
- Rotacja tokenów i przechowywanie w KMS
- Odwołania i dziennik audytu
Stos technologiczny
Co kryje się za API integracji bankowości cyfrowej
Osiem warstw, jeden system. Każda warstwa ma określonego właściciela, kontrolę i konkretny dowód audytowy — nic nie pozostaje domyślnie ukryte pod etykietą „open banking”.
Wzorce wdrożeniowe i dowody: jak dostarczamy. Szersze spojrzenie na platformę: infrastruktura fintech. Z perspektywy aplikacji enterprise: firma tworząca aplikacje fintech.
| Warstwa | Co budujemy |
|---|---|
| Adaptery dostawców | Bezpośrednie API banków i agregatorzy PSD2 (np. GoCardless, TrueLayer, Tink, Nordigen, Yapily, Salt Edge lub odpowiedniki dostępne w Twoim regionie) Jeden kanoniczny format na każdą rodzinę API; nowy dostawca to adapter, a nie przepisywanie kodu. |
| Zarządzanie zgodami | Przepływy zbierania zgód, magazyn stanu, harmonogram odnawiania i mechanizmy odwołania Stan zgody jest przechowywany, wersjonowany i weryfikowany ponownie przed każdym wywołaniem — nigdy nie jest zgadywany. |
| SCA i uwierzytelnianie | Ścieżki silnego uwierzytelniania klienta — przekierowanie, rozłączone i wbudowane — z logiką wyjątków tam, gdzie jest dozwolona Doradcy ustalają politykę; przepływ ją wdraża i zapisuje dowody jej zastosowania. |
| Przesyłanie PIS | Idempotentne inicjowanie płatności z ponawianiem, odpytywaniem o status, obsługą webhooków i uzgadnianiem w księdze podwójnego zapisu Każde zgłoszenie zawiera klucz idempotencji wygenerowany po stronie klienta oraz podpisany identyfikator żądania. |
| Model danych | Kanoniczny schemat rachunku, salda i transakcji obowiązujący we wszystkich bankach, z uwzględnieniem kursów walut, opłat i stanów oczekujących Kod produktu po stronie downstream nie rozgałęzia się w zależności od banku — robi to model danych. |
| Przechowywanie i retencja | Przechowywanie zgód, transakcji i tokenów zgodne z RODO, z regułami retencji dla każdej klasy danych Mapowanie danych i retencja są elementem konfiguracji; usuwanie danych odbywa się zgodnie z harmonogramem. |
| Obserwowalność i alerty | Panele opóźnień, błędów i utraty zgód w podziale na dostawców, a także alerty dotyczące zablokowanych płatności i wygasłych zgód Zespół dyżurny widzi, który bank zaczął zwalniać, zanim dowie się o tym support. |
| Środowisko uruchomieniowe i wdrożenie | Hosting w UE, pipeline'y CI/CD, sekrety w zarządzanym KMS, całodobowe dyżury 24/7 Twój dostawca tożsamości, Twoje regiony danych, Twoje zasady dostępu. |
Ścieżka zgody i płatności
Od zgody do uzgodnionej płatności
Każde wywołanie open banking w ramach integracji przechodzi przez te same bramki kontrolne. Szybkość wynika z optymalizacji pipeline'u, a nie z pomijania weryfikacji zgód czy skracania dziennika audytu.
- 01
Onboarding użytkownika
Pierwsze uruchomienie
Użytkownik wybiera bank; produkt zapisuje zakres zgody oraz listę docelowych rachunków.
- 02
SCA i zgoda
Przekierowanie / model rozłączony
Użytkownik uwierzytelnia się w swoim banku. Stan zgody, token i data wygaśnięcia trafiają do magazynu wraz z wpisem audytowym.
- 03
Pobranie AIS / złożenie PIS
Na żądanie lub według harmonogramu
Produkt odczytuje rachunki i transakcje albo inicjuje płatność w oparciu o bieżącą zgodę.
- 04
Status i uzgadnianie
Na bieżąco
Status płatności jest odpytywany, a webhooki są przyjmowane; każde zdarzenie jest zapisywane w księdze z kluczem idempotencji.
- 05
Odświeżenie lub cofnięcie
Cykl życia
Zgoda jest odświeżana przed wygaśnięciem lub cofana na żądanie użytkownika; każda zmiana stanu jest zapisywana w dzienniku audytu.
Realizacja
Jak realizujemy integrację API bankowości
Pięć kroków, w tej kolejności. Prace nad open banking prowadzimy w ramach backlogu produktowego — bez osobnej fazy PSD2 doczepionej przed startem, bez wdrożenia „wszystko naraz” nieprzetestowanej warstwy zgód.
- 01
Zakres
Tygodnie 1–2
Mapujemy dostawców, banki, docelowe regiony, politykę zgód oraz ryzyko, za które musicie odpowiadać. Efekt: zakres, mapa kontroli i wyceniony plan.
- 02
Architektura
Tygodnie 3–4
Najpierw spisujemy kontrakty adapterów, kanoniczny model danych, maszynę stanów zgód, politykę SCA oraz przepływ uzgadniania.
- 03
Budowa
Dwutygodniowe sprinty
Adaptery, magazyn zgód, składanie PIS oraz uzgadnianie wdrażamy etapami. Każde scalenie uruchamia testy, kontrole statyczne i skan zależności.
- 04
Utwardzanie
Przed przełączeniem
Testy kontraktowe dla każdego dostawcy, testy obciążeniowe, ćwiczenia awaryjne, odtwarzanie zdarzeń w środowisku sandbox oraz okno przeglądu przez zewnętrzny podmiot, zanim dotkniemy produkcji.
- 05
Wdrożenie i utrzymanie
Przejście + bieżąca obsługa
Wyznaczeni inżynierowie w trybie 24/7. Runbooki, panele i pakiet audytowy przekazujemy waszemu zespołowi już pierwszego dnia.
Model współpracy
Cztery sposoby na zakup wdrożenia integracji API open banking
Ci sami inżynierowie, ten sam standard. Zmienia się tylko forma komercyjna.
-
Budowa o stałym zakresie
Zdefiniowana integracja w stałej cenie i terminie. Najlepsza opcja, gdy dostawcy i regiony są już ustalone.
-
Dedykowany zespół
Stały zespół z liderem. Najlepsza opcja przy długich planach rozwoju i nowych bankach dodawanych co kwartał.
-
Uzupełnienie zespołu specjalistami
Starsi inżynierowie w waszym zespole. Najlepsza opcja, gdy plan macie już gotowy i potrzebujecie wyłącznie głębokiej wiedzy o PSD2.
-
Doradztwo CTO
Przegląd architektury oraz analiza „kupić czy zbudować” przed podjęciem decyzji. Najlepsze na etapie projektowania.
Pytania
FAQ: integracja API open banking
Sześć odpowiedzi na wstępie dotyczących zakresu, kompromisów przy gotowych rozwiązaniach, pokrycia, PSD2, wyboru między owinięciem a wymianą oraz wsparcia. Resztę pytań zostawcie na rozmowę.
Co obejmuje integracja API open banking w ramach współpracy z TrustChange?
Projektujemy dla was dedykowaną, należącą do klienta warstwę API integracji bankowości — adaptery dostawców, zarządzanie zgodami, przepływy SCA, składanie PIS, agregację AIS oraz zapis i uzgadnianie w waszej księdze. Dostarczamy ją jako kod źródłowy w waszych repozytoriach, z prawami własności intelektualnej przeniesionymi na was. Nie ma opłaty za transakcję na rzecz TrustChange ani współdzielonego wielodostępnego backendu między wami a waszymi połączeniami bankowymi; warunki handlowe z dostawcami bazowymi pozostają bezpośrednio po waszej stronie.
Czym różni się nasza praca od gotowego dostawcy integracji open banking i API?
Gotowe agregatory pakują dostęp do banków za licencją i stałym API. TrustChange pozostawia model agregatora jako opcję, ale projektuje warstwę ponad nim — cykl życia zgód, politykę SCA, księgowanie oraz retencję — tak aby to wasz produkt był właścicielem powierzchni integracji. Dostawców możecie później wymieniać lub łączyć bez przepisywania kodu produktu. Ten kompromis jest uczciwy: dedykowane wdrożenie zajmuje więcej czasu na starcie, ale uzależnienie od jednej integracji bankowej to dokładnie to, czego regulowani operatorzy chcą uniknąć.
Które banki, regiony i dostawców może obejmować API integracji bankowości cyfrowej?
Punktem odniesienia są bezpośrednie API banków oraz agregatory PSD2 w UE, EOG i Wielkiej Brytanii, wraz z adapterami API integracji bankowości cyfrowej dla głównych rodzin rozwiązań używanych przez PSP, EMI i neobanki. Prace specyficzne dla Wielkiej Brytanii — na przykład integracja API integracji bankowości cyfrowej w Wielkiej Brytanii zgodna ze specyfikacją opartą na OBIE — działają na tej samej warstwie adapterów. Kolejne regiony trafiają do systemu jako nowe adaptery oparte na tym samym kanonicznym modelu.
Jak integracja API w bankowości uwzględnia w naszych wdrożeniach PSD2, SCA i RODO?
TrustChange jest partnerem inżynieryjnym, a nie kancelarią prawną — politykę ustalają wasi doradcy ds. zgodności i IOD; my dostarczamy kod i dowody. Oznacza to przepływy SCA uwzględniające PSD2, z logiką wyjątków tam, gdzie jest to dozwolone, wersjonowany i odwoływalny stan zgód, przechowywanie tokenów w zarządzanym KMS, reguły retencji uwzględniające RODO oraz dziennik audytu zawierający informacje kto, co, kiedy i dlaczego dla każdego wywołania. Nie składamy w waszym imieniu żadnych deklaracji dotyczących statusu licencji PSD2, opinii ani zgód regulatora.
Czy zastępujecie naszą obecną integrację API bankowości, czy ją owijacie?
Oba podejścia są powszechne. Większość projektów zaczyna się od owinięcia obecnych dostawców kanonicznym modelem, tak aby pierwszego dnia nic w produkcji się nie zmieniało, a następnie dodajemy lub wymieniamy adaptery zgodnie z planem rozwoju. Dzięki temu działający przychód pozostaje nienaruszony, podczas gdy nowa integracja API open banking kształtuje się w tle, a jednocześnie unikamy gwałtownego przejścia na ścieżce płatności.
Czy prowadzicie integrację również po jej wdrożeniu, czy przekazujecie ją nam?
Obie opcje są możliwe. Większość klientów zaczyna od wyznaczonych inżynierów TrustChange w trybie 24/7 przez pierwsze miesiące, w czasie gdy ich własny zespół się rozwija, a następnie przejmuje platformę we własnym zakresie z runbookami, panelami i wspólnie opracowanym przekazaniem dyżurów. Część klientów zatrzymuje nas jako dedykowany zespół deweloperski lub w modelu augmentacji zespołu przy pracach nad nowymi dostawcami i rozwojem modelu zgód.
Umów rozmowę wstępną w sprawie integracji API open banking
Przynieście listę docelowych banków, regionów, waszą politykę zgód oraz informację, gdzie odczuwacie presję — opóźnienia PIS, wygasające zgody, ciche duplikaty czy zablokowane uzgadnianie. My wracamy z mapą kontroli, wizją architektury i wycenionym planem. Bez pokazówek demo.