Introduction: Bolt’s scale and the need for fraud checkpoints

Bolt operates large-scale businesses across ride-hailing, food delivery, and micromobility, spanning over 50 countries. Each business vertical involves multiple participants — riders, drivers, couriers, and restaurants — all connected through millions of transactions every day.

Wherever money moves, so does the risk of fraud. Every transaction, signup, or delivery step can become a potential attack vector — from fake accounts and stolen cards to multi-party fraud and promotion abuse.

To protect against these threats, Bolt has developed an anti-fraud platform built on a generic, reusable framework. This framework enables fraud analysts to design, monitor, and fine-tune detection logic efficiently, without requiring deep engineering involvement.

At the core of this system are fraud checkpoints — structured flows that collect data, evaluate risk, and make decisions in real time.

This article walks through how Bolt’s checkpoints evolved — from custom code and overengineering to a balanced approach combining flexibility and simplicity.

What is a fraud checkpoint?

In our fraud prevention platform, a checkpoint is a flow for evaluating business activity (like a transaction, login, or signup). A checkpoint can:

Collect additional data (business entities' data, statistics, ML predictions)
Run dynamic rules
Make a decision (approve / decline / review)
Save information for auditing and monitoring

The made decision is a primary outcome of fraud checkpoint work.

Checkpoint lifecycle

As of today, Bolt has ~60 checkpoints, developed over the last 8 years. Each checkpoint may have dozens of rules tailored to its specific use case.

Part 1: How it started

One checkpoint, one custom implementation

We began with a single checkpoint. It was an all-in-one block that did everything, i.e. all steps mentioned above in one block (class).

Copy-paste scaling

The second checkpoint arrived, followed by the third. We copied the first checkpoint, tweaked it, and repeated the process. It quickly became apparent that we needed to extract common parts.

Why maintenance and refactoring are important

Code is read far more often than it is written. That means the real cost isn’t just in creating it, but in how easily others (or even you in 6 months) can read, understand, and work with it.

Over time, every system changes. Business rules shift, new features appear, and technology evolves. Without regular maintenance and refactoring, the codebase slowly drifts out of shape.

Think of it like health checkups, dentist visits, or servicing your car. Skip them long enough, and minor issues turn into painful surprises. A small cavity becomes a painful toothache, worn brake pads turn into a dangerous breakdown, and suddenly you’re stuck on the side of the road waiting for a tow truck.

Software is no different. Neglecting maintenance may seem fine for a while, but sooner or later, the “engine light” comes on. And when it does, the cost of emergency repairs is always higher than the cost of regular care.

Refactoring is our preventive medicine. It keeps the system healthy, reduces risks of sudden failure, and ensures that when change inevitably comes, the code is ready to adapt.

First refactoring: extracting common flow

We introduced the Builder pattern:

Customisable parts → data loaders, decision logic, result logging
Shared library → rule evaluation, flow orchestration

Part 2: How we went for the ETL framework

The A/B testing requirement

We needed to experiment with keeping or dropping rules and see how that changed the decision outcome.
That sparked the idea: checkpoints resemble an ETL pipeline.

From fraud-specific towards a generic framework

We modified the builder to support this ETL style and tried to make it domain-agnostic so that:

Other teams could reuse it.
It can be configured without engineers (via the database and web forms).

⠀The reasoning was simple:

If a checkpoint can be defined through configuration, then we no longer need to copy and paste code every time a new checkpoint is added.
Configuration implies flexibility: we can change flows by updating stored rules, thresholds, or actions — without needing to rebuild and redeploy code.
In theory, this reduces engineering involvement for repetitive work and lowers long-term maintenance costs.

And to be fair, this worked in some areas.
For example, we successfully delegated the maintenance of fraud rules to analysts. They could tune, add, or remove rules themselves without waiting for an engineering team to take it into development. That was a significant win: it accelerated experimentation and made the fraud system more responsive to new attack patterns.

But trying to extend the same idea to the entire checkpoint lifecycle (data enrichment, orchestration, decision flows) backfired.

Instead of classes and objects, engineers had to manipulate strings and flags.
Debugging became more challenging, as logic was spread across both code and database entries.
Complexity grew, and the original goal of simplicity drifted away.

Part 3: How we went back to simplicity

Observing the state

Returning to the system after a break, we realised:

Cognitive overload was everywhere.
Multiple adapters were doing the same thing.
Onboarding was painful.

Ironically, the “no-engineer config” idea had increased complexity.

Discussions and reset

We aligned on a new goal:
Prioritise Developer Experience (DX) over extreme flexibility.

Benefits of simplification

Faster onboarding → easier to explain to new hires.
Clearer architecture → fewer adapters, single APIs.
Lower maintenance cost → easier to debug, extend, and support.

Conclusion: finding the balance

The checkpoint journey followed a familiar pattern:

Start simple → custom implementation
Add abstraction → builder pattern
Drift into overengineering → ETL framework + config-driven system
Return to simple builder pattern abstraction → focus on clarity and maintainability

The idea behind a config-driven system was attractive:

If a checkpoint can be expressed in configuration, we avoid copy-paste code.
Fraud rules were a real success story here — analysts could own them, engineers could step back, and the system became more agile.

But not everything benefits from being configurable.
When we applied the same idea to the entire checkpoint lifecycle, the cost outweighed the benefits:

Config replaced code, but added complexity (strings, flags, hidden logic).
Debugging and maintenance became harder, not easier.
The promise of “no engineer involvement” increased the cognitive load for engineers.

The lesson we learned:

Flexibility is powerful — but only when applied to the right place.

Delegating rule maintenance to analysts worked. For core checkpoint architecture, simplicity and clarity worked better.

By returning to a lean, developer-friendly design while keeping rules flexible, we achieved the right balance: agility for analysts, maintainability for engineers, and resilience for the business.

Fraud checkpoints: from overengineering to simplicity — and where flexibility works

We’re hiring!

Recent posts

Safety amplified: unveiling the new audio trip recording feature