Knowledge

Using TrustBuilder Mobile Authenticator to approve payment requests

Retail banks face a dilemma: users, these days, are demanding frictionless access to their banking app yet, at the same time, they will not tolerate any weakness in the security of their transactions. How to solve this conundrum?

Well, TrustBuilder proves that airtight security and customer experience can go hand in hand. TrustBuilder Mobile Authenticator caters to mobile users who want to get rid of passwords without compromising on security.

 

Read on to learn how:

  • TrustBuilder Mobile Authenticator supports mobile payments and adheres to EU standards
  • How passwordless approval of payment initiation works
  • How payment approval works with TrustBuilder Mobile Authenticator
  • How payment app activation works with TrustBuilder Mobile Authenticator
  • How payment app initiation works with TrustBuilder Mobile Authenticator

How TrustBuilder Mobile Authenticator supports mobile payments

TrustBuilder Mobile Authenticator is a solution to obtain verifiable confirmation from a user using their trusted phone without the need to enter a password.

The type of confirmations that a user can give ranges from “I’m still there and holding my phone” and “I’m explicitly giving my consent for this activity” to “I approve this payment request from the merchant.” The former case is typically referred to as: authentication.

The latter case is referred to as ‘payment initiation’ of which Secure Customer Authentication (SCA) is the subject of this article. With EU 2015/2366, the European Commission and the European Banking Authority issued the second Payment Services Directive (PSD2). The Berlin Group issued standards for PSD2-compliant payments within a payment ecosystem. The system described below complies with the ‘NextGenPSD2 XS2A Decoupled SCA Approach: Implicit Start of the Authorization Process’.

How passwordless approval of payment initiation works

We’ll illustrate a potential passwordless payment with a fictional bank, BestPay. For the example, we are assuming that BestPay is a TrustBuilder customer, using TrustBuilder Mobile Authenticator. We’ll use the story of Hanna, a buyer at a fictional online shop called BestBuys, affiliated with BestPay. We will follow Hanna as she uses the BestPay app on her smartphone.

Hanna receives an invitation from her bank to activate passwordless payments. She installs the app from BestPay on her personal phone.

She only needs to provide her consent and activate the phone. She is told that this activation actually starts a cryptographic process. In this process, her phone generates secret keys that are used to establish a super-secure channel between her phone and the bank. The secret keys are safely stored in the vault on her phone and cannot be retrieved by a hacker or any other cybercriminal.

To keep fit, Hanna goes off for a run. Down at the park, it starts raining and her feet get wet. So she thinks: high time to buy new shoes.

Surfing the web, she finds BestBuys offering summer sales up to 50%. BestBuys happens to be affiliated with her bank, so she wants to try out passwordless payments.

She finds a pair of Fly&Run shoes and orders them immediately.
The online shop now gives her a choice to pay the traditional way or the ‘flash’ way. Paying the traditional way means that her browser would be redirected to her bank.
Hanna chooses the Flash Checkout option.
The Flash Checkout invites her to open the BestPay payment app
By scanning the QR code the payment app obtains the payment request. Hanna is now invited to confirm the purchase, which unlocks the vault of her phone and executes a cryptographic exchange with her bank.
This actually completes the transaction. Her bank transfers the money to BestBuys and BestBuys can book the purchase as ‘paid.’

Hanna is a happy customer of both BestBuys and her bank BestPay thanks to this frictionless handling of her payment.

How does payment approval work with TrustBuilder Mobile Authenticator?

Rather than entering a password into the browser or app that is then sent to the server, TrustBuilder Mobile Authenticator lets the user give their consent and approve transactions simply by using their trusted device.

The TrustBuilder Mobile Authenticator process to the bank (or third-party payment services provider) is basically broken up into two disjoint steps:

  1. First, the user authenticates to their trusted mobile to prove they are the owner and are present. This is local and device-specific and is typically done using a PIN code, fingerprint or face-id.
  2. Then, the Mobile Authenticator client, within the app, authenticates itself to the Mobile Authenticator server without exchanging passwords or long-term secrets but by executing a cryptographic process using secret keys in the vault of the device.

This means that user authentication is out-of-band, i.e., using a different device and channel. Given the security of the vault and the biometrics on mobile phones, the security of TrustBuilder Mobile Authenticator is superior to traditional methods. The only requirement of this model is that the TrustBuilder Mobile Authenticator client must be installed on the trusted mobile and be registered at the TrustBuilder Mobile Authenticator server beforehand.

The authentication between the Mobile Authenticator client and the server adopts a SIGMA cryptographic protocol (‘SIGn-and-Mac’). The SIGMA family of key-exchange protocols offer perfect forward secrecy which means that session keys remain protected even in case the long-term secrets used for the key exchange are compromised. To ensure secrecy of the mobile client as well as mutual authentication between the mobile client and the server, these protocols adopt Diffie-Hellman and add a secure hash and signature of the requester. In this way, the SIGMA protocol of TrustBuilder Mobile Authenticator establishes a trusted channel between the mobile client and the authentication server.

From a PSD2 perspective, TrustBuilder Mobile Authenticator adds consent and signing of the payment request, as per the SCA requirements for PSD2.

The process with TrustBuilder Mobile Authenticator is as follows. In this process we assume the user has previously installed and activated the payment app that contains the TrustBuilder Mobile Authenticator client, as described below.

  1. During the check-out process, the merchant will initiate the payment request with the bank of the buyer. This process may happen through an acquirer and/or a third-party payment service provider – see below. The result is a ‘Payment Initiation Response’.
  2. Using the Payment Initiation Response, a QR code is generated that contains the payment details. The merchant shows the QR code and invites the buyer to use the payment app of their bank.
  3. The buyer now takes their trusted device and opens the payment app of her bank. By scanning the QR code, the payment details are exchanged between the browser and the Mobile Authenticator client inside the payment app.
  4. The buyer reviews the payment details and approves/refuses the transaction after which she authenticates herself to her trusted device, e.g. face-id, fingerprint or PIN code. This unlocks the device’s private vault for the Mobile Authenticator client.
  5. The Mobile Authenticator client uses the secret keys held in the private vault and opens the trusted channel with the bank. This is done by initiating the Mobile Authenticator protocol. The payment details are then signed and passed on to the Mobile Authenticator server of the bank.
  6. The Mobile Authenticator server now formally declares that the buyer has approved the payment and the bank can execute the payment.
TrustBuilder account linking sequence diagram

How does payment app activation work with TrustBuilder Mobile Authenticator?

The bank (or, in general, a payment service provider) installs the secure TrustBuilder Mobile Authenticator server. They also publish a payment app (or extend their banking app) that contains the TrustBuilder Mobile Authenticator client.

They then invite their customers to install the payment app on a device they trust, i.e. that they own and that has a secure vault for secret keys that only they can unlock. The customer then follows these steps:

  1. Open the payment app on their device
  2. Unlock their device’s vault using fingerprint, face-ID, or PIN
  3. Read and accept the bank’s privacy policy and terms and conditions
  4. Start the activation process.

The activation process is handled by the TrustBuilder Mobile Authenticator client in collaboration with the TrustBuilder Mobile Authenticator server using the SIGMA-1 cryptographic protocol.

How does payment app initiation work with TrustBuilder Mobile Authenticator?

With EU 2015/2366, the EU issued the second Payment Services Directive (PSD2). Whereas in the UK, the Open Banking initiative standardizes PSD2-compliant payment services, the EU set up the Berlin Group, led by EU banks and payment processors.

The European Banking Authority issued a Regulatory Technical Standard (RTS) relative to PSD2, which calls for multi-factor authentication and explicit detailed payer consent in what is called Strong Customer Authentication (SCA). SCA basically adds dynamic linking of transaction details (amount and payee) to the multi-factor authentication of the payer.

The Berlin Group further standardizes PSD2-compliant Access-to-Account (XS2A) practices in technical detail. The aforementioned step #1 payment initiation implements the ‘Decoupled SCA Approach: Implicit Start of the Authorization Process’.

This Decoupled SCA Approach: Implicit Start of the Authorization Process works as follows:

The Secure Customer Authentication (SCA) is performed by TrustBuilder Mobile Authenticator as described above.

There may be several parties between the merchant and the bank. Payment initiation can, legally speaking, only be done by a licensed Payment Initiation Service Provider (PISP). Large e-merchants may pick the PISP role themselves, but often the PISP role is done by the merchant’s Acquirer or a third-party payment service provider (TPPSP). The bank may also be an intermediary and be the Account Servicing Payment Service Provider (ASPSP) as a front door to the bank holding the buyer’s account.

A more elaborate process involves token exchange that builds upon OAuth 2. The Berlin Group has standardized this under OAuth2 SCA Approach: Implicit Start of the Authorization Process with Confirmation Code.

Are you interested in offering your banking customers the best of both worlds: ease of use and the highest level of security? Contact us and we will help make your customers happy.