Logo
Quali-Sign
A dedicated mobile app to capture Strong Customer Authentication for PSD2
W3Schools
Supports both Decoupled and App-to-app Redirection.
Both these two flavours of Strong Customer Authentication (SCA) share a common set of bank issued user credentials.
Caters for Retail and Corporate Banking use cases.
Supports single and multi-user approval of individual or bulk payments, initiated via a PSD2 'Access-To-Account' (XS2A) API, via a bilateral API or via a bank's 'host-to-host' channel.
The user reviews a summary of the payment order and can access the full content as required.
It is essential that all payment details are available to the reviewer. This is because the act of approval will effect the transfer of liability from the bank to the payer.
However, in the case of bulk payments, it is unreasonable to expect the user to validate every beneficiary account and amount. To address this, the approver is given comfort that the payment content has not been modified since creation.
The user then approves or requests cancellation of the payment order.
This invokes the procedure to capture SCA.
SCA is performed via the creation of an electronic signature using the facilities (incl. biometric) of the user's mobile device.
The SCA proof is is unique, unambiguous and demonstrable (i.e. portable and verifiable).
Following approval, the user can continue to monitor payment status.
Payment status, including reason information, is reported at file, batch and transaction level. Status is also presented/filtered in coloured 'traffic light' categories.

Features and Benefits

Company Name     The Quali-Sign name reflects the legal certainty offered by the use of eIDAS Qualified Electronic Signatures. Our solution supports 'simple' Electronic Signatures, Advanced Electronic Signatures and optionally Qualified Electronic Signatures.
   
Security and Communication Standards     Our solution has adopted best practice international security and communication standards. As recommended by the PSD2 RTS on SCA, the 'possession' element is represented by a cryptographic public/private key pair. The private key resides within the 'secure element' of the user's device and is unlocked using the device's biometric sensor ('inheritance') and/or via a PIN ('knowledge'). Communication between the app and bank's server is performed using the highly secure 'Electronic Banking Internet Communication Standard' (EBICS).
   
Automation of Credentials Provisioning     User activation and device migration requires SCA to be performed on all new credentials. When the app creates new credentials, the public key is included, together with the user's personal details, within an X.509 certificate request. This request enters the bank's decoupled SCA procedure. Once one or more active users have approved the request, the bank issues an X.509 certificate which is automatically downloaded to the user's device and the user is activated. When the user subsequently performs SCA, a copy of this certificate is included as part of the SCA proof. The bank can centrally revoke this certificate at any time, which invalidates their SCA credentials.
   
Packaging the SCA Proof     In our solution the SCA proof package contains the history (audit trail) of the payment order. This includes a copy of the order data, 'proof of creation' and 'proof of approval' for all approvers. The proof of creation and approval are dynamically linked to the entire order data (not just the payee and amount). Proof of creation gives the approver comfort that the order data has not been changed since creation. If any element is subsequently invalidated, prior to payment execution, this will invalidate the SCA proof and unexecuted payments become unauthorised. In the event of a dispute, this package is essential evidence to prove SCA. It is sharable (e.g. with the payer) and can be independently verified via 3rd party web sites.
   
Device, Software and Credential Integrity     On Android devices, 'Attestation' evidence is made available to prove the integrity of the hardware; operating system; the app itself; other apps installed on the device; the private key credentials and proof that it was created and resides within the Secure Element of the device. Each time SCA is performed, this attestation evidence is included within the 'proof of approval' elements in the SCA package.
 
On Apple devices, although attestation evidence is not currently made available to apps, the verification process is performed internally by iOS which will reset the device to factory settings if it is found to be compromised.