Sean Weldon
September 22, 2026
8
min. read
and updated on:
September 22, 2026
A fintech application is a conventional application with four additional obligations layered on: correctness of financial records, regulatory compliance, identity verification, and a security posture that will be examined by parties other than your customers. Those four are what make fintech builds cost 40 to 80 percent more than functionally comparable non-regulated products.
Understanding which of the four apply to your product is the difference between a realistic budget and a surprise in month four, because a personal finance app that only reads data has a very different obligation set from one that holds a balance.
First, establish what your product actually does to money
Four categories with sharply different requirements. Place yourself precisely.
Read-only financial data. Aggregating accounts and displaying balances, transactions, budgets, and insights. No money moves. Obligations centre on data security, consent, and the terms of your aggregation provider. This is the lightest category and the one most personal finance products occupy.
Payment acceptance. Taking card or bank payments for goods or services. PCI DSS applies, and its scope depends almost entirely on your architecture. Using a hosted payment provider so card data never touches your systems reduces obligations dramatically compared with handling card numbers yourself.
Money movement between parties. Transfers, payouts, marketplace settlement. Requirements escalate: identity verification, transaction monitoring, ledger integrity, and in many arrangements a licensed partner or a money transmission analysis. This is where legal counsel becomes a prerequisite rather than a precaution.
Holding customer funds or extending credit. Licensing, sponsor bank relationships, and regulatory examination. The software is the smaller half of the problem.
Most founders describe category three and are legally prepared for category one. Establishing the boundary is the first deliverable of any competent fintech discovery process.
The ledger, which is where correctness lives
The most common serious defect in fintech applications is not a security failure. It is a balance that can be wrong.
Storing a balance as a number and updating it is how this happens. The correct approach is double-entry: an immutable, append-only record of entries where balance is derived rather than stored, every movement has an offsetting entry, and nothing is ever updated or deleted. A correction is a new reversing entry, not an edit.
Alongside that, three practices are non-negotiable. Integer minor units rather than floating point, because floating point arithmetic on currency produces cent-level errors that compound and are difficult to explain to an auditor. Idempotency keys on every write operation, so a retried request cannot double-post. And database transactions with appropriate isolation around any multi-step financial operation.
Reconciliation is the companion discipline: an automated daily comparison of your ledger against your provider's records, with discrepancies alerting a human. Products without reconciliation discover problems from customers.
PCI DSS scope, and how to keep it small
PCI DSS applies to anyone handling payment card data, and its burden varies enormously with architecture. The strategic goal is to minimise scope rather than to comply with the maximum version of it.
The mechanism is ensuring card data never reaches your servers. Hosted payment fields or a provider SDK collect the card, tokenise it, and return a token that your systems store instead. Your application handles tokens, which are not card data, and your compliance obligation reduces to the lightest self-assessment tier.
Building your own card capture form that posts to your backend expands scope enormously, requiring network segmentation, formal vulnerability management, and in many cases an external audit. Almost no early-stage product should do this, and any development partner proposing it should be asked to justify the decision explicitly.
Identity verification and transaction monitoring
Once money moves between parties, knowing who your customers are stops being optional. Customer identification, document verification, sanctions and watchlist screening, and ongoing transaction monitoring are provider-delivered capabilities in practice, and the engineering work is integration, state management, and handling the cases that fail.
That last part is where estimates go wrong. The happy path, a customer who verifies instantly, is straightforward. The real work is the manual review queue, the resubmission flow, the partially verified state, the customer who cannot be verified and must be declined gracefully, and the audit trail proving what you checked and when. Budget for the failure paths, which are typically 60 percent of the work in this area.
Account linking and data aggregation
Products reading bank data connect through an aggregation provider. The integration itself is well documented. The operational reality is harder.
Connections break, and they break constantly: credentials change, multi-factor prompts appear, institutions alter their interfaces. A product that treats a linked account as permanent will show stale data confidently, which is worse than showing nothing. Design for connection health monitoring, proactive re-authentication prompts, clear staleness indicators, and graceful behaviour when an institution is unavailable.
Transaction categorisation is the other underestimated piece. Provider categories are approximate, and users notice immediately when a purchase is filed wrongly. Plan for user correction and for learning from corrections.
Cost and timeline
| Product type | Build cost | Duration |
|---|---|---|
| Read-only aggregation and insights | $70,000 to $140,000 | 14 to 20 weeks |
| Payment acceptance with tokenised provider | $60,000 to $120,000 | 12 to 18 weeks |
| Peer-to-peer or marketplace settlement | $120,000 to $220,000 | 18 to 26 weeks |
| Balance-holding or lending product | $180,000 upward | 24 weeks upward |
Bolder Apps has fintech products in its portfolio including Clearcover in insurance and Spendee in personal finance, quotes MVP engagements at 8 to 20 weeks, and prices project work fixed-scope rather than hourly. Fintech builds sit at the upper end of any agency's stated range for a specific reason: compliance and reconciliation work is largely sequential and cannot be parallelised the way feature work can.
The number that most often derails a fintech budget is not the build. It is the security review. Enterprise customers, sponsor banks, and payment partners will each examine your architecture, and remediation discovered during that examination is more expensive than building correctly. Ask any development partner what they build in anticipation of it.
Choosing a development partner for fintech work
Generic app development competence is necessary and not sufficient here. Six questions establish whether a firm has actually shipped regulated financial software.
- How do you model balances? The correct answer involves an append-only ledger with derived balances. Any answer involving a balance column that gets updated should end the conversation.
- How do you handle currency arithmetic? Integer minor units. Floating point is a defect in this category.
- How do you make writes idempotent? A specific mechanism, not a general reassurance about reliability.
- How would you keep our PCI scope minimal? The answer should involve tokenisation and never touching card data, and should be volunteered rather than extracted.
- What does your reconciliation process look like? Products without daily reconciliation against the provider find out about discrepancies from customers.
- What did the last security review of your work surface, and what did you change? Every real fintech build has been through one. A firm with no answer has not shipped in this category.
Bolder Apps has fintech products in its portfolio including Clearcover and Spendee, builds backends in Node.js and Laravel, and prices project work fixed-scope rather than hourly. Named, verifiable fintech work is the relevant credential rather than a general claim of financial services experience, and it is checkable in the app stores in an afternoon.
Phasing a fintech build to reduce exposure
The compliance burden scales with what your product does to money, which means phasing is a genuine risk-reduction strategy rather than a compromise.
Phase one, read-only. Aggregate accounts, display data, produce insights. No money movement, lightest obligation set, and it validates whether users care about the core value proposition. Many products discover here that the interesting part was the data rather than the transaction.
Phase two, payment acceptance through a tokenised provider. Adds revenue capability without expanding PCI scope, provided card data never reaches your systems.
