Transparency is an important part of Cake’s core values. We call it “lead in the open”. That’s why it goes without saying that we like to explain in all transparency how we deal with security.
Offering any service or product involves operational and safety risks. That’s just the way it is. Because we work with sensitive information, the privacy and security of our users’ data are especially important. We have therefore made it our top priority. However, you don’t have to take that from us just like that. It is too important! That’s why we like to explain how we work and what security measures we have built into our way of working.
Supervised by the National Bank of Belgium
Let’s start by explaining once more the legal framework within which we operate.
You as a consumer are the sole owner of your bank details thanks to the European PSD2 regulation. Until recently, the banks had the exclusive right on payment transactions. In order to break the dominance of the banks and to encourage innovation in the financial sector, Europe has partly shifted the control of the bank data from the bank to the customer.
So now European consumers can ask their bank to share their data with other companies, like Cake. After all, it’s your data that matters and that’s up to you to decide.
Because it concerns bank data, an extra security has been built in and banks are only allowed to pass on data to companies that have obtained a license from the financial supervisor. In Belgium this is the National Bank of Belgium (NBB).
Cake received a license as a payment institution from the NBB on 9 July 2019, and so we are also regulated and controlled by them. This means that we have to comply with the financial legislation that applies to European payment institutions.
This is one of the reasons why we employ a compliance officer, Olivier. And periodically we are audited by an accredited internal auditor and an accredited revisor. Each year, we must provide the National Bank of Belgium with more than 30 different reports, of which a comprehensive overview of the possible risks and the measures we take to limit these risks. This is the so-called report on “IT, Operational, Security & Business Continuity”.
Safety first, right from the start
When we started Cake, we made sure safety was built in right from the start. Where many companies see security as something that will be added afterwards. For us, this was part of the construction.
Cake’s entire IT infrastructure is what is called cloud-based. A cloud infrastructure means that we don’t have our own servers nor hardware but make use of an external provider that offers this service in the cloud.
If you want to know more about this you can also read this interview. The infrastructure is hosted by Amazon Web Services (‘AWS’). AWS provides services to millions of companies around the world and thanks to their economies of scale, they are always up to date with the most advanced new security methods. We apply the best practices and recommendations for keeping our infrastructure secure and regularly evaluate this by technically auditing our environment in real-time. If you are interested in all the technical details – nerd alert – this includes the use of VPC’s, encryption at rest of all data, restricting access through IAM. 🤯 And a 100 more security compliance checks we use to maintain our infrastructure.
When exchanging information, we ensure that this is always done via secure channels.
In the event that information is nevertheless released, a so-called “data breach”, an extra security is built in. The chance of something like this happening is extremely small, but it is important to be prepared for everything anyway.
This extra security consists of making all data of Cake users unrecognizable from beginning to end. We do this by applying encryption to all the data. This data can only be decrypted with a security key that is stored elsewhere. It wouldn’t be wise to put the key of the safe next to it. 😜 This also means that all information in the app is permanently unreadable for people (Cake employees or users) and external applications. Only via the necessary permissions on the Cake application this information can be made readable again for use.
Compare it to a car with tinted windows. 🚙 When we transport data between our database and the Cake user, we do this via an “opaque” secured layer. This ensures that you cannot see who is in the car. Suppose someone smashes ⛏ the window to look inside the car, then you will see that the passenger wears a mask 👺 and is therefore unrecognizable. The latter is encryption, the first is security of your transport channel.
The chance of a safety problem occurring is extremely small, but we do of course have to continuously test whether all safety measures are still working properly. From a car that you rarely use, you also want to be very sure that it will work in case you need it urgently.
That’s why we continuously run a series of automated security tests with the aim of detecting and monitoring security risks in the application. If, thanks to the test, we detect a possible error at an early stage, the risk is again reduced.
But because we don’t just want to rely on our own tests, we also schedule a test once a year by an external party. This is done manually and not automated. The annual inspection by specialists, so to speak.
We also open our app for a “bug bounty program” where we even ask specialists (actually hackers) to try to hack into our systems. This is especially important because we make a new version of our app every week, so we want to have permanent insight into possible risks.
This way, we work on our security every day, both inside and out.
Because we can never be sure enough, we also have a backup. A replacement car, so to speak. It makes sure Cake can keep running even if there’s a problem somewhere.
The entire Cake infrastructure is hosted by Amazon Web Services on 2 different locations: Frankfurt and Ireland. And at each location in different datacenters, many kilometers away from each other. If there is a problem at one location, we switch to the second datacenter. If Frankfurt fails completely, then we will switch to Ireland and vice versa.
We also have a strict access rights policy. A difficult word to say that as a Cake user or Cake employee you only have access to what you really need, and no more than that.
As a Cake user you only have access to your own data through the Cake app and not that of other users. That makes perfect sense.💡
Based on your identification data, a unique customer identity is created. For those who really like to know all the details: we do this through Amazon Cognito.
Cake employees only have access to the things they need to do their job or for a specific reason. In this way, each employee is individually determined which access he or she needs.
The access for the employees is done through an authentication procedure of OneLogin. This login actually confirms that employee Smith is indeed employee Smith. After authentication via OneLogin, the system (Amazon IAM/STS) checks which data and functions employee Smith has access to. Logs are also kept in order to be able to check afterwards who had access to a certain database, when and why.
Someone from the marketing or sales team, for instance, will have far fewer accesses than a data scientist who develops models for enriching transactions in the app.
We also have to take into account attempted fraud. By both employees and Cake users.
At Cake, we work with actual people. We really do. 👨👩 You can get to know them better here. And where people work, human mistakes can also happen.
We limit this risk by means of two specific measures.
Firstly, the application of strict access rights policies to Cake’s IT systems, as described above.
Secondly, through a monthly check on the allocation of Rewards.
This is because we have to make sure that our employees do not wrongly assign Rewards to themselves.
Rewards are automatically assigned by Cake’s IT system. After executing a payment transaction that qualifies for a Reward, the Reward is automatically assigned by the Cake system to the Cake user who made the payment. This does not involve any human intervention and therefore the risk of errors is virtually non-existent.
In addition, the IT manager, Pieter, performs monthly checks on all awarded Rewards, checking which Rewards belong to which expenses, and whether the amount of the Rewards corresponds to what was determined by the commercial partner when launching the Rewards action. ✅
If any discrepancy arises, it will be investigated. The audit by the IT manager is then checked again by the Head of Legal, Yves. ✅ And the audit of our Head of Legal is checked by our auditor. ✅ To be really sure. Check and triple-check!
Additionally, employees or freelancers who suspect fraud by a colleague can report this anonymously via an internal whistleblower system or an external reporting point with the supervisor.
But we must also take into account possible fraud by Cake users. This could involve, for example, attempted money laundering or terrorist financing or the misuse of the Rewards system. We assume that most of you do not intend to do this. 👼 But to keep an eye on the rascals, we’ve taken our precautions there, too. Also our commercial partners wouldn’t like to see the Reward system abused.
If you have already claimed Cake Rewards you know that at a certain point we ask you to take a picture of your identity card. This is an annoying step, but we are legally obliged to do so.
We must identify and accept everyone according to our acceptance policy. This means we have to do certain checks to see if there are users on national or international sanction lists, if they are a Politically Exposed Person (PEP), or if they live in a country on the EU list of countries with an increased risk of fraud.
Once accepted, we are also required by law to carry out ongoing checks on a permanent basis. These checks verify that there are no suspicious transactions or frauds with Rewards. We have devised all kinds of rules for this, which are automatically checked and, if necessary, put under a magnifying glass by our compliance officer.
Protection of personal data
Cake’s commercial partners have access to anonymized data of the Cake users. And to ensure that this data can never be traced back to an identified or identifiable individual Cake user, identity and transaction data are stored separately in dedicated, encrypted databases that are only accessible according to the strict access rights policy (see above). You can read exactly how we do this here.
Of course, commercial partners never have direct access to databases. They have access to a securely closed platform (the Cake for Business platform) where they can consult statistics and reports created from the anonymized transaction data of all Cake users together. Currently we have over 2.7 million transactions in our database for a total value of almost 900 million euro. In this article you can read more about what we deliver to commercial partners.
For some services we also engage with suppliers and third parties. We impose the same conditions on them in the selection of and in the contracts with these partners. We work for instance with Ibanity (for the connections with the banks), with Looker (for the development of data analysis and dashboards), …
Last but not least, we also have to make sure that everything we have described above actually happens. For this, there are no less than 3 control mechanisms in place.
The first control lies within the IT systems of Cake itself. The systems keep an eye on everything and generate automatic notifications in case of possible infringements.
The third control is the internal audit of Cake. The controls of everything described above are included in the audit program of the internal audit. These audits are spread throughout the year. The last internal audit dates from February 2020. But in the meantime, the next ones have already started.
🚀 Did you know Cake was awarded Belgian Startup company of the Year? 🥳
Read all about it in this article.