How to Make an App Like Revolut

Building a fintech app at Revolut's scale is a serious engineering undertaking. This post breaks down the architecture, compliance requirements, and technology decisions you'll face — so you can plan realistically, not optimistically.

What Does "an App Like Revolut" Actually Mean?

Revolut is not a single app. It's a regulated financial institution operating across 35+ countries, with a banking licence in the EU, an e-money licence in the UK, and broker-dealer registrations in several markets. The consumer-facing app sits on top of a microservices platform that handles currency exchange, card issuing, crypto trading, savings, stock trading, and business accounts.

When a client says "build something like Revolut," what they usually mean is one of three things:

• A multi-currency wallet with real-time FX conversion
• A neobank with card issuing, account management, and payment rails
• A full financial super-app with multiple product verticals

The architecture for each of those is meaningfully different. Get clear on the scope before you write a line of code.

What Are the Core Technical Components?

Payment Rails and Banking Infrastructure

You will not build payment rail integrations from scratch. The realistic options are:

Provider	What They Give You	Typical Use Case
Modulr / ClearBank	UK sort code, Faster Payments, BACS	UK neobank MVP
Railsbank / Synctera	BaaS with card issuing + accounts	Multi-market launch
Stripe Treasury	Embedded finance APIs	US-focused products
GPS (Global Processing Services)	Mastercard/Visa card issuing	Full card programme

Revolut itself started on top of Wirecard before building proprietary card infrastructure. Most teams underestimate how long card programme setup takes: plan for 4–6 months minimum just for card issuing agreements, regardless of the technical work.

Multi-Currency and FX Engine

A real-time FX engine has two distinct problems: pricing and settlement.

For pricing, you need a live interbank feed. Common sources are XE, Open Exchange Rates (free tier is rate-limited), or a direct Reuters/Refinitiv feed if you're doing volume. Revolut's margin on FX was historically 0.5% on weekdays and 1% on weekends, because interbank markets close and the spread widens.

For settlement, you need to hold nostro accounts in each currency or partner with a liquidity provider. This is a treasury problem as much as a tech problem, and it's where many fintech MVPs quietly punt to a BaaS provider rather than managing it directly.

Core Banking System

You need a ledger. A proper double-entry accounting ledger, not a database table with balances. Temenos, Mambu, and Thought Machine Vault are the established options. Mambu is the most common choice for startups because it's modular and has reasonable API coverage. Vault is more powerful but takes longer to implement.

For an early-stage product, some teams build a lightweight ledger in PostgreSQL using append-only transactions with strict constraints. This works until it doesn't — typically around 500,000 monthly active users, when reconciliation complexity overtakes the engineering team's capacity to manage it manually.

Mobile App Architecture

Revolut ships on iOS and Android with near-feature parity. The sensible build choice depends on your timeline and team.

React Native is the most common choice for early-stage fintech. You get one codebase, reasonable access to native modules for biometrics and NFC, and a large talent pool. Flutter is the better choice if you're building heavily animated, custom UI components. Revolut's own app uses native development on both platforms, which gives them maximum control but requires two separate engineering teams.

For authentication, implement FIDO2/WebAuthn from the start. Retrofitting biometric auth onto a session-cookie architecture is painful.

How Do You Handle Compliance Without Slowing Everything Down?

This is the question most engineering teams ask too late.

KYC and AML

Know Your Customer checks are a legal requirement in every jurisdiction you operate in. The practical options are Onfido, Jumio, or Sumsub for document verification, and Comply Advantage or Acuris for sanctions screening and PEP checks. These are not optional; operating without them is a criminal offence in most markets, not just a regulatory violation.

Automated KYC covers roughly 85–90% of cases. The remaining cases go to manual review. Budget for a compliance operations team from day one — the technology alone does not solve this.

PCI DSS

If you're handling card data, you need PCI DSS Level 1 compliance if you process more than 6 million card transactions annually, or Level 2 for 1–6 million. Most early-stage products should use a tokenisation-first approach: card numbers never touch your servers. Stripe, Adyen, and GPS all offer card vaulting so your scope is limited to the tokenised reference.

Data Residency

GDPR mandates that EU user data either stays in the EU or is transferred under an approved mechanism (Standard Contractual Clauses, adequacy decisions). If you're using AWS, use eu-west-1 or eu-central-1 and set your RDS, S3, and SQS resources explicitly. The default region in most SDKs is us-east-1, and this has caught teams out.

The Architecture Decisions That Will Hurt You Later

Two decisions cause the most long-term pain.

Synchronous money movement. Every financial transaction should be modelled as an event, not a synchronous API call. If your transfer endpoint does debit, credit, and notification in a single HTTP request, you will have consistency bugs under load. Use Kafka or RabbitMQ to decouple the stages. A debit event and a credit event should be independently committed and reconcilable.

Ignoring idempotency. Every financial API endpoint needs an idempotency key. Network timeouts cause duplicate requests. Duplicate requests without idempotency handling cause double charges. This is table-stakes engineering for fintech and is frequently skipped in the first sprint.

What Does a Realistic Build Timeline Look Like?

For a multi-currency wallet with card issuing in a single market:

• Months 1–2: BaaS partner selection, banking integrations, ledger setup
• Months 3–4: KYC flow, compliance tooling, card programme agreements
• Months 5–6: Mobile app, FX engine, internal testing
• Months 7–9: Regulatory review, soft launch, penetration testing

That's 9 months to a limited launch with a focused team. Teams that try to compress this to 4–5 months typically do it by skipping compliance architecture, which either blocks their launch or creates regulatory exposure post-launch.

A full-scale multi-product platform closer to Revolut's breadth is a 2–3 year programme with an engineering team of 20–40 people.

Conclusion

Building a Revolut-like product is tractable. It's not simple, but the components are well-understood and the vendor ecosystem has matured significantly since 2015. The hard parts are compliance architecture, ledger design, and managing the dependency on third-party banking infrastructure you don't control.

The clearest next step: define which one product vertical you're launching first, choose a BaaS provider that fits that geography, and design your ledger before you design your UI. Everything else follows from those three decisions.

---

FAQ

How much does it cost to build a fintech app like Revolut? A focused MVP covering multi-currency accounts and card issuing in one market typically costs between £500,000 and £1.5 million, depending on team location and BaaS provider fees. A multi-market, multi-product platform is a £5–15 million programme over 2–3 years. Infrastructure and compliance tooling are ongoing costs, not one-time.

Do you need a banking licence to build a neobank? Not immediately. Most early-stage products operate under a partner bank's licence through a Banking-as-a-Service arrangement. This gets you to market faster but limits your product control and takes a significant margin cut. A full banking or e-money licence makes sense once you have proven volume — Revolut's EU banking licence took approximately 3 years to obtain.

What's the difference between a BaaS provider and a core banking system? A BaaS provider gives you a regulated banking infrastructure through APIs — accounts, payments, card issuing — and handles the regulatory overhead. A core banking system is software you run yourself to manage your own ledger and product logic. Most early-stage fintechs use BaaS. Later-stage ones migrate to a core banking system when they want more control and the BaaS margin becomes material.

Can React Native handle the security requirements for a fintech app? Yes, with the right libraries. Use react-native-keychain for secure credential storage, implement SSL pinning with react-native-ssl-pinning, and ensure your CI pipeline runs static analysis with tools like Semgrep. The gap between React Native and native in terms of security surface area is small if you configure it correctly. The bigger risk is developer error, not the framework itself.

How do you handle fraud detection at scale? Rule-based systems (velocity checks, device fingerprinting, geo-anomaly detection) handle the majority of fraud cases and are straightforward to implement. ML-based scoring models become worthwhile once you have 6–12 months of labelled transaction data. Most early-stage products are better served by a vendor like Feedzai or Sift than by building custom models before they have the data volume to train them meaningfully.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.