FAQ
Our Open Banking platform provides TPPs with an innovate approach to build applications and business cases together, creating new digital services through APIs.
EU directive on payment services in the internal market (PSD2) entered into force in the European Union on 12 January 2016 and will apply as of 13 January 2018. One of the 11 mandates conferred on EBA, as specified in Article 95 of PSD2, relates to the development, in close cooperation with the European Central Bank (ECB), of Guidelines on the security measures for operational and security risks of payment services. PSD2 is the revised Payment Service Directive, which was mandated in 2016. It stems from PSD1, which was mandated in 2009. Second Payment Service Directive requires Europe`s banks to give regulated TPPs access to customers` account information and payment initiation with the customers` permission and consent.
The open banking is regulated with the Law on payment services and payment systems (ZPUPS) which complies with PSD2. This law entered into force on 20 April 2022 and is applied from 1 January 2023.
RTS SCA is the set of rules that the PSPs must adhere to comply with the PSD2 Regulation. The role of the RTS is to define specific security measures that were only addressed through general principles in PSD2, and to ensure effective and secure communication between the relevant actors. SCA is a methodology by which PSD2 looks to secure payments. Strong Customer Authentication aims to reduce payment fraud and is based on authenticating payment initiation using multiple factors that include inherence, possession, and knowledge.
The customer's identity must be verified using two of the following three items:
For all remote transactions, a unique authentication code which dynamically links the transaction to a specific amount and a specific payee with transaction details is needed.
Possible exemptions of SCA:
CSC is the second major principle described in the RTS. CSC defines communication between main participants:
The RTS CSC regulates how the access to the customer's account is shared between the ASPSP and the TPP (AISP or PISP). It includes requirements to the Consent and Secure Communication Channel.
This Decision is for establishing the requirements for SCA and common, secure, and open standards for communication, that is under the Law of payment services and payment systems that was adopted by Nacional Bank Council in December 2022. Decision on SCA contains the same requirements as RTS.
The "Berlin Group" is a pan-European payments interoperability standards and harmonization initiative with the primary objective of defining open and common scheme- and processor-independent standards in the inter-banking domain between Creditor Bank (Acquirer) and Debtor Bank (Issuer), complementing the work carried out by e.g. the European Payments Council.
PSD2 compliant Access to Account API interface defined by The European Banking Authority- Regulatory Technical Standards (EBA-RTS). Which must be provided by an Account Servicing Payment Services Providers (ASPSP) and to be used by a TPPs.
We support version 1.3.12 of the Berlin Group X2SA specification.
To access our Developer portal, you must first register by filling in registration form. Afterwards, an account activation link will be sent to your email. You must follow the link and complete the registration process. After successful completion of the registration process you are ready to access of API documentation and try out our APIs.
We recommend to read the API documentation first, then proceed to the Sandbox and test our API services.
API services under PSD2 are completely free.
If you want to use APIs under ZPUPS (PSD2), you need to obtain appropriate PISP, AISP and/or PIISP license from the National Bank of the Republic of Macedonia.
With the APIs you can:
More information is available in the API documentation.
eIDAS stands for Electronic Identity and Trust Services for Electronic Transactions. According to the Decision for SCA, the usage of QWAC or QSEAL certificates is mandatory, but according to Berlin Group specification, only the usage of QWAC is mandatory and the usage of QSeal is optional.
QSealCs make it possible for the owner of the certificate to create electronic seals on any data that ensure the integrity and correctness of the origin (i.e. authenticity) of the signed/sealed data. This means that the persons receiving digitally signed data can be sure who signed the data, that the data have not been changed since being signed, and that they can also present these signed data to third parties as evidence of who signed the data and that they were not changed after being signed. QSealCs are used to protect the data or messages in the application layer during or after the communication, but they do not provide confidentiality of the data (i.e. there is no encryption of application data).
QWACs make it possible to establish a channel for communication with the subject of the certificate using the Transport Layer Security (TLS) protocol, which guarantees confidentiality, integrity, and authenticity of all data transferred through the channel (in the transport layer). This means that the person or system connecting to the website presenting the certificate can be sure who "owns" the end point of the communication channel (the owner of the certificate), that the data was not changed between the end points, and that nobody else could have read the data along the way. However, the data communicated by the QWAC are only protected while they are travelling through a channel that uses TLS protocol. Therefore, the person or system connecting to the website can be sure who they are communicating with, but cannot prove this to third parties, which means that QWACs do not give legally assumed evidence of a transaction.