Security White Paper — A Detailed View on Numbrs’ Approach to Security

At Numbrs, the security and protection of our customers’ data is our number one priority. With the security measures we have implemented, we can strictly protect and control the flow of customer data whilst simultaneously guaranteeing the kind of secure and seamless user experience that is expected from a first-rate Smart Wallet app like Numbrs.

These security measures are implemented at all stages of development of the Numbrs app from the earliest conceptualisation to regular app updates. As such, these measures are not solely undertaken by our dedicated security team but are part of our overall company strategy and culture.

The following article provides a detailed account of Numbrs’ approach to security in designing, maintaining and updating the Numbrs app

We are hiring:

Senior Security Engineer – Remote
Security Engineer – Remote
Head of Software Engineering

Engineering Manager
Machine Learning Engineer
Senior Product Owner
Product Owner

People: where it all starts

The weakest link in any security system are the people who build and maintain that system. Security vulnerabilities ultimately come down to oversights made by the people who design and/or implement a system. Therefore, hiring the right people is critical to ensure the right security culture is created within the organisation, especially within engineering.

This process begins with the engineers who write the code that makes up the Numbrs app. As part of our hiring process, all potential candidates are asked security-specific questions pertaining to cryptography, secure app design and other common security concerns. The results of this process contribute significantly to our overall decision-making process, ensuring that every engineer hired has a solid understanding of security, thereby enabling our actual security team to focus on more advanced security aspects of the app.

Once hired, every staff member must learn Numbrs’ security policy and go through a comprehensive security awareness training session followed by an exam to ensure that they understand the policy and its relevance to the company’s security and its users. Key topics such as customer data privacy, data security and phishing awareness are covered.

Unlike most companies that do no not have a dedicated security personnel (or may perhaps have an engineer who handles security topics), Numbrs works with a dedicated team of full-time security professionals who work closely with engineers, UX and third parties to ensure that we are building security into the core of our app and not just as a mere addon that is patched-in just before product release.

All of our security engineers are proficient in software development and thus understand the point of view of the developer.

All of this is crucial to getting security right; by ensuring that the security team is engaged from the point of conceptualisation of a new feature through to its release, we significantly reduce the prevalence of security-relevant bugs in the product.

Building a secure product

Our security team is actively involved from the point of conceptualisation of a new feature. The security team works with our UX department to ensure that the flow of the feature handles scenarios that may put user data at risk. Some of our driving questions at this stage are: What happens if the user places the Numbrs app in the background during a critical step? What if the user’s phone is stolen at this exact moment? What if malware is running on the device or what if someone reverse-engineered the app and is targeting our back-end? All of these questions and many more are considered to ensure that the design of the user experience reflects these aspects.

When it gets to the technical design of the solution, our security team is once again involved. They work hand in hand with our architects and engineers to consider how the flow of data, credentials, tokens, etc. function within the broader architecture and the potential risks along the way, from advanced external attacks through to theoretical insider threats.

As soon as security signs off on the design and implementation begins, automated tooling runs to flag code changes made to areas of code that have been marked as security-relevant (e.g. handling credentials, performing encryption, etc.) in addition to the usual automated tests that look for low-hanging fruit. If anything raises concerns, security is in touch with the relevant and engineers and discussions are held about the potential risks and the necessary improvements to the code.

As the planned release date approaches, the security team puts its “black hat” on and starts testing the release. The complete app is tested to ensure that any collateral changes to the code that may impact security are also tested. Testing consists of a combination of automated tooling plus creative white-box penetration tests that attempt to simulate sophisticated attack scenarios by someone with intimate knowledge of the app. Not a single release is delivered to users without a security sign-off.

Throughout this process, the security team is not a “policeman” that blocks each step, but a partner and collaborator who maintains an open-door policy, helping the business deliver a quality product to our users at each step of the way. We believe that this is the only way such a process can work.

Numbrs app security

Thus far, the focus has been on how Numbrs ensures security throughout the development of the Numbrs app. However, just as important are the actual technical elements within the app itself that are leveraged to maximise security. The following is an overview of the Numbrs application’s high-level architecture.

Standard across all devices is the use of network-level encryption which is performed using industry-standard TLS with ciphersuites based on RSA-2048 or higher, AES-256 and SHA-256 or higher (the selected ciphersuite will depend on what is negotiated between Numbrs’ servers and the user’s device).

Certificate pinning is implemented for all network connectivity between the Numbrs client application and the back-end. The server certificate is what is pinned, not the Root CA, which also mitigates the risk of the Root CA key being compromised.

This is implemented to ensure that the client is not susceptible to man-in-the-middle (MITM) attacks, although this, of course, makes it more challenging and expensive for us to keep the apps updated with the latest certificate for the back-end.

Pinning is a key aspect of our security model. Properly securing data in transit with mobile devices is difficult to achieve, and apps that do not utilise certificate pinning are highly prone to man-in-the-middle attacks. By ensuring that our users connect to their bank through our infrastructure utilising certificate pinning, we can provide a higher degree of assurance that the data is protected in transit and is actually going to their bank and not to an attacker who may have compromised the user’s Wi-Fi connection, DNS or other local infrastructure.

To deal with the architectural differences between iOS and Android devices, different approaches are taken to securely store data on the device and perform application-level encryption. Nevertheless, the approach remains consistent on a fundamental level: Encryption is used to encrypt data stored locally on the user’s device and additionally for application-level encryption on top of TLS to the Numbrs back-end.

On iOS, the Keychain (a physically controlled security mechanism native to iPhone devices) stores various encryption keys used for the encryption of banking credentials, chat messages and other data as an additional layer of encryption beyond the TLS encryption mentioned above. This is done to ensure that even in the unlikely scenario of the TLS encryption being compromised, the transferred data would remain protected. The key used for the encryption of such keys is tied to the security code only known by the user and is stored on the Keychain.

Once unlocked, encryption keys and unencrypted data are only kept in memory while the app is in the foreground;. Once the app is placed in the background or closed, the key(s) and data are no longer in memory and can only be retrieved once the security code (or TouchID/FaceID) is entered by the user.

On Android, application memory holds a dynamically generated RSA encryption key (tied to the security code of the user) that is used to encrypt other various encryption keys.

Finally, when a user logs out of the app or deletes it, all temporary data stored in this local database and encryption keys stored in secure storage are deleted from the device.


Starting from the bottom up, all of our infrastructure where customer data is stored and processed is located in Frankfurt, Germany. We ensure that the provider(s) we use are independently ISO 27001- and PCI-DSS-certified so that we can be confident that the physical aspects of security are taken care of.

Our backend components sit within their own network segments, with communication between components only permitted where it is strictly required. All components sit on internal, restricted networks that are not directly accessible from the Internet. Additionally, all communication between these components is TLS 1.2 encrypted. Access to the infrastructure is only possible from two points: the API available to the front-end applications (, which only exposes port 443 (TLS) to the outside world. The other entrypoint is a bastion server used for administrators to connect to for remote administration over SSH, enforcing two-factor authentication.

All the systems that we use are Linux-based. The components are running within Docker containers within a Kubernetes cluster that is enforcing isolation between them, with network policies restricting outgoing communications. Deep monitoring is implemented across all servers, with logging performed centrally, monitored and alerted on in real-time.

Access to administration of the environment is only possible via restricted environments which require two-factor authentication over SSH. The servers themselves are patched automatically and regular vulnerability scans are performed to detect unpatched vulnerabilities or other security configuration issues.

Payments: bank security

When it comes to payments, Numbrs leverages German banking security (specifically, the “TAN”) to authorise transactions. Banks require a second factor to be provided when payments are made, and this cannot be bypassed, even by Numbrs. That second factor may be an SMS message directly to the user’s phone, or be a device that looks something like this:

What this means is that Numbrs cannot perform payments on the user’s behalf. Even if Numbrs experienced a security breach, attackers still cannot perform payments on behalf of the user because the use of a TAN device is required.

Data Protection

In reference to the implemented network segmentation earlier, not only do we segment within the network environment but our whole production environment is completely segmented from testing environments as well as from our office environment in Zurich.

With the exception of what users explicitly share with our support and store staff, no user data is stored or processed in our office environment.

The data that we do store is pseudo-anonymised. This means that we break up personally-identifying data into different locations in our infrastructure, so that the task of reconstructing it by an attacker would be technically challenging. Before such data is available to our data scientists, it undergoes a process of anonymisation, stripping out names, bank account numbers, e-mail addresses, etc. to ensure that this type of data remains protected and private to our users.

Furthermore, all data is encrypted at least to two levels while stored — from full disk encryption on the servers themselves to database-level encryption. For some data, there is a third level of row-level encryption. When transported over the network it is further encrypted using TLS, and when temporarily persisted to the phone it is also encrypted as detailed above.

Only a few carefully selected employees (site reliability engineers and security engineers) have access to the production server environment. All of their activities are logged, monitored and they must perform two-factor authentication to be able to access the environment.

External verification

It goes without saying that the possibility of missing something is always real, which is why we have been engaging highly skilled and experienced third parties to perform black-box penetration testing against the Numbrs application and the back-end every year and now every six months. In the last three years, no test uncovered any critical or high vulnerabilities, meaning that customer data has never been at risk.

Our implementation of KYC has led to additional external audits, which involved not only a review of our technology but also of our business processes. The audit was completed with no non-conformities detected.

We will also be introducing a bug bounty program, which will broaden the scope of skilled security people attempting to find security bugs in the application, offering them financial rewards in exchange for findings.


Numbrs is committed to ensuring user data safety with the help of leading security and data protection technologies designed to safeguard personal information and ensure a bug-free user experience.

As such, security is built into every aspect of the Numbrs app. From the drawing board to release and regular app updates, state-of-the-art approaches to data storage and industry-leading encryption technologies ensure that user data remains safe at all times.

This approach is not solely carried out by our dedicated security team but is maintained and practiced by everyone working at Numbrs who understands that security is key in the financial services industry.

Regular auditing, training and active monitoring of new potential security issues and threats will guarantee Numbrs’ ability to defend against intrusions in the future and continue to provide optimal experiences for its users.