mBank S.A.

In our opinion, any transaction performed online, including mobile transactions, in principle generate risk. Additional examples that can indicate fraud risk are:
• changes of authentication / authorization methods, PSU linked devices or any authentication data,
• changes of address or personal data, especially correspondence address or phone number (this way fraudsters are trying to take over authentication data),
• pairing with account of new mobile devices (mobile banking) ,
• changes of transaction limits
• launch of credit/loans applications (after taking over an account fraudsters also try to increase available funds by applying for cash loans on behalf of victim),
• mass payments / payments baskets, also uploaded as files with transactions list – usually it’s difficult to create dynamically linked authentication data in human readable form which would allow to verify all mass transactions, if strong authentication will be only for whole basket (batch) than attackers can inject fraud transactions.
Thus ASPSP on the basis of multi factor risk assessment should be able to enforce strong consumer authentication for any operation initiated by the PIS or AIS provider. This important to reduce risks related to rouge PIS (companies established with fraud in mind – i.e. providing regular services for some time and finally initiating multiple fraud transactions).
It is also crucial that PIS and AIS would not have access to PSU credentials for ASPSPs. Authentication concept for transactions placed through PIS or AIS have to ensure accountability of those transactions and to ensure it PIS and AIS have to use dedicated authentication i.e. based on tokens exchanged between ASPSP and AIS/PIS and authorized by PSU or using pay-by-link concept.
In our opinion data on device, can be used in the context of strong consumer authentication but under condition that ASPSP is able to build risk profile for each transaction including profiling of the authentication device. Second condition is that all PSUs authentication data for ASPSP are not available for PIS or AIS. PSU authentication data should also be properly protected on ASPSP side (like in case of sensitive payment data in SecuRe Pay). As mentioned earlier PIS and AIS should use additional, separate credentials (like tokens exchange between ASPSP and AIS/PIS after authorization by PSU) or using pay-by-link concept.
Additionally possession elements in the context of strong authentication should be:
• linked to physical device – token or in case of data on mobile device, implementation should ensure that data can’t be moved/cloned on different device (at least not easily),
• protected by strong cryptography using knowledge (PIN) or inheritance elements, in case of data on mobile device at least one element (i.e. PIN) should not be stored on the same device but on ASPSP side,
• for transactions authorization and in authentication process there should be independent channel used – it can be on the same device, but has to be protected by different set of data (i.e. separate channel to authorization system using own certificate set), this channel should also allow to send back from ASPSP to PSU full details of transaction for confirmation
Behaviour-based characteristics should be used only as additional (supporting) authentication method, not as a only one. In fact behaviour-based characteristics should be part of risk analysis and considering also additional factors (like type of the transaction, authentication method used, amount etc.) give a combined risk score which can be used to accept, reject or exact additional authentication.
To make behaviour-based characteristics reliable (and to build proper risk profile for the transaction) ASPSPs have to receive from PIS required transactions details like true beneficiary, description etc. and not transaction internal id generated by PIS.
Use behaviour-based characteristics as an only strong authentication is in our opinion not recommended approach. There are no standards defining what elements of such characteristics should be considered as minimum, what parameterization should be applied, what algorithms, scores etc. If too simple characteristics will be used than there is high probability of attacks circumventing such authentication mechanism (i.e. simulation, also learning of mouse movements, keyboard strokes, using proxy and tunneling to perform attack from typical IP address space etc.).
Main challenge would be aversion of customers to use additional devices (tokens) which would impact their mobility. Another factor would be cost of additional devices/elements.
Additional factor is that there are many different standards and solutions on the mobile market (not every device has biometric capabilities, not every uses SIM card, not every SIM card will have secure element that can be used etc.).
Because of that it should be possible to use data on the device as a possession element (as described in comments to the 2nd question) considering that:
• transactions will have reasonable limits (different in case of one device and different in case 2 separate device are used)
• mobile application is used that has implemented measures against modification (data or memory) and uses strong cryptography (as in comment to 2nd question)
• there is independent (different than channel used for transaction) channel for authentication (as described in comment to 2nd question)
• PSP uses behavioral antifraud solution
Considering dynamic linking as a value that is linked only for one remote transaction and can’t be used for a different one we see challenge for voice only channels. But from our perspective dynamic linking should also provide user (PSU) with clear information about transaction (like part of account number, amount etc.) so one will be able to verify it. The dynamic code itself is not enough (user is not able to decipher it and to verify that it is linked to transaction data that he intended – it’s especially important in case of man-in-the browser attacks). This can be achieved using separate digital communication channel (SMS, or separate encrypted data stream) but again is difficult in voice only environment and most secure solution would involve separate hardware token with own display (this can be not welcomed by heavy mobile users and generates additional costs).
Strongest one are dedicated devices with own display which are able to establish connection to authorization system in the bank using i.e. computer or mobile device only as a router/access point. Data are encrypted point-to-point (between token and bank) and device can present transaction details on the screen and ensures strong digital signature.
Cheaper variant uses dedicated, protected application on mobile device (but the risk of altering is higher than in case of dedicated hardware token).
EBA's clarification is useful, but the key issue is, what kind of actions really requires strong authentication and segregation of responsibilities between PIS and PIS/AIS. However, it should be emphasized that at this stage seems that any transaction involving PIS or AIS should be authenticated on ASPSP side. Additionally exemptions options should be related to risk assessment.
Yes:
• when customer (PSU) doesn’t want to use strong authentication (like hardware token) and thus responsibility of ASPSP should be limited
• when PIS is not providing enough information about transaction and as a result risk analysis is limited
• base capital of PIS companies which should impact allowed limits and volumes of transactions
• Intended authentication method
• General risk related to particular type of transaction (i.e. higher for card not present)
• Last activity (i.e. geolocation, loans applications)
Yes, but we would like also to emphasize again that access to authentication data should be allowed only to the user and the institution that provides the customer with this data - eg. ASPSP to its customer. This institution is also entity to decide in what kind of environment it can be used (for example: only on the transaction system of this institution).
Man-in-the-middle attacks (especially man-in-the-browser) and also internal fraud (especially when credentials are not properly protected). Also as stated earlier allowing access to those credential by different institution that provides the customer with this data creates high risk related to limited accountability, possibly lower security of smaller PISes and rouge PIS scenario.
Physical delivery of QR-like code which is associated to particular device / application delivered or installed by the customer (so even in case of interception of code it is impossible to link another device to the customer account).
We see no alternatives to certification or assessment.
• User side (mobile & windows malware, social engineering including obtaining i.e. SIM duplicates)
• Merchant
• PIS/AIS (social engineering combined with many PIS/AIS services)
• Credentials enrolment process (PSP)
At a general and high level we consider them to be sufficient. However, we expect that those will be further clarified in RTS.
A minimal (hard) requirements, recommended (soft) requirements, guidelines. We would prefer clarification restrain from binding to specific underlying implementation, especially to vendor-specific implementations. Although we would welcome references to open and industry standards and methods.
An exemplary, commercially functioning solution on the Polish market are Pay-by-link as a way to transfer the context of payment or other requests (e.g. data within AIS). Moreover, it seems reasonable to consider a European registry of all AIS or PIS for use by all ASPSP.
Because of responsibility of ASPSP in particular, it should be ensured the they have influence on security standards. It seems that markets should be able to develop national rules, best adjusted to their singularity, existing practices, regulations and payment practices.
Yes, but different maturity and availability of local (national) systems should be considered.
It seems that relying on the already-developing standard, is a good approach. The new circumstances introduced by Directive PSD2 should, however, be taken into account.
Yes
[ "]"
[ "]"
Piotr.Moroz@mbank.pl
Piotr Moroz
+48228291970
Yes