API Strong Customer Authentication for Payments

This document describes a solution for Strong Customer Authentication (SCA) for payments created using Ebury API.

Reference Documents

Reference	Document Location
SCA01	Regulatory Technical Standards on strong customer authentication and secure communication under PSD2

Problem Description

In order to be able to add Payments into the Mobile App we will need to address the regulatory requirement [SCA01] that enforces SCA for untrusted beneficiaries.

The Mobile App uses Ebury API for all operations, acting as a client application, therefore we need to enhance the Ebury API to support SCA for payments to untrusted beneficiaries.

Background

Ebury API Auth currently supports SCA for logins, using Verify to send verification codes. However, there is no solution for SCA for payments in Ebury API.

We need to pause payment creation until it's verified, avoiding modifications to BOS or other legacy systems. We need to inject an intermediary step in the payment processing that would store payment instructions, send verification codes, accept verification codes and after a successful verification send the instructions to the right service (currently BOS).

This functionality could be provided by the Payment Command Service, but its development hasn't started yet.

Solution

Implementing a first phase of the Payment Command Service.

The phase one implementation of the Payment Command Service will implement the logic to persist, validate the need for SCA, hold those payment instructions if needed, and release them when the SCA flow is complete. In this first phase it will only act as a coordinator between the Public API, Verify and BOS for the payment submission process.

Payment instructions flow

Whenever a payment batch (consisting of one or more payment instructions) is submitted, the Payment Command Service contacts Verify to figure out if the payment requires SCA. Verify will check if there is at least one untrusted beneficiary in the batch.

Payment instruction batches without untrusted beneficiaries

If there are no untrusted beneficiaries the Payment Command Service will release the payment instructions to BOS immediately.

Payment instruction batches with untrusted beneficiaries

If the payment batch have untrusted beneficiaries the Payment Command Service will hold the payment instructions and coordinate the SCA flow. The response to the user will indicate the need to perform the SCA flow and include a payment request id that will be used during the rest of the flow.

2FA code submission

Once the user submits the 2FA code and the payment request id through the Public API the payment batch will be released to BOS after verifying the code.

Invalid 2FA code submission

If the user submits an invalid 2FA code the payment instruction batch will be kept on hold. Verify is on charge of tracking failed attempts.

2FA code resend request

The service also needs to allow the user to request a new 2FA code. In this case Verify will also be the service enforcing limits to avoid abuse of the resend flow.

Public API impact

All the flows are completely synchronous in order to introduce as fewer changes as possible to the Public API interface for our existing API clients. Anyway we will need to include a new type of response for the payment creation endpoints to cover the case when the payments require SCA which is a breaking change in the API. The new response will include a special status code, a payment request id, and maybe a url for submitting the verification code (the exact format of the response will be decided later). To avoid affecting our current API consumers the SCA checks will be only enforced for the mobile app requests during this first phase. That distinction will be done at the Public API level, by routing the payment directly to BOS for non-mobile consumers or to the new Payment Command Service for mobile ones.

Future development

Payment Command Service

This RFC only proposes a first phase for the service. In future phases the Payment Command Service can be extended to include the following features: - Asynchronous payment instruction submission to BOS. To make this future development easier the Phase One will take it into to consideration, designing the system to easily swap between different upstreams and payment instruction submission methods. - Domain events publishing. - Asynchronous submission of payment instructions. - Full validation of the payment instructions performed by the Payment Command Service.

Verify

It can be interesting to extract the SCA logic which currently is located in Verify to an independent SCA for Payments service, that could take care of SCA for the payments domain.

Alternatives

A simpler and quicker alternative would be to add the SCA logic and an operation instruction database in the existing API services. However, the logic will be more difficult to interact with and used in isolation by other Ebury services, as Ebury API is meant to be used directly by Ebury customers. With this solution we would incur in technical debt.

Caveats

Data protection impact

The payment instructions database will contain attributes that are considered personally identifiable information: client id, contact id, beneficiary id, account id.

This data will only be kept in the database for a short amount of time, it will be removed shortly after the the verification token expires or until the payment is verified. From a data protection perspective this retention is appropriate and doesn't require additional data protection impact assessments.

Concurrency

The Payment Command Service is delegating the concurrency management to the Public API and Verify.

The Public API through its idempotency functionality will ensure that a batch of payment instructions is only processed once.

Verify will ensure that multiple parallel 2FA code submissions or new 2FA code requests for the same payment instruction batch can not avoid the maximum attempts constraints.

Beneficiary ids

The only information associated to beneficiaries in Verify is their ID. There is no way to identify beneficiaries by IBANs or account identifiers or other information BOS is using to identify beneficiaries when creating multipayments, so we need to know the beneficiary ID in order to get its trust status. For multipayments, we need to perform the validation of beneficiaries in BOS first, get the IDs of existing beneficiaries and check their trusted status in Verify.

Operation

Payment Command Service is an internal service, cannot be accessed directly by API clients.

Payment Command Service will be deployed in Production (Kubernetes) and Mobile (EBOX). If Sandbox is not in Kubernetes yet when the feature has to be rolled out to clients that use the Sandbox environment, then Payment Command Service will be deployed to the sandbox EBOX too.

We might need to provide a management console to keep track of the unverified operations in order to assist customers in case of issues.

Security Impact

None.

Performance Impact

Payment Command Service introduces additional communication overhead, as traffic must still go through it, even if operations do not need to be verified.

Extra time is spend deciding if operations need to be verified and this check might involve interactions with other services (e.g. for payments we need to query Verify). We consider this a necessity of the SCA flow, and we do not expect a significant performance degradation.

Developer Impact

None.

Data Contracts

Not applicable.

Data Sources

Not applicable.

Deployment

At the beginning the SCA flow for payments will be rolled out only for the Mobile App client (payments submitted throught the Mobile App).

Dependencies

None.