Web app considerations for fintech products

Building a fintech web app is mostly the same as building any other web app, right up until it isn't. The 20% that's different (money math, compliance, fraud, audit trails) is the part that quietly sinks projects, blows up timelines, and turns a tidy MVP into a multi-quarter slog. This is a plain-spoken tour of what to think about before you write a line of code, written for the person signing the invoices.

Decide what kind of fintech you actually are

The first question isn't technical. It's regulatory. "Fintech" covers everything from a budgeting dashboard that reads bank data to a product that actually holds customer money, and those two live in different universes.

If you touch, store, or move funds yourself, you are likely in money transmission or e-money territory, which means licensing, capital requirements, and a compliance officer. Most startups avoid this by sitting on top of a regulated partner. In the US that's a Banking-as-a-Service provider or a processor like Stripe Treasury or Unit. In Europe it's an e-money or payment institution that sponsors you. This single decision shapes everything downstream, so make it deliberately and write it down.

A useful rule of thumb

The less money you hold, the cheaper and faster you ship. A product that never touches funds (read-only account aggregation, analytics, lending decisioning) can launch in a few months. The moment you custody balances, add 3 to 9 months and a real legal budget. Founders consistently underestimate this gap.

Money is not a float

This sounds basic and it ruins production systems anyway. Never store money as a floating-point number. 0.1 + 0.2 does not equal 0.3 in JavaScript, and that rounding error becomes a reconciliation nightmare at scale.

Store amounts as integers in the smallest currency unit (cents, pence) plus an explicit currency code. In Postgres use bigint or numeric, never float or double. In your TypeScript layer, wrap money in a type so you can't accidentally add USD to EUR.

// amount is always an integer count of minor units
type Money = { amount: bigint; currency: "USD" | "EUR" | "GBP" };
 
const fee: Money = { amount: 250n, currency: "USD" }; // $2.50

Pair this with an append-only ledger. You don't update a balance row in place. You record immutable entries (debits and credits) and derive the balance by summing them. This gives you a provable history, makes reconciliation possible, and means a bug can be traced rather than guessed at. Double-entry bookkeeping is 600 years old because it works.

Treat the audit trail as a feature, not a log

In a normal app, logs are for debugging. In fintech, the audit trail is a product requirement and sometimes a legal one. You need to answer "who did what, to which account, when, and why" months later, including actions taken by your own staff and your support tools.

Build this in from day one. Retrofitting it means reconstructing history you no longer have. Keep it tamper-evident (append-only, timestamped, ideally with a hash chain) and separate from the operational data it describes. When an auditor or a regulator asks, you want to hand them a clean answer, not a developer spelunking through Datadog.

Authentication, authorization, and the boring stuff that matters

Auth in fintech is higher stakes, so a few specifics:

• Step-up authentication. Logging in is one bar. Moving money should be a higher one. Require re-authentication or a second factor for sensitive actions, not just at session start.
• Real authorization, not just authentication. Knowing who someone is differs from knowing what they may do. Most fintech breaches we've seen up close are broken object-level access (user A reading user B's transactions by changing an ID in the URL), not stolen passwords. Check ownership on every single request.
• Session and device awareness. Track devices, flag new ones, and let users see and revoke active sessions.
• Don't roll your own. Use a vetted provider (Auth0, Clerk, AWS Cognito, or a well-maintained library) and spend your energy on the authorization logic that's specific to your domain.

KYC, fraud, and the parts users hate

If you onboard customers who move money, you'll need identity verification (KYC) and anti-money-laundering checks. You buy this, you don't build it. Providers like Persona, Onfido, or Alloy handle document checks and watchlist screening. Budget both money and UX attention here, because a clumsy onboarding flow kills conversion faster than almost anything.

Fraud is a moving target and partly a data problem. Early on, sensible rules plus a third-party screening tool are enough. Don't build a machine-learning fraud engine for your first thousand users. You don't have the data to train it and you have better things to do.

Compliance scope: PCI, SOC 2, and friends

A few acronyms worth understanding before a sales call surprises you:

• PCI DSS applies if card data touches your systems. The cheap path is to never let it: hand card entry to Stripe Elements or a hosted field so the raw number never reaches your servers. This drops you into the simplest compliance tier and saves enormous effort.
• SOC 2 isn't a law. It's an audited report that enterprise customers and banking partners will demand before they trust you. A Type II report takes an observation window (often 3 to 6 months) plus prep, so start early if you're selling to businesses.
• Data residency and privacy. GDPR, CCPA, and regional rules affect where you store data and how you delete it. Decide your hosting regions deliberately.

Rough timelines and costs (clearly rough)

Every project differs, so treat these as order-of-magnitude, not quotes.

• Read-only or decisioning product (no funds held): roughly 3 to 5 months to a real launch with a small senior team.
• Product that moves money via a BaaS partner: roughly 6 to 12 months, with a chunk of that spent on partner integration, compliance, and reconciliation rather than the UI everyone gets excited about.
• Ongoing compliance (SOC 2, audits, monitoring): a recurring annual cost in the low five figures and up, not a one-time line item.

The pattern to notice: the visible app is often the smaller half of the work. Reconciliation, edge cases in money movement, failed-payment handling, and audit requirements eat the rest. An agency that only quotes you the screens hasn't priced the hard part.

What to watch out for

A short list of things that bite people:

• Webhooks and payment events arrive out of order, twice, or not at all. Design every money operation to be idempotent so a retried event doesn't double-charge anyone.
• "We'll add compliance later" almost always costs more than building it in.
• Background jobs and reconciliation are where bugs hide, because nobody's watching them on a Tuesday night. Invest in alerting.
• Pretty dashboards are easy to demo and easy to overweight. The ledger underneath is what actually matters.

The takeaway

Get four things right early and the rest gets easier: store money as integers in a ledger, keep an immutable audit trail, sit on a regulated partner unless you have a strong reason not to, and check authorization on every request. Decide your compliance scope before you build, not after a customer asks for your SOC 2 report. The fintech web app considerations that trip teams up are rarely the flashy ones, so spend your care on the plumbing.

If you'd like a second pair of eyes on the architecture before you commit to it, that's the kind of thing we're happy to talk through.