AUTHENTICATION.
IS IT REALLY HIM/HER?
Because of its particular relevance in the context of payments, identification is followed by proof of identity - authentication. When it comes to preventing fraud in the process of payment, authentication plays a very important role. Authentication ensures that the payer is authorized to access the account determined in the identification process.
Because of its particular importance in fraud prevention, customer authentication for payment transactions in the EU is regulated by law (as part of PSD2). For the first time, strong customer authentication became a mandatory factor within the payment process and static methods, that had previously been used, were also declared to be insufficient.
AUTHENTICATION WITHIN THE CONTEXT OF
Contribution of Sam Boboev; Also on LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7248935088824979456/
Convergence of Identity and Payment
The convergence of digital identity and payment has been a focal point for years, striving to balance convenience with security. With the introduction of the European Digital Identity Framework, the need for robust identification throughout the customer journey has become more pronounced.
Early forms of combining digital identity and payment have been present for years, with companies like Google and Apple paving the way through their local payment wallets. These wallets store tokenized credit cards and integrate biometric authorisation to confirm transactions. Emerging approaches, such as ensuring delegated authentication in alignment with PSD2 compliance, facilitate seamless authentication, allowing merchants to process transactions efficiently.
The integration of digital identity and payment credentials in a single wallet is viewed as a strategic move by tech giants to enhance the payment ecosystem. The EUDIW stands out with its emphasis on a decentralised, privacy-centric, and standardised approach. By leveraging verifiable credentials, these wallets enhance trust and pave the way to a more secure digital landscape.
Upcoming pilots will explore the relevance of digital identity in various payment contexts, potentially extending to initiatives like the digital euro. Whether for age verification, in-car payments, or future Web3 verifications, the prospects of integrating digital identity with payment systems are bright, contingent on user adoption and service provider acceptance.
The European Commission’s intention to link digital payment wallet with the EUDIW aims to create a coherent and efficient electronic transaction environment across the EU.
Impact of the Digital Identity Wallet on Banks
The digital transformation of banking security is essential, and its importance has been amplified by the COVID-19 pandemic. The introduction of EUDIW will bolster digitalization efforts, providing customers with convenience, environmental benefits, and cost savings. Bank could assume multiple roles within the new ecosystem:
• As Wallet Issuers, banks would serve as trusted entities, responsible for security and privacy, a role explored in detail in the first part.
• As Relying Parties, banks could use services from the wallet for user authentication or to access qualified attributes within the wallet.
• As Attributes Providers, banks could contribute to, and enrich, the wallet with qualified attributes.
Unless for special exceptions apply, strong authentication applying 2 different factors out of the categories listed below is required in order to trigger a payment.
- Knowledge (e.g. a PIN)
- Possession (e.g. possession of a payment card)
- Biometric factor (inherence; e.g. a biometric feature)
The factors chosen have to be independent from one another. Should one factor be compromised, this may not automatically apply to the other. Likewise, at least one of the elements must not be reusable or reproducible.
Due to central regualtion, authentication for card and account payments do not differ fundamentally. The same technical media can be used within the respective authentication process. Especially in the context of the more account-oriented banking in continental Europe, authentication for card payments is often carried out using the same authentication media that are used for account payments in online banking.
TRANSACTION RISK ANALYSIS.
Transaction Risk Analysis (TRA) is one of a total of six exemptions that legally release a Payment Service Provider (PSP) from performing Secure Customer Authentication (SCA)1 in a payment. Having to carry out SCA for certain card-based transactions, which, after a few postponements, became mandatory for Germany (and other European countries2) on March 15, 2021, leads to a large number of legally required authentications and, as a consequence, to canceled transactions in eCommerce.
The TRA is a risk-based exemption under the PSD2/RTS to process a payment transaction without SCA.
By means of a TRA exemption, SCA can be omitted in compliance with technical, organizational and legal requirements. First experiences in this field show that TRA is one of the most commonly used exemptions to SCA.
BACKGROUND
Among other objectives, payers are to benefit from a higher protection level against fraud, an aim achieved by combining the Payment Service Directive 2 (PSD2) and the separate Regulatory Technical Standards (RTS). To this aim, SCA became mandatory in payment transactions.
In order to improve user experience, legislation has defined six exemptions in which SCA can be waived due to low risk of fraud. Depending on the amount of the transaction, there are various ways to exempt a transaction from the SCA requirement or, if necessary, to hedge it specifically by means of SCA3
.One of the most complex and far-reaching exemptions - in terms of the additional requirements to be met - is the TRA exemption. The TRA exemption can be applied to transaction amounts between EUR 0 and EUR 500 if specific conditions are met.
Transactions for amounts beyond this limit will only be carried out without SCA by using exemptions which are not linked to a specific amount. The PSP of both the payer and the payee may use the TRA exemption or, after assuming liability, to propose it as an exemption to the other PSP.
More about
transaction risk analysis.