Z tego artykułu dowiesz się, jak oceniać usługi AIS dostępne dla polskiego rynku i dlaczego sama lista obsługiwanych banków nie wystarcza do wyboru rozwiązania. Wyjaśniam, jak połączyć dane z rachunku z procesem biznesowym, rozdzielić odpowiedzialności i przygotować integrację na opóźnienia, niepełne wyniki oraz zmiany dostawcy.
Klient składa wniosek o finansowanie i wybiera potwierdzenie danych przez połączenie z bankiem. Przechodzi uwierzytelnienie, wraca do aplikacji i widzi informację, że dane są pobierane.
W tym momencie system ma kilka osobnych zadań. Musi ustalić, czy autoryzacja zakończyła się poprawnie, które rachunki objęto dostępem, czy pobieranie już się zakończyło i czy wynik wystarcza do dalszej obsługi wniosku. Powrót klienta do aplikacji nie odpowiada jeszcze na wszystkie te pytania.
To dobry punkt wyjścia do rozmowy o AIS w Polsce. Wybór usługi dostępu do informacji o rachunku jest decyzją o sposobie włączenia danych bankowych do konkretnego procesu. Samo uruchomienie API rozwiązuje tylko część zadania.
Gdzie AIS mieści się w Open Bankingu
AIS, czyli Account Information Service, dotyczy dostępu do informacji o rachunkach płatniczych dostępnych online. Nie jest usługą inicjowania płatności. PSD2 rozdziela te usługi i wiąże AIS z wyraźną zgodą użytkownika oraz dostępem do wskazanych rachunków i związanych z nimi transakcji. [1]
W polskim otoczeniu ważnym punktem odniesienia jest PolishAPI — inicjatywa standaryzacji interfejsów dostępu do rachunków, rozwijana z udziałem Związku Banków Polskich i innych uczestników rynku. Jej celem jest m.in. ograniczenie kosztów wdrażania wymogów PSD2. [2]
Zespół QRQS.eu PSA współtworzył PolishAPI. Doświadczenie zdobyte przy pracach nad standardem wykorzystuje dziś w projektowaniu architektury i integracji systemów finansowych — łącząc interfejsy bankowe z rzeczywistymi procesami biznesowymi.
Ze względu na moje bezpośrednie zaangażowanie w inicjatywę PolishAPI szczególnie bliska jest mi perspektywa wspólnego standardu, który ma pomagać w rzeczywistych integracjach, przy zachowaniu świadomości różnic między wdrożeniami.
Standard pomaga opisać komunikację. Przy wdrożeniu nadal trzeba sprawdzić zachowanie konkretnej usługi, zakres danych i scenariusze obsługi klienta. Z perspektywy architekta właśnie na tym poziomie warto porównywać rozwiązania dostępne dla polskich rachunków.
Model współpracy przed wyborem API
Pierwsze pytanie powinno dotyczyć roli dostawcy w planowanym rozwiązaniu. Czy dostarcza on techniczną warstwę komunikacji podmiotowi mającemu odpowiednie uprawnienia, czy sam świadczy regulowaną usługę AIS wobec użytkownika? Jaką rolę pełni organizacja, która buduje produkt?
To rozróżnienie ma znaczenie dla umów, komunikacji z klientem i podziału obowiązków. KNF wskazuje, że działalność krajowego dostawcy świadczącego wyłącznie AIS wymaga wpisu do rejestru, a nie zezwolenia KNF. Nie należy więc traktować wszystkich modeli współpracy jako jednej kategorii „zakupu licencji API”. [3]
Przed integracją warto potwierdzić status podmiotu, zakres jego uprawnień oraz zasady działania w Polsce w odpowiednich rejestrach. W umowie i projekcie technicznym trzeba następnie wskazać, kto obsługuje dostęp, certyfikaty, incydenty oraz kontakt z użytkownikiem. Sama nazwa handlowa modelu współpracy tego podziału nie rozstrzyga.
Pokrycie banków trzeba odnieść do produktu
Liczba obsługiwanych instytucji jest użytecznym wskaźnikiem wstępnym. Do decyzji projektowej potrzebna jest jednak dokładniejsza macierz: bank, rodzaj klienta, typ rachunku, tryb dostępu i wymagany zakres informacji.
Przykładowo publiczna dokumentacja jednego z dostawców rozróżnia dostęp jednorazowy i wielokrotny oraz pokazuje dla nich osobne pokrycie. To ilustracja, dlaczego jednej liczby nie należy utożsamiać z dostępnością wszystkich funkcji. [4]
Dla produktu obsługującego osoby fizyczne i dla rozwiązania kierowanego do firm istotne mogą być inne scenariusze. W drugim przypadku warto sprawdzić również uprawnienia osoby działającej w imieniu organizacji. Do tego dochodzi wymagany okres historii, waluta rachunku i obecność danych potrzebnych do konkretnej analizy.
Najbardziej przydatne pytanie brzmi więc: czy usługa obsługuje rachunki i sytuacje, które wystąpią w naszym produkcie? Odpowiedź warto potwierdzić testami, z uwzględnieniem różnic między środowiskiem testowym a produkcyjnym.
Skąd pochodzi zestawienie i jak czytać mapę
Punktem odniesienia przy doborze krajowych dostawców był rejestr dostawców usług płatniczych i wydawców pieniądza elektronicznego KNF. Sprawdzono go 28 października 2026 roku, wybierając typ „dostawca świadczący wyłącznie usługę dostępu do informacji o rachunku” oraz status „Wpisany”. W tej kategorii rejestr zwracał siedem podmiotów. Wśród nich do mapy wybrano Kontomatik, AIS Gateway, Fizen, Easy Check i TransactionLink, dla których zweryfikowano również publiczny opis oferty B2B. [Q8]
Zestawienie uzupełniono o Tink i Banqup na podstawie ich publicznych katalogów usług. Sama kategoria krajowych AISP nie obejmuje wszystkich modeli świadczenia AIS w Polsce, dlatego liczba wpisów nie określa wielkości całego rynku. Nie jest to pełny rejestr firm ani lista rekomendacji zakupowych.
Rejestr KNF jest źródłem informacji o statusie krajowych AISP, natomiast opisy produktów i dokumentacje dostawców są źródłem profili przedstawionych na mapie. Easy Check opisuje m.in. kategoryzację i identyfikację dochodu, a TransactionLink łączy Open Banking API z szerszym podejściem do onboardingu. Banqup pozostaje osobną pozycją mapy. W przypadku Fizen uwzględniono technologię PIS dla uprawnionych dostawców, bez przypisywania spółce własnej licencji PISP. [Q1–Q7]
Kwadrant jest autorską klasyfikacją profili oferty, a nie oceną jakości czy udziału w rynku. Każda nazwa występuje raz. Położenie w polu nie wyklucza innych funkcji, a odstępy między nazwami nie są wynikami pomiarów. Dostępność konkretnego produktu, trybu dostępu i banku trzeba potwierdzić przed wdrożeniem.
Powiększ mapę ↗SDK jest elementem ścieżki uwierzytelnienia
Biblioteka mobilna może uprościć integrację i obsługę powrotu do aplikacji. Nie przesądza jednak, że cały proces uwierzytelnienia odbędzie się wewnątrz jednego ekranu. Publiczna dokumentacja Tink opisuje różne warianty, w tym przekierowanie do przeglądarki lub aplikacji. [5]
Dlatego oceniałbym pełną ścieżkę dla docelowych banków i systemów mobilnych. Czy aplikacja poprawnie wraca do właściwej sprawy? Co dzieje się po zamknięciu przeglądarki? Jak rozpoznajemy anulowanie, opóźnienie i błąd techniczny? Czy klient wie, dlaczego przechodzi do innego środowiska?
Przy aplikacji opartej na Flutterze należy dodatkowo potwierdzić, czy wybrany sposób integracji jest oficjalnie wspierany oraz kto odpowiada za jego aktualizacje. Samo istnienie pakietu nie mówi jeszcze o zakresie wsparcia producenta.
Dostęp i ponowne uwierzytelnienie mają osobny cykl życia
W modelu danych warto oddzielić zgodę na usługę, techniczny stan dostępu oraz moment, w którym trzeba ponownie zaangażować użytkownika. Każdy z tych elementów wpływa na możliwość dalszego pobierania informacji.
Przepisy dotyczące SCA przewidują okres 180 dni w określonym mechanizmie dostępu przez AISP. Dotyczy on ponownego silnego uwierzytelnienia przy spełnieniu warunków zwolnienia; nie jest uniwersalną definicją okresu ważności każdej zgody ani gwarancją nieprzerwanego dostępu. [6]
System powinien umieć rozpoznać wycofanie zgody, utratę dostępu i potrzebę ponownego uwierzytelnienia, a następnie wykonać właściwą czynność. Dostępność powiadomień i sposób sprawdzania statusu należy potwierdzić dla wybranego interfejsu.
Osobno trzeba określić podstawy i cele przetwarzania danych, zakres informacji oraz okres przechowywania. Dostęp techniczny do historii nie zastępuje tej analizy. Zasady ochrony danych wymagają m.in. zgodnego z prawem, określonego celu i ograniczenia danych do niezbędnego zakresu. [7]
Jakość wyniku wymaga własnych reguł
Poprawna odpowiedź API może nie zawierać informacji wystarczających do podjęcia decyzji biznesowej. Proces powinien wiedzieć, czy otrzymał pełny wymagany okres, kiedy dane pobrano oraz czego brakuje. Brak informacji o wpływie nie powinien automatycznie oznaczać potwierdzenia, że wpływu nie było.
Warto też rozdzielić dane źródłowe i wyniki ich interpretacji. Transakcja, przypisana jej kategoria i wniosek o regularności dochodu to różne informacje. Jeżeli system korzysta z analityki, powinien zachować pochodzenie wyniku i wersję reguł lub modelu, które go wyznaczyły.
Jeśli produkt potrzebuje informacji o transakcjach oczekujących lub blokadach, ich dostępność i znaczenie trzeba sprawdzić osobno. Tak samo należy postąpić z dopasowywaniem operacji po kwocie i dacie. W zależności od scenariusza mogą być potrzebne dodatkowe identyfikatory, opisy i reguły obsługi niejednoznaczności.
To zadania projektowe. Nie warto zakładać jednakowego zakresu dla każdego banku i dostawcy.
Integracja powinna zachowywać stan
Publiczna dokumentacja Kontomatik opisuje model, w którym import jest uruchamiany, a wynik odbierany po sprawdzeniu jego zakończenia. [8] Pokazuje to potrzebę odróżnienia przyjęcia żądania od uzyskania danych.
W architekturze proponowałbym jawne stany: oczekiwanie na użytkownika, autoryzacja zakończona, pobieranie w toku, dane gotowe, wynik niepełny i wymagane działanie. Stan procesu biznesowego powinien być czytelny niezależnie od nazw statusów konkretnego API.
Adapter dostawcy może tłumaczyć te statusy na wspólny kontrakt. Proces decyduje wtedy, czy czekać, bezpiecznie ponowić operację, poprosić klienta o działanie albo przekazać sprawę pracownikowi. Monitorowanie powinno pozwalać ustalić, na którym etapie wystąpiła trudność.
Taki podział ułatwia rozwój, ale nie czyni zmiany dostawcy bezkosztową. Ponownej oceny mogą wymagać umowy, ścieżka użytkownika i zakres danych; może być też konieczna nowa autoryzacja. Adapter ogranicza zależność kodu, nie usuwa różnic między usługami.
Jak podjąć decyzję o wdrożeniu
Ocenę zacząłbym od kilku reprezentatywnych scenariuszy produktu. Dla każdego ustaliłbym potrzebne dane, dopuszczalny czas oczekiwania i sposób postępowania przy niepełnym wyniku. Następnie sprawdziłbym je z dostawcą i w testach.
Warto mierzyć ukończenie ścieżki, czas uzyskania użytecznych danych, kompletność wyniku i liczbę spraw wymagających pomocy. Koszty należy zestawić według wspólnych założeń: sposobu naliczania opłat, odświeżeń, ponowień, wsparcia i utrzymania integracji. Dopiero taki kontekst pozwala porównać oferty.
Nie ma potrzeby zakładać jednego najlepszego modelu dla wszystkich zastosowań. Inne wymagania ma jednorazowa weryfikacja wniosku, inne regularna aktualizacja danych finansowych. Rozbudowana orkiestracja ma sens przy dłuższych procesach i wielu stanach oczekiwania; prosty import może wymagać znacznie lżejszego rozwiązania.
W mojej ocenie dojrzałe wykorzystanie Open Bankingu zaczyna się od zdefiniowania granicy między dostępem do danych a decyzją biznesową. Usługa AIS dostarcza określone informacje. System korzystający z tych informacji musi wiedzieć, kiedy może na nich oprzeć kolejny krok, a kiedy powinien poczekać lub poprosić o uzupełnienie. Tę odpowiedzialność warto zapisać w architekturze przed wyborem dostawcy.
Nota o zakresie zestawienia
inFakt również figuruje w sprawdzonym rejestrze krajowych AISP (AISP7/2021) i udostępnia połączenie rachunku bankowego we własnej aplikacji księgowej. [Q8, 9] Nie umieszczono go na mapie, ponieważ w sprawdzonych materiałach publicznych nie potwierdzono odrębnej oferty AIS dla zewnętrznych integratorów. Opisane API inFaktu dotyczy integracji z funkcjami jego aplikacji; samo jego istnienie nie potwierdza udostępniania AIS jako osobnej usługi. [10] Nie przesądza to o możliwości indywidualnej współpracy partnerskiej. Stan weryfikacji: 28.10.2026.
Źródła
Stan weryfikacji źródeł: 2026-10-28. Tekst omawia kryteria projektowe dla AIS w polskim otoczeniu; nie stanowi rankingu dostawców ani pomiaru udziałów rynkowych. Scenariusz otwierający jest ilustracją projektową. Rekomendacje architektoniczne są oceną autora. Funkcje poszczególnych usług wymagają potwierdzenia dla wybranego produktu, banku i modelu współpracy.
[1] Dyrektywa (UE) 2015/2366, w szczególności art. 4 i 67 oraz załącznik I — definicje i zasady AIS: https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1709060489202&uri=CELEX%3A32015L2366
[2] PolishAPI, opis inicjatywy i jej celów: https://polishapi.org/en/polishapi/
[3] KNF, informacje ogólne dotyczące krajowych dostawców świadczących wyłącznie AIS: https://www.knf.gov.pl/dla_rynku/procesy_licencyjne/platniczy/AISP/Informacje_Ogolne_Dzialalnosc_AISP
[4] Kontomatik Developer Portal, tryby dostępu i macierz pokrycia — przykład sposobu prezentowania zakresu usługi: https://developer.kontomatik.com/
[5] Tink Docs, Tink Link for web — warianty uwierzytelnienia i integracja mobilna: https://docs.tink.com/resources/tink-link-web
[6] Rozporządzenie delegowane (UE) 2022/2360, art. 1 wprowadzający art. 10a do rozporządzenia 2018/389 — warunki zwolnienia z SCA i ponownego uwierzytelnienia: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32022R2360
[7] Unia Europejska, Your Europe — ochrona danych, cele i podstawy przetwarzania: https://europa.eu/youreurope/business/governance-and-sustainability/digital-and-data-compliance/data-protection-gdpr/index_en.htm
[8] Kontomatik Documentation, Account Information Service — sekwencja importu i odbioru wyniku: https://developer.kontomatik.com/docs/
[9] inFakt, połączenie rachunku bankowego z aplikacją: https://pomoc.infakt.pl/hc/pl/articles/7832715162386-Jak-po%C5%82%C4%85czy%C4%87-rachunek-bankowy-z-aplikacj%C4%85-inFakt
[10] inFakt, opis integracji za pomocą API: https://www.infakt.pl/integracje-z-infakt-za-pomoca-api/
Źródła doboru podmiotów i profili oferty (Q8: rejestr; Q1–Q7: materiały firm):
[Q1] Kontomatik: https://www.kontomatik.com/
[Q2] Tink: https://tink.com/products/
[Q3] Fizen: https://docs.fizen.com/
Uzupełnienie: https://fizen.com/pl/news/pyk-payment-requests-powered-by-fizen
[Q4] Easy Check: https://easycheck.pl/produkty
[Q5] AIS Gateway: https://aisgateway.pl/produkt/
[Q6] Banqup: https://www.unifiedpostgroup.com/open-banking
Uzupełnienie: https://img.unifiedpost.com/openbanking/goodbye.html
[Q7] TransactionLink: https://www.transactionlink.io/integrations/transactionlink-2
Uzupełnienie: https://www.transactionlink.io/about-us
[Q8] KNF — rejestr ERUP: https://e-rup.knf.gov.pl/