Solutions
Product
Services
Resources
Company
Developer
hello@okaythis.com

Kverndalsgata 8,
3717 Skien,
Norway

Solutions
Embedded Finance Providers and BaaS
Banks
BtoC and BtoB Fintechs
Corporate Sector
Okay Passwordless
Products
Okay KYC
Okay PSD2 SCA
Okay ACS
Okay IAM
Services
Advisory Services
Risk and Security Audits
Integration and Professional Services
Application Management Services
Resources
Blog
Glossary
Patents
PSD2/3 Resources
Company
About
Get In Touch
Partners
Developers
iOS SDK Guide
React Native Module
Android SDK Guide
Server Documentation
API Documentation
©2025 Okay. All rights reserved
Privacy & Policy
Terms & Condition
Back to Blog

Traceability and Payment Transaction Security

Published: 07.11.2019

Updated: 07.11.2019

Author: Erik Vasaasen

Along with articles 29, 72 and 73 from the RTS, in the post we explore how seriously we take traceability and payment transaction security with our Single Device SCA service.

Article 29: Traceability

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?

Articles 72 & 73: Payment Transactions

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.

Sign Up for Our Newsletter

Unlock updates, insights, and exclusive content delivered to you.

Traceability and Transaction Security with Okay

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.

Related Articles

From PSD2 to PSD3… to PSD4? Tracking the Next Wave of Regulatory Updates for Europe

Regulation and compliance
22.04.2025

PSD2 SCA Compliance: Preparing for the Deadline

Regulation and compliance
12.02.2019

Why Should You Care? PSD2 Explained

Regulation and compliance
15.08.2019