​
Context

These operations are available through multiple platforms and third-party-integrations maintained by Olinda for the sake of their customers:

Each of these public entry-points further communicates with a number of backend HTTP endpoints in order to perform specific business functions.

​
Multi-factor authentication

Clients are required to choose a password that respects the following constraints:

  • 9 characters minimum
  • Complex enough to pass an algorithmic strength test

These rules are in accordance with the NIST 800-63b directive.

Furthermore and in compliance with PSD2, customers are required to set up a second authentication factor in order to approve sensitive actions (login, payments and so on). Each validation screen on the phone contains enough context (e.g., IP address in the case of Login or beneficiary IBAN in the case of transfer) to allow customers to make an informed decision and detect any suspicious activity.

​
Web application firewall

All of Qonto’s public endpoints are protected behind a Web Application Firewall (WAF), that provides the following security measures:

  • Rejection of malicious requests
  • Blockage of requests exploiting Web application vulnerabilities
  • Blockage of requests issued from suspicious IP addresses
  • DDOS protection

​
Encryption and data confidentiality

Communication between customers and the Qonto application are encrypted using publicly trusted TLS certificates supporting strong encryption and hashing algorithms.

​
Server and application hardening

We automatically update all of our software, packages and servers to guarantee the security of the components running the Qonto application.

Servers are configured to only contain the packages required to run our applications therefore minimising the attack surface. We follow all the hardening guidelines provided by the international standards such as NIST 800-123.

​
Security assessments

Every code change submitted to the Qonto application is scanned for vulnerabilities and malicious packages. The code is also submitted a human review and must pass non-regression tests before deployment.

Qonto calls on a specialised third party auditor to perform annual security assessment. The result of this assessment is shared with the Executive team.

​
Backup and resiliency

Customer data is backed up in AWS S3 along with the guarantees that this service provides in terms of durability.

The Qonto application is actively running in three AWS datacenters around the Paris region insuring that no single point of failure could impact our quality of service.

We perform an annual business continuity plan where we simulate in real conditions the failure of a critical component and stress test our technical mitigations and process.

​
Qonto’s internal security

On top of the protections mentioned above, Qonto employs many more security measures to protect the infrastructure against various threats:

  • Phishing-resistant multi-factor authentication (WebAuthn) is mandatory for all employees
  • Fine-grained access control coupled with the least privilege principle
  • Detection of suspicious behaviour covering all our critical tools
  • An infrastructure described as code to easily identify all assets
  • Ephemeral access
  • Encryption of all datastores

​
Security certifications

As a payment institution authorised and supervised by the ACPR, Qonto is subject to many regulatory requirements mandating strong security commitments:

Qonto was certified ISO 27001 in July 2023 on the e-invoicing scope.

​
Third party access through the open banking API

In compliance with PSD2 requirements, Qonto is mandated to provide an open banking interface to licensed entities (aggregators, accounting software, and so on). Customers can access their Qonto data through licenced payment services providers thanks to the integration of this interface.

Each partner may request one or several scopes to make their integration work: access to the balance, transactions, attachments and so on. Their detailed permissions are presented to the customer upon installation of the integration. See the screen below for an example:

OAuth 2.0 consent screen

Each integration may establish its own frequency of access and data synchronisation to suit their provided service.