Strong Customer Authentication requires payment service providers to authenticate users using at least two independent factors drawn from the categories of knowledge, possession, and inherence. A push notification delivered to a user’s registered mobile device can qualify as a possession factor within an SCA-compliant authentication flow, but only when it meets the technical and operational requirements defined in the EBA RTS on SCA and secure communication. Meeting those requirements involves several distinct conditions covering device control, dynamic linking, encryption, and delivery reliability, each of which is examined below. The landscape of modern financial technology is rapidly evolving, with push notifications becoming an indispensable tool in the Strong Customer Authentication (SCA) Regulatory Technical Standards (RTS).
As illustrated in a typical SCA-compliant push notification flow, a user initiates a payment or account access request. The payment service provider sends a push notification to the user’s pre-registered device containing transaction-specific details, including the payment amount and beneficiary. The user reviews the details and confirms the transaction on the device, which then generates or transmits a confirmation back to the provider. This confirmation, combined with a second independent factor such as a biometric verification or PIN entry on the same device, completes the SCA process. The entire flow is logged for audit purposes, with timestamps and device identifiers recorded at each step.
Key Takeaways: #
- Push notifications can form a valid possession factor within a PSD2 Strong Customer Authentication (SCA) flow, provided they meet specific requirements set out in the EBA Regulatory Technical Standards (RTS) on SCA and secure communication;
- To be SCA-compliant, push notifications must be delivered to a device solely under the user’s control, transmitted through an encrypted and tamper-resistant channel, and incorporate dynamic linking that ties the authentication to the specific transaction being authorised;
- Push notifications do not satisfy SCA requirements on their own. They must be combined with a second independent factor from a different category, such as a knowledge factor (PIN or password) or an inherence factor (biometric verification).
Leveraging Independence #
Requirements for SCA-Compliant Push Notifications #
Device independence and possession: For a push notification to qualify as a possession factor under SCA, it must be delivered to a device that is solely under the control of the user. This means the device must be uniquely registered to that user within the payment service provider’s system, and the authentication confirmation must originate from that specific registered device. The device binding process typically involves cryptographic keys generated and stored securely on the device at the time of registration, ensuring that the possession factor cannot be replicated on another device without the provider’s knowledge.
Dynamic linking: The EBA RTS on SCA requires that authentication of payment transactions incorporates dynamic linking, meaning the authentication code generated during the process must be specifically linked to the transaction amount and the payee. For push notifications, this means the notification must display the transaction-specific details clearly to the user before they confirm, and the authentication code generated by the confirmation must be mathematically linked to those details. This ensures that the authentication cannot be reused for a different transaction or intercepted and redirected to authorise a fraudulent payment.
Encryption and secure transmission: Push notifications used within an SCA flow must be transmitted through encrypted, tamper-resistant channels. The content of the notification, including any authentication data or transaction details, must be protected against interception, modification, or replay attacks during transmission. The cryptographic mechanisms used must meet the standards specified in the EBA RTS, ensuring that the notification cannot be read or altered by a third party between the server and the user’s device.
Delivery reliability and confirmation: SCA compliance requires that the possession factor used in the authentication process is reliably delivered to the intended device and that delivery can be confirmed. For push notifications, this means the payment service provider must have mechanisms in place to detect failed or undelivered notifications and to prevent the authentication process from completing if the notification has not been successfully received by the registered device. This guards against scenarios where a notification is intercepted, redirected, or silently dropped before reaching the intended recipient.
Push notifications as one factor within a broader SCA flow: Push notifications address the possession factor requirement within SCA but do not satisfy the full two-factor requirement on their own. To complete an SCA-compliant authentication, the push notification must be combined with a second independent factor from a different category. This may be a knowledge factor, such as a PIN or password entered by the user, or an inherence factor, such as fingerprint or facial recognition. Many implementations combine the push notification with an on-device biometric, allowing the user to confirm both the possession and inherence factors within a single, streamlined interaction on their registered device.
FAQ: #
Does a push notification combined with an on-device biometric satisfy SCA on its own?
- A push notification delivered to a registered device (possession) combined with an on-device biometric such as a fingerprint or facial recognition (inherence) can constitute a valid two-factor SCA combination, provided both factors meet the independence and technical requirements of the EBA RTS. The two factors must be independent in the sense that compromising one does not compromise the other. Where the biometric is processed locally on the device and the push notification is cryptographically bound to that device, this combination is generally considered compliant. Payment service providers should confirm their specific implementation against the EBA RTS requirements and, where applicable, seek guidance from their national competent authority.
What is the difference between a push notification OTP and an SMS OTP for SCA purposes?
- Both push notification OTPs and SMS OTPs can qualify as possession factors under SCA, but they carry different security profiles. SMS OTPs are delivered via the mobile network and are vulnerable to SIM-swap attacks, where an attacker redirects a user’s phone number to a device under their control. Push notifications delivered through a dedicated application with cryptographic device binding are considered more resistant to this type of attack, as the notification is tied to the specific device rather than the phone number. The EBA has noted the vulnerabilities associated with SMS OTPs and payment service providers should assess whether their SMS-based SCA implementations adequately mitigate this risk.
The principle of independence asserts itself as a fundamental aspect of SCA-compliant push notifications. Not only does the notification need to be delivered, but it should be delivered to a device that is under the sole ownership and control of the user. This amplifies the element of ‘possession’ in the two-factor authentication mix, adding another dimension to secure financial interactions.
By incorporating device possession as a central part of the SCA compliance process, push notifications elevate the security protocols from simply relying on knowledge-based elements like passwords or PINs. These notifications take on a deeper role in the security apparatus, serving as an exclusive bridge between the banking institution and the user’s personal device.
Payment service providers must assess the implementation of compliant push notifications against the stipulations of the SCA RTS to ensure full compliance. The ultimate aim here is to strike a balance between stringent security measures and a smooth user experience, thus transforming the realm of online transactions. Baseella had in mind the above considerations from the day one when developing our software, learn more how you could benefit by reading about the features that we have.
