The balance between security and friction

The EU’s Second Payment Services Directive (PSD2) transformed how electronic payments are secured across Europe. At its core lies Strong Customer Authentication (SCA), a regulatory standard designed to protect consumers by enforcing multi-factor authentication for nearly every transaction. While effective at reducing fraud, SCA has introduced a new challenge for banks and payment providers. How can they maintain compliance without eroding user experience through repeated verification steps?

Transaction Risk Analysis (TRA) offers a way to reconcile these priorities. Defined in Article 18 of the PSD2 Regulatory Technical Standards (RTS) on Strong Customer Authentication, TRA allows low-risk transactions to proceed without triggering SCA. This is provided that the bank can prove, through real-time risk analysis, that the transaction and device environment are secure.

This blog post explores how TRA functions and why it matters commercially. We will also explain how secure mobile environments enable banks to unlock the business value of PSD2 TRA. App security enables the frictionless payment experience that customers crave.

Understanding PSD2 and Strong Customer Authentication (SCA)

Multifactor authentication (MFA) is a security process that requires two or more independent factors to verify a user’s identity. MFA verification methods typically fall into three categories for users:

• something you know (password or PIN)
• something you have (smartphone, token or hardware key)
• something you are (biometric information like a fingerprint)

Under the EU’s PSD2, SCA is a legal standard that enforces strict conditions for electronic payments. Its purpose is to reduce fraud in banking and payment apps in the EU. It mandates that at least two authentication elements are used from the three MFA categories. It also adds further regulatory requirements on how authentication factors are combined and verified.

Banks and Payment Service Providers (PSPs) often meet SCA requirements by deploying MFA mechanisms, such as biometrics plus a one-time password or push notification. But they must prove compliance with PSD2’s technical and procedural mandates too, not just the existence of multiple factors.

Note on names: The Directive itself is referred to as PSD2. It sets out the broad principles and legal obligations for payment services across the EU. The RTS on Strong Customer Authentication and Secure Communication (SCA & CSC) is a separate but related legal document. Requirements for SCA and details on TRA are not contained in the Directive but in this delegated regulation that implements PSD2. It is normally referred to as ‘SCA RTS’ or ‘RTS under PSD2’.

More learning: Download our report on how you can achieve PSD2 compliance with app shielding

Why SCA creates friction and revenue pressure

By default, PSD2 requires SCA for every electronic payment, typically implemented using MFA. This means customers must use a blend of facial identification, one-time passwords (OTPs), PINs, and app confirmation for each payment. This process introduces and adds friction to every transaction, particularly in high-frequency mobile and e-commerce environments.

The overall result is higher drop-off rates (‘digital process abandonment’), fewer transactions, and less revenue generation. Studies across Europe have shown cart-abandonment increases of 10–25 percent after PSD2 enforcement.

SCA has drawn criticism from nearly every stakeholder group since PSD2 enforcement began. Its purpose of reducing fraud and strengthening consumer protection is widely supported. SCA has succeeded in raising payment security and lowering fraud within the European Economic Area (EEA).

But its implementation has created operational pain points. Lowering the security risk without sustaining a seamless experience for users has raised the business risk. This is precisely where TRA and in-app protection technologies like application shielding become strategic. They let banks preserve SCA’s integrity while minimizing friction, maintaining compliance, and protecting revenue streams.

More reading: Mobile banking apps: A guide to mitigating fraud

Introducing Transaction Risk Analysis (TRA)

TRA is an exemption mechanism defined in Article 18 of the SCA TRA requirement that is allowed under PSD2 RTS. It allows low-risk transactions to bypass SCA regulations, provided the PSP can PSP demonstrate a consistently low fraud rate and uses real-time risk assessment. In practice, it means users can skip MFA for low-value transactions. But when transaction risk is higher, MFA is triggered as normal.

“1. Payment service providers shall be allowed not to apply strong customer authentication where the payer initiates a remote electronic payment transaction identified by the payment service providing as posing a low level of risk according to the transaction monitoring mechanisms referred to in Article 2 and in paragraph 2(c) of this Article.”  

— Article 18(1), RTS 2018/389

What ‘risk’ means here is not just about transaction amounts. The analysis of risk considers factors such as:

• the payer’s behavioral and spending patterns

• the typical amount and context of similar transactions

• the device’s integrity and software state

• geolocation or IP abnormalities

• presence of malware or session manipulation (Article 18 (2)(c)(ii–iii))

TRA typically relies on advanced analytics and fraud detection models that evaluate transaction risk in real time. If the engine flags unusual device information or possible malware infection, TRA cannot be used, and SCA must apply.

How TRA works in practice

Is TRA a clever way for users and banks to shorten the payment route? Yes, but it's not a loophole or workaround. TRA is a lawful, data-driven exemption to SCA with strict conditions attached. It is not an addition to SCA or a bypass around it. It’s a way for banks to streamline the user journey and protect conversion rates without breaking PSD2 rules.

In practice, TRA operates as a smart, compliant, risk-based shortcut inside the SCA framework. It lets banks and PSPs reduce payment friction and preserve revenue, all while staying fully PSD2-compliant. By using real-time analytics to assess transaction risk and maintain fraud rates below regulatory thresholds, institutions can offer seamless user experiences without compromising security or compliance.

The business case for TRA

TRA offers substantial, measurable benefits for banks and users.

Benefits for users

Since users don’t need approval for each transaction via Face ID or OTP, authentication friction is greatly reduced for everyday payments. A smoother, faster checkout without repeated MFA challenges, less context switching, and fewer time-outs means better user experience (UX) and higher satisfaction.

Benefits for banks

The definite financial gains for banks that use TRA are multilayered.

• Higher transaction completion (‘conversion’) rate—Lower authentication drop-off directly increases completed transactions.

• Lower operational costs—Fewer OTPs and API calls reduce infrastructure and support overhead.

• Increased customer satisfaction and loyalty—A smoother experience drives retention and positive NPS.

• Competitive differentiation—Frictionless, compliant flows attract merchants and end users.

• Maintained fraud controls—Continuous fraud-rate monitoring keeps institutions eligible for exemptions.

Illustrative banking scenario 

Here’s a hypothetical case study to help banks calculate in approximate terms the financial benefits of TRA. Over 1 billion transactions averaging €50 each, with a 0.3% service fee per transaction:

• Under SCA, an is 8% abandonment rate = €1.2 billion in lost volume

• Under TRA, a 2% abandonment rate = €0.3 billion lost

The result is €900 million recovered transaction volume. This could roughly result in a €2.7 million additional fee revenue. This demonstrates that TRA doesn’t just streamline payments; it protects the business model.

The compliance catch: Why device trust matters

It is important to examine the exact wording of Article 18 (2)(c) of the RTS (EU 2018/389) as it comes closest to providing technical details about an electronic payment that is “considered as posing a low level of risk”. One of the conditions of low-risk payments is that the payment service provider can perform a “real time risk analysis” that results in not identifying any of the following:

(ii), unusual information about the payer's device/software access;

(iii), malware infection in any session of the authentication procedure;

That clause creates a critical dependency. TRA decisions are only valid when the device and app environment are verified as trustworthy. If a mobile app is compromised, its telemetry cannot be trusted, and the transaction must not be exempted from SCA.

A compromised app is one that is rooted, jailbroken, infected, or injected. Due to these and other security issues, the risk engine may receive false signals, corrupting the TRA system’s input. This undermines the exemption's integrity and potentially violates PSD2 requirements.

TRA depends on trusted data flowing from a secure app and device layer to the bank’s risk-decision engine. Without that integrity, the 'smart shortcut' becomes a liability. What banks require for their apps at this point is a security architecture that safeguards the conditions that make TRA legitimate under PSD2.

How application shielding secures the TRA ecosystem

Application shielding safeguards the conditions that make TRA trustworthy. It functions as a foundational security control layer covering two main areas of the data trust chain: the mobile app and the device signals.

More reading: App shielding: The essential layer for mobile app security

Protecting the app environment   

Application shielding embeds a self-defending security layer within the mobile app itself. It prevents app tampering, code injection, and reverse engineering attempts that could compromise authentication sessions or device trust. This ensures the mobile environment meets the Article 18 requirement for a “trusted software access” state.

Securing device-level signals 

Shielding also verifies and protects the device signals that feed TRA models, such as OS integrity, runtime status, and security patch levels. If those signals are manipulated by malware or rooting tools, TRA decisions become invalid. Promon’s in-app protection ensures those signals remain authentic and untampered, so risk assessments reflect reality.

Business impact and competitive advantage

With device integrity secured, banks can apply TRA with confidence in their compliance and to gain competitive advantage.

Maintaining continuous compliance

By continuously verifying app and device integrity, even when offline, shielding provides verifiable evidence that no malware or abnormal access was detected during authentication. Auditable runtime checks prove Article 18 requirements are met. That allows banks to demonstrate PSD2 compliance and safely apply TRA exemptions without regulatory exposure.

Application shielding technology such as Promon’s safeguards the conditions that make TRA legitimate. This enables banks to turn a regulatory requirement into a business advantage.

Growing competitive advantage 

Secure TRA creates both UX and revenue opportunities for financial institutions. Banks can use it to reduce authentication friction and improve conversion rates. Each recovered transaction represents retained interchange and merchant volume. Banks that protect their mobile environments can market both security and ease of use in the same stroke. This is a rare combination in the compliance-heavy banking industry.

Promon acts as a silent enabler of PSD2 TRA for banks and PSPs. Mobile app security fortifies the digital infrastructure that regulators require, and customers expect.

The foundation of trusted compliance

For financial institutions operating under PSD2, Transaction Risk Analysis offers more than a compliance option. It is a business opportunity. It lets banks deliver frictionless payment experiences while reducing fraud and maintaining regulatory trust.

But the integrity of that system depends on the security of the mobile app and device where transactions begin. By embedding app shielding and runtime protection directly into their mobile channels, banks can ensure that every TRA decision is based on authentic, tamper-free data.