In the RTS article 29, the traceability requirements are detailed as:

“Payment service providers 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 transaction in all the various stages.”

This article is essential when talking about transaction security. According to it, you now have to be able to document all events relevant to the transaction, and (in our view) be able to answer questions such as:

• Can you prove what the end-user saw when approving the transaction?
• Can you be sure that there was no malware influencing either the user input or the display?

The questions stated previously are important in light of article 72 and 73 of the PSD2. Article 72 states in part:

“Where a payment service user denies having authorised an executed payment transaction, the use of a payment instrument recorded by the payment service provider, including the payment initiation service provider as appropriate, shall in itself not necessarily be sufficient to prove either that the payment transaction was authorised by the payer or that the payer acted fraudulently or failed with intent or gross negligence to fulfil one or more of the obligations under Article 69. The payment service provider, including, where appropriate, the payment initiation service provider, shall provide supporting evidence to prove fraud or gross negligence on part of the payment service user.”

Article 73 states in part:

“In the case of an unauthorised payment transaction, the payer’s payment service provider refunds the payer the amount of the unauthorised payment transaction immediately, and in any event no later than by the end of the following business day, after noting or being notified of the transaction, except where the payer’s payment service provider has reasonable grounds for suspecting fraud and communicates those grounds to the relevant national authority in writing.”

When put together, this means that if you cannot provide sufficient documentation proving that the security around your transaction was strong enough, you are liable for the entire amount. In PSD2 terms, this is generally known as the “liability-shift”, where fraud goes from being something that the end-user has to prove, to something that the payment service provider or merchant has to provide didn’t take place.

With our Single Device SCA Okay, we take both traceability and payment transaction security very seriously. We go to the extent of transferring a screenshot of the transaction as seen by the end-user to the server, just so you can prove exactly what the user-approved. The liability shift is not just a requirement of using Secure Customer Authentication (SCA), but it makes it obligatory to use a separate secure execution environment, and to log much more than before.