Introduction

In today’s digital-first economy, the web is the critical touchpoint between people and their money. At Revolut, we embrace this reality in our approach to web engineering: focusing on not just building interfaces, but on creating seamless, secure, and future-proof financial experiences.

Our mission at Revolut is to redefine the global standard for digital finance. Every line of code, design decision, and feature we release serves this goal: to make finance more accessible and beautifully engineered.

These principles shape our culture, set a high standard for excellence, and require constant attention to detail. They also drive us to rethink modern web development tools and practices.

This article focuses on the principles that help us deliver secure, beautiful financial products worldwide, and explains how engineers are building their careers along the way.

The scope of Revolut web products

Two independent but complementary pillars represent the current stage of the Revolut web ecosystem.

Customer-facing applications
These are the digital gateways through which our customers and partners experience Revolut directly:

Main website and brand hub

Revolut Business platform

Revolut crypto exchange platform

Human Resources Management Systems (HRMS) by Revolut

Each of these touchpoints is an individual part of a unified ecosystem offering a consistent product experience that is closely aligned with our mobile platform.

Internal web products
Alongside our external platforms, Revolut operates around a hundred internal web applications. These provide our employees, operations, and partners with tools for:

• Back-office management
• Compliance and risk monitoring
• Customer support services
• Data and reporting systems
• Operational efficiency at scale

These internal tools are the driving force behind Revolut, ensuring customer-facing products remain fast, secure, and globally scalable

Core principles of web engineering in Revolut

Principles set the direction. Practices deliver the results.

Revolut’s web ecosystem is built on scale — nearly a hundred independent applications, all evolving to meet the demands of a fast-growing business. To keep pace, we run on small, empowered teams that take ownership of entire services, driving speed and accountability.

Our approach is guided by clear engineering principles and shaped by modern agile practices, inspired by eXtreme Programming (XP). However, principles alone aren’t enough. We amplify them with critical practices that turn vision into execution and impact.

Together, these principles and practices form the framework that lets us ship fast, adapt to hyper-growth, and never compromise on quality.

Now, let’s look at how these ideas translate into real-world solutions.

Adapting to hyper-growth

Build systems that can explain their own evolution.

As the business grows rapidly, so must our codebases and teams. Designing for change means designing for the future as well as the present. It’s structure that promotes scaling, not the other way around. In practice, this means:

• Code should explicitly reflect current business needs — no more, no less. Domain-Driven Design (DDD) helps us organise the code on the frontend in a way that keeps it aligned with the domain. While there are many books on this topic, almost all of them focus on backend implementation when it comes to ‌tactical patterns. We adapt these ideas for the frontend, applying bounded contexts, clear models, and explicit contracts to ensure that our codebase mirrors the business as it evolves. This way, the system itself becomes the most reliable source of truth, guiding both engineers and stakeholders.
• Treat types as executable documentation — every type in your codebase is a specification that guides developers, prevents errors, and accurately documents intent. Your types are not just safety nets. They’re the clearest, most reliable form of communication between engineers, designers, product owners, and machines. Design your types so that only correct, meaningful states are possible. We love to use type NEVER a lot, as it makes the invalid states unrepresentable. These “type guards” turn runtime errors into compile-time guarantees, ensuring that every path the code can take is intentional, safe, and self-documenting.
• Systems must fail loudly and clearly when new, unsupported states appear — unexpected inputs and impossible branches should trigger explicit, actionable errors rather than silent degradation. We enforce this by validating every external boundary (APIs, configs, feature flags) at runtime (we’ve bet on Zod), aligning schemas with our TypeScript types. Hence, the same contract guards both compile time and production;
• The system itself should guide its future evolution — the architecture, components, designs, and type system of our web platform act as a map for growth. By embedding conventions, designing tokens, and sharing libraries that strictly rely on the centric UI-kit library, we ensure that every new feature aligns with established patterns, marking the path of least resistance for growth and evolution.

Never compromise on quality

Build trust through correctness and clarity.

In financial products, quality is the foundation of customer trust. A bug, security gap, or broken flow can impact people’s money directly, leading to reputational and regulatory risks.

• Make quality everyone’s responsibility. At Revolut, we don’t have dedicated QA engineers. Instead, we see this as a strength. Engineers design, build, test, and monitor their products themselves. They provide engineering expertise in writing code, and also in testing it. This tight ownership creates a direct feedback loop, fosters a culture of accountability, and ensures that quality is built in from the first line of code — not inspected at the end.
• Ensuring stability on components, features and product levels. Our testing approach is built around Playwright and Jest, including unit, functional and production e2e types of tests. It allows us to automate end-to-end scenarios confidently, ensuring that key user flows work as expected across browsers and platforms. This helps us catch regressions early and maintain stability without slowing down delivery;
• Sensitive production monitoring is a part of the quality loop. We complement the automated testing approach with a continuous production monitoring system, ensuring quality doesn’t stop at release. We identify, debug, and resolve production issues with Sentry. Sensitive alerts notify our engineers of every issue occurring in production, enabling early detection and rapid response. They help us catch edge cases that slip past automated tests and manual validation, often before users notice or report them to customer support. This proactive approach is essential for maintaining trust and minimising impact, particularly in an environment where the engineering team is responsible for quality from start to finish.
• Fixing a bug is just the first step. Outstanding quality means using every issue as an opportunity to improve the system. We treat each bug as a chance to uncover gaps, strengthen our architecture, and prevent similar problems from happening again.

Quality concerns are always the top priority. They’re non-negotiable in code reviews, routine planning, and the shaping of engineering strategy. No matter the pressure, we never trade quality.

Built to ship fast

Speed comes from clarity, not shortcuts.

Velocity doesn’t mean skipping steps. It means eliminating friction and building systems that facilitate safe and rapid execution.

• Types as the first line of testing. When the types mirror the business rules they become the immediate quality guards with the instant feedback, catching issues before tests even run. This accelerates development times and shortens the feedback loop. This makes iterations faster, reduces wasted cycles, and helps teams ship with confidence.
• Standards are the foundation of a true ecosystem. We simply don’t do custom styling in our projects. Together with the central design system team, we develop robust, resilient UI patterns. The patterns are translated into ready-to-use components stored inside a centralised rich Uikit library. This means that every new design decision becomes a standard available for every project.
• Developers should solve business needs, not fight code complexity. We reduce cognitive overhead, automate the boring parts, and let engineers focus on what matters. The frontend platform team builds technical solutions that simplify product development across Revolut. Our internal frameworks and tooling provide a ready-made foundation, so new services launch with everything needed for growth and maintenance.
  In other words, we’ve built an orbital launch station for projects — allowing teams to start from orbit, not from the ground, and accelerating delivery and innovation across the company

These principles are a shared compass for engineers. Revolut is all about innovations, but everything we build must support clarity, resilience, and confidence.

🌟 Excellence through people

World-class products can only be built by world-class people

Engineering principles are like cookbooks: they provide the instructions for creating reliable, scalable, and innovative products. But it’s people who bring those recipes to life.

• Hire A-Players. A-Players are more than technically skilled. They’re impact-driven, adaptable to change, and raise the performance bar for everyone around them. At Revolut, our interviews place candidates in real-world scenarios, asking them to implement features standard to web engineers, the solutions they probably did this week in their current job. We don’t focus on cracking obscure JavaScript puzzles (like figuring out how 0.1 + 0.2 !== 0.3), we don’t ask “How many golf balls fit in a school bus?”, we value the way of solving the practical tasks (think deeper), the ability to deliver solutions end-to-end (get it done), and the sense of perfection that drives excellence (deliver wow).
• Grow A-Players. Impact creates leaders. We foster engineers at Revolut who make an impact and empower their strengths. At any seniority.
• Empower A-Players. High performers need trust and ownership. With autonomy, they move faster, take responsibility, and lift the whole team.

When put into practice, our principles shape a culture of clarity, ownership, and innovation. Company-wide patterns enable developers to move fast with confidence, collaborate seamlessly, and continuously raise the standard of web products. This culture isn’t accidental — it’s the natural result of aligning philosophy with execution. It enables Revolut to scale web engineering to hundreds of people, hundreds of products, dozens of teams, and millions of customers moving billions of dollars.

Tech stack

Legacy is valued. Progress is mandatory.

Revolut is now a well-established company with a history spanning more than 10 years. It was founded in 2015, just a year after React 0.12 was released. Over this time, we’ve accumulated a wide range of solutions, approaches, tools, experiments, and lessons learned.

We treat legacy with respect and don’t rush to rewrite entire products every time a new library version is released. Instead, we follow a structured process to ensure that dependencies are updated in a timely manner across all systems. When a new version of a core or widely used library is issued, we first upgrade it in a specific project. Once stability is proven, automation triggers update requests across all dependent products.

This layered approach keeps our stack unified, up to date, and — most importantly — adaptable to change.

Our tech stack is well known in the web engineering community, and we work to keep it clean, light, and modern. We run on the latest stable releases — never more than one major version behind — ensuring consistency and adaptability across all products.

• Typescript — latest stable (within 1 major version)
• React, React Query — latest stable (within 1 major version)
• Bitbucket for code storage
• TeamCity for build management (CI/CD)
• Rush and NX for monorepo management
• Sentry platform for error tracking
• Kubernetes for automated app deployment, scaling, and management

For testing we use:

• Jest
• Playwright
• Storybook
• React testing library

Engineering with purpose

Our philosophy is to let the code reflect the business, let the system empower the team, and let mistakes guide the future.
We believe in people, and their ability to grow to shape the future.
But we also believe in balance — respecting the past, while building for what’s to come. These principles encapsulate the essence of web engineering at Revolut: confident, flexible, and driven to set new standards.

Join Revolut

Make an impact at a global scale

At Revolut, there’s always room for talent.
We don’t define your journey for you. Bring curiosity, drive, and ownership, and you’ll shape your own path while making an impact on a global scale.

Our ecosystem is a unique opportunity for web technology — built for massive scale, the highest quality standards, and the ambition to keep pace with a fast-growing business.

Want to shape what’s next in finance?

See where you can make your impact at — Revolut Careers.

Building the Web that Moves Money: inside Web engineering at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Revolut is known for its innovation in delivering “super-app” financial services to its customers. The success is evident not only through the rocketing user growth, but also via the ripple effects caused across the banking industry — traditional finance has to reinvent and evolve, or remain part of history, just like the internet search replaced the paper phonebook.

Behind this success stands a complex and impressive machinery, which is still piloted by the same founders, who also engineered the very first components and set the Revolut rocketship in motion.

This machine is mostly known for its software excellence, however, with any financial services comes the responsibility of navigating a complex net of regulations and risks. True to the company values, the Risk function at Revolut also innovates, leveraging the decades of banking experience of its leadership and adding the challenger way of thinking with the latest technology.

What is Risk?

One can find many definitions of risk, ranging from explanations suitable for children, “The possibility of something bad happening”, to advanced statistical definitions used in finance:

Uncertainty of the return on investment, characterised by standard deviation, asymmetry and tails of the return distribution

and the generic ISO 31000 definition:

“The effect of uncertainty on objectives”

In addition, both graduate textbooks and banking regulations define two general types of risk:

• Financial: related to financial positions, such as: user deposits, lending, and investments in market instruments.
• Operational: related to failure of operations, such as: system outage, fraud and natural disasters.

Some of you might already sense the inevitable challenges in distinguishing the above definitions and risks. Events seldom happen in isolation and independently: a natural disaster can lead to system outages and market crashes, similarly fraudsters might use fake accounts to withdraw loans which would never be repaid. Finally, sometimes adverse events just happen simultaneously even without having a common cause.

Problem statement

Financial institutions estimate and manage risk in large, segregated departments specialising in their own risk type. For example, the operational risk department has teams specialising in fraud and technology failures. The market risk department has teams focusing on risks stemming from investments in bonds or derivatives. To make it even more complicated, model risk teams oversee the possibility of all of the other teams using inappropriate techniques in estimating their risks — leading to the risk of risk, or something like risk squared.

The above approach leads to methodological silos of how risk is defined, monitored, and estimated. Although the underlying probability theory is the same, the financial and operational risk departments might have broadly inconsistent approaches and even diverge in their views of the same risk event or double count some of the risks. This prevents accurate view and management of risk on enterprise level.

Note that this legacy banking set-up is not the result of some careful consideration of all possible risk types and the optimal way to oversee them consistently. It is simply the result of old banking, tree-like structures which kept appending new teams and systems for tackling the risks from new products and regulatory requirements.

Solution requirements

If we imagine a new type of Enterprise Risk Management Framework (ERMF), what features should it posses in order to solve the above problems?

1. Scientific: Use scientific principles as universal and reusable building blocks that can define any risk, but also be shared across multiple risks.
2. Measurable & Comparable: Enable calculation of a standardised set of metrics for each risk that can be compared and combined across risks.
3. Hypothetical: Allow for risk to be defined as a hypothesis of something that could happen, even when no observed data is available.
4. Data Driven: Link the risks to live data sources in order to enable monitoring against data of observed business events, with the ability to monitor for any events that are missing in the currently defined risks.
5. Learning: Update the hypothesis (requirement 3) based on the difference between expected and observed data.
6. Explainable: Be able to explain and decompose any result of calculated metrics (requirement 2) to all components that lead to its derivation, including data inputs and logical rules. The generated audit trail will be extremely valuable during regulatory, audit, and validation exercises.
7. AI assisted: Enable interaction via natural language with the defined risks and the audit trail of the calculated metrics, we can call this functionality Risk to Text. Equally important is the ability to generate risks, from natural language descriptions such as regulations or expert reports, we can call this functionality Text to Risk.

Reinventing Risk

How NOT to do it

Legacy risk frameworks often start from high-level, top-down definitions such as risk types, controls, materiality, risk appetite, and so on, without clarifying their relations or defining first the common ground concepts that they share.

Thus, you end up with a framework in which you have a lot of high-level concepts which seem to be expert knowledge, however, when you drill down you find most of them overlapping or even contradicting each other. The culmination of this approach is usually a tree structure called Risk Taxonomy of different risk types and subtypes, here is what the Open Risk Manual says about issues with this approach:

“Risk types in practice may exhibit significant overlap either due to poor definition or due to the fact that a complex Risk Event intrinsically maps to multiple risk types”

How to GET IT DONE

A general principle is to define as little as possible concepts unless they are based on our scientific building blocks, or if I may quote a famous electric car enthusiast “The best part is no part”.

We will start from the bottom-up and if a more specific concept cannot be derived from the building block, then either our foundation is not good or the concept is not needed at all.

Building blocks = events

Our choice of building block is the event, with the following arguments:

1. The natural way that risk is usually thought of and described by humans typically involves events: “The risk that in the event of …”. This increases the ability to satisfy requirement 7, and the translation of risk to and from natural language.
2. Risk estimation is heavily reliant on probability theory for things like frequency and severity distributions, both of these are always in terms of specific events such as risk incidents that lead to losses. This is consistent with requirement 1 for using scientific building blocks.
3. Modern IT systems are to a large extent event-driven, in order to deliver live information on things like news and stock prices. By making our risk framework event-based, we are opening the door to seamless integration with the data sources and live monitoring of our risks, based on specific business events. This is consistent with requirement 4.

The way we will think about an event is quite general, in terms of the event leading to a transition between two states over a period of time:

The main benefit of this is that we can stack any number of events and states into a network/graph of things that may or may not happen, sounds a bit similar to risk, right?

The other benefit is on the scientific side, from having the ability to perform standardised calculations over such structure. This is essentially a state space (Markov chain) representation, which is widely used in statistics. This satisfies requirements 1,2, and 3.

Risk = chain of events

Jumping straight into a specific example, one of the risks that Revolut faces is related to a user’s balance becoming negative (money owed to Revolut) and subsequently becoming a financial loss if not repaid within a given timeframe. This risk is interesting from two aspects:

1. The base risk population has the broad scope of all users with positive balance.
2. The loss of negative balances represents pure credit risk, however, some of these losses can arise due to fraud which is operational risk, hence we could have composite risk with both financial and operational risk events. For simplicity, we will include only the credit risk in the example, however the extension with additional events and states is analogous.

The main states included in the risk are: positive balance (+Balance), negative balance (-Balance), and (Lost). Where each state is defined in terms of the characteristics of the user instances. Stacking the states and the transitioning events, we obtain the following chain of events:

Transitions from a state to itself are also possible, like a +Balance staying such, but also some states can be completely absorbing like a Lost balance always remaining such. Finally, above in red, we introduce the notion of loss rate which indicates what proportion of money can be lost in a given state. For simplicity, we assume 100% loss rate only in the lost state, however, in reality there could also be losses associated with the -Balance state, for example, due to collection costs from the negative balances.

Now that we have a solid and scientific building block, let’s start making structures with it. The above chain of events is our first example of a specific risk and generalising the definition, we end up with the following single sentence:

Risk: The potential of financial loss, as a result of a chain of events, over a given time horizon

Note that apart from defining risk as a chain of events, we also require it to be linked to a tangible financial loss and have a strict time dimension. This will help satisfy requirement 2, by being able to calculate risk metrics. The financial loss need not necessarily be in absolute terms, and it could be in relative terms as opportunity cost relative to an objective, which is consistent with the ISO 31000 definition of risk.

Metrics

A main advantage of formal risk definition is that it enables the calculation of a standardised set of metrics for every risk. Back to the negative balance risk example, let’s set values for the main parameters of the risk, which can be considered ex-ante expert estimates:

• Amount of +Balances: 100£
• Probabilities of events:
  - P(stay +): 90%
  - P(become -): 10%
  - P(become +): 20%
  - P(become lost): 80%
  - P(stay lost): 100%

Maximum loss

The first and most trivial metric is worst case scenario loss, knowing that all probabilities above are just ex-ante expectations one can ask: what is the most I could lose in the worst case scenario? In our simplified example, this will happen if all £100 of positive balances become negative and then lost, leading to a loss of £100 * 100% = £100.

Expected loss

Now let’s try a more sophisticated metric in the form of Expected Losses (EL or ECL). For this, we will need to define a time horizon, e.g. whether we form our expectation over 1 or 10 periods, and we will need to iterate over our ex-ante expectations. To keep the example simple let’s consider 2 period horizon, and starting from the +Balance state, we have the following paths at 2 period distance, where the cumulative probability along a path is obtained by multiplying the individual probabilities:

• [+Balance → -Balance → Lost]: P = 10% * 80% = 8%
• [+Balance → -Balance → +Balance]: P = 10% * 20% = 2%
• [+Balance → +Balance → -Balance]: P = 90% * 10% = 9%
• [+Balance → +Balance → +Balance]: P = 90% * 90% = 81%

In this simplified example, we can calculate EL only by considering the paths which end state have a loss rate, since all others will be multiplied by 0. This is the path ending with Lost state, with 8% probability and 100% loss rate, leading to EL = £100 * 8% * 100% = £8. Note the big difference between the maximum(£100) and the expected loss (£8) due to the probability weighting of the events in the risk.

Generalising further, the risk definition essentially gives us a generator of discrete loss distributions for any time horizon at which we want to form our expectations. These distributions are the backbone of risk theory and estimation, used even in bank regulations for calculating capital requirements. The maximum, expected, and unexpected losses are just one of the many generic metrics that can be calculated from such distributions which satisfy requirement 2.

Fellow nerds, might have recognised the embedded Markov chain in our Risk definition. This automatically unlocks the utilisation of tonnes of scientific knowledge, from things like efficiently computing n-period transitions via matrix multiplication, to advanced topics like: Bayesian inference, time inhomogeneous probabilities and probabilistic graphical models.

Observed loss

In addition to enabling the calculation of standardised ex-ante expectations about what could happen, our risk definition also enables the monitoring of actual live events and calculation of ex-post observed metrics. This means that we can form subjective expectations before we even launch a given product. However, once data is available, we can calculate losses and use this to update our initial expectations. This satisfies ‌learning requirement 5 and is dependent on having an implementation that links our abstract states to data sources (requirement 4). We will talk about this in the next section.

Sounds nice, but how would you actually do it?

The implementation requirements are becoming non-trivial, taking into account the needs of: defining high-level abstractions, linking them to data, performing efficiently recursive calculations over a large graph of rules, while preserving explainability and audit trail of the derived facts.

Reasoning

Semantic reasoning is the “inference of logical consequences from a set of asserted facts” (Semantic Reasoner). It became initially popular with the idea of Semantic Web in the early 2000s, representing the evolution of the internet from linked pages (Web 1.0), to linked apps (Web 2.0), and linked data (Web 3.0). Reasoners enjoy a new surge of popularity together with the AI hype, due to their interaction with language models in terms of adding explainability and reducing hallucination.

For our demo, we used Prometheux, an explainable AI platform for big data and distributed processing, which we used as our reasoning layer. Prometheux’s research-backed platform abstracts away our various data sources, letting us iterate quickly on a virtual knowledge graph of our data and business rules, instead of writing complex database queries or migrating data.

While other knowledge graph technologies require representing relationships as triplets consisting of Subject, Predicate, Object, (e.g. is_son(Child,Father)), Prometheux is capable of representing more complex rules based on n-tuples.

Methodology implementation

Using Prometheux, we start by implementing our new risk methodology, first specifying data models of our main concepts: State, Event, Risk. The code below defines:

1. State: something having ID and loss rate.
2. Event: something consisting of start and end State and a probability.
3. Risk: collection of Events.

@model("state","['State(ID):string', 'LossRate:double']").

@model("event","['Event(ID):string', 'StartState:state', 'EndState:state', 'Probability:double']").

@model("risk","['Risk(ID):string', 'Events:[event]']").

Next, we proceed by adding the first logical rules, for a given set of parameters: [Risk, StartState, NumPeriods], we want to calculate all paths of NumPeriods distance from the StartState and their cumulative probability. The first rule initialises the path at the StartState, with 0 periods and a probability of 1, with the parameters being provided in curly brackets {}:

risk_path_probability(Risk, StartState, StartState, NumPeriods, Events, Probability) :-
  risk(Risk, Events),
  NumPeriods = 0,
  StartState = ${start_state},
  Probability=1.0.

The second rule defines a recursion that traverses events within the specified Risk, until the NumPeriods distance is reached, accumulating the probability of every new event along the path:

risk_path_probability(Risk, StartState, EndStateNew, NumPeriodsNew, Events, ProbabilityNew) :-
  risk_path_probability(Risk, StartState, EndStateOld, NumPeriodsOld, Events, ProbabilityOld),
  event(Event, EndStateOld, EndStateNew, ProbabilityEvent), 
  NumPeriodsNew = NumPeriodsOld + 1,
  ProbabilityNew = ProbabilityOld * ProbabilityEvent,
  IsEventOfRiskInstance = collections:contains(Events, Event), IsEventOfRiskInstance=#T,
  NumPeriodsNew <= ${num_periods}.

Finally, we define predicates that store the end probability at NumPeriods distance and one that aggregates all paths that end in the same state, to get end-state probabilities:

risk_path_probability_end(Risk, StartState, NumPeriods, EndState, Probability) :-
  risk_path_probability(Risk, StartState, EndState, NumPeriods, Events, Probability),
  NumPeriods = ${num_periods}.

risk_state_probability_end(Risk, StartState, NumPeriods, EndState, ProbabilityState) :-
  risk_path_probability_end(Risk, StartState, NumPeriods, EndState, ProbabilityPath),
  ProbabilityState = msum(ProbabilityPath).

Risk register

Now that we have data models and some logic, let’s define our negative balances risk with it. In the negative balances risk, the main abstraction is the user with their Balance property. Note that the object instances used in the risk have to comply with the earlier defined data models. One of the main advantages of using a reasoner, is that upon compilation it verifies the logical consistency amongst rules and data without allowing any contradictions.

state(“Positive balance”, 0.0).
state(“Negative balance”, 0.0).
state(“Lost”, 1.0).

event("Become negative", "Positive balance", "Negative balance", 0.1).
event("Stay positive", "Positive balance", "Positive balance", 0.9).
event("Recovery", "Negative balance", "Positive balance", 0.2).
event("Loss", "Negative balance", "Lost", 0.8).
event("Stay lost", "Lost", "Lost", 1.0).

risk(
    "Negative Balances Risk",
    ["Become negative", "Stay positive", "Recovery", "Loss", "Stay lost"]
).

Data driven

Requirement 4 is for our methodology to be data driven. The above ex-ante definitions are already enough to calculate metrics like expected losses, however, without an easy way to link to data sources we can’t calculate ex-post observed metrics and update our initial beliefs, which is part of the learning requirement 5.

Fortunately, our reasoner allows us to directly bind predicates to data sources, such as: CSV, DB table/query, API. This is as simple as a single line pointing the predicate “user” to the data source, and of course, the data source is required to match the data model of the predicate:

@input("user").
@bind("user","csv useHeaders=true","disk/negative balances/data","users.csv").

In our case, the user abstraction is something with ID, Revolut entity ID, Balance, and Date. And we can imagine it being linked to a daily data source with all Revolut users and their balances. In this case, we’ve created an artificial dataset of user balance time series. Based on user data, we can derive our Risk specific states, depending on whether the balance is positive, negative, or if there has been a loss event:

user_state(State, User, Balance, Date) :-
  user(User, EntityId, Balance, Date),
  not loss_event(User, EntityId, Balance, Date),
  Balance >= 0,
  State = “Positive balance”.

user_state(State, User, Balance, Date) :-
  user(User, EntityId, Balance, Date),
  not loss_event(User, EntityId, Balance, Date),
  Balance < 0,
  State = "Negative balance".

user_state(State, User, Balance, Date) :-
  user(User, EntityId, Balance, Date),
  loss_event(User, EntityId, Balance, EventDate),
  Date >= EventDate,
  State = "Lost".

Risk calculation

Before we trigger the calculation, let’s see how the reasoner querying works. This is as simple as requesting which predicate to be outputted, then all dependencies are evaluated including fetching from the data sources.

First we initiate the parameters which in our case is the starting state, date, and number of periods. Then we output the predicates. In this case let’s explore the artificial data, and see the user states at the start date and the end date at 11 days distance.

@param("start_state", "Positive balance").
@param("start_date", "2024-12-01").
@param("num_periods", 11).

@output("risk_state_start").
@output("risk_state_end").

Now let’s output a predicate which defines how ex-ante expected loss is calculated — this will immediately trigger the materialisation=calculation of all dependencies. In this case, we can calculate expectations purely out of the risk definition and ex-ante probabilities, before we even have any actual data.

First, let’s output the end state probabilities at 11 periods distance from the starting state. Then we output the expected loss, which in this simplified case is dependent only on the Lost end state and its probability = 0.538 (all other end states have 0 loss rate), hence the expected loss of each user is proportional to their current balance ExpectedLoss = Balance*0.538

@output("risk_state_probability_end").
@output("risk_expected_loss").

Finally, using the end-state data we can calculate the observed losses, which closes the feedback loop and enables requirement 5 for learning based on expected vs actual observations:

Generalisations

Note that so far we’ve kept the example simple on purpose, however, the implemented methodology is general enough to accommodate more complicated cases:

• Apply calculations for a given Risk on a population with multiple states, e.g. if we want to calculate expected losses for the entire population of users including both those currently in negative and positive balance states.
• Calculate metrics for different time horizons — parameterised by the number of periods.
• Calculate multiple Risks for a given abstraction, e.g. a user can have both negative balances risk and credit risk if it possesses a credit product.

Explainable audit trail

So far, there is nothing that effectively differs from an alternative Python implementation and which satisfies requirement 6 for explainability.

However, our implementation choice via reasoner keeps track of logic rules and their materialised results called facts inside a knowledge graph, which can provide explanation and audit trail (proof tree) of every derived fact. Let’s take, for example, one particular calculated fact and ask for its explanation:

explain(fact="risk_expected_loss(B,8.07)")

The above fact is based on the predicate risk_expected_loss with the arguments: user B in our population and calculated expected loss value of 8.07, but how was this derived?

By default, the reasoner provides a proof tree of all predicates that were used to derive the fact selected for explanation. The proof tree is described in code but can also be visualised as a graph:

In the proof above, we can clearly see that the fact risk_expected_loss(B,8.07) was derived by the fact risk_expected_loss_rate(0.538) and the start state of the user, with the latter being further derived from a positive balance state of a user of Revolut Ltd.

The explain functionality of the reasoner satisfies requirement 6 which is extremely valuable in the financial sector where audit trail and logical transparency is of very high priority. In the risk domain, there are further benefits from explainability in delivering clear and objective methodology when assessing and controlling the risks of the business teams.

What if we want to deliver this explainability to the non-technical user and avoid code and predicates in the proof tree? Fortunately, the structured explanations are easily translated to natural language (NL) by a large language model (LLM).

Risk xAI

As I’ve previously discussed, LLMs perform pattern matching and prediction of the most likely sequence of words without having any semantic understanding of the concepts behind them. This often leads to “hallucination” which can be fun in artistic domains but unacceptable in scientific ones.

Fortunately, our use of semantic reasoner enables an architecture that solves exactly this problem. The benefit of the reasoner is that it ensures 100% consistency and audit trail, with the drawback of the latter being in the form of machine code which is not human friendly, especially at scale. In combination, the Reasoner and LLM prove to be a surprisingly good tandem.

The Reasoner can handle:

1. Data models and Rules of our Risk risk domain compiled in a fully consistent Ontology (onto-logos from Greek meaning the study of existence, in our case the existence of Risk).
2. Binding of Data sources which can be used as required Inputs in order to derive requested Outputs following our Ontology. This process is called reasoning and is used to derive new Facts.
3. Explanation of any Fact via Proof tree.

Similar to the popular use of RAG (Retrieval-Augmented-Generation) for providing additional information to the LLM, we can store our domain Ontology and any Proof tree in a Vector DB and make this information available to the LLM.

The LLM can handle:

1. Show NL (natural language) description of the individual Rules, e.g. “How is expected loss calculated?”.
2. Show NL description of the entire Ontology, including shared concepts between rules, e.g. “What is Risk and how it is defined?”.
3. Explain any fact by translating the Proof tree, e.g. “How was the expected loss of x£ derived?”.
4. Have a NL chat around all of the above: facts, rules, explanations.

The architecture above satisfies requirement 7, as we can harness the power of the reasoner and access it via human friendly NL. Now let’s see how it works in practice.

Natural language explanation

Using the LLM, we can generate a NL description of the fact risk_expected_loss(B,8.07)which proof tree and diagram we saw previously:

User B has a positive balance of 15 with Revolut Ltd as of 2024-12-01.
The expected loss for user B is 8.07, with a loss rate of 0.538

Note that the association with Revolut Ltd, is not something directly available in the fact on which the explanation was requested, this was correctly inferred by the LLM through the knowledge of the proof tree and the complete ontology from which the association with Revolut Ltd is visible.

Some might say “I can give the LLM python code and function results and it can also generate explanation” — yes, you can, but here the reasoner has the responsibility of providing 100% accurate explanation while the LLM has the task of “prettifying” this explanation to NL. The resulting combination is much more robust than any standalone LLM explanation.

Risk to Text

Proof tree explanation is just one of the surprisingly good interactions between reasoner and LLM. Even before any facts and explanations are generated, we can easily generate NL descriptions of the logic that we have implemented and the risk instances that we have added to it. Let’s look at the NL description of the predicate risk_path_probability:

The probability of encountering risk when transitioning from a start state
to a new end state over a given number of periods is calculated
by multiplying the probability of encountering risk
in the previous period by the probability of the event causing the state transition,
provided the event is a risk instance and the total number
of periods does not exceed a specified limit.

Just think of the current development and documentation process of such rules, in which risk managers have to provide business specifications and developers have to implement, while also writing an elaborate documentation. Here, essentially we have logic which can be self-describing and documenting.

Auto doc and policy

Let’s see ‌the LLM generated NL description of our entire ontology. You can imagine a use case of this functionality in automatically generating and updating documentations and internal policies and procedures. All of our examples are with minimal promt engineering meaning that there is room for a lot of customisation and improvement:

The ontology defines a framework for assessing risk and loss in financial states through various predicates and rules. The key predicates and their roles are:
1. **state**: Represents financial states with an associated loss rate. Used to define states like “Positive balance”, “Negative balance”, and “Lost” with specific loss rates.
2. **event**: Describes transitions between states with associated probabilities. Events like “Become negative”, “Stay positive”, “Recovery”, “Loss”, and “Stay lost” define how states change over time.
3. **risk**: Represents a collection of events that define a specific risk, such as “Negative Balances Risk”, which includes events affecting balance states.
4. **user_state**: Indicates the state of a user’s balance at a given date. It determines if a user is in a “Positive balance”, “Negative balance”, or “Lost” state based on their balance and loss events.
5. **risk_state_start**: Marks the beginning of a risk state for a group with a specific amount and date. It is derived from the user state at the start date.
6. **risk_state_end**: Marks the end of a risk state for a group with a specific amount and date. It is derived from the user state at the end date.
7. **risk_path_probability**: Represents the probability of encountering a risk when transitioning between states over a number of periods, considering the occurrence of events.
8. **risk_path_probability_end**: Represents the probability of transitioning from a start state to an end state over a specified number of periods, summarizing the risk path probabilities.
9. **risk_state_probability_end**: Represents the probability of a risk transitioning from a start state to an end state over a number of periods. It aggregates the probabilities from risk path probabilities.
10. **risk_state_expected_loss_rate**: Represents the expected loss rate for an end state. It is calculated by multiplying the loss rate of the state by the probability of reaching that state.
11. **risk_expected_loss_rate**: Represents the overall anticipated loss rate associated with a specific risk. It sums the expected loss rates of all states.
12. **risk_expected_loss**: Represents the expected loss for a group, calculated by multiplying the expected loss rate by the amount at the start.
13. **count_state_start**: Represents the count of a state at the start. It is derived from the number of groups starting in that state.
14. **count_state_end**: Represents the count of a state at the end. It is derived from the number of groups ending in that state.
15. **risk_observed_state_probability**: Represents the observed probability of a risk ending in a specific state. It is calculated by dividing the count of the state at the end by the count at the start.
16. **risk_observed_loss**: Represents the observed loss for a group at the end state. It is calculated by multiplying the end amount by the loss rate of the end state.
The predicates link through rules to form a cohesive risk assessment model. Events define state transitions, which are grouped into risks. User states determine initial and final risk states, which are used to calculate probabilities and loss rates. The model aggregates these calculations to determine expected and observed losses and probabilities, providing a comprehensive understanding of financial risks and their impacts.

AI assistant

Combining the ontology together with all of the reasoner — LLM interactions above, we can unleash the full potential by creating our own AI assistant with which we can chat about the different rules, how they work, but also how specific results were derived:

chat("What are the risks associated with users?")

Generates the following response:

The risks associated with users include transitioning from
a "Positive balance" to a "Negative balance" with a probability of 0.1,
transitioning from a "Negative balance" to a "Lost" state with a probability of 0.8,
and remaining in a "Lost" state with a probability of 1.0.
The "Lost" state has a level of loss of 1.0, indicating a complete loss.
Additionally, users may experience "Recovery" from a "Negative balance"
to a "Positive balance" with a probability of 0.2,
and "Stay positive" where the "Positive balance" remains unchanged with a probability of 0.9.
The expected loss for a user is calculated based on these transitions and their associated probabilities.

Text to Risk and challenges ahead

So far we implemented flexible and scientifically grounded methodology and with the help of LLM, delivered a user-friendly interaction without sacrificing accuracy and objectivity.

However, if we are to fully automate the process, we ought to improve the initial step of manually coding our specific risk instances. One way to do this is by using the LLM as software developer which has to follow both correct syntax but also the codified risk instances have to be compatible with the generic risk ontology. In that case, we can think of the ontology as a schema which provides a template for the LLM for what constitutes a valid risk. The success of the LLM can then be tested via compiling the existing ontology and the newly generated risk by the reasoner.

Our concept workflow is the following:

1. Risk manager: describes new risk and references data sources where its events can be observed.
2. LLM: generates code for the new risk instance including the chain of events and possible states, as well as bindings to the data sources.
3. Reasoner: adds the new risk to the existing ontology and compiles it. If compilation is successful, the risk is sent to the risk manager for review. If not, it is sent back to the LLM for correction.

The above is a separate project by itself and is similar to the emerging topic of AI agents for code generation and iterative testing. Nevertheless, this is just another highlight of the vast potential for future development that is made possible by our scientific approach to Risk.

Reinventing Risk at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s take a look behind the scenes of the iOS development at Revolut, where we strive to provide exceptional financial services and seamless customer experiences for the customers who rely on our iOS apps to manage their financial lives.

We believe that it’s possible to deliver high-quality software, fast. To achieve this we follow a set of important principles and apply a number of modern agile practices, mainly inspired by XP (eXtreme Programming).

Deliver fast

Currently, on the iOS platform, we have both applications and SDKs.
Here’s a list of what’s live:

Revolut, Revolut <18, Revolut Business, Revolut POS and Revolut Pay SDK.

All iOS applications are updated in the App Store on a weekly basis. We operate on the principles of continuous integration and continuous delivery to swiftly deliver new functionality to customers — ‌as soon as a feature or part of it is ready.

We’ve built our own in-house framework for feature-based releases. According to our process, the Product Owner specifies a feature to be enabled starting from a selected version of the application. Then both the application version and its features are rolled out gradually, starting with a small percentage of our customer base. These two approaches — feature flagging and gradual version and feature rollout — enable delivering value to customers with the minimum amount of risk. If anything goes wrong, the flag will be turned off or the older version will be re-submitted as rollback, to remove the problematic change. Moreover, feature flags allow team members to easily switch between different user experiences, compare them, or turn them on and off for testing.

We’ve also developed an in-house experimentation platform that allows teams to experiment with new features and measure their impact using predefined metrics in a statistically significant way. This platform guarantees that experiments are properly set up, and that results are produced using a robust statistical framework.

All ideas are tested, with decisions being made using data-driven logic, making sure that only the best user experiences receive major development efforts. This results in a rapid and focused development of key user-centric features.

Architecture

As we delve into iOS fundamentals, it’s crucial to recognise that our iOS applications are just one piece of a larger ecosystem. Our aim is to cultivate cutting-edge technology to enhance user experiences‌ — ‌keeping it both straightforward and effective. To ensure alignment across our diverse range of apps, features, and teams, we rely on a structured process known as System Design Review (SDR).

The SDR process serves as a crucial mechanism for evaluating and refining the architecture of our solutions. Architecture acts as the glue, seamlessly merging technological elements to create a unified and effective system. In the context of SDR, mobile architecture is especially significant, guaranteeing that our iOS solutions are sturdy, scalable, in line and above industry standards.

Understanding solution-level architecture not only facilitates effective participation in the SDR process but also presents an opportunity for personal and professional growth within Revolut.

From the iOS platform perspective, all our products are implemented with Clean Architecture and MVVM-C.

Our apps aren’t monolithic. They include shared modules such as the core module, UI components‌, and feature modules like trading, payments, crypto, loans, and cards.

Currently we have:

• 160 shared modules
• 170 modules in Revolut
• 80 modules in Revolut Business
• 45 modules in Revolut <18

All our apps and shared modules are stored in a single mono-repository, and each module can be built and run independently.

Brief highlights of modular architecture:

• Faster build times — every module has an example or demo project to develop it in isolation quickly without compiling the whole app
• Faster development resulting from faster compiling and easy access to screens in the example project
• Isolated environment for trying new things
• Tests running in seconds

Tech stack

We develop using Swift and use iOS SDKs. Our goal is to reduce dependency on third-party frameworks to minimise reliance on external code. For example, instead of relying heavily on external frameworks, we’ve adopted a lightweight reactive approach within our core library. This strategy mirrors the functionality of Combine and will facilitate a smoother transition to SwiftUI in the future with minimal effort.

With our app we have heavily exceeded the limits of XCode build capabilities and to ensure we’re corresponding with our main principle of delivering quality software fast we use a complex of fine-tuned open source and in-house tools.

To be able to build and test our applications and frameworks rapidly, we switched to Bazel by Google which provides reliable cloud and local modules build cache.

Our in-house tools are fully built in Swift (to be understood and modified by every iOS engineer in the company) as a command line interface and give the ability to easily operate with the whole code base.

We can build, test, and deploy easily as our CI config is similar to the local one. Which means that builds could be created and tested anywhere: from any environment as remote or local, and from every branch as release, develop, specific feature, and can be published to TestFlight and AppCenter.

For a better understanding of the development scale, let’s look at the numbers. Each month, our iOS engineers create around 2,200 Pull Requests which result in nearly 4,000–5,000 CI builds.

Having such intensive development, we also optimise our configs and module structure relentlessly. For example, the latest such optimisation helped to decrease PR validation time from 40 to 10 minutes, which resulted in nearly 2,000–2,500 CI hours decrease per month.

Also worth noting are other tools and technologies that we use, including:

• Git
• Xcode
• Figma
• CoreData for data storage (all our applications provide offline viewing, so data from CoreData cache database can be shown on the screen when no internet connection is reachable and the customer needs to look up card details, for example)
• SwiftLint, TeamCity, and others

Cross-functional teams

We have more than 120 highly skilled iOS developers spread among different teams and locations. There’s established code ownership where each team is responsible for maintaining one or more modules. Each team typically consists of developers for iOS, Android, Web, and Backend, a Product Owner, a Designer, and a Data Analyst. So each team is like a small start-up that can come up with ideas and turn them into products or features.

Team members have full control over the functionality they develop. For an engineer, being part of a cross-functional team means having the opportunity to influence the product, participate in decision-making, and engage in learning technologies outside their expertise.

To increase our team’s productivity, we use a lot of tools for disruption-less development with respect to distributed ways of working. Surely, every team is unique in their own setup and process, but in general, we follow Agile methodologies, communicate in Slack, store our development artifacts in Confluence, and track our progress in Jira.

Quality

To ensure the rapid delivery of high-quality software, we prioritise maximising the automation of our quality assurance process. Our testing pyramid forms a solid foundation, with every test utilised for our iOS products being written in Swift and leveraging native SDKs such as XCTest and XCUITest. Additionally, for syntax sugar and documentation-driven test development, we incorporate frameworks like Quick + Nimble, featuring contexts and behaviour-driven testing. Furthermore, for reusable design components, we implement SnapshotTestCases.

Here are some numbers regarding our automated part of the testing pyramid:

• On the lowest level we have around 12,000 unit test suites with more than 150,000 separate test cases to verify individual components.
• On the middle and top level, we have 3000 UI tests cases covering both integration and the UI/UX part of the application

Also it’s important to mention that ensuring the quality of our products is a shared responsibility among all our employees. While we don’t have dedicated QA engineers, our developers, product owners, designers, and all other employees take comprehensive measures to maintain high standards. They incorporate various testing methods into their workflow, including manual cross-checks and everyday app usage testing. By adopting this automated and collaborative approach to quality assurance, we uphold our commitment to delivering reliable and user-friendly products to our customers.

Security

Our dedicated Information Security (InfoSec) team plays a pivotal role in safeguarding Revolut’s systems and user data. Through rigorous code reviews, penetration testing, automated vulnerability scanning and proactive threat hunting. Their unwavering commitment ensures that our users can trust Revolut with their sensitive information, knowing that every measure has been taken to protect their privacy and security.

In particular, for our iOS platform, we implement complex security measures to uphold the integrity of our application and safeguard user data. We employ encryption techniques and leverage the Keychain to securely store sensitive data and credentials, ensuring they remain inaccessible to unauthorised entities, even in the event of device compromise. Furthermore, we meticulously design our API endpoints and local storage mechanisms to minimise data transfer and stored data.

To defend against potential threats from unsafe devices and runtime modifications, we integrate advanced runtime protections and detection mechanisms into our app’s codebase. These measures actively monitor the app’s execution environment, detecting and responding to any unauthorised attempts to tamper with or exploit the application. By proactively addressing such risks, we reinforce the resilience of our iOS platform, bolstering user trust and ensuring the confidentiality and integrity of their data.

Design consistency

All UI components are designed for high reusability within our applications and are housed within separate modules to uphold consistency in the app’s visuals. These modules are implemented natively across all platforms we develop for, ensuring the same UI and UX implementation. We call this approach a Design System. We’ve developed this system with the core principles of atomic design in mind.

The Design System serves as a resource-saving tool, reducing both code volume and development time. Developers no longer need to duplicate code or spend time reinventing components. Instead, they can utilise the Revolut Design System App, which showcases all existing UI components, allowing developers to easily select and reuse the appropriate components for their features.

Join Revolut

Want to build a world-class financial app for iOS?
Explore the career opportunities at Revolut, and join the team of the most talented developers.

Links

Our Applications:
Revolut
Revolut <18
Revolut Business
Revolut POS
Revolut Pay SDK

Approaches:
​​https://martinfowler.com/articles/practical-test-pyramid.html
https://bradfrost.com/blog/post/atomic-web-design/

Tools:
https://bazel.build/
https://github.com/realm/SwiftLint
https://github.com/Quick/Quick
https://github.com/uber/ios-snapshot-test-case

More about Revolut:
https://medium.com/revolut/under-the-hood-engineering-at-revolut-2dc183c04228
https://www.revolut.com/careers
https://www.youtube.com/watch?v=SPDnhMg7kMk&t=1898s

The fundamentals of iOS at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

While developing the Know Your Customer (KYC) module in the banking sector, we faced a specific challenge. KYC is a process where banks verify the identity and assess the risk profile of their clients. As part of this module’s development, we needed a JavaScript library that was capable of analysing images — specifically, we required it to detect if an image is blurred and, importantly, to determine the degree of that blur. This functionality was crucial because clear images are essential for accurate identity verification in KYC processes so a dedicated library was needed. Unfortunately, there were no suitable solutions in opensource that fulfilled criteria satisfactorily.

Left with no alternative, we embarked on creating an algorithm on our own. The outcome was a user-friendly algorithm that effortlessly checks any image for the presence and degree of blur. From the voluminous inquiries we observed on platforms like StackOverflow, it became evident that our solution could greatly benefit the community.

This utility has significant potential for diverse applications, such as image quality analysis on the client side. Yet, surprisingly, a modern, uncomplicated, resource-friendly library to tackle this common problem remains absent in today’s software landscape. Our experience, therefore, not only serves as a case study, but also underscores the urgent need for such a library in the JavaScript/TypeScript ecosystem.

Relevance

In an era where the visual web dominates, the quality of images plays a significant role in user engagement and experience. Blurry images can tarnish user perceptions and limit the effectiveness of visual communication. Yet, our research has shown a glaring gap in the JavaScript/TypeScript ecosystem: the lack of a simple, accessible tool to detect and quantify image blur. This absence impacts developers, businesses, and users alike, leaving a critical need unmet.

In the digital age, the quality of visuals is paramount across a broad spectrum of platforms. From e-commerce sites, where product images are pivotal in influencing purchasing decisions, to online galleries showcasing artists’ portfolios, news portals highlighting photojournalism, and even social media platforms where the clarity of a shared image can dictate its virality. Consider for example a retailer on Aliexpress. Take a look at the images below. It is impossible to determine how the product looks and what is written in the explanation to it because images are blurry.

Even a minor degradation in an image can turn potential buyers away. Although there are some guidelines for file formats and sizes, maintaining the intrinsic quality of an image, ensuring aspects such as clarity, remains a daunting task. Among various determinants of image quality, blur stands out as a predominant issue, impacting both amateur snapshots and occasionally even professionally curated images.

Addressing this glaring need, the proposed open-source blur detection tool for the JavaScript/TypeScript ecosystem goes beyond just identifying blurs. It aims to provide real-time feedback to users like shop owners, photographers, or journalists, prompting immediate rectification. Such a tool not only ensures that images meet the highest visual standards but also enhances user trust and engagement, reinforcing the idea that in the modern digital landscape, the clarity of an image is often synonymous with its value. The goal of the proposed blur detector is to introduce automated quality checks in the browser. This could provide feedback to users and potentially prompt them to upload images of higher quality.

Current solutions

This part spotlights other solutions and a crucial need in the software landscape: an accessible and efficient blur-detection library in JavaScript/TypeScript.

1. OpenCV approach

Solutions such as js-blur-image-detection, based on the heavy OpenCV library makes it an impractical choice for many applications for the multiple reasons:

Performance Overhead with OpenCV:

• Size: OpenCV is a comprehensive computer vision library. While this means it’s feature-rich, it also means it’s heavy. For web applications, using such a bulky library can significantly increase the size of your bundled JavaScript, leading to longer load times.
• Complexity: OpenCV offers a myriad of functionalities, many of which may not be needed for a simple blur detection task. This can add unnecessary complexity to the application.

Deployment Challenges:

• Browser Compatibility: OpenCV, given its origins and extensive functionality, might not be entirely optimised for all browsers. This can lead to potential compatibility issues.
• Version Maintenance: With a complex library like OpenCV, staying updated with the latest versions or dealing with potential security vulnerabilities can become a challenge.

Runtime Efficiency:

• Processing Time: Due to its comprehensive nature, operations in OpenCV might be more resource-intensive, potentially leading to slower runtimes, especially on less powerful devices (eg. mobile devices) or in browsers with multiple tabs and operations.

Dependency Concerns:

• External Dependencies: Relying on large external libraries can sometimes introduce bugs or conflicts with other packages, making debugging more challenging.

On the other hand, a zero-dependency JS/TS solution offers:

1. Lightweight & Fast: With a dedicated focus on blur detection, a zero-dependency solution would be optimised for that sole task, ensuring swift performance without unnecessary overhead.
2. Simplified Maintenance: A specialised JS/TS library would likely have fewer updates, and when updates do occur, they would be directly relevant to the blur detection task.
3. Better Integration & Compatibility: Being designed specifically for the JS/TS ecosystem ensures better compatibility with other JS libraries and frameworks. It’s also more likely to be optimised for a wide range of browsers.
4. Enhanced Security: Fewer dependencies mean a reduced surface area for potential security vulnerabilities.

In summary, while OpenCV-based solutions like the one mentioned provide a vast array of features, they might be akin to using a sledgehammer to crack a nut when it comes to specific tasks like blur detection in web applications. A zero-dependency JS/TS solution, tailored for this particular problem, offers a more efficient, maintainable, and user-friendly approach.

2. Plain JS approach

The best solution found so far is inspector-bokeh: Canvas-based blur detection with JavaScript. The approach here is based on this article. The provided algorithm showcases a detailed method for blur detection in images. It begins with a preprocessing step to blur the image slightly with the intention to enhance edge detection. This is followed by the utilisation of a Sobel kernel convolution to detect edges in the luminance-converted image. The core of the blur detection leverages these edges to calculate the average edge width, which is then used to infer the level of blur in the image. Some points of consideration:

1. Typescript Compatibility: This algorithm, while detailed, does not cater to TypeScript-specific applications. Absence of type annotations and interfaces makes its direct adoption into TypeScript projects challenging.
2. Usability & Dependency: The algorithm has a dependency on canvasfilters, which is sourced from an arbitrary GitHub repository. This presents two primary concerns: firstly, the potential for usability issues if the library is not well-maintained or lacks comprehensive documentation. Secondly, there’s a security risk associated with depending on unverified repositories.
3. Size-Dependent Metric: The algorithm’s blur metric, which takes the average edge width as a proportion of the image’s width (avgEdgeWidth / width * 100), may yield inconsistent results for images of varying dimensions. This relationship could result in misleading blur assessments for either very large or small images.
4. Complexity: The algorithm, though comprehensive, presents a steep learning curve with its multiple stages of processing and a myriad of parameters. Its intricacy could pose challenges for developers seeking a plug-and-play solution.

In conclusion, this algorithm offers a methodical approach to blur detection. However, issues related to TypeScript compatibility, dependency clarity, and a questionable size-driven metric, compounded by its inherent complexity, could limit its applicability and accuracy in diverse scenarios.

Proposed solution

The solution is a lean and focused library designed to tackle one specific problem: analysing an image and returning a quantified blur score. This library takes a minimalist approach, intentionally avoiding dependencies, style exports, or unnecessary frameworks. What it does export is a simple TypeScript function, embodying the essence of “do one thing and do it well”.

Within this package, all the necessary mathematical computations are internalised, thus keeping the interface clean and straightforward. Most importantly, the underlying blur detection algorithm has been carefully crafted and thoroughly vetted by our data science team. This ensures that not only is it effective and reliable, but it’s also optimised to deliver accurate results swiftly. This library, therefore, represents a streamlined, specialised solution to the image blur detection problem, designed to integrate seamlessly into modern development workflows.

Approach description

Like many blur detection algorithms, this solution is fundamentally based on an edge detection algorithm. The process begins by passing the input image through a sequence of filters. Initially, the image is blurred to reduce high-frequency noise. Subsequently, it is transformed into grayscale to simplify the image structure, which is then convolved using the Laplacian aperture, further enhancing the image’s features.

To expedite the blur detection process, an image reduction technique is employed to decrease the number of pixels in the image without compromising on the critical details. Finally, the principal algorithm is executed, which locates the edges within the processed image. The density and clarity of these edges form the basis of the blur score returned by our function.

This series of operations forms a robust and efficient pipeline for blur detection. Our library, therefore, stands as a streamlined and effective tool for image analysis, offering an accurate blur score as a measure of image clarity.

Helper functions

While developing this blur-detection solution, I chose not to use external libraries for image filtering due to the lack of quality TypeScript libraries. Instead, it was decided to craft custom helper functions, to reduce library’s size and complexity. This choice results in a streamlined, performance-optimised library that could be easily integrated into other projects.

1. Grayscalling

Images often use the RGBA format: Red, Green, Blue, and Alpha (for transparency). If an image is grayscaled then Red, Green, and Blue values for any pixel will be the same. Storing all three identical values is redundant. The code provided optimises this by keeping only one channel — in essence, transforming the image into a grayscale representation. The implementation of the algorithm is shown below.

export const greyScale = (pixels: ImageData): ImageData => {
  const output = createImageData(pixels.width, pixels.height)
  const dst = output.data
  const d = pixels.data
  for (let i = 0; i < d.length; i += 4) {
    const r = d[i]
    const g = d[i + 1]
    const b = d[i + 2]
    // CIE luminance for the RGB
    const v = 0.299 * r + 0.587 * g + 0.114 * b
    dst[i] = v
    dst[i + 1] = v
    dst[i + 2] = v
  }
  return output
}

2. Reducing Image data for efficiency

When working with image data, especially in the context of web applications, it’s often crucial to reduce memory usage and improve processing speed. One common approach is to reduce image data. In the given code snippet, it is achieved by transforming an image with RGBA channels into a single-channel grayscale representation.

const reducedPixels = (imageData: ImageData): Uint8ClampedArray[] => {
  const { data: pixels, width } = imageData
  const rowLen = width * 4
  let i
  let x
  let y
  let row
  const rows = []

  for (y = 0; y < pixels.length; y += rowLen) {
    row = new Uint8ClampedArray(imageData.width)
    x = 0
    for (i = y; i < y + rowLen; i += 4) {
      row[x] = pixels[i]
      x += 1
    }
    rows.push(row)
  }
  return rows
}

3. Initial edge smoothing

A Gaussian blur is then applied to smooth out any high-frequency noise that could disrupt edge detection. The implementation of the algorithm is shown below.

export const gaussianBlur = (pixels: ImageData, diameter: number): ImageData => {
  diameter = Math.abs(diameter)
  if (diameter <= 1) return pixels
  const radius = diameter / 2
  const len = Math.ceil(diameter) + (1 - (Math.ceil(diameter) % 2))
  const weights = getFloat32Array(len)
  const rho = (radius + 0.5) / 3
  const gaussianFactor = 1 / Math.sqrt(2 * Math.PI * rho * rho)
  const rhoFactor = -1 / (2 * rho * rho)
  let wsum = 0
  const middle = Math.floor(len / 2)
  for (let i = 0; i < len; i++) {
    const x = i - middle
    const gx = gaussianFactor * Math.exp(x * x * rhoFactor)
    weights[i] = gx
    wsum += gx
  }
  for (let i = 0; i < weights.length; i++) {
    weights[i] /= wsum
  }
  return separableConvolve(pixels, weights, weights)
}

4. Edge enhancement

The final step uses a Laplacian aperture to enhance the image’s edges, readying it for the core edge-detection process in our blur algorithm. These functions help the tool remain compact, reliable, and independent, providing accurate blur scores without the need for external dependencies.

Core algorithm

Blur check is done by calculating a variance matrix of Laplacian operator applied to the input. The implementation follows that post.

Steps:

• Remove noise by applying a Gaussian blur and then convert the original image to grayscale
• Apply a Laplacian operator to the grayscale image

That produces a matrix of second derivatives and variance of second derivatives will be a blurriness score. If we want to find blurry images we should adjust the threshold, e.g. 5. Of course threshold adjustment should be done on real data.

The basic edge analysis algorithm is given below.

const detectBlur = (pixels: Uint8ClampedArray[]) => {
  const width = pixels[0].length
  const height = pixels.length
  const getMean = () => {
    let sum = 0
    for (let i = 0; i < height; i++) {
      for (let j = 0; j < width; j++) {
        sum += pixels[i][j]
      }
    }
    return sum / (width * height)
  }
  const getVariance = (mean: number) => {
    let sum = 0
    for (let i = 0; i < height; i++) {
      for (let j = 0; j < width; j++) {
        const normalized = pixels[i][j] - mean
        sum += normalized * normalized
      }
    }
    return sum / (width * height)
  }
  return getVariance(getMean())
}

In order to determine the blur score using the approach described above, the code below could be used.

const BLUR_BEFORE_EDGE_DETECTION_DIAMETER = 3.0 // pixels
const LAPLACIAN_APERTURE = [0, 1, 0, 1, -4, 1, 0, 1, 0]

const prepareImage = (imageData: ImageData) => {
  const preBlurredImageData = gaussianBlur(imageData, BLUR_BEFORE_EDGE_DETECTION_DIAMETER)
  const greyScaled = greyScale(preBlurredImageData)
  return convolve(greyScaled, LAPLACIAN_APERTURE)
}
export const measureBlur = (imageData: ImageData): number =>
  detectBlur(reducedPixels(prepareImage(imageData)))

Conclusions

Proposed approach is more streamlined then existing ones because it has no dependencies and focuses on variance as a measure of blur. It consists of fewer operations and has a more straightforward process which might lead to better performance, especially when applied iteratively or on numerous images.

Advantages:

• Simplicity makes it easy to understand, modify, and maintain.
• The Laplacian-based approach is a classic method for blur detection, relying on the principle that a sharp image will have a high variance of intensities in its edges.
• It does not depend on external libraries like canvasfilters or openCV.

Disadvantages:

• May not be as nuanced or detailed in its evaluation as existing solutions.
• Could potentially miss subtle details or nuances in certain images.

In summary, the proposed algorithm’s simplicity could suffice for most general blur detection tasks. It makes it easier to integrate, adapt, or extend. The existing solutions, due to its dependence on other libraries, might have some constraints. If speed, simplicity, and independence from external libraries are paramount, then this solution would be the way to go.

Canvas-based JavaScript Blur detection was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s everything you need to know about how translations have evolved at Revolut. We currently have 6 apps, with 330 modules containing strings.xml files. And don’t forget, we need to support 33 languages.

To make the translation process smooth, we use the API of Lokalise.

When one of our engineers adds a new string on the platform, it’s translated into all languages within 1 hour. After that, we need to download and place the translations into the correct module. Now, from an engineering perspective, here comes the most interesting part!

Initial implementation

In 2017, we began our expansion, and the first supported languages were French and Polish. We quickly reached a stage where fast translation became an integral part of the feature release process.

Using our partner, Lokalise.com, we started implementing translations for a single app (only Revolut retail app existed at the time).

We added Lokalise library to our project and used keys from it via a Singleton pattern:

Library downloads translations from the server once the user opens the app. This approach was fast to implement, but had 2 limitations:

1. API has user limit, which is critical for the fast-growing application
2. Download translations on app launch degrades the performance

First script

To answer both of these problems, we created a simple local script that downloads strings and puts them into the resources’ folder. Before releasing a new version of the app, one of the engineers has to call this script and merge translated files into the release branch.

Simplifying developers’ life

Later on, one of our engineers introduced an additional script to upload keys to Lokalise. The goal was to let engineers create new keys in strings.xml during the development process, automatically upload them to the provider, translate them, and then download them back.

However, we soon discovered that this approach caused confusion: what should be the source of truth, if an iOS developer added the same key on the website, but an Android dev used the script, how to pick the correct key? As a result, after just one month, we decided to disable the new script.

Migration to Groovy

Python script was executed using a Gradle task:

Why do we need to wrap it, when we can easily write the same simple script in Groovy? If we’re going to run it on CI, we can remove dependency on Python. After 3 months of using Python script, we migrated to Groovy.

For the next 2 years, this script was our main way of downloading strings.

Modularisation

In 2019, with a large codebase (1+ million lines of code), we embarked on the journey of adapting modern approaches to address the growing build time and initiated the modularisation process. Soon, we realised that the existing script wasn’t flexible enough to be used in a multimodule environment, as it could only place files within the app module

We migrated to a more complex, but flexible solution using Yaml, Bash, and Kotlin. We used Yaml config to declare all required data, such as token, project ID (each app is represented by a different Localise project), languages, module names, and their corresponding files:

After parsing this config with Kotlin code, the translations were downloaded and placed into a dedicated module. To execute the Kotlin code, we utilised a Bash script, which was unique for each application.

It was a working solution, but complicated and overwhelming. Let’s highlight the key disadvantages we faced:

• Messy Yaml configs: same modules in different configs, hundreds lines of configuration in one file
• Solution fragility in case of failure: if one config was broken, it caused downloading issues for all Revolut apps
• Difficulty in sharing modules between apps: making modules shared between apps wasn’t straightforward, especially when translations belonged to different projects on Lokalise. For example, sharing a module from Revolut Business with Revolut <18 app required the separation of Bash scripts and Yaml configs.
• Hard to modify Bash script because we need to modify and test all 6 for each app every time
• Inability to execute in parallel: the existing setup didn’t allow for parallel execution, slowing down the process.
• Bash scripts and configs are hard to cover with unit or integration tests, leading to lack of good test coverage

Gradle solution

We decided to implement a custom Gradle plugin and move the existing downloading logic there. We can pass all required parameters, such as token or file name into Gradle configuration to get rid of Yaml. To get rid of Bash, we can create a Gradle task and execute it straight away for the module.

Let’s see how it works for the feature_payments module we saw in Yaml config. We need to add these lines to its build.gradle file:

To download translations, we have to execute our new task downloadStrings using this simple line in the terminal:

To download Strings for all apps, we can run ./gradlew downloadStrings

How the task works under the hood

1. Clear all files in the module with pattern strings_*.xml
2. Download translations archive from Lokalise api
3. Unzip and place files in the module

Pros of the new approach:

• Each module is configured independently. No more Yaml configs with 300 lines of configuration
• Making modules shared between apps has become effortless, requiring no changes to the configuration
• No need to maintain multiple Bash scripts
• Downloading and moving files can be done in parallel, speeding up the process
• Unit and integration tests on Kotlin included into the CI pipeline to make sure everything works as expected
• The plugin is written on Kotlin, a language familiar to every Android developer in the company, making it easy for them to contribute

Improvements

After applying configuration to 300+ modules, we noticed 3 fields in Gradle configuration are the same for each app: projectId, apiToken and languages. To encapsulate them, we used the Gradle conventional plugin.

Inside a new plugin, we created a simple Enum class with all our projects:

Instead of writing 3 boilerplate fields, the developer has to specify only projectName. The rest would be applied inside the conventional plugin. This is how final configuration looks like:

Code from Conventional plugin:

Other problems we solved

Duplicated files

We couldn’t have the same strings files in different modules because of transitive R classes, which couldn’t contain duplicates. To fix it, we enabled non-transitive R classes. Now we have to specify the full path to the R in code (e.g. com.revolut.feature.payments.R.string.my_title), but we can make the same file be added to multiple modules.

Merge conflicts

Strings files can change quite often if multiple people work on the same feature. In such cases, we might encounter numerous merge conflicts and even risk breaking the main branch.

For instance, if one person merges a new string “A” and its corresponding code, and later another person merges a file without the string “A,” it can lead to complications and errors.

We fixed this issue with 2 simple rules:

1. No one can merge strings xml files manually. We have a Danger rule to block such Pull requests
2. Automated script on CI merges strings to always the same branch (to not have conflicts). Strings are merged to the release branch and automatically back merged to the main development branch. Script is automatically triggered every day or can be triggered by the engineer

Changed or deleted strings used by older app versions

Currently, we have at least 3 app versions in the release cycle. For instance:

- version 1 is available on Google Play

- version 2 is accessible in the Beta channel

- version 3 is the one we are currently working on and releasing internally

We came across a problem: if a decision is made to remove a string that’s no longer needed in version 3, it could potentially break the release of versions 1 and 2, as they’re still utilising that string.

To prevent such issues, we have another set of rules:

• Don’t remove strings immediately. Move them to the separate file called strings_unused.xml and remove them only after some time, when we’re completely sure it won’t break anything (usually after 6 months)
• If we intend to modify the number of placeholders in the string, it is essential to create a new string. We need it as an incorrect number of arguments, whether shown or not, can lead to unexpected UI and UX bugs
• If an engineer wants to change any text — they’re welcome to do it

Conclusion

Over the past 7 years, we’ve explored various solutions for translation management. While the task may not appear complicated at first glance, as you can see, there are many pitfalls.

Even though our current solution isn’t a silver bullet, it’s flexible enough to be improved upon as soon as we face a new challenge.

If you have a single app with a few modules, it probably doesn’t make sense to invest time into creating your own library; instead, you can use what’s already available or do everything manually.

Evolution of translations management for Android at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Revolut, we always aim to consistently provide efficient, high-quality, and secure services. Our primary goals are to enhance product quality, increase customer satisfaction, and reduce business risk.

To achieve those goals, we should aim to be as proactive — rather than reactive — as possible. This means fixing any point of failure before it reaches production by identifying, reporting, and potentially blocking deployments that can impact the reliability of our products.

In this article, we’ll explain how we achieve those goals using automated risk calculation, data analysis, and imposing constraints to push for the mitigation of open vulnerabilities and the fix of reported bugs identified in our products.

Challenges faced by Revolut

Each application/service has its own specifications, with different technology stacks and architectures, bringing a diversity of security challenges and different vulnerabilities. That being said, application risk cannot be based only on the reported security vulnerabilities but also in the context of that specific application.

Continuous scanning, reporting, visibility, and risk evaluation are essential to providing the best security advice and automated security controls.

Nowadays there are several types of security scanners (SAST, SCA, DAST, IaC, etc.) that help security professionals to identify and report vulnerabilities, where each of them can belong to a different third-party provider. For further information on these, read our article on continuous security.

Data scraped from different sources creates friction when it’s needed to group findings and provide mitigations. This can also decrease mean time to identify vulnerabilities and mean time to provide mitigations. Also, to avoid such negative workflow impact, security must be shifted left.

Without a centralised source of truth for security-related application data, most of the time is wasted on searching for information/findings in segmented platforms and finding the correct people to provide the necessary details for the security assessments.

It’s also important to note that applications being deployed in production should also be controlled. By calculating the dynamic risk of applications and collecting the number of present bugs during CI/CD stages, it’d be possible to block the most vulnerable applications from being deployed. This would make sure that no critical vulnerabilities or bugs reach production, improving product reliability.

Therefore, the main problems were raised:

• How to push for the mitigation of existing vulnerabilities?
• How to push for the fix of existing bugs?
• How can data from different sources be centralised?
• How can a risk score be dynamically calculated using a mathematical expression that considers not only security findings but also the context of the application?
• How can that mathematical expression be easily scalable, flexible, and tuned in different situations?
• How to control applications being deployed using constraints?
• When emergency situations occur, how to effectively bypass a constraint decision?

Proposed Ecosystem Solution — DARC

As explained in this article, Security Drone is an all-in-one security scanner framework that can be integrated in the SDLC, developed by Application Security Team. Security Drone serves an HTTP/API that receives webhooks from our code repository to initiate a security scan against the source branch of each Pull Request (PR). Taking advantage of this existing solution, it was decided to implement constraints at PR level, shifting left as much as possible. This way Security Drone, besides scanning for security vulnerabilities, will also gain blocking functionality at each PR.

Although this solution was already in place, it wasn’t enough. We still needed to collect and store all necessary data from different data sources to provide the most accurate decisions based on risk and number of bugs. With that in mind, over the last year, we created a new application called Dynamic Application Risk Calculator (DARC).

DARC is an automated security platform that provides constraining decisions based on the correlation of internal data sources.

DARC is used to calculate the risk associated with each application, as well as evaluate how many bugs a team has open. With those computational capabilities, a blocking mode is implemented at the PR stage using Security Drone integration to scan every new and updated PR.

To support such features, DARC provides company-wide integration with several internal data sources, from which data is frequently collected.

DARC is divided into the following sub-components:

• API — a backend service responsible to manage requests and integrations
• Collector — schedule tasks (apscheduler) used to update DARC DB with data from internal data sources, defined to refresh data at regular intervals (depending on the data source)
• DB — a database to store necessary data
• UI — a frontend to present all data

Added value

Blocking Mode

Two different types of blocking mode were defined in our ecosystem: one related to application risk score and another to the number of open bugs. Although both have the same main logic flow and outcomes, they should be distinct from each other to improve audit and traceability.

Risk-based blocking mode performs assessments based on the target application of the PR, which Security Drone can directly map using the repository slug. Then, the target application is sent in a request to DARC API, where the risk score will be obtained based on the security-related information associated with that target application.

Bugs-based blocking mode works by team. Security Drone maps the owner of the PR to their assigned team, then a request is sent to DARC API where the number of open bugs for that team is obtained.

For positive blocking decisions — besides blocking the PR — a message explaining why the PR was blocked is added to the target PR with a link to DARC-UI where engineers get insight into the main inputs that caused the blocking mode to trigger.

For emergency or justifiable reasons, we also implemented a derogation mechanism, that allows high-role engineers to bypass the blocking mode.

DARC also focuses on improving visibility and awareness around blocking mode, so besides adding feedback in the PR, it also sends weekly messages to global internal communication channels with the teams and applications that are currently above or near the thresholds.

Also, to improve traceability, an audit log mechanism was created that allows us to keep track of all blocked PR’s (bugs or risk-related) and their respective derogations.

Blocking Mode Sequence Diagram

Risk-Based Blocking Mode

The main goal of risk-based blocking mode isn’t only to reduce the number of vulnerabilities, but also to prevent vulnerabilities from reaching that production environment, consequently reducing the mitigation cost and decreasing business risk.

In DARC, the risk score is stateless, meaning that it is only calculated at the moment of each request using previously collected data related to the application context and vulnerabilities waiting to be fixed.

Risk is usually defined as likelihood multiplied by the impact. But at a lower level, it should depend on several factors, including the context of the application and the number of vulnerabilities found in each scanner and their associated severity. However, if the approach to define application risk scores requires manual work and does not have flexible metrics, it’d be hard to scale and maintain. For instance, if we want to integrate another scanner, vulnerabilities found from that scanner should be seamlessly integrated into the risk calculation. The same applies if another useful context attribute from the context of the application needs to be integrated. Therefore, a flexible and scalable mathematical expression is needed, where we can define different heights for each input.

Risk Factors

To calculate the risk score, DARC considers the findings from our security scanners and internal findings, evaluating the severity of each finding based on CVSS score. We ensure that all reported vulnerabilities have a CVSS score and have the target application defined, to guarantee that later we can associate each finding to its respective application. Security findings are used to calculate the Risk Factor Vulnerability (RFV) value.

Most of our scanners’ rules are created and tuned internally, with a target of less than 10% false positive rate. This is a trustworthy value that enables us to calculate RFV with precision and very low uncertainty.

Another component for the risk calculation is the Risk Factor Context (RFC). RFC will contain several child risk factors (RF) from the application context, where as a baseline we included:

• [RF1] Data Store or Processed — Related to data sensitivity level, personal data and regulations applied. Risk should increase at the same level as the sensitivity level of data that the application handles
• [RF2] Exposure — Internal-accessible services with internal registered DNS aren’t exposed to the public, and therefore risk should be lower in such cases. Other types of network specifications can be used in this section. ‌For example, types of firewall rules, or if it has integration with third party services
• [RF3] Maintenance / Lifecycle — Security Drone scans new code. Therefore, if a service isn’t actively maintained and new code pushed, we won’t have recent scans. New vulnerabilities appear everyday and we’re constantly creating new rules under our scanners, so it’s important to scan regularly. Besides that, services that aren’t actively deployed won’t have the last version of internal updated packages (OS or software). Those are the main reasons risk should increase when an application isn’t actively maintained
• [RF4] Confidentiality, Integrity, and Availability (CIA) — This is the core of information security and has a higher impact on each, as higher risk must be
• [RF5] Security — From our security monitoring, we can extract some valuable information from this RF. For example, the number of security incidents or identified attacks on an application. This can increase the risk, as we know that malicious actors frequently target the application

Risk Mathematical Expression

To be flexible and resilient, the DARC mathematical expression is based on a weighted arithmetic mean.

The weighted average (x) is equal to the sum of the product of each of the RF weights (wi) multiplied by the RF value (xi) and divided by the sum of the weights:

RFs can have different weights, which gives us the ability to manipulate the importance of some attributes compared with others. This makes sense depending on the amount of value that we want to give to an attribute in the final risk value, allowing us to adapt source metrics weight in a way we understand to be more meaningful. It also provides a dynamic variation, and can never be null in case some (but not all) of the RFs aren’t applicable or available.

This approach ensures scalability in terms of new source metrics that need to be added.

The approach to this problem was obtained from the following scientific investigation in the article A Delphi Study to Categorize Security of Health Data and Provide Risk Assessment for Mobile Apps.

How DARC Score is Calculated

Baseline metrics

The following baseline metrics were defined:

• Output value is defined between min=0 and max=100
• Weights for each RF have values low=1, medium=2 and high=3

And also the following thresholds:

• 0–50 → Pass
• 50–75 → Warning
• 75–100 → Block

Calculating RFC

Values available for impact of each RF in RFC are:

• Low=0
• Isolated=30
• Medium=60
• High=100

Weight values were defined as the most meaningful values, giving more importance to the RF values that we feel are most important. Now, let’s consider the following sample data inputs related to a random application context and their respective impact values to each RF:

[RF1] Data Store or Processed (weight = 3)

• Confidential data and is regulated by PCI DSS → High=100

[RF2] Exposure (weight = 3)

• Internal service (not exposed to public access) but integrated with one third-party provider → Isolated=30

[RF3] Maintenance / Lifecycle (weight = 1)

• Actively maintained and deployed every week → Low=0

[RF4a] Confidentiality (weight = 3)

• High=100

[RF4b] Integrity (weight = 3)

• High=100

[RF4c] Availability (weight = 3)

• Medium=60

[RF5] Security (weight = 1)

• No open incidents and some tentative of attack in last months → Isolated=30

By applying previous RF values and their respective weights, the RFC value with weighted arithmetic mean can be obtained:

RFC = (3x100 + 3x30 + 1x0 + 3x100 +3x100 + 3x60 + 1x30) / (3+3+1+3+3+3+1)

= 70.6

Previous PoC shows that — besides being easily scalable — this isn’t a static approach. The weights and impact values of each RF can be easily adapted whenever meaningful reasons are proven, giving us the ability to evolve further down the road. It was also made sure that low-impact values for RF are rarely used to have a better balance between RFC and RFV — otherwise we could end with RFC considerably decreasing the final score.

Calculating RFV

RFV is calculated based in reported vulnerabilities, using the respective severity of each security finding. All of them have a CVSS score defined, and it’ll be used as a base for a risk multiplier. The risk multiplier makes sense to avoid low values and to increase the output when high or critical vulnerabilities are reported. Considering this, rules for RFV calculation are:

1. Target application has a critical vulnerability (CVSS >= 9) → RFV = 100
2. Target application has a high vulnerability (7 <= CVSS <= 8.9) → RiskMultiplier = 3
3. Target application has a medium vulnerability (4 <= CVSS <= 6.9) → RiskMultiplier = 2
4. If only low vulnerabilities (0.1 <= CVSS <= 3.9) are present → RiskMultiplier = 1

Then, the final mathematical expression for RFV is:

RFV = sum(vulns[CVSS]) x RiskMultiplier

For rule number 1, RFV will automatically be a maximum of 100 since any critical vulnerability presents a maximum risk.

Now let’s consider an application that has four reported vulnerabilities:

1. SAST finding with 8.2 CVSS score
2. Internal finding with 7.9 CVSS score
3. SCA finding with 6.5 CVSS score
4. DAST finding with 5.3 CVSS score

RFV = (8.2 + 7.9 + 6.5 + 5.3) x 3 = 83.7

DARC score

To obtain the final DARC score, RFC and RFV values must be correlated. The same logic of weighted arithmetic mean is used, allowing us to change the importance of each by manipulating the weights or even adding another risk factor. This allows us to be adaptable and easily scalable. At the moment, both RFC and RFV have the same weight (3) since we felt they have the same importance and will bring a better balance.

Considering the previous values of RFC=70.6 and RFV=83.7:

DARC score = (3x70.6 + 3x83.7) / (3 + 3) = 77.15

The obtained DARC score is above the defined threshold (75), therefore all the PRs for the application in this example would be blocked.

Bugs-Based Blocking Mode

The main goal of bugs-based blocking mode is to reduce the number of bugs by prioritising bug resolution over future development, increasing product quality and customer satisfaction.

The flow for this blocking mode is similar to the logic behind the risk blocking mode, but it’s more simple to obtain the final decision.

DARC Collector frequently gets all reported bugs and stores them in DARC-DB, associating each bug to the respective team. Then, when requested by Security Drone to validate bugs blocking mode, DARC computes how many bugs each team has in some states — triaged and not closed.

If the team of the PR owner has more bugs than the allowed threshold, the PR will be blocked until bugs are fixed and the threshold is respected.

Relaunch Blocking Validation

Each approver action in our code repository will trigger a blocking validation flow by sending a webhook to Security Drone. This action is used to relaunch blocking validation and create derogations.

If the owner of a PR wants to relaunch the blocking validation flow after decreasing the risk or fixing bugs (to remove the blocking mode if thresholds are now respected), the owner can just approve their own PR. This will validate a new risk score or number of bugs against the thresholds. At this stage, the PR still can’t be merged since all of the PRs need to be reviewed and approved by another engineer as peer review logic.

Derogation Mechanism

In exceptional or urgent situations where the blocking mode needs to be bypassed, a derogation mechanism was created to overwrite the blockage.

This mechanism is only used in exceptional or urgent situations and not as a utility to skip fixing vulnerabilities or bugs. The main requirements for this mechanism are:

• Authorisation: only engineers in the allowed approvers list will be able to create a derogation and unblock the PR. We keep this list short and restricted to AppSec, Heads of Engineering, and Directors
• How to create a derogation: an authorised engineer just needs to approve the blocked PR. A webhook will be sent to Security Drone that’ll validate with DARC-API if the approver is in the allowed list. If yes, the PR will be unblocked
• Tracking: DARC-DB will store each derogation occurrence for audit purposes
• Alerting: each time a derogation occurs, we receive a notification in a dedicated channel

Derogation Sequence Diagram

What have we achieved?

To allow teams and engineers to comply with the thresholds and create awareness around DARC, we deployed the first version in warning mode, meaning that teams and applications above the thresholds only received warning messages in the PRs. This warning period lasted for 2 weeks, and a positive effect was felt — the number of non-compliant applications and teams decreased.

After the activation of the blocking mode, we achieved:

1. An automated and flexible way to quantify risk for each application
2. An effective way of increasing the quality of our products, with constraints implemented within a shift-left approach (at the PR phase). It takes approximately 5 seconds ‌to block a PR after its creation or update
3. More visibility and control over the global risk and quality of our products
4. An ecosystem to quickly identify and report (PR and weekly notifications) applications and teams that aren’t compliant with our thresholds for risk and bugs, respectively, increasing global awareness
5. UI that provides us with means to quickly access and filter all necessary security data for our daily work
6. A forecast feature that allows us to predict applications and teams that are currently not compliant with the threshold
7. Audit logs for every relevant action that’s taken under the ecosystem
8. All PRs are evaluated and triaged automatically. Since the activation of the blocking mode (~2 months), DARC evaluated 165,670 PR and blocked 1,832
9. Currently only 1% of our applications are above the defined risk threshold — the percentage was higher when blocking mode was announced
10. Decrease in the number of open bugs by ~ 31%
11. Clear metrics that the teams’ proactivity related to risk and bugs increased

Next Steps

DARC will always be under development as it can be widely integrated and its use cases are enormous. On our roadmap, we have various points, some of which include:

• Decrease thresholds to achieve even better results and therefore products
• Add more risk factors to DARC risk calculation, from internal sources
• Improve DARC user interface
• Use DARC capabilities to implement regular scans and on-demand scans
• Integrate with more custom security scanners
• Add other types of blocking modes

Credits

Credits go to every Revolut AppSec engineer involved in the design and development of DARC and Security Drone:

Pedro Moura, Arsalan Ghazi, Krzysztof Pranczk, Alejandro Ulises, Roger Norton, Kevin Borras

Improving product reliability by imposing constraints as a part of CI/CD process was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Keeping an app fresh and engaging is important to provide users with an enjoyable experience. One effective method is to add a personal touch to your app by supporting different themes in the application.

In this article, we’ll explore the various options that developers have to enhance user experience with the themes. We’ll also share our company’s experience in building themes, and the technical hurdles we faced during Android development.

Let’s dive in!

Depending on your app and company goals, you have several options to consider when implementing theming in your Android app. Here are a few:

• Switching between light and dark mode: This has become almost a necessity on mobile platforms due to users’ preference for dark mode
• Implementing dynamic colours. Android 12 introduced Dynamic Color, allowing you to adapt your app’s colour scheme to match the user’s wallpaper
• Going above and beyond, as we did in Revolut: We offer all the options mentioned above, and also provide our customers with the ability to choose colour-based themes in the app. This allows them to select their favourite colour from a predefined palette, and the app’s appearance changes to match it

By leveraging these options, you can create an app with a look and feel that aligns with your company’s branding and goals.

In this article, we’ll build a simple app that takes advantage of all the mentioned customisations options:

Switching between light and dark mode

With many platforms now offering system-wide dark mode, implementing a dark theme in your app has become almost an industry standard. While there are numerous resources available for implementing dark mode, we won’t delve into all the technical details here.

That said, if you’re interested in learning more about implementing a dark theme in Android, you can refer to the official guide.

In our demo app, we support dark and light mode by defining two styles:

Light:

Dark:

As we put themes to the separate folders (values and values-night), the system will pick up the required theme automatically, depending on user settings.

Both styles inherit Theme.MaterialComponents.DayNight.NoActionBar, which provides support for light and dark modes for basic UI elements such as backgrounds and text. Additionally, we define our own colorPrimary and colorSecondary to give our app a unique look.

We use AppCompatDelegate.setDefaultNightMode to switch between light and dark mode in runtime:

Here is an example of how the app looks with support for both dark and light modes:

If you’re interested in seeing the full screen layout and code, you can check out the demo project on GitHub.

Applying dynamic colours

Android 12 introduces extended personalisation capabilities. Users can now choose a wallpaper, and the system will automatically adapt its colours to match the wallpaper. Additionally, apps can support wallpaper colours using the DynamicColors API.

The simplest way to enable dynamic colours in an Android app is to use the Theme.Material3.DynamicColors.DayNight theme. But, using it requires migrating to the Material3 theme, which may not always be desirable because it not only changes the colours but also alters the appearance of components according to Material3 guidelines.

If we want to support dynamic colours without changing the app’s theme, we can specify a dynamicColorThemeOverlay for our theme:

Light theme style

Dark theme style

To apply the styling, we need to call DynamicColors API in the Application’s onCreate:

And that’s how the app looks with dynamic colours enabled:

📢 Heads up! It’s crucial to follow Material Design naming conventions for the dynamic colours overlay to work properly. The overlay applies a set of dynamic colours on top of the current theme and replaces the color tokens it is aware of, such ascolorPrimary and colorSecondary. You can learn more about material color tokens in the official doc.

Changing colours in runtime

With the approach described above, an app will always apply dynamic colours if they’re available.

But what if we want to have a more flexible way to work with themes? Some apps may want to maintain their branding by default and not rely on dynamic colours completely, giving users the option to select a theme they want.

At Revolut, we give our customers the ability to change the app’s theme at any time:

Although, this non-standard approach can be quite tricky to implement. After customers select a theme, we need to tell the app to recreate all the views, so they apply the new colours. The Android framework handles that for us when we need to change from the light to dark theme using AppCompatDelegate.setDefaultNightMode. This method will recreate activities under the hood.

But there is no way to force color changes to support switching to dynamic colors in the runtime. The good news is that nobody stops us from checking how AppCompatDelegate.setDefaultNightMode works and reproducing its approach:

Yes, this method simply loops through each activity and calls applyDayNight forcing activities to recreate! sActivityDelegates is a static set that collects all activity references.

The mentioned API is private, so to make our solution work we’ll draw inspiration from Android’s approach:

ColorThemesController registers ActivityLifecycleCallbacks to collect all activities to a single set. The applyColorTheme method will store a selected theme in the static field and trigger recreation for all the activities.

The most interesting part happens in onActivityCreated callback. It applies a selected theme to the newly created activity. DynamicColors.applyToActivityIfAvailable(activity) sets the dynamic colours. And for default theme, we’ll do nothing to keep default activity theme.

The logic starts working after we initialise ColorThemesController in the App class:

Now we can invoke ColorThemesController.applyColorTheme() to make a change in runtime:

Let’s check how that works in action:

You can find the full code of the app in the GitHub repository.

Custom themes

Dynamic colours are available on Android only, which leads to differences in personalisation capabilities between platforms if your app is distributed for iOS as well.

For those reasons, at Revolut, we didn’t stop at dynamic colour support. We also offer custom colour themes, allowing users to choose the main colour of the app:

It will be quite easy to modify our sample app setup to support a custom theme.

Let’s check how can we bring a custom Orange theme to the app.

First step will be to write a theme overlay which we’ll apply on top of the default theme. You can find more info on how theme overlays work in the following article. But in short, a theme overlay defines colours to replace in the given theme. It will add new colours to the theme if they are not present there. It’s like adding keys to the HashMap.

Here is a theme overlay for the light mode that replaces colorPrimary of our base theme:

And for the dark mode:

Now we’ll modify our ColorThemesController to support the new theme:

The Orange theme applied to activity using activity.theme.applyStyle(R.style.ColorThemeOverlay_Orange, true) . This call sets an overlay on top of the current activity theme, as we wanted.

Last touch will be to trigger ColorThemesController.applyColorTheme when orange theme selected:

Now our demo app is ready to switch between default, dynamic and the custom Orange theme, maximising customers personalisation capabilities.

Conclusion

In this article, we’ve explored a variety of ways to personalise your app’s appearance. By supporting dark mode, you can cater to the preferences of many users, or you can choose to use dynamic colours to make sure your app stays in sync with the system. Custom overlays offer cross-platform styles that are accessible to everyone.

Each app is one-of-a-kind, and every app has its own unique styling needs. With the right tools and techniques, you can create an experience that aligns with your app’s objectives and keeps users happy by offering a look and feel they enjoy. By implementing the approaches discussed in this article, you can make your app’s styling more adaptable and user-friendly.

Customising Android app UI with themes was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

People deserve more from their money. More visibility, more control, more freedom. Since 2015, Revolut has been on a mission to deliver just that. With an arsenal of awesome products that span spending, saving, travel, transfers, credits, crypto, investing, exchanging, and more, our mobile super app has helped 25+ million customers send, spend, save, and invest smarter.

Let’s take a look behind the scenes of the Android development at Revolut and learn how we deliver our iconic apps to millions of customers all over the world.

Dream team

Our Android team is one of the best in the industry — and we’re proud of it. It’s one of our driving forces: over a hundred excellent Android engineers work on our key products, such as Revolut for personal customers, Revolut Lite, Revolut Business, and Revolut < 18 for teens.

At Revolut, we believe that building diverse, lean teams of brilliant go-getters who break down barriers, is the key to winning. That’s why we have around 70 strong teams that split their work across two main streams: Platform and Product.

The Platform stream consists of Design System and Mobile Platform teams, while the Product stream includes various product teams, such as the Onboarding team, Payments team, Trading team, Crypto team, Credit team, and more. Each team is made up of Product Owners, Designers, iOS, Android, Backend, and Frontend engineers who work together to deliver exceptional results.

To better understand our teams and how they contribute to our success, let’s take a closer look at their roles and responsibilities.

Mobile Platform Team 👨‍🔧

Our Mobile Platform team is involved in a broad range of areas, such as building infrastructure, managing releases, maintaining architecture, and owning internal tools and libraries.

The team upgrades projects configuration, particularly improve performance of Gradle Builds, maintains architecture, manages dependencies and keeps architecture sustainable, modernises CI/CD pipeline, facilitates mobile release process, creates internal tools and frameworks (Automated Analytics tracking tool, Automated UI tests framework, DI declaration framework etc.), enhance app performance, and increase security.

Design System Team 👨‍🎨

The Design System team is the heart of our design culture. It’s responsible for building and maintaining the central source of truth for the developers, our UIKit (library of reusable components and guidelines).

They create high quality UI components, keep the designs consistent across the apps, customize themes and styles, optimise views, layouts, and overall rendering performance. They constantly improve user experience, create unified visual interfaces, ensure smooth transitions, and make our UI/UX not just convenient but also enjoyable.

Product Teams 👩‍💻

The Product teams play a critical role in every step, stage and release of a product. They’re like small startups; self-led, with the freedom to innovate and develop new products and features.

Such a team is focused on building a particular product, gathering requirements, implementing new features, collecting customer feedback, and making improvements. Each of our products, including Credit, Crypto, Stays, Rewards and others, build our one app for all things money.

Development process

The development process requires participation of all team members to achieve their goal. Planning, visibility, and structure in the development process, are integral components that allow the team to remove stress and implement quality functionality that satisfies business needs on time.

The process starts with the definition of requirements and acceptance criteria, which are validated and challenged by the team. Once requirements are clear, the scoping phase can begin. Scoping phase is covering an analysis of the requirements, identifying potential solutions, and building development plans.

After the scoping phase, all team members should be aligned, so the development itself can start. That said, new ideas or challenges may appear during the development process, meaning the already defined solution may need to be re-visited..

We adhere to Agile philosophy, and each team has a choice which Agile project management systems to use, usually a Scrum and Kanban, or a mix.

Project level architecture

All our projects are multi-module, meaning we organise our features as separate modules. At the same time, we pay attention to granularity level, and tend not to separate features that have high cohesion and are linked to the same domain area, because we know that modules that are too fine-grained make the overhead a burden.

Not all our modules are feature modules. There are Core modules for common needs, like network, databases, or android components, UIKit modules for design elements, Models modules for basic data structure, and Test modules. We reuse common components and basic functionality between feature modules in one project, and share it across our projects. It’s also applicable to features: we have several feature modules that we share across different products.

In case of feature modules, we follow an Api/Implementation approach, so each feature is represented as a lightweight Api module and a heavy Implementation module.

According to this approach, an Implementation of a feature should depend only on Api modules. This way, heavy Implementation modules don’t depend on each other, and can be built in parallel, to speed up the build time. This approach also makes a feature implementation less fragile, since it depends only on stable Api modules.

App level architecture

All our products are implemented with Clean Architecture principles. Revolut Business and Revolut < 18 are based on our own Kompot framework. Kompot implements the MVVM design pattern, provides unidirectional data flow, simplifies navigation between different parts of an app, and supports multi-module from the box.

But it’s not the only one: Revolut for retail customers, the oldest and biggest app, follows a different approach based on MVP design pattern. That said, the new approach with Kompot can also be used.

UI/UX

The way we work with UI deserves special attention, and we mostly build our screens atop the RecyclerView.

Our UIKit defines a set of design components that can be used for building UI. Most of these components are represented in our code as RecyclerViewDelegates, and we build each screen as a list of these premade components (delegates). You can find more details about how we recycle our screens.

We also pay extra attention to UX. According to our guidelines, screens should support Loading/Error/Empty states. In addition, transition between states should be smooth, without any visual noises. We also tend to render all content that’s already loaded, and only use shimmer skeletons for parts that are on the way, instead of blocking the whole screen with old-fashioned progress bars.

More importantly, we strive to show content on a screen as fast as possible, regardless of poor internet connectivity.

Here, Reactive data flow enters the scene. According to this approach, a repository provides a stream of the Data, containing typed content, a flag indicating that we’re loading content from the network, and optional error.

The repository also defines logic regarding content retrieving and storing. Usually, the content we get from remote sources is stored in local cache, so when we subscribe to a Data stream, our repository emits cached content at first, so we can avoid loading, and show screen state immediately. We store information in memory and persistent storage, so our customers have access to their financial data from everywhere, even in offline mode.

Tech stack recap

We write in Kotlin and tend to use Kotlin coroutines and flows, but RxJava 2 will probably always be part of our heart and code base too.

We also use:

• Frameworks: RxJava 2, Coroutines (Flow), OkHttp, Retrofit, Dagger 2, Facebook Screenshot tests, Kaspresso UI tests, Android SDK
• Database: SQLite (Room OM)
• Infrastructures: Bitbucket, Jira, TeamCity
• Utilities: Charles, Postman

QA & Testing

At Revolut, we don’t have QA engineers, but it doesn’t mean that we don’t verify our app’s correctness, or don’t identify possible issues, before releasing it to the public. We have several types of tests that help us consistently verify functional behaviour. Unit tests, Integration tests, Screenshot tests, and automated UI tests, allow us to get quite comprehensive coverage.

Additionally, our release lifecycle consists of several stages. In the first Alpha phase, we test our new products and features internally to make sure that the product meets business requirements and functions correctly without major bugs.

The following phase is Beta, where we publish beta app versions, used by external beta users, to help us identify bugs, and performance or usability issues, at an early stage, before public release.

Last but not least, we cover all major changes and updates in the code by feature toggles, managed by our internal release management system, Vader. This allows us to roll out features gradually and safely, and turn the feature off in case there’s an error.

Code review & Git flow

Developers create a new branch for any functional changes, rather than committing directly onto their local main development branch. After updating, committing, and pushing changes to the corresponding branch, developers open a Pull Request to discuss and review the changes before they go to the development branch.

When a Pull Request is opened, or any changes to the remote tracked branch appear, we perform CI/CD pipelines, including project building, running Unit and a set of most fragile UI tests, executing Danger verifications.

Danger is a tool that helps automate common code review routines, allowing us to create and share automated messages that remind developers of common mistakes, so they don’t run into them time and time again.

The Pull Request is ready to merge only if the project is successfully built, Unit and UI tests are passed, there’s no error from the Danger side, and the Pull Request has at least two approvals. All our code, modules, classes and tests are assigned to particular code owners (teams), allowing us to find owners of the code easily while developing, and more importantly, to assign reviewers, whose code has been changed to the Pull Request.

Release management 🚝

Our Release train departs each Tuesday at 9:00 am. At this moment, the automated code freeze happens, where all changes from the development branch go to the release branch. By this time, all involved teams make sure everything is ready, and check corresponding feature toggles. Starting from this moment, only critical fixes can be added to the release branch.

When a freeze has happened, we prepare a Google Play bundle, running Unit, and all UI tests. If everything is fine, we publish the first beta release. (We go through these steps and upload beta releases every day but Sunday.) At this stage, we collect the first beta customer feedback, and check analytics and crash reports.

On the following Tuesday, if all goes well, we merge the release branch to the store branch, and perform a staged public rollout of the release version. By this time, our release train transforms into a rocket, delivering a new version of the app to millions of users around the world, and a new release train comes into the station.

This is the last step of the app release cycle, but not necessarily a feature release. Even when a rocket is far away in space, and our new version of the app already on customer devices, we can manage rollout and availability of the particular feature remotely, using feature toggles powered by Vader.

Analytics

We analyse customer data to create personalised models and enhance the customer experience. For instance, we categorise events to personalise the main screen for each customer, and offer features based on their behaviour.

To protect our customers’ privacy, we do not use third-party analytics tools. Instead, we’ve built an in-house UI analytics solution that includes both a frontend framework and a server. The frontend framework tracks user interactions with the app out of the box, without requiring developers to write any ad-hoc code. The server captures batched events of screens appearing and buttons being clicked, allowing us to analyse the user journey and behaviour to create a better experience for our customers.

Join us

If you’re excited by our processes, how we work, and the opportunities you could get from working with us, why don’t you check out our Careers page and explore openings in our Android team?

Credits go to Revolut Android team, especially Anton Nazarenko, Nikita Barishok, Akhmetov Kirill and Artur Kharchenko, Head of Engineering Ivan Vazhnov and our CTO Vlad Yatsenko.

The Fundamentals of Android at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro

As we’re continuously growing and extending our product offerings, we can face many technological challenges. These challenges are solved by our engineers and this results in many features, changes and updates being developed and successfully delivered to our customers. However, with the development of new features comes many security challenges that are faced by the internal Application Security Team.

This lovely bunch is responsible for the security assurance of every new feature developed by our engineers. To provide the highest level of security assurance to our products, we’ve implemented a number of processes placed in different stages of the Software Development Life Cycle (SDLC), including automated scans in our CI/CD pipelines. However, it wouldn’t be possible to efficiently triage every security finding produced by automated scanners. In July 2022, there were nearly 39,000 commits created by over 900 authors! To address this challenge, we developed Security Drone. In this article, we’d like to share with you our approach to provide the highest security assurance in fast CI/CD environments.

Challenges faced by Revolut

The classic approach to security testing requires the security teams to perform a manual review of any developed features, with the help of automated security scans. Traditionally, this work was executed on a risk and priority basis and that need was stretching the team beyond its capacity. Additionally, the team had to cope with the numerous CI pipelines across the company. This approach wasn’t a viable solution in terms of scaling, quality and coverage.

Some of you may have an idea of the security challenges faced in a fast CI/CD environment. If not, let us make a little recap of the challenges we’ve been facing:

1. Software changes are constantly increasing
2. New changes are integrated and deployed every day
3. Engineers tend to prioritise the development of functionalities over security
4. The internal application security team can’t be big enough to have a dedicated security engineer for each project — both internal and external
5. AppSec teams nowadays must work on automating the work they were doing 10 years ago in a manual way
6. With more tools integrated into the pipelines, the timeline of each job increases, which negatively affects the development experience
7. And many more challenges you probably observe in your companies too!

First solution — The classic approach to CI/CD pipeline scans

Our first solution, and the most simplistic one, was to onboard automated security scanners like Static Application Security Testing (SAST) and Software Composition Analysis (SCA) and review the findings within the AppSec team. It worked, but we started facing another problem: the company was growing, and from an initial handful of projects, now we had to deal with thousands of projects and non-stop builds at any given time. As a result, we had to manage hundreds of CI pipelines used for security purposes.

Let’s see some numbers of what we observed in our environment. Every 24h of a working day were about 950 new pull requests (PR) with nearly 1.85 commits per PR. During working hours, automated scans were executed 3–4 times per minute, on average, against various projects. The chart below presents how many security scans were performed on the 14th of July 2022 every 30 minutes.

With those numbers, we faced another challenge — triaging all of the security findings. These scans produced a high number of false positive vulnerabilities that had to be manually triaged by the security team.

Initially, we didn’t think scanning every software change was the way to go, we should only be scanning the changes intended for the Production environment. We did the analysis and concluded that about 81% of the commits had a final destination to the main branch, and we were facing the same challenge. Our scanners would be completing at least three successful security scans on a software change every minute! This amount of scans would still result in a potentially high number of false positives, which had to be reviewed and triaged within a certain period of time. Not only that, but more and more security scanners within CI/CD pipelines would affect their timelines negatively.

So we thought: ‘Do we really have to go in this direction? Do we have to manage all of the pipelines for various projects and triage all of the identified security issues within the AppSec Team? Do we have to affect CI/CD timelines negatively?’

At this point, we had a lot of doubts and questions about this approach. In the Application Security team we understood this approach wouldn’t be scalable in a fast-paced environment such as Revolut. We could implement some small improvements to address each of these questions. However, those improvements could just delay bigger problems for later on. At this point, we decided to go in a slightly different direction, having a security-shift-left approach in our minds. Security static analysis tools can easily be shifted left to an earlier phase in the SDLC, since these types of tools don’t require the application to be running.

Second solution — Security Drone

You may expect as a second solution something extremely smart and well-designed. So did we. But it didn’t take long for us to take an agile approach with lean implementations. We also started security shifting left and communicating security issues to developers as early as possible, before going into testing or production environments.

At the beginning of our MVP solution, we decided to scan code changes during the pull request phase. In our opinion, it was a natural step for engineers to propose software changes for their colleagues to approve. At this point, we also decided to communicate all of the identified security findings to developers. The scanner’s results could be taken into account during code review, which is an integral part of the development process in Revolut. It should be noted that our scanner was triggered when a new PR was created or code was updated in an already existing PR. We also decided to place Security Drone in a Kubernetes cluster to scan the code independently from CI/CD pipelines and have a centralised scans management. In many cases, independent scans were able to deliver results to developers faster than CI jobs were finished.

Initially, we implemented only a SAST scanner solution to make the process as fast as possible, to quickly deliver results to developers. We aimed to provide results in under 300 seconds. We carefully researched available SAST solutions to choose the most suitable one for our needs. It had to be fast, well-documented and allow us to write custom rules to identify potential security issues specific to our environment. Last but not least, we wanted to achieve the lowest possible false positive rate to avoid producing irrelevant findings, to limit the amount of manual work that we had to cope with during triaging. But not only that, as we had decided to communicate all of the identified security findings to developers at the PR page, we had to make sure not to affect their experience negatively by reviewing a number of irrelevant findings.

Later, we started implementing new scanners in Security Drone such as Software Composition Analysis and Infrastructure as Code to bring more value to the automated security testing. Security Drone’s high level architecture is presented below.

Currently, we scan all pull requests created by Revolut engineers. In July, Security Drone performed over 39,000 scans. Median scanning time is below 112 seconds and the average is below 110 seconds. Initially, we used 19 SAST and 63 IaC rules. Only high and critical SCA issues were directly reported to our developers. Our first MVP was released in Q1 2022, extended and adjusted in the last months. Now, Security Drone has been operating in production for the last eight months without issues on both the operational and engineering distribution sides.

We use the following tools in Security Drone:

• Semgrep — Static Application Security Testing
• Snyk Open Source — Software Composition Analysis
• Checkov — Infrastructure as a Code

What have we achieved with Security Drone?

1. We have adopted a shift-left approach to security to identify and communicate security findings earlier in the SDLC, before going into testing or production environments
2. Security issues can be fixed before going into production, and as a result, they don’t have to be manually triaged by AppSec Team members
3. Only merged security issues are reported to the AppSec Team to triage and loop into the vulnerability lifecycle process
4. We lowered the false positive rate by carefully choosing the SAST solution and continual tuning of rules. We were able to achieve ~3.8% FP rate!
5. Our centrally managed scanner currently scans 100% of the code in Revolut which saves us hundreds of hours of manual reviews. Here are some numbers from last 24 hours:
   • Nearly 1700 pull requests were scanned
   • Over 3900 scans associated with above PRs were performed
6. Ability to find new vulnerabilities in other applications based on patterns
7. The scans are fast and don’t disrupt the developer experience. They’re executed in parallel and scanning times are presented below:
   • Median scanning time for SAST is 11 seconds
   • Median scanning time for IaC is 22 seconds
   • Median scanning time for SCA is 101 seconds
8. Increased security awareness and continuous learning amongst engineers. They’re also aware of the direction that AppSec is moving.

What is next?

Security Drone will always be under development as new technologies are emerging and improvements to the development experience can be made. On our roadmap we have various points, some of which include:

• Ability to flag findings as a false positive in a developer-friendly way
• Incremental SAST scans — scan only code changes in PRs
• Integration of more security scanners and the development of more SAST/IaC rules

Keep your eyes peeled for our next blogpost around Application Security in Revolut, as we may share more interesting tools and guides on how we solve the challenges we face every day.

Credits

Credits go to every Revolut AppSec engineer involved in the design and development of Security Drone, especially:

Arsalan Ghazi, Krzysztof Pranczk, Pedro Moura, Roger Norton

Security Drone: scaling continuous security at Revolut. was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever heard about the Coordinator pattern? Good for you, this article isn’t about it. I’m here to open your eyes to Custom Navigation Engines just like the one we created on our Revolut Flow Engine.

First let’s talk about some traditional approaches for navigation before we get into our Flow engine:

Storyboard actions navigation

The most traditional way of doing navigation with storyboards is the one that’s triggered by an action. As you know, you can ctrl + drag from your button to reach the desired screen on your storyboard.

Segue driven navigation

Another traditional type of storyboard navigation are segues, by doing ctrl+drag from one view controller to another we create a connection of a certain type (push, modally, etc) and assign it an ID.

ViewController code driven navigation

The most traditional way outside storyboards, is to instantiate and push or present your view controllers programmatically.

Flow Engine

Now let’s bring out the big guns: the abstraction of navigation outside view controllers.

Why do we need to abstract navigation? Well, imagine you have a FoodDeliveryApp and in there you have a screen called ProductDetails that shows the information for a given product (Hamburger 🍔, fish and chips 🍟, etc) — but you want to call this screen and its dependencies from anywhere. Will it be enough to just instantiate the screen everywhere, with its dependencies and its actions? 🤯 of course not! 😅

Wait, what? Don’t worry, here’s some code:

When we want to call our ProductDetail screen and pass its business actions through dependency injection, we end up doing this:

Code looks clean to you? Well, kind of 😅. What happens when you need to show that product page from other view controllers and handle its actions? .showRelatedProduct and .addToOrder? Copy and paste this implementation? 😢 Of course not!

What if you could abstract this so you only call some magic method? Let’s say runProductDetailsFlow(productId:_) with actions and dependencies of this screen abstracted in that layer? Well, without further ado:

Basically as the name says, it’s an engine (state machine) to handle a flow (set of steps). A carefully crafted state machine created by our own Revolut Legend Ilya Velilyaev. Let’s start with the backbone of it:

After having your FlowEngine (feel free to copy and paste that file, and use it to create great flows in your apps 🚀), you can create Flows for your different business cases. Let’s go back to our FoodDelivery app example and create a flow to show ProductDetail with its dependencies and business actions abstracted! 🎉

Once you create and define yourFlow with its steps and initial State, you need to create aFlowPerformer — the one who will actually execute these steps and their logic.

When you have your FlowPerformer you can proceed to create your magic maker FlowRunner — this is the one that allows you to call as one liner: flowRunner.runProductDetailFlow(...) :

Finally from anywhere in your code (most preferably from other flows), you can call as many flows as you like while avoiding code duplication and have an easier TDD approach to your code.

That’s it, hope you enjoyed and that you start controlling, testing and abstracting your navigation in your apps 🚀

iOS Screen Navigation Engine at Revolut was originally published in Revolut Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.