The PolishAPI was created in response to the EU’s PDS2 directive by the Polish payment sector (banks and non-banking entities). It focuses on defining the interface enabling third parties to access payment accounts.
Back to the Standards Library
Polish API
The Polish Bank Association
Poland
The standards incorporate strong customer authentication and common and secure open standards of communication (RTS).
The PolishAPI standard goes beyond the services required by PSD2 (the compliance scope) and includes a ‘premium scope’ of AIS, PIS and CAF services. The X2SA interface must be compliant with the PolishAPI standard.
X2SA sessions can be established using external authorisation tools (decoupled), an exchange token or a refresh token.
Alior Bank set up a developer portal for third party providers to test products, and upon approval, become an approved partner.
JSON
RESTful
YAML
Active API
v3.0 / 12 Dec 2019
All documentation available through the website with SwaggerHub links.
Regulated
Mandated
The PSD2 Directive brought in three new categories of service, the Account Service Information (AIS), the Payment Initiation Service (PIS) and the Confirmation of the Availability of Funds (CAF). To allow this, the standard developed needed to create the XS2A interface for access by Third Party Providers (TPPs), to be produced by account servicing payment service providers (ASPSP).
Banking
Open Banking
-
Account information
-
Payment initiation
-
(Confirmation of availability of funds)
Credit Cards
Current Accounts
Wallets Or Prepaid
Certificates
DCR
Registry
App To App Redirect
Browser Redirect
Decoupled
The TPP may perform services for a PSU only upon his/her consent and within the scope covered by such consent.
OAuth
Other
The security framework is based on Json Web Signature (JWS) and Json Web Token (JWT).
The Payment Service User (PSU)’s authentication and authorisation data are given exclusively at the ASPSP’s website. The PSU is authenticated in the ASPSP’s interface.
The PolishAPI Standard allows the use of an authentication mechanism using an external authorization tool (EAT) during the performance of the AIS and PIS services. This is a system providing the strong customer authentication (SCA) procedure.
Therefore, the ASPSP cooperates with the provider of an EAT. The PSU holds an account with an EAT and has taken steps necessary to use the code generator function. The ASPSP prepares a message containing basic information about the transaction displayed in EAT before confirmation.
The granting of consent is always accompanied by a SCA, the choice of which is selected by an ASPSP. The PolishAPI standard does not define or recommend any way in which this procedure may be conducted.
The mutual authentication of the TPP and the ASPSP takes place on the basis of the X.509v3 certificates issued by a trusted third party.
Accounts
Balances
Confirmation Of Funds
Other
Parties Or Contacts
Standing Orders
Transactions
Parties information included in AIS Accounts: there is not a separate Party endpoint, but Party information is provided in accounts endpoint.
Bulk Payments
File Payments
Future Dated Payments
Other
Single Domestic Payments
Single International Payments
Standing Orders
PIS includes tax payments.
API Specifications
Operational Guidelines
polish-api | 3_0 | ZBP | SwaggerHub
Sandbox testing environment for different banking implementing the API.
The PolishAPI was created through the Polish Bank Association together with commercial and cooperative banks, cooperative savings and credit unions (SKOK), the Polish Organisation of Non-banking Payment Institutions (PONIP) together with its associated members, the Polish Chamber of Information Technology and Telecommunications (PIIT), the Polish Insurance Association (PIU), Krajowa Izba Rozliczeniowa, Biuro Informacji Kredytowej, and Polski Standard Płatności in response to the PDS2 directive from the EU.
The application of the standard is not mandatory. Each of the entities operating on the market on the basis of the PSD2 Directive may use any solution compliant with PSD2 and the related acts of law.
The IP address and userAgent of the PSU are provided in the Request Header class to prevent potential fraud.
X2SA sessions can be established using external authorisation tools (decoupled), an exchange token or a a refresh token.
The TPP must be registered in at least one register of the European Union Member State in the role it intends to play during the PolishAPI standard-based communication.
It must be compliant with PDS2, the Payment Services Act and the RTS (EUR-Lex – 32018R0389 – EN – EUR-Lex (europa.eu)).
The TPP must be registered in at least one register of the European Union Member State in the role it intends to play during the PolishAPI standard-based communication.
The TPP and ASPSP must have a valid certificate used for mutual identification in the XS2A interface obtained from a qualified provider of trust services and meet the regulatory requirements concerning electronic identification and trust services.
Ozone API in partnership with Smart Data Foundry
