Strong Customer Authentication Solution for PSD2

The Authenticator App handles “Dynamic Linking” and meets all the Strong Customer Authentication (SCA) requirements

Get Started
Strong Customer Authentication

What is Strong Customer Authentication?

The Regulatory Technical Standards (RTS) on SCA implies that the end-customer’s identity must be verified by two or more authentication methods: Knowledge, Possession and Inherence. Each element must be independent, so that the breach of one element will not compromise the others.

Electronic remote transactions (such as payments made via mobile devices or online) are subject to an additional authorization layer to SCA — “Dynamic Linking”, which in fact requires ASPSP (e.g. banks) to add a specific Authorization Method for each remote transaction. Such authorization should include an Auth Code, which is generated based on payment amount and payee information. The Auth Codes must be provided to the end-customer via a different environment than the one through which the end-customer has initiating the payment. In essence, it means that the Authorization cannot be performed on the internet/mobile banking with payment initiation (PISP app) support otherwise, the Payment and the Authorization process would be combined in a single environment, which is prohibited by PSD2.

Strong Customer Authentication

NOTE: Generic Tokens, SMS, and non-encrypted push notifications cannot be used for Auth Code delivery as they might be read by the third parties involved in the message delivery. The RTS requires that “Dynamic Linking” information must be transmitted securely without any possibility for a third party to read or have access to this data.

Main Features

Linking of TPPs

Grant access to payment accounts for Third Party Providers (PISP/AISP). The authorization process is used as a second confirmation of the end-customer, besides the banking credentials.

Action Authorization

The bank generates the Auth Codes, while the Authenticator App offers the end-customer the possibility to allow or deny the action.

Document Signing

Receive and sign legally binding electronic documents from a mobile device. The Authenticator is used for digitally signing the received documents using private keys stored on the mobile device.

Get the SCA and Dynamic Linking Compliance Solution

Get more in-depth details on how Salt Edge can help your bank become compliant with all the SCA requirements.

Get Started

How does it work?

The only thing that Salt Edge stores on the end-customer’s device itself is the Private Key, that was designated special for this end-customer and for that particular device. The Authorization session of any action expires in just a couple of minutes. Therefore, the maximum that an attacker could do is only accept or decline an existing payment.

TPP (Application) Bank Authenticator (end- customer) 1 4 2 Initiate end-customer Consent Bank sends the Auth Code to the Authenticator Bank executes the action 3 End-customer confirms the action in Authenticator
  1. End-customer initiates an action
  2. Bank sends the code to the Authenticator
    1. Bank generates the unique dynamically linked Auth Code
    2. Bank encrypts the code with the end-customer’s Public Key
    3. Bank sends a push notification to the Authenticator to notify about the end-customer's action confirmation request
  3. End-customer confirms the action in the Authenticator
    1. End-customer unlocks the Authenticator with PIN/Face/Fingerprint
    2. Authenticator decrypts the Auth Code from the bank
    3. End-customer confirms the action and the Authenticator sends the Private Key signed Auth Code to the bank
  4. Bank executes the action
    1. Bank verifies the request signature and the Auth Code (using the Public Key)
    2. Bank performs the action initiated via TPP
    3. Bank notifies the TPP about the action's status
Note: All communication between services is done via HTTPS, TLS 1.2

Implementation

implementation

The Authenticator is a white-label application which can be easily added as a separate app or as a module to an existing banking app. It can be used by any financial institution interested in being compliant with the SCA requirements. The Authenticator can be purchased separately or as part of the PSD2 Compliance Solution for banks. If ordered as a separate module, the Authenticator's implementation takes on average 4 to 6 weeks.

Request a Demo

GET Product Sheet!

Strong Customer Authentication Solution for PSD2

GET

Request a Demo

Get a first-hand experience with our global leading software to see the full range of possibilities that are unlocked for you and your company

Please complete this mandatory field
Please complete this mandatory field
Invalid email.
Please select an option from the dropdown
Please complete this mandatory field

Which product are you interested in?*