REGULATORY/ GENERAL FRAMEWORK

In principle, when using TRA, quantitative and qualitative requirements have to be differentiated and implemented.
Both the PSP on payer’s and payee’s side may apply or propose a TRA exemption. The core requirements of TRA need to be submitted to the responsible local financial regulatory authority upon request. They consist of the following three categories:

1. Compliance with general IT security standards (PSD2) and authentication-specific measures (RTS & TRA).
2. Fulfilling the underlying reference fraud rate in the respective observation period (per payment method).
   The European Banking Authority (EBA) defines the following fraud rates according to the RTS:

The reference fraud rate is calculated using the following formula:

3) Carrying out a real-time risk analysis including the specified security measures and monitoring the reference fraud rate.

In addition to these quantitative legal criteria, a number of other qualitative requirements exist that should also be considered part of regulatory TRA compliance.

In the first place, a qualified attestation by an expert third party is required. The expert attests to the PSP's correct calculation method of the reference fraud rate and its underlying data, and also to the correctness of the written documentation regarding the associated processes and measures.
In addition to the requirements for quarterly reporting, in order to monitor the key figures and reference fraud rate binding standards for documentation with regard to the upstream and downstream TRA processes are mandatory. This includes documentation for the supervisory authorities and ensuring the integration into the respective financial regulatory authority’s reporting system.

It is therefore advisable to have an external expert screen the legal organizational requirements before applying the TRA exemption for the first time.
Whether existing risk prevention systems meet the requirements of PSD2 / RTS must be individually examined and attested for each market participant.

TECHNOLOGIES/ FUNCTIONALITIES

Since, from an organizational point of view the only time frame for ensuring that the requirements for a risk analysis are met is during the processing of a transaction, a real-time analysis must be ensured in the authentication or authorization phase.
The real-time risk analysis of the payment transactions is performed based on verifiable criteria and processes that are necessary to evaluate risk.
In addition to the technical risk prevention system / the system for risk assessment and measurement, first and foremost a real-time risk analysis requires an intelligent control logic which controls the transaction up until the final authorization. This control logic may be implemented by the same tool that performs the actual TRA. Ideally, authentication and authorization run together as a process and flow.
Both control logic and TRA require real-time processing. This requires a scalable, highly available application and architecture. Most tools used for this purpose employ a hybrid approach of statistical machine learning (ML) and a rule-based expert system.
In addition, the corresponding protocol versions of the respective payment instrument require support for processing the correct TRA fields. For instance, in the card business SCA is specified by EMVCo in the 3DS2 protocol which is used by most international card organizations. However, differences arise in the field assignments within Authorization and Clearing when applying TRA (or other exemptions).

USER EXPERIENCE (UX)

From the perspective the of the payer or its PSP, the UX is mostly to avoid SCA in low-risk transactions, and whenever permissible.

Ideally, after submitting the standard payment data, e.g. card number, expiration date, and check digit, all further authentication by the payer will be waived.
Embedding the TRA exception into the correct and meaningful test sequence of all existing exemptions in use is critical to a smooth implementation.
However, next to the technical implementation it is also crucial which SCA methods will be accepted and used by the customer in the event of an SCA query. They should be simple and comprehensible for both the payer and the payee, easy to perform and support.

STRATEGIC POTENTIAL

To date, the screening of transactions has primarily been geared towards fraud prevention and the compliance requirements of money laundering legislation. This resulted in either rejecting a transaction or reporting of individual transactions.
Regulation on TRA mandates risk-oriented real-time analysis, defines target fraud rates, and sets an organizational framework for fraud prevention. Fraud prevention is thus moving from a mere business perspective, selectively motivated by fear of large failures, to a more formalized, professionalized structure.
Together with the use of ML tools, this will lead to a more intensive and holistic consideration of the topic, this includes the opportunities presented by this infrastructure. In particular, moving away from a pure "reject-or-approve" logic creates a multi-criteria view. Fraud prevention by rejecting transactions is now complemented by additional means of choice between strong customer authentication and frictionless UX. However, ML tools have the potential to optimize criteria such as liability or routing in real time.
Depending on the business model or the risk appetite of the respective PSP, different approaches for applying SCA are conceivable. The priority need not necessarily be to aim for the lowest reference fraud rate. Likewise, generally performing SCA in order to standardize the customer experience may become a common denominator.
Since regulation provides an organizational framework in addition to the mere technology, these issues are now systematically brought to the decision-maker level. TRA is thus becoming the catalyst for a movement away from pure transaction processing to intelligent real-time transaction management.