PSD2 – 2015/2366 / UE

PSD2 the long awaited successor of the 1rst Payment Services Directive from 2007, aims to harmonize (as eIDAS do) the European retail payments market, which is very much fragmented along national borders, and foster the adoption of innovative, easy-to-use and secure payment & authentication schemes.

EBA defines the SCA, from the base of the traditional concept of SA, “Strong customer authentication” is defined as “an authentication based on the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others”


And it must be applied by Payment Service Providers (PSPs) when “strong customer authentication where the payer:(a) accesses its payment account online; (b) initiates an electronic payment transaction; [or] (c) carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses” and “Strong Customer Authentication could include elements linking the authentication to a specific amount and payee. The technology solution enabling the strong authentication data and transaction data to be linked should be tamper resistant”.

For SecurCall Out-of-Band:

  1. knowledge (Username + password);
  2. possession (your phone – MSISDN that identifies the calling number);
  3. and inherence (the voice recognition during the call – “my voice is my identity”).

During the call to link “the authentication to a specific amount and payee” a voice prompt the Operation & the amount to pay”

For SecurCall SmartOtp:

  1. knowledge (Username + password);
  2. possession (your phone – the OTP is crypted and send to the phone that holds the encryption key);
  3. and inherence (the FingerPrint -touchID- or the voice recognition “my voice is my identity”).

The transaction description and the “specific amount and payee” is embedded in the notification/QrCode send to the Phone (the only device that can decrypt the description).

An additional security layer can be the FingerVein (Hitachi) Strong Authentication Device. It can be used for “important transfer” to secure the even more the transaction.  


Enrolment for and provision of authentication tools and/or payment-related software delivered to the customer should ful l the following requirements.

  1. Trusted environment – The related procedures should be carried out in a safe and trusted environment while taking into account possible risks arising from devices that are not under the PSP’s control.
  2. Secure Delivery of Credentials – Effective and secure procedures should be in place for the delivery of personalised security credentials, payment-related software and all internet payment-related personalised devices. Software delivered via the internet should also be digitally signed by the PSP to allow the customer to verify its authenticity and that it has not been tampered with.
  3. Specific StandAlone Registration –  For card transactions, the customer should have the option to register for strong authentication independently of a specific internet purchase. Where activation during online shopping is offered, this should be done by re-directing the customer to a safe and trusted environment.

After eIDAS regulation, a further step towards unification of the processes at the European level.



Research Sources


(1) nalversionafterpc201301en.pdf

BlocKChain Add-on

The authorisation data and the authentication transaction data can be entered into a BlockChain to ensure the immutability and the impossibility of tampering.



At AliasLab we offer cutting-edge solutions to help prepare companies for the eIDAS digital transformation. In partnership with Thales, we offer solutions that meet the following requirements defined by eIDAS:

  • Security of data used in creating an electronic signature
  • Unique connection between the data used in creating an electronic signature creation and the signature itself
  • Protect the signature data against forgery
  • Protect the data used in creating an electronic signature against illegitimate use by others

Thales HSMs act as the root of trust for AliasLab’s IDSign Signature engine, allowing the creation and management of the cryptographic keys used to create electronic signatures. This enables us to provide secure products and services that meet the new eIDAS cross-border standards.

The digital transformation brought about by eIDAS is well underway, and many kinds of companies, public and private, in all sectors. And AliasLab is part of it.

IDSign’s Signature Engine, in conjunction with the use of Thales’ HSM as a cryptographic module for the generation and protection of the data used in creating a signature, comprise a compliant QSCD according to the A-SIT-VI-16-048 Conformity Certificate as a SSCD -Secure Signature Creation Device according to Art. 51 E-IDAS Regulation UE Nr. 910/2014 – Art. 3, Par.4 -Annex III D.E. 1993/93 / EC.

Thales – Thales e-Security is a leading global provider of data protection solutions with more than 40 years experience securing the world’s most sensitive information. Our customers—businesses, governments, and technology vendors with a broad range of challenges—use Thales products and services to improve the security of applications that rely on encryption and digital signatures. By protecting the confidentiality, integrity, and availability of sensitive information that flows through today’s traditional, virtualized, and cloud-based infrastructures, Thales is helping organizations reduce risk, demonstrate compliance, enhance agility, and pursue strategic goals with greater confidence.

Thales Link


SecureCall can be used both by means of call to the toll-free number, or by means of QR Code.

The QR Code has the role guide in an automatic authentication procedure, in fact, this may contain, in addition to the toll free number, even the session OTP or the number of IBAN of the recipient (in the case of transaction). There is therefore no need to use the phone pad, but you just scan the QR Code with your enabled mobile (Enrolled).

We take for example the case of a generic login page.

The user accesses the portal by providing his username and password (something you know). Once logged into, the server in charge of managing the authentication process generates a QR Code (two-dimensional barcode) in which the OTP is stored in encrypted form to be used during the transaction; at this point the user scan with the camera of his mobile phone the QR Code (speaker and encrypted) using an application previously installed (something you have). The scan leads the user to his personal homepage . In this case there is no need to type in the phone number or enter the session OTP, but only use the QR code.

This implies an intuitive user experience and a more simple and fast procedure.


Today the entire suite of products SecureCall exceeded 200,000,000 authentication and over 1,500,000 Volume Users. Click here to view same use cases and project data of SecureCall Suite.

SecureCall Volumes

more than
Users Volumes
more than
Authentication Volumes

Use Cases



What is SecureCall? How does it works? Why Using it?

In a comic stripe we try to explain the key features of SecureCall and how it works in different Use Cases.