Status: Please note you should read all Brexit changes to the FCA Handbook and BTS alongside the main FCA transitional directions. Where these directions apply the 'standstill', firms have the choice between complying with the pre-IP completion day rules, or the post-IP completion day rules. To see a full list of Handbook modules affected, please see Annex B to the main FCA transitional directions.

Chapter 2 Security measures for the application of strong customer authentication

Article 4 Authentication code

  1. (1)

    Where payment service providers apply strong customer authentication in accordance with Regulation 100 of the Payment Services Regulation 2017 (SI 2017/752), the authentication shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code.

    The authentication code 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.

  2. (2)

    For the purpose of paragraph 1, payment service providers shall adopt security measures ensuring that each of the following requirements is met:

    1. (a)

      no information on any of the elements referred to in paragraph 1 can be derived from the disclosure of the authentication code;

    2. (b)

      it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated;

    3. (c)

      the authentication code cannot be forged.

  3. (3)

    Payment service providers shall ensure that the authentication by means of generating an authentication code includes each of the following measures:

    1. (a)

      where the authentication for remote access, remote electronic payments and any other actions through a remote channel which may imply a risk of payment fraud or other abuses has failed to generate an authentication code for the purposes of paragraph 1, it shall not be possible to identify which of the elements referred to in that paragraph was incorrect;

    2. (b)

      the number of failed authentication attempts that can take place consecutively, after which the actions referred to in Regulation 100(1) of the Payment Services Regulations 2017 (SI 2017/752) shall be temporarily or permanently blocked, shall not exceed five within a given period of time;

    3. (c)

      the communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements in Chapter 5.

    4. (d)

      the maximum time without activity by the payer after being authenticated for accessing its payment account online shall not exceed five minutes.

  4. (4)

    Where the block referred to in paragraph 3(b) 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(2).

    The payer shall be alerted before the block is made permanent.

    Where the block has been made permanent, a secure procedure shall be established allowing the payer to regain use of the blocked electronic payment instruments.

Article 5 Dynamic linking

  1. (1)

    Where payment service providers apply strong customer authentication in accordance with Regulation 100(2) of the Payment Services Regulations 2017 (SI 2017/752), in addition to the requirements of Article 4 of these Standards, they shall also adopt security measures that meet each of the following requirements:

    1. (a)

      the payer is made aware of the amount of the payment transaction and of the payee;

    2. (b)

      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;

    3. (c)

      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;

    4. (d)

      any change to the amount or the payee results in the invalidation of the authentication code generated.

  2. (2)

    For the purpose of paragraph 1, payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following:

    1. (a)

      the amount of the transaction and the payee throughout all of the phases of the authentication;

    2. (b)

      the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code.

  3. (3)

    For the purpose of paragraph 1(b) and where payment service providers apply strong customer authentication in accordance with Regulation 100(2) of the Payment Services Regulations 2017 (SI 2017/752) the following requirements for the authentication code shall apply:

    1. (a)

      in relation to a card-based payment transaction for which the payer has given consent to the exact amount of the funds to be blocked pursuant to Regulation 78 of the Payment Services Regulations 2017 (SI 2017/752), the authentication code shall be specific to the amount that the payer has given consent to be blocked and agreed to by the payer when initiating the transaction;

    2. (b)

      in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees.

Article 6 Requirements of the elements categorised as knowledge

  1. (1)

    Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as knowledge are uncovered by, or disclosed to, unauthorised parties.

  2. (2)

    The use by the payer of those elements shall be subject to mitigation measures in order to prevent their disclosure to unauthorised parties.

Article 7 Requirements of the elements categorised as possession

  1. (1)

    Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.

  2. (2)

    The use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.

Article 8 Requirements of devices and software linked to elements categorised as inherence

  1. (1)

    Payment service providers shall adopt measures to mitigate the risk that the authentication elements categorised as inherence and read by access devices and software provided to the payer are uncovered by unauthorised parties. At a minimum, the payment service providers shall ensure that those access devices and software have a very low probability of an unauthorised party being authenticated as the payer.

  2. (2)

    The use by the payer of those elements shall be subject to measures ensuring that those devices and the software guarantee resistance against unauthorised use of the elements through access to the devices and the software.

Article 9 Independence of the elements

  1. (1)

    Payment service providers shall ensure that the use of the elements of strong customer authentication referred to in Articles 6, 7 and 8 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. (2)

    Payment service providers 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 multi-purpose device being compromised.

  3. (3)

    For the purposes of paragraph 2, the mitigating measures shall include each of the following:

    1. (a)

      the use of separated secure execution environments through the software installed inside the multi-purpose device;

    2. (b)

      mechanisms to ensure that the software or device has not been altered by the payer or by a third party;

    3. (c)

      where alterations have taken place, mechanisms to mitigate the consequences thereof.