The Hungarian National Bank (MNB) in its capacity of supervisory authority turned to the European Banking Authority (EBA) with a question of legal interpretation in connection with PSD2.
During online banking, it is possible to create a list of trusted beneficiary partners. This list is practical since strong customer authentication is not necessary when initiating a payment transaction to such partners.
In the app of a Hungarian commercial bank it was possible to add a partner to the trusted beneficiaries' list by ticking a checkbox before the payment's approval and thus both the payment and the modificatrion of the list was approved by the same text generated code.
However, an online or mobile app session can involve multiple actions, but does each require strong client authentication? When logging into the online interface (mobile app), initiating the payment and compiling/modifying the trusted beneficiary list? Or can these latter two go within the same session with the same authentication element?
MNB has recently noticed a fraudulent practice where fraudsters obtained the user's credentials, then initiated an extremely low amount of payment using a self-developed mobile application, and at the same time set their own account as a trusted payee by ticking a checkbox. Once fraudsters saved their own accounts as trusted payees, they could initiate and execute payments without strong customer authentication.
According to the Commission Regulation on strong customer authentication (SCA), payment service providers apply SCA when a payer draws up or amends a list of trusted payees through his account servicing payment service provider.
MNB's question focused on whether it is possible to use the same SCA element (within a single session) that applies to payment approval, which at the same time adds the beneficiary to the list of trusted payees by ticking the appropriate checkbox. This basically means that after the user logs in to the online interface (app) and initiates a payment and ticks the box to add to the trusted beneficiary list, these two actions can be performed with the same authentication (text message generated code).
SCA must be based on two or more elements that fall into the categories of knowledge, possession and biological trait, and must result in the generation of an authentication code.
As electronic remote payment transactions are subject to a higher risk of fraud, an additional requirement is necessary that dynamically links each element of the transaction to the amount and payee specified by the payer when initiating the transaction. Dynamic linking is possible through the generation of authentication codes.
In its reply, the EBA stressed that SCA is required when the payer initiates a payment. The element of logging into the online interface (app) (e.g. username + password (knowledge) + one-time text code (possession)) can also be used for payment initiation within the same session, with the proviso that another element of SCA is still necessary to initiate the payment (e.g. one-time code generated by text) and the elements must be dynamically linked to each other within this session. For the specific question this means that elements of consent for initiating a payment can be used when the payer adds a payee to the list within the same session. However, EBA stresses that the same element (e.g. text generated code) cannot be used to approve both tasks, the initiation of payment and adding the partner to the trusted beneficiaries' list. Therefore, it does not comply with the law if the two tasks are approved with the same authentication element (e.g. text generated code). This also means that adding to trusted payees can be accomplished by generating another text code, provided that all elements within the session are dynamically linked. EBA's answer can be found here.
