How to build a fintech app: compliance and architecture

Founders and product teams usually arrive with wireframes. That's the wrong place to start. The parts of a fintech app that are hard, slow, and expensive to change are the parts users never see — and they have to be designed first, because everything else is built on top of them.

Start with compliance, not screens

Compliance isn't a phase near launch; it's a set of constraints that shapes the architecture from day one. Before design, work out which of these apply to your product, market, and users:

• PCI DSS if you touch card data. The cheapest way to comply is usually to touch as little of it as possible — tokenise through a provider so raw card numbers never reach your servers or the device.
• KYC and AML for onboarding and monitoring. Identity verification, sanctions screening, and transaction monitoring aren't features you bolt on — they're flows woven through onboarding and payments.
• PSD2 / strong customer authentication for European payments, and equivalent local rules elsewhere, which mandate multi-factor authentication for many transactions.
• GDPR and, in India, the DPDP Act for personal data — lawful basis, retention, and user rights.

Map each obligation to a concrete control in the build, in writing, before you start. Retrofitting compliance after a failed audit is one of the most expensive ways to build a fintech app.

The architecture that follows

Once you know the constraints, a fairly standard shape falls out for most mobile-first fintech products:

A secure API layer in front of the system of record

The app should never talk directly to a core banking system or ledger. A secure API layer sits between them, handling authentication, authorisation, tokenisation, rate limiting, and audit logging. This layer is where most of the real engineering lives, and it's what lets you modernise the customer experience without touching the core — a pattern we lean on heavily in our fintech and banking work.

Minimise sensitive data on the device

Treat the phone as hostile. Tokenise card and account data so the device holds references, not raw values. Use the platform's secure storage for anything sensitive, pin certificates to prevent interception, and add a force-update mechanism so you can retire a vulnerable client version quickly.

Everything auditable

In finance, "what happened and when" is not optional. Design the audit trail into the API layer from the start — every meaningful action logged, immutable, and traceable.

Authentication and transaction integrity

This is where fintech apps earn or lose trust, and where cutting corners is most dangerous.

• Multi-factor authentication, with biometrics for convenience and a fallback that doesn't undermine the security biometrics provide.
• Transaction signing so a payment can't be replayed or altered in transit — the value and recipient are cryptographically bound to the request.
• A second factor on sensitive actions — a push approval or one-time passcode — and, crucially, reconciling that factor across the app, the API layer, and the core. Getting the session lifecycle and OTP reconciliation right across the whole stack is subtle, and it's where a lot of otherwise-good apps break.

Integrate the core; don't replace it

If you're building on top of an existing bank or processor, the goal is almost never to replace the core system of record — it's to build a modern experience in front of it. An anti-corruption layer translates between the clean, modern API your app wants and the older interfaces the core exposes, so the core stays untouched and the programme can't be derailed by a migration nobody signed up for. This is the same "modernise around the core" principle behind legacy modernization generally.

A sane build sequence

Order matters. A sequence that consistently works:

1. Map compliance to controls in a written scope before design.
2. Threat-model the auth and money flows — where value moves, the review goes.
3. Prove the hardest integration first. Spike the connection to the core and the auth flow before feature work, because that's where the unknowns are.
4. Build the app in short cycles on top of a proven integration and a real design system.
5. Independent penetration testing and remediation before launch, not after.
6. Phased rollout against a live cutover, with monitoring and fraud alerting on from day one.

Notice how little of that is about screens. The UI matters — it's what customers judge you on — but it's the last mile of a build whose success was decided much earlier.

Building a fintech app is mostly a compliance-and-architecture problem wearing a UI. We build secure mobile banking and fintech apps on existing cores, to the bar of a real financial institution. If you're scoping one, the most valuable first step is mapping your compliance obligations to a concrete architecture — before anyone designs a screen.