2023-02-23
Added · Updated
The Council of the Central Bank of Montenegro issued this Decision to prescribe security requirements for payment service providers regarding strong customer authentication and secure communication standards. It mandates the implementation of transaction monitoring mechanisms, independent audits, and specific technical safeguards for authentication codes and dynamic linking. The document also defines exemptions from strong customer authentication for low-risk scenarios, including contactless payments, trusted beneficiaries, and transaction risk analysis.
CBCG published 8 documents in the last 30 days — get each new one by email the day it lands.
Pursuant to Article 44 paragraph 2 item 3 of the Central Bank of Montenegro Law (OGM 40/10, 6/13, 70/17) and Article 56c of the paragraph (7) of the Payment System Law (OGM 62/13, 111/22), the Council of the Central Bank of Montenegro, at its meeting held on 23 February 2023, passed the following DECISION ON ENSURING STRONG CUSTOMER AUTHENTICATION AND COMMON AND SECURE OPEN STANDARDS FOR COMMUNICATION I BASIC PROVISIONS Subject Matter
Article 1
This Decision prescribes security requirements to be met by the payment service providers for ensuring strong customer authentication and common and secure open standards for communication, as well as exemptions from the application of strong customer authentication requirements. General authentication requirements
Article 2
(1) A payment service provider shall have transaction monitoring mechanisms in place that enable them to detect unauthorised payment transactions or fraudulent payment transactions for the purpose of the implementation of the requirements referred to in Articles 5 to 22 of this Decision. (2) Monitoring mechanisms referred to in paragraph (1) of this Article shall be based on the analysis of payment transactions taking into account elements which are typical of the payment service user in the circumstances of a normal use of the personalised security credentials. (3) A payment service provider shall ensure that the monitoring mechanisms referred to in paragraph (1) of this Article take into account, at a minimum, each of the following risk-based factors:
Audit of the security measures
Article 3
(1) The implementation of the requirements set up in this Decision shall be documented, periodically tested, evaluated and audited in accordance with the law by independent internal or external auditors with expertise in IT security and payments. (2) The frequency of audits referred to in paragraph (1) of this Article shall be determined in accordance with the regulations governing the conditions and the method of auditing financial statements of the payment service providers. (3) By way of derogation from paragraph (2) of this Article, where the payment service provider does not apply strong customer authentication in accordance with Article 19 of this Decision, the payment service provider shall provide, at a minimum on yearly basis, audit of the methodology, models and reported fraud rates referred to in Article 20 of this Decision. (4) By way of derogation from paragraph (1) of this Article, during the first year of making use of the exemption referred to in Article 19 of this Decision and at least every 3 years thereafter, or more frequently at the request of the Central Bank of Montenegro (hereinafter: the Central bank), the audit referred to in paragraph (3) of this Article shall be carried out by an independent and qualified external auditor. (5) The report containing the evaluation on the compliance of the payment service provider's security measures with the requirements set out in this Decision shall be drawn up after the audit conducted in accordance with the provisions of this Article. (5) The audit report referred to in paragraph (5) of this Article shall be made available to the Central Bank upon their request. Meaning of terms
Article 4
The terms used in this Decision shall have the following meanings:
payment initiation service provider and account information service provider, the name of the account owner and the account number do not constitute sensitive payment data;
6) personalised security credentials means personalised features provided by
the payment service provider to a payment service user for the purposes of authentication;
7) payment card means a payment instrument enabling its holder to make
payments for goods and services either at an accepting device or remotely, and/or to withdraw cash and/or use other services at an automated teller machine or another self-service device;
8) remote payment transaction means a payment transaction initiated via
internet or through a device that can be used for distance communication;
9) strong customer authentication means an authentication based on the use of
two or more elements categorised as knowledge, possession and inherence that are independent and that only user knows and possesses, which means that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data; II SECURITY REQUIREMENTS FOR THE APPLICATION OF STRONG CUSTOMER AUTHENTICATION Authentication code
Article 5
(1) Strong customer authentication shall be performed using two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code. (2) The authentication code referred to in paragraph (1) of this Article shall be only accepted once by the payment service provider when the payer uses the authentication code to access its payment account online, to initiate an electronic payment transaction or to carry out any action through a remote channel which may imply a risk of payment fraud or other abuses. (3) For the purpose of acting in accordance with paragraphs (1) and (2) of this Article, a payment service provider shall adopt security measures ensuring that:
no information on any of the elements referred to in paragraph (1) of this Article
can be derived from the disclosure of the authentication code;
it is not possible to generate a new authentication code based on the knowledge
of any other authentication code previously generated;
the authentication code cannot be forged.
(4) A payment service provider shall ensure that the strong customer authentication by means of generating an authentication code includes the following measures:
where the strong customer authentication has failed to generate an
authentication code referred to in paragraph (1) of this Article, it shall not be possible to identify which of the elements referred to in paragraph (1) of this
Article was incorrect;
the number of failed authentication attempts that can take place consecutively,
after which the actions for which the strong customer authentication is carried out shall be temporarily or permanently blocked, shall not exceed five within a given period of time;
the communication sessions are protected against the capture of strong
customer authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements referred to in Articles 29 to 37 of this Decision;
the maximum time without activity by the payer after being authenticated for
accessing its payment account online shall not exceed five minutes. (5) Where the block referred to in paragraph (4) item 2) of this Article is temporary, the duration of that block and the number of retries shall be established based on the characteristics of the service provided to the payer and all the relevant risks involved, taking into account, at a minimum, the factors referred to in Article 2 paragraph (3) of this Decision. (6) The payment service provider shall alert the payer before the temporary block referred to in paragraph (4) item 2) of this Article is made permanent. (7) Where the temporary block referred to in paragraph (4) item 2) of this Article has been made permanent, a secure procedure shall be established allowing the payer to regain use of the blocked electronic payment instruments. Dynamic linking
Article 6
(1) Where a payment service provider applies strong customer authentication in the case of initiating remote electronic payment transaction, in addition to the requirements of Article 5 of this Decision, they shall also adopt security measures ensuring that:
the payer is made aware of the amount of the payment transaction and of the
payee;
the authentication code generated is specific to the amount of the payment
transaction and the payee agreed to by the payer when initiating the transaction;
the authentication code accepted by the payment service provider corresponds
to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;
any change to the amount or the payee results in the invalidation of the
authentication code generated.
(2) For the purpose of acting in accordance with paragraph (1) of this Article, payment service provider shall adopt security measures which ensure the confidentiality, authenticity and integrity of:
the amount of the payment transaction and the payee throughout all of the
phases of the strong customer authentication;
the information displayed to the payer throughout all of the phases of the strong
customer authentication including the generation, transmission and use of the authentication code.
(3) For the purpose of acting in accordance with paragraph (1) item 2) of this Article the following requirements for the authentication code shall apply:
guarantee resistance against unauthorised use of the elements through access to the devices and the software. Independence of the elements for strong customer authentication
Article 10
(1) A payment service provider shall ensure that the use of the elements of strong customer authentication referred to in Articles 7, 8 and 9 of this Decision is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements. (2) The payment service provider shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multipurpose device being compromised. (3) For the purposes of paragraph (2) of this Article, the payment service provider shall establish the following mitigating measures:
Contactless payments at point of sale
Article 12
A payment service provider shall be allowed not to apply strong customer authentication, subject to compliance with the requirements laid down in Article 2 of this Decision, where the payer initiates a contactless electronic payment transaction and where:
included in the series of payment transactions referred to in paragraph (1) of this
Article.
Credit transfers between accounts held by the same natural or legal person
Article 16
A payment service provider shall be allowed not to apply strong customer authentication, subject to compliance with the general requirements laid down in
Article 2 of this Decision, where the payer initiates a credit transfer in circumstances
where the payer and the payee are the same natural or legal person and both payment accounts are held by the same account servicing payment service provider. Low-value transactions
Article 17
A payment service provider shall be allowed not to apply strong customer authentication, where the payer initiates a remote electronic payment transaction and where:
equivalent to or below the reference fraud rates specified in Annex 1 which is an integral part of this Decision;
2) the amount of the transaction does not exceed the relevant exemption threshold
value (‘ETV’) specified in Annex1 of this Decision;
3) the payment service provider as a result of performing a real time risk analysis
has not identified any of the following:
(3) The methodology and any model, used by the payment service provider to calculate the fraud rates referred to in paragraph (1) of this Article, as well as the fraud rates themselves, shall be adequately documented and made fully available to the Central Bank, upon their request. Cessation of exemptions based on transaction risk analysis
Article 21
(1) A payment service provider that does not apply strong customer authentication referred to in Article 19 of this Decision shall immediately report to the Central Bank where one of their monitored fraud rates, for any type of payment transactions indicated in the Annex 1 of this Decision, exceeds the applicable reference fraud rate and shall provide a description of the measures that they intend to adopt to restore compliance of their monitored fraud rate with the applicable reference fraud rates. (2) The payment service provider referred to in paragraph (1) of this Article shall immediately cease to apply strong customer authentication for any type of payment transactions indicated in the Annex 1 of this Decision in the specific exemption threshold range where their monitored fraud rate exceeds for two consecutive quarters the reference fraud rate applicable for that payment instrument or type of payment transaction in that exemption threshold range. (3) In the case of paragraph (2) of this Article, payment service provider shall use the strong customer authentication until their calculated fraud rate equals to, or is below, the reference fraud rates applicable for that type of payment transaction in that exemption threshold range for one quarter. (4) Where the payment service provider intends to cease the application of strong customer authentication referred to in Article 19 of this Decision, they shall notify the Central Bank in a reasonable timeframe and shall provide evidence of the restoration of compliance of their monitored fraud rate with the applicable reference fraud rate for that exemption threshold range in accordance with paragraph (3) of this Article. Monitoring of payment transactions
Article 22
(1) The payment service provider that does not apply strong customer authentication set out in Articles 11 to 19 of this Decision shall record and monitor the following data for each type of payment transactions, with a breakdown for both remote and nonremote payment transactions, at least on a quarterly basis:
the total value of unauthorised payment transactions or fraudulent payment
transactions in accordance with the provisions of Article 30 of the Law, the total value of all payment transactions and the resulting fraud rate, including a breakdown of payment transactions initiated through strong customer authentication and under each of the exemptions in accordance with the provisions of this Decision;
the average transaction value, including a breakdown of payment transactions
initiated through strong customer authentication and under each of the exemptions in accordance with the provisions of this Decision;
for each of the exemptions applied in accordance with the provisions of this
Decision, the number of payment transactions where each of the exemptions was applied and their percentage in respect of the total number of payment transactions. (2) The payment service provider shall make the results of the monitoring in accordance with paragraph (1) of this Article available to the Central Bank, upon their request. IV CONFIDENTIALITY AND INTEGRITY OF THE PAYMENT SERVICE USERS' PERSONALISED SECURITY CREDENTIALS General requirements for confidentiality and integrity of the personalised security credentials
Article 23
(1) Payment service provider shall ensure the confidentiality and integrity of the personalised security credentials of the payment service user, including authentication codes, during all phases of the authentication. (2) For the purpose of acting in accordance with paragraph (1) of this Article, the payment service provider shall ensure that the following requirements is met:
personalised security credentials are masked when displayed and are not
readable in their full extent when input by the payment service user during the authentication;
personalised security credentials in data format, as well as cryptographic
materials related to the encryption of the personalised security credentials are not stored in plain text;
secret cryptographic material is protected from unauthorised disclosure.
(3) The payment service provider shall fully document the process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials. (4) The payment service provider shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Articles 5 to 10 of this Decision take place in secure environments in accordance with strong and widely recognised industry standards. Creation and transmission of personalised security credentials
Article 24
(1) A payment service provider shall ensure that the creation of personalised security credentials is performed in a secure environment. (2) The payment service provider shall mitigate the risks of unauthorised use of the personalised security credentials and of the authentication devices and software following their loss, theft or copying before their delivery to the payer.
Association with the payment service user
Article 25
(1) A payment service provider shall ensure that only the payment service user is associated, in a secure manner, with the personalised security credentials, the customer authentication devices and the software. (2) For the purpose of acting in accordance with paragraph (1) of this Article, payment service provider shall ensure that the following requirements is met:
Traceability
Article 30
(1) A payment service provider shall have processes in place which ensure that all payment transactions and other interactions with the payment services user, with other payment service providers and with other entities, including merchants, in the context of the provision of the payment service are traceable, ensuring knowledge ex post of all events relevant to the electronic payment transaction in all the various stages. (2) For the purpose of acting in accordance with paragraph (1) of this Article, payment service provider shall ensure that any communication session established with the payment services user, other payment service providers and other entities, including merchants, relies on the following:
account information service providers, payment initiation service providers and
payment service providers issuing card-based payment instruments are able to identify themselves towards the account servicing payment service provider;
account information service providers are able to communicate securely to
request and receive information on one or more designated payment accounts and associated payment transactions;
payment initiation service providers are able to communicate securely to initiate
a payment order from the payer's payment account and receive all information on the initiation of the payment transaction and all information accessible to the account servicing payment service providers regarding the execution of the payment transaction. (2) For the purposes of authentication of the payment service user, the interface referred to in paragraph (1) of this Article shall allow account information service providers and payment initiation service providers to rely on all the authentication procedures provided by the account servicing payment service provider to the payment service user. (3) The interface referred to in paragraph (1) of this Article shall at least meet all of the following requirements:
a payment initiation service provider or an account information service provider
shall be able to instruct the account servicing payment service provider to start the authentication based on the consent of the payment service user;
communication sessions between the account servicing payment service
provider, the account information service provider, the payment initiation service provider and any payment service user concerned shall be established and maintained throughout the authentication;
the integrity and confidentiality of the personalised security credentials and of
authentication codes transmitted by or through the payment initiation service provider or the account information service provider shall be ensured. (4) Account servicing payment service provider shall ensure that their interfaces referred to in paragraph (1) of this Article follow standards of communication which are issued by international or European standardisation organisations. (5) Account servicing payment service provider shall also ensure that the technical specification of any of the interfaces referred to in paragraph (1) of this Article is documented specifying a set of routines, protocols, and tools needed by payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments for allowing their software and applications to interoperate with the systems of the account servicing payment service providers. (6) Account servicing payment service provider shall, before the application date of the access interface referred to in paragraph (1) of this Article, make the documentation referred to in paragraph (5) of this Article available, at no charge, upon request by authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments or payment service providers that have applied to the Central Bank for the relevant authorisation, and shall make a summary of the documentation publicly available on their website. (7) Account servicing payment service provider shall ensure that, except for emergency situations, any change to the technical specification referred to in paragraph (5) of this Article is made available to authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments, or payment service providers that have applied to the Central Bank for the relevant authorisation, in advance as soon as possible and not less than three months before the change is implemented. (8) Payment service provider shall document emergency situations referred to in paragraph (7) of this Article where changes to the technical specification referred to in paragraph (5) of this Article were implemented and make the documentation available to the Central Bank on request. (9) Account servicing payment service provider shall make available a testing facility, including support, for connection and functional testing to enable authorised payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers, or payment service providers
that have applied to the Central Bank for the relevant authorisation, to test their software and applications used for offering a payment service to users. (10) The testing facility referred to in paragraph (9) of this Article should enable testing of the interface in the manner specified in item 5.5 of Annex 2 which is an integral part of this Decision and it should be made available before the application date of the access interface referred to in paragraph (1) of this Article. (11) The testing facility referred to in paragraph (9) of this Article shall not be used for sharing sensitive information, in particular for sharing sensitive payment data. (12) In the event that an account servicing payment services provider fails to comply with the requirements set out in this Decision for interfaces referred to in paragraph (1) of this Article, they shall ensure that the provision of payment initiation services and account information services is not prevented or disrupted to the extent that the respective providers of such services comply with the requirements referred to in
Article 34 paragraphs (6) and (7) of this Decision.
Access interface options
Article 32
Account servicing payment service provider shall establish one or more interfaces referred to in Article 31 of this Decision by means of a dedicated interface or by allowing the use by the payment service providers referred to in Article 31 paragraph (1) of this Decision of the interfaces used for customer authentication and communication with the account servicing payment service provider's payment services users. Obligations for a dedicated interface
Article 33
(1) Notwithstanding the provisions of Articles 31 and 32 of this Decision, the account servicing payment service provider that has put in place a dedicated interface shall ensure that the dedicated interface offers at all times the same level of availability and performance, including support, as the interfaces made available to the payment service users for directly accessing its payment accounts online. (2) Account servicing payment service provider that has put in place a dedicated interface shall define transparent key performance indicators and service level targets, at least as stringent as those set for the interface used by their payment service users, both in terms of availability and of data exchanged in accordance with Article 37 of this Decision. (3) Payment service provider shall perform stress-tests of the dedicated interface referred to in paragraph (2) of this Article. (4) Account servicing payment service provider that has put in place a dedicated interface shall ensure that this interface does not create obstacles to the provision of payment initiation and account information services.
(5) Obstacles referred to in paragraph (4) of this Article, shall include, in particular, preventing the use by payment service providers referred to in Article 31 paragraph (1) of this Decision of the credentials issued by account servicing payment service providers to their customers, imposing redirection to the account servicing payment service provider's authentication or other functions, requiring additional authorisations and registrations in addition to those provided for in the Law, or requiring additional checks of the consent given by payment service users to payment initiation service providers and account information service providers. (6) For the purpose of acting in accordance with paragraphs (1) and (2) of this Article, the account servicing payment service provider shall monitor the availability and performance of the dedicated interface, and publish on its website quarterly statistics on the availability and performance of the dedicated interface and of the interface used by its payment service users. Contingency measures for a dedicated interface
Article 34
(1) Account servicing payment service provider shall include, in the design of the dedicated interface, a strategy and plans for contingency measures for the event that the interface does not perform in compliance with Article 33 of this Decision, that there is unplanned unavailability of the interface or that there is a systems breakdown. (2) Unplanned unavailability or a systems breakdown within the meaning of paragraph (1) of this Article may be presumed to have arisen when five consecutive requests for access to information for the provision of payment initiation service or account information service are not replied to within 30 seconds. (3) Contingency measures referred to in paragraph (1) of this Article shall include communication plans to inform payment service providers making use of the dedicated interface of measures to restore the system and a description of the immediately available alternative options payment service providers may use during this time. (4) Both the account servicing payment service providers and the payment service providers referred to in Article 31 paragraph (1) of this Decision shall report problems with dedicated interfaces referred to in paragraphs (1) and (2) of this Article to the Central Bank without delay. (5) Account servicing payment service provider shall establish a contingency mechanism, which shall allow the payment service providers referred to in Article 31 paragraph (1) of this Decision to make use of the interfaces made available to its payment service users for the customer authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 33 of this Decision. (6) For the purpose of acting in accordance with paragraph (5) of this Article, the account servicing payment service provider shall ensure that the payment service providers referred to in Article 31 paragraph (1) of this Decision can be identified and can use the authentication procedures provided by the account servicing payment service provider to the payment service user.
(7) Where the payment service providers referred to in Article 31 paragraph (1) of this Decision make use of the interface referred to in paragraph (5) of this Article they shall:
(6) In case of loss of confidentiality of personalised security credentials under their sphere of competence, payment service providers referred to in paragraph (5) of this
Article shall inform without undue delay the payment services user and the issuer of
the personalised security credentials.
Data exchanges
Article 37
(1) Account servicing payment service providers shall:
provide account information service providers with the same information from
designated payment accounts and associated payment transactions made available to the payment service user when directly requesting access to the account information, provided that this information does not include sensitive payment data;
immediately after receipt of the payment order, provide payment initiation
service providers with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user when the payment transaction is initiated directly by the latter;
upon request, immediately provide payment service providers with a
confirmation in a simple ‘yes’ or ‘no’ format, whether the amount necessary for the execution of a payment transaction is available on the payment account of the payer. (2) In case of an unexpected event or error occurring during the process of identification, customer authentication, or the exchange of the data elements, the account servicing payment service provider shall send a notification message to the payment initiation service provider or the account information service provider and the payment service provider issuing card-based payment instruments which explains the reason for the unexpected event or error. (3) Where the account servicing payment service provider offers a dedicated interface in accordance with Article 33 of this Decision, the interface shall provide for notification messages concerning unexpected events or errors to be communicated by any payment service provider that detects the event or error to the other payment service providers participating in the communication session. (4) Account information service providers shall have in place suitable and effective mechanisms that prevent access to information other than information from designated payment accounts and associated payment transactions, in accordance with the user's explicit consent. (5) Payment initiation service providers shall provide account servicing payment service provider with the same information as requested from the payment service user when initiating the payment transaction directly. (6) Account information service providers may access information from designated payment accounts and associated payment transactions held by account servicing payment service providers for the purposes of performing the account information service in the following circumstances:
whenever the payment service user is actively requesting such information;
where the payment service user does not actively request such information, no
more than four times in a 24-hour period, unless a higher frequency is agreed between the account information service provider and the account servicing payment service provider, with the payment service user's consent.
VI. FINAL PROVISION
Entry into force
Article 38
This decision shall be published in the “Official Gazette of Montenegro”, and it shall enter into force on the day of entry into force of the Law amending the Payment System Law (OGM 111/22). THE COUNCIL OF THE CENTRAL BANK OF MONTENEGRO CHAIRPERSON GOVERNOR, Decision number: 0101- 1732 -2/2023 Podgorica, 23 February 2023 Radoje Žugić, m.p.
ANNEX 1
Reference fraud rate (%) for:
Exemption threshold value
(ETV)
Remote electronic card-based payment transactions Remote electronic credit transfers EUR 500 0,01 0,005 EUR 250 0,06 0,01 EUR 100 0,13 0,015
ANNEX 2
Additional requirements for the exemption from the obligation to set up a contingency mechanism referred to in Article 34 paragraph (5) of this Decision To be eligible for the exemption from the obligation to set up a contingency mechanism referred in Article 34 paragraph (5) of this Decision, the account servicing payment service provider must meet the following additional requirements:
the uptime per day of each interface; and
the downtime per day of each interface.
1.3 In terms of the performance of the dedicated interface, the account servicing
payment service provider should define at a minimum the following key performance indicators:
the daily average time (in milliseconds) taken, per request, for the account
servicing payment service provider to provide the payment initiation service provider with all the information requested in accordance with Article 30b paragraph (5) of the Law and Article 37 paragraph (1) item 2) of this Decision;
the daily average time (in milliseconds) taken, per request, for the account
servicing payment service provider to provide the account information service provider with all the information requested in accordance with Article 37 paragraph (1) item 1) of this Decision;
the daily average time (in milliseconds) taken, per request, for the account
servicing payment service provider to provide the payment service provider issuing card-based payment instruments or the payment initiation service provider with a ‘yes/no’ confirmation in accordance with Article 30a paragraph (3) of the Law and Article 37 paragraph (1) item 3) of this Decision;
the daily error response rate – calculated as the number of error messages
concerning errors attributable to the account servicing payment service provider sent by the account servicing payment service provider to the payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments in accordance with
Article 37 paragraph (2) of this Decision per day, divided by the number of
requests received by the account servicing payment service provider from payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments in the same day.
calculate the percentage uptime as 100% minus the percentage downtime;
calculate the percentage downtime using the total number of seconds the
dedicated interface was down in a 24-hour period, starting and ending at midnight;
count the interface as ‘down’ when five consecutive requests for access to
information for the provision of payment initiation service, account information service or confirmation of availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple payment initiation service providers, account information service providers or payment service providers issuing card-based payment instruments. In such a case, the account servicing payment service provider should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided.
the capability to support access by multiple payment initiation service providers,
account information service providers and payment service providers issuing card-based payment instruments;
the capability to deal with an extremely high number of requests from payment
initiation service providers, account information service providers and payment service providers issuing card-based payment instruments, in a short period of time without failing;
the use of an extremely high number of concurrent sessions open at the same
time for payment initiation, account information and confirmation of availability of funds requests; and
requests for large volumes of data.
3.3 The account servicing payment service provider should provide the Central Bank
with a summary of the results of the stress tests, including the assumptions used as a basis for stress testing each of the elements referred to in item 3.2 of this Annex and how any issues identified have been addressed.
provider or account information service provider to access the information on the payment accounts held with the account servicing payment service provider or to initiate payments.
5. Requirements regarding the design and testing to the satisfaction of payment
service providers
5.1 The account servicing payment service provider shall provide the Central Bank
with the following:
5.5 The testing facility should allow account servicing payment service providers,
authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments or a person that has applied to the Central Bank for the authorisation to provide any of these services, to test the dedicated interface in a secure, dedicated testing environment with non-real payment service users data, for the following:
providers and payment service providers issuing card-based payment instruments in relation to item 5.5 of this Annex may also be taken into account.
6. Requirements regarding the wide usage of the interface
6.1 For the purposes of evidencing compliance with the condition referred to in Article
34 paragraph (8) item 3) of this Decision, the account servicing payment service provider shall provide the Central Bank with the following:
Note from RegAlert. AI assistants can read this document in full, and search 70,000+ more, through the RegAlert MCP connector (https://mcp.regalert.today/mcp). Free with an account. How to connect ChatGPT, Claude or Cursor.
Source: Central Bank of Montenegro — original document · Summary generated with machine assistance and reviewed before publication; the authoritative text is the regulator's original document. How RegAlert works