What counts as a fintech product and what does not
Everything with money on the screen gets called fintech, and that skews estimates in both directions. The practical boundary runs along a single question: is your system responsible for the state of an account? If it only displays data received from a bank, it is an interface, and it costs what any web application costs. If it decides for itself how much money a client has and what happened to it, it is fintech, with every requirement that follows.
The layers a system is made of
The architecture of a fintech product is almost always the same, and that is good news: the argument is about details, not about structure. There are five layers, and the cross-cutting requirements — audit, monitoring, PCI scope — belong to none of them individually.
The core is a ledger, not a balance table. A balance is always a derived value: the sum of posted operations. The moment a balance becomes a column that somebody updates, you have two sources of truth and the question “why does the client show 1,000 when the operations add up to 980”, which has no good answer.
If a balance cannot be recomputed from operations, you do not know where it came from.
What the regulator requires and what of it reaches the developer
There are many requirements, but only three groups reach the code — and confusing them is expensive.
- PCI DSS — about card data. The key insight: the standard is cheaper to stay out of than to satisfy. If a card number never touches your server, and the input form belongs to the provider and hands you back a token, your assessment scope shrinks by an order of magnitude. That decision is made once and lasts the life of the product.
- KYC/AML — about who the client is and where the money came from. For a developer this is not “a passport upload form” but a set of user states (unverified, under review, verified, rejected, frozen) and rules about what is permitted in each. States are designed before interfaces.
- The audit trail — about who changed what and when. The requirement sounds dull and costs more than the rest: the ledger must be immutable, and “delete an operation” must be an impossible command. A reversal is a new record, not an edit of the old one.
Three things you cannot add later
- 01
Idempotency
The network does not guarantee a response: the client will retry, and without protection you will charge twice. How this works at the level of tables and code is a separate walkthrough — on repeated payments.
- 02
An immutable ledger
Operations are only ever appended. A correction is a reversal plus a new record, never an
update. Otherwise you can neither answer a claim nor pass an audit. - 03
Reconciliation with the provider
A daily comparison of your ledger against the bank’s statement. Discrepancies always exist; the only question is whether you find them yourself within a day or hear about them from a client a month later.
Data, migrations and growth
A fintech system cannot be stopped “over the weekend” — money has no weekends and clients have time zones. So any change to the data schema is planned as a staged transition with a rollback point: the full walkthrough is how a live database is moved without losing writes.
The third is settled even earlier and usually silently: what counts as saved. Replicas and automatic failover buy availability, but on their own they do not guarantee that a write acknowledged to the client survives a node failure — that is a separate property and it is checked separately: what happens to your data when the master dies. The isolation level answers the neighbouring question — what concurrent transactions are allowed to see of each other: isolation levels and anomalies.
The second thing worth settling early: where one database ends. A ledger grows linearly and forever, so it is partitioned by time from day one — adding partitioning to a hundred-million-row table is possible, but it is a project of its own.
Team, timeline and budget
Honest reference points below, the same ones as in the calculator on our home page. Fintech costs more than ordinary development not because of “difficult code” but because of work that simply does not exist in an ordinary project: compliance, reconciliation, audit, and testing money paths.
The team for a core: a product analyst who can talk to compliance; two or three backend engineers; a front-end engineer; a QA who can write money scenarios; a DevOps engineer for infrastructure and monitoring. The designer joins later than people expect: until the states of an operation are described, there is nothing to draw.
A checklist before you start
- Who is responsible for the state of an account — you or a partner bank?
- Will card data reach your server? If yes, why can a token not do the job?
- What states can a client be in, and what may they do in each?
- What does reversing an operation look like? (If the answer is “we delete the record”, go back to the audit section.)
- Who do you reconcile against, how often, and who sees a discrepancy first?
- What happens when the provider does not answer within 30 seconds?
- Who owns the code, the data and the keys once you have paid?
The last point is not technical, but it determines everything else. What belongs in the contract, and how to tell a decent vendor from a bad one, is covered in how to choose a development vendor.
Frequently asked questions
Do we need a licence to launch a fintech product?
It depends on whose money you hold. If client funds sit in accounts at a partner bank and you provide the interface and the bookkeeping, the licence is usually the partner’s, not yours. The moment money lands on your own account and you dispose of it in your own name, it becomes a different conversation. This is a question for a lawyer in your jurisdiction rather than a developer — but the answer changes the architecture, so it has to be asked before the start.
Can an MVP be built in three months?
Yes, if the MVP is payment acceptance on top of existing processing plus order tracking: 9–14 weeks is realistic. Your own ledger, limits and reconciliation cannot be done in three months — not because there is a lot of code, but because money paths have to be tested, and testing here takes as long as building.
Which is cheaper: our own processing or a provider?
Over a three-year horizon, almost always a provider — you pay a percentage but avoid licences, bank integrations, reconciliation and 24/7 support. Your own processing pays off at volume, when the provider’s percentage starts to exceed the cost of an in-house team. That is the calculation to make, not “it is just an API”.
How do you test things that involve money?
With a separate set of scenarios that check invariants rather than interfaces: the sum of operations equals the balance, a repeated request does not create a second operation, a cancelled operation leaves a trace, the nightly reconciliation balances. Those tests are written before the code — they are the specification.
Have you built systems like this?
Yes — payment cores, banking dashboards, wallets. We do not publish client names: the contracts are covered by NDAs and some projects run white-label, where the product ships under the client’s brand. On a call under a mutual NDA we show the contracts, the systems themselves in operation, and provide reference contacts.
Sources
Every claim here can be checked: below are the primary sources, not a retelling.
- 01PCI Security Standards Council — PCI DSS — the official text of the standard and the rules that define assessment scope
- 02Stripe API — Idempotent requests — a production-grade implementation of idempotency worth modelling against
- 03Double-entry bookkeeping — a five-hundred-year-old principle that is still the best way not to lose money in a ledger
These articles are written by engineers working on the projects — but they are not signed by name. The reason is the same one that keeps client logos off this site: nearly every project runs under an NDA or white-label, and a byline on a piece about a payment core points at the client as clearly as a logo would. Instead of names, we stand behind the text with rules — except for articles about our own open-source code, which carry the author’s name.
How we write and what we verify