This article explains how to assess AIS services for the Polish market and why a list of supported banks is not enough to choose a solution. It examines how to connect account data to a business process, separate responsibilities and prepare an integration for delays, incomplete results and a potential change of provider.
A customer applying for financing chooses to verify their details by connecting to their bank. They complete authentication, return to the application and see a message saying that their data is being retrieved.
At this point, the system has several separate tasks. It needs to establish whether authorisation succeeded, which accounts are covered by the access, whether retrieval has finished and whether the result is sufficient to continue processing the application. The customer's return does not yet answer all those questions.
This is a useful starting point for discussing AIS in Poland. Choosing an account information service means deciding how to incorporate bank data into a specific process. Getting an API connection working solves only part of the problem.
Where AIS fits within Open Banking
AIS stands for Account Information Service and concerns information from payment accounts accessible online. It does not initiate payments. PSD2 distinguishes these services and links AIS to the user's explicit consent and access to designated accounts and their associated transactions. [1]
In Poland, an important reference point is PolishAPI: an initiative to standardise account access interfaces, developed with the participation of the Polish Bank Association and other market participants. Its objectives include reducing the cost of implementing PSD2 requirements. [2]
The team at QRQS.eu PSA helped develop PolishAPI. Today, it applies the experience gained from working on the standard to financial systems architecture and integration, connecting banking interfaces with real business processes.
Given my direct involvement in the PolishAPI initiative, the perspective of a shared standard is particularly important to me: it should help real integrations while leaving room to recognise differences between implementations.
A standard helps describe communication. An implementation still needs to verify the behaviour of the particular service, its data coverage and the customer journeys involved. From an architect's perspective, this is the level at which solutions for Polish accounts should be compared.
Establish the operating model before choosing an API
The first question should concern the provider's role in the proposed solution. Does it supply a technical communication layer to an appropriately entitled entity, or does it itself provide the regulated AIS service to the user? What role does the organisation building the product take?
This distinction matters for contracts, customer communication and the allocation of duties. KNF states that a domestic provider offering exclusively AIS needs registration rather than KNF authorisation. Different operating models should therefore not be treated as a single category of “buying an API licence”. [3]
Before integration, the entity's status, permissions and basis for operating in Poland should be checked in the relevant registers. Contracts and technical design should then specify who handles access, certificates, incidents and communication with users. A commercial label for the operating model does not settle those responsibilities.
Assess bank coverage against the product
The number of supported institutions is a useful initial indicator. A project decision needs a more detailed matrix: bank, customer segment, account type, access mode and required information.
For example, one provider's public documentation distinguishes single and multiple access and presents separate coverage for each. This illustrates why one number should not be equated with the availability of every function. [4]
A consumer product and a service for businesses may depend on different scenarios. In the latter, it is also worth checking the authority of the person acting for the organisation. Other considerations include the required history period, account currency and availability of the data needed for a particular analysis.
The more useful question is therefore whether the service supports the accounts and situations that the product will encounter. The answer should be confirmed through testing, taking differences between test and production environments into account.
Where the selection comes from and how to read the map
The KNF register of payment service providers and electronic money issuers was the reference point for selecting domestic providers. It was checked on 28 October 2026 using the entity type “provider offering exclusively account information services” and the status “Registered”. The register returned seven entities in this category. From these, Kontomatik, AIS Gateway, Fizen, Easy Check and TransactionLink were selected for the map, alongside verification of their public B2B offering descriptions. [Q8]
Tink and Banqup were added on the basis of their public service catalogues. The domestic AISP category alone does not cover every model for providing AIS in Poland, so the number of entries does not indicate the size of the entire market. This selection is neither a complete register of companies nor a purchasing recommendation list.
The KNF register is the source for the status of domestic AISPs; provider product descriptions and documentation are the sources for the offering profiles shown on the map. Easy Check describes categorisation and income identification, while TransactionLink combines its Open Banking API with a broader onboarding approach. Banqup remains a separate entry on the map. For Fizen, the classification includes PIS technology for entitled providers, without attributing an own PISP licence to the company. [Q1–Q7]
The quadrant is an author-defined classification of offering profiles, not a quality or market-share assessment. Each name appears once. Placement does not exclude other capabilities, and spacing between names does not represent measurements. Availability of a specific product, access mode and bank needs confirmation before implementation.
Enlarge the map ↗An SDK is one part of the authentication journey
A mobile library can simplify integration and the return to the application. It does not determine whether the entire authentication process stays within one screen. Tink's public documentation describes different options, including browser and app redirects. [5]
I would therefore assess the complete journey for the target banks and mobile operating systems. Does the application return to the correct case? What happens if the browser is closed? How are cancellation, delay and technical failure distinguished? Does the customer understand why they are moving to another environment?
For an application built with Flutter, the team should also confirm whether the chosen integration approach is officially supported and who maintains it. The existence of a package alone does not establish the scope of vendor support.
Access and reauthentication have separate lifecycles
The data model should distinguish consent to the service, the technical state of access and the point at which the user needs to become involved again. Each affects whether further retrieval can take place.
The SCA rules provide for a 180-day period within a specific mechanism for access through an AISP. This concerns renewed strong customer authentication under the exemption's conditions. It is not a universal definition of every consent's lifetime or a guarantee of uninterrupted access. [6]
The system should recognise withdrawn consent, lost access and a need for reauthentication, then take the appropriate action. Notification availability and status-checking mechanisms need to be confirmed for the selected interface.
The legal bases and purposes for processing, data scope and retention periods must be established separately. Technical access to transaction history does not replace that assessment. Data protection principles require, among other things, a lawful, specified purpose and limiting data to what is necessary. [7]
Result quality needs explicit rules
A successful API response may contain insufficient information for a business decision. The process should know whether it received the full required period, when the data was retrieved and what is missing. Missing information about an incoming payment should not automatically be treated as confirmation that no such payment occurred.
Source data and its interpretation should also be separated. A transaction, a category assigned to it and a conclusion about income regularity are different pieces of information. If the system uses analytics, it should retain the result's provenance and the version of the rules or model used to produce it.
If a product needs pending transactions or holds, their availability and meaning should be verified separately. The same applies to matching transactions by amount and date. Depending on the use case, additional identifiers, descriptions and rules for handling ambiguity may be necessary.
These are design questions. Identical coverage across every bank and provider should not be assumed.
The integration should retain state
Kontomatik's public documentation describes a model in which an import is started and its result retrieved after checking for completion. [8] This demonstrates the need to distinguish acceptance of a request from obtaining data.
In the architecture, I would propose explicit states: waiting for the user, authorisation completed, retrieval in progress, data ready, incomplete result and action required. The business process state should remain understandable independently of a particular API's status names.
A provider adapter can translate those statuses into a common contract. The process can then decide whether to wait, safely retry an operation, request customer action or refer the case to an employee. Monitoring should make it possible to identify the stage at which a difficulty occurred.
This separation helps development, but does not make switching providers cost-free. Contracts, the user journey and data coverage may need reassessment, and fresh authorisation may be required. An adapter reduces code coupling; it does not remove differences between services.
Making an implementation decision
I would start with several representative product scenarios. For each, I would establish the required data, acceptable waiting time and handling of incomplete results. I would then validate them with the provider and through testing.
Useful measures include journey completion, time to obtain usable data, result completeness and the number of cases requiring assistance. Costs should be assessed under common assumptions covering the charging model, refreshes, retries, support and integration maintenance. This provides a meaningful basis for comparing offers.
There is no need to assume one best model for every use case. One-off application verification and recurring financial data updates have different requirements. Extensive orchestration makes sense for longer processes with multiple waiting states; a simple import may need a much lighter solution.
In my view, mature use of Open Banking starts with defining the boundary between data access and a business decision. An AIS service provides specified information. The system using that information needs to know when it can support the next step and when it should wait or request additional input. That responsibility should be reflected in the architecture before choosing a provider.
Note on the scope of the selection
inFakt also appears in the domestic AISP register checked for this article (AISP7/2021) and offers a bank account connection within its own accounting application. [Q8, 9] It was not included on the map because the public materials reviewed did not confirm a standalone AIS offering for external integrators. The described inFakt API integrates with functions of its application; its existence alone does not establish that AIS is available as a separate service. [10] This does not rule out individually agreed partnerships. Checked on 28 October 2026.
Sources
Sources checked as of 2026-10-28. This article discusses AIS design criteria in the Polish context; it is not a provider ranking or a measurement of market shares. The opening scenario is illustrative. Architectural recommendations are the author's assessment. Individual service capabilities require confirmation for the selected product, bank and operating model.
[1] Directive (EU) 2015/2366, particularly Articles 4 and 67 and Annex I — AIS definitions and access rules: https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1709060489202&uri=CELEX%3A32015L2366
[2] PolishAPI, initiative description and objectives: https://polishapi.org/en/polishapi/
[3] KNF, general information on domestic providers offering exclusively AIS: https://www.knf.gov.pl/dla_rynku/procesy_licencyjne/platniczy/AISP/Informacje_Ogolne_Dzialalnosc_AISP
[4] Kontomatik Developer Portal, access modes and coverage matrix — an example of how service coverage is presented: https://developer.kontomatik.com/
[5] Tink Docs, Tink Link for web — authentication options and mobile integration: https://docs.tink.com/resources/tink-link-web
[6] Commission Delegated Regulation (EU) 2022/2360, Article 1 inserting Article 10a into Regulation 2018/389 — SCA exemption and reauthentication conditions: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32022R2360
[7] European Union, Your Europe — data protection, processing purposes and legal bases: https://europa.eu/youreurope/business/governance-and-sustainability/digital-and-data-compliance/data-protection-gdpr/index_en.htm
[8] Kontomatik Documentation, Account Information Service — import and result retrieval sequence: https://developer.kontomatik.com/docs/
[9] inFakt, connecting a bank account to its application: 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, API integration overview: https://www.infakt.pl/integracje-z-infakt-za-pomoca-api/
Sources for entity selection and offering profiles (Q8: register; Q1–Q7: provider materials):
[Q1] Kontomatik: https://www.kontomatik.com/
[Q2] Tink: https://tink.com/products/
[Q3] Fizen: https://docs.fizen.com/
Additional source: 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
Additional source: https://img.unifiedpost.com/openbanking/goodbye.html
[Q7] TransactionLink: https://www.transactionlink.io/integrations/transactionlink-2
Additional source: https://www.transactionlink.io/about-us
[Q8] KNF — rejestr ERUP: https://e-rup.knf.gov.pl/