Traceability and proving that you are secure
Along with the articles 29, 72 and 73 from the RTS, we explore how seriously we take traceability and payment transaction security with Okay.
Article 29: Traceability
In the RTS article 29 there traceability requirements are detailed:
1. 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 important when it comes to transaction security: 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 were no malware influencing either the user input or the display?
Article 72 and 73: Payment Transactions
The questions stated previously are important in light of article 72 and 73 of the PSD2. Article 72 states in part:
2. 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.
This is important, as 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.”
So, basically, if you cannot document 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.
Traceability and Transaction Security with Okay
With our Single Device SCA Okay we take this very seriously, to the extent that we transfer 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.