Build the ledger first

How to build a fintech app that regulators and users both trust

The practical answer to how to build a fintech app is to settle three questions before writing a schema: which licensing route you are taking, how the ledger records money, and what every state change writes to an audit log. Those three decisions set the boundary between the controls your app owns and the ones it inherits from a partner. Most other choices in fintech app development, including the stack, the onboarding flow and the card issuing partner, can be revised later at reasonable cost. These three cannot.

The pressure to move fast is real. Mordor Intelligence puts the global fintech market at $320.81 billion in 2025, heading to $652.80 billion by 2030 at a 15.27 percent compound annual growth rate.¹ The pressure to move carefully is equally real, and it arrives from two directions at once: supervisors who want evidence, and users who have already decided that most fintechs are less safe than a bank.

What the fintech trust gap actually looks like

Consumers separate “I use it” from “I trust it with my money”. In 2025, US adults said they trust banks to protect them from fraud at 50 percent, against 8 percent for non-bank fintech payment providers and 2 percent for crypto companies.² Even customers who say they trust their bank hold reservations, with 58 percent worried about hacking risk and 53 percent about privacy.³

That gap is the product opportunity. A fintech that can show its controls rather than assert them converts better and holds users longer. Showing them is an architecture problem.

Why licensing strategy comes before architecture

Choose the licensing route first, because it decides which controls your codebase owns. Two broad paths exist. You partner under a sponsor bank through a Banking-as-a-Service provider, inheriting their charter and much of their compliance function, or you pursue direct licensing, such as a money transmitter license in every state where you operate.

The sponsor bank route is faster and the partner absorbs part of the regulatory load, but the obligation does not disappear. Sponsor banks push their own control requirements down into your product: onboarding standards, transaction limits, reporting formats, and the right to audit you. You are building to a private supervisor as well as a public one. Direct licensing costs more time and capital and puts every control in your scope, but it removes a single point of dependency and the risk of a partner leaving the segment.

The failure mode is choosing a route after the build. A team that architects for a partner model and then moves to direct licensing finds that reconciliation, settlement timing and customer-of-record data were all modelled around someone else’s system. That is a rewrite, not a refactor. An engineering team should treat the licensing decision as a requirements document, not a legal footnote.

Why the ledger is the product, not a backend detail

Build an immutable, append-only double-entry ledger in the first sprint. An immutable ledger is a record system where entries, once written, cannot be altered or deleted; corrections happen by appending a new offsetting entry. Double-entry means every movement of value writes matched debit and credit entries, so the books always balance and any imbalance surfaces as a detectable defect rather than a silent data quality problem.

Teams that skip this usually start with a balance column on the user table and increment it. That works until the first dispute, the first partial refund, the first chargeback that lands three weeks after the original transaction. At that point nobody can reconstruct what the balance was on a given date or why it changed, which is exactly the question an auditor asks.

The practical test: can you answer “what was this user’s balance at 14:32 on 03-Mar-2026, and which entries produced it” with a single query against production data, no spreadsheet involved? If yes, audits become a reporting exercise. If no, every audit becomes an engineering project. Retrofitting a ledger after launch generally means a full data migration with historical reconstruction, which is why it belongs in the first release rather than the second year.

An audit you can answer with a query is a cost line. An audit you have to reconstruct is a crisis.

KYC and AML: a pipeline, not a gate

KYC, know your customer, is the identity verification process that confirms who a customer is before they transact, using government ID, biometric or database checks. AML, anti-money laundering, is the ongoing set of controls, monitoring and reporting obligations that detect and prevent illicit funds moving through the product. The common design error in fintech compliance is treating both as a single onboarding screen.

Onboarding verification is a point-in-time check. Laundering patterns are temporal: structuring below reporting thresholds, rapid pass-through of funds, a dormant account that suddenly moves volume, networks of accounts that only look suspicious in aggregate. None of that is visible at signup. Build KYC and AML as a risk-scoring pipeline that re-evaluates every user and every transaction against behavioural signals, with tiered outcomes rather than a binary block.

The enforcement backdrop is easing but not benign. Global AML, KYC, sanctions and customer due diligence penalties totalled $3.8 billion in 2025, down from $4.6 billion in 2024 and $6.6 billion in 2023.⁶ The largest single penalty of 2025 was $985 million against a Swiss bank for AML failings, issued by French authorities.⁶ Total value is falling while individual actions stay large enough to end a company.

What audit trail requirements apply to a financial app?

Every state change needs a timestamped, attributable log entry: balance movements, permission grants, KYC status transitions, limit overrides and any manual intervention by support staff. Attributable means the record names which human or service made the change, not just that it happened. An examiner cannot credit a control they cannot see evidenced, and evidence cannot be created after the fact.

What to log, at minimum

• Money movement: every debit and credit, with the initiating actor and the request that caused it.
• Identity: each KYC status change, the evidence relied on, and the decision maker or model version behind it.
• Access: every staff read of customer personal data, with a stated reason code.
• Configuration: changes to limits, fee schedules, risk thresholds and any feature flag that touches money.
• Overrides: any manual action that bypasses an automated control, with the approver named.

Logs also need retention matched to the applicable regulatory period and tamper-evidence, which usually means write-once storage or cryptographic chaining. This is the same discipline that governs regulated health software; the reasoning behind building a HIPAA compliant app transfers almost directly, with different retention periods and a different regulator.

Compliance as code

Faster-moving teams are replacing the manual pre-launch compliance review with automated policy checks in the CI/CD pipeline: tests that fail a build when a money-moving endpoint lacks an audit hook, static checks for personal data in logs, and evidence records generated on every deploy. That does not remove the compliance officer. It removes the queue.

What does fintech app development actually cost?

A fintech MVP with KYC and banking integrations typically costs $75,000 to $150,000 and takes six to eight months, with compliance work driving much of the timeline.⁷ Mid-scale builds carrying the same integrations reach roughly $300,000 at the upper end.⁸ PCI DSS compliance on its own adds $15,000 to $50,000 for initial implementation, plus annual recertification.⁸

The figure that surprises founders is the recurring one. Post-launch costs for APIs, audits, hosting and licensing run $30,000 to $100,000 or more per year.⁸ A fintech is not a build with a maintenance tail. It is a subscription to being regulated.

Which fintech app features belong in the first release?

The test for a first-release feature is not user demand. It is whether adding it later damages the record.

Rewards, budgeting insights, social features and tailored recommendations are second-release decisions. Fraud controls need one caveat: they belong in the first release, but they should be adaptive rather than blunt. Step-up authentication triggered by a risk score keeps friction proportionate, so low-risk users get a fast path and the checks concentrate where the signal is. Risk models built with applied AI can carry that scoring, provided every decision is logged with the model version that produced it.

A build sequence for how to build a fintech app without rework

1. Licensing decision. Sponsor bank or direct licensing, in which jurisdictions, with which product permissions. Write it down as a constraints document the architecture has to satisfy.
2. Ledger and audit design. Chart of accounts, entry types, reversal semantics, retention, and the log schema for every state change. Review it with whoever will answer the first audit.
3. Core money movement. Build against the ledger, not around it. Add the KYC pipeline with tiered outcomes and the monitoring rules that will run from day one.
4. Evidence and controls. Policy checks in CI/CD, penetration testing, PCI DSS scope reduction, and the reporting queries an examiner will ask for.
5. Monitoring calibration. Tune thresholds against real volume, review false positive rates, and keep model versions and rule changes inside the audit record.

The order matters more than the calendar, which will move. Licensing before architecture, ledger before features, evidence before launch. Teams that follow that order tend to spend their compliance budget once. Teams that invert it spend it twice, and the second time to a deadline someone else sets. If you are weighing routes and want a second read on the trade-offs, talk to our team.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.