Fintech App Development Cost: The Five Modules That Move Money
Five modules make up what we call the control core: the smallest thing that can move money and prove it afterwards. At the floor they come to 1,380 hours — $55,200 at $40 per hour, about $89,700 at a $65 blended rate, $138,000 at $100. At the ceiling the same five reach 2,600 hours.
Here is the thing most fintech estimates get wrong. None of those five modules is the app. Not the onboarding screens, not the card, not the dashboard the customer sees. They are the ledger, the identity checks, the rail, the reconciliation and the back office — and a product that ships the customer experience without them is a demo that happens to hold real money.
The two modules worth naming individually are the ones our own costing flags. The double-entry ledger and posting engine, at 400 to 800 hours, is the highest-risk module. And the back office console with access control and audit, at 300 to 550 hours, is the one most often left out of quotes — which is why fintech projects so often arrive at launch with no way for a human to investigate anything.
The ordinary failure is not a security breach. It is a customer balance that is wrong by a small amount, nobody able to establish why, and a support team with no tool to look.
Module | Published range | Note |
KYC and KYB onboarding with identity orchestration | 250 to 450 h | Add 100 or more for a manual review console |
Double-entry ledger and posting engine | 400 to 800 h | The highest-risk module |
Payment rail integration, one rail | 180 to 350 h | Returns and exceptions included |
Reconciliation and break management | 250 to 450 h | Three-way, daily, from day one |
Back office console with access control and audit log | 300 to 550 h | Most often left out of quotes |
Floor | 1,380 h | Ceiling: 2,600 h |
Quality assurance, user acceptance testing and partner certification run at 15 to 25 percent of build, and they are not optional on a regulated rail. A payment partner certifies your integration before it goes live, on their schedule, and that is a dependency rather than a task.
Note the phrase "one rail". Each additional rail is the same again — a second scheme, a second country's local transfer system, a card network alongside bank transfers. Rails do not get cheaper with practice, because the work is in the other side's exceptions rather than in your own code.
400 to 800 hours, the widest range on the page, and the module our own costing flags as highest risk.
A ledger is double-entry because every movement has two sides and the sum of them is always zero. That property is what makes a system provable: if the books balance, no money has appeared or vanished. A balance stored as a number on a customer record is not a ledger, it is a cache, and when it disagrees with reality nothing can tell you which transaction caused the difference.
So: entries are immutable. Corrections are reversing entries, never edits. A balance at any past moment is derivable by replaying entries to that point, because someone will ask what the balance was on the 3rd and "the current number" is not an answer.
Then the parts that make it hard rather than merely strict. Pending versus settled, because money authorised is not money moved, and a customer's available balance differs from their ledger balance. Idempotency, because a payment instruction that times out may or may not have executed, and retrying it must not double-post. Ordering, because entries arriving out of sequence still have to produce the correct position.
Each of those is why the upper end of the range is double the lower one.
Multi-currency, where it applies, is the other reason. Holding balances in more than one currency means every account has several positions rather than one, conversions post as paired entries at a recorded rate, and the revaluation of held balances is its own periodic job. None of that is exotic, but it roughly doubles the surface the ledger has to get right, and it is a decision to take before the first entry is written rather than after.
250 to 450 hours, plus 100 or more if humans need to review cases — and they will.
Identity verification is a sequence of checks against several providers: document authenticity, a liveness check, sanctions and politically-exposed-person screening, address verification, and for business customers the ownership structure behind the entity. No single provider does all of it well in all markets, which is why the module is called orchestration.
That means handling each provider's failure independently. A check that times out is not a rejection. A provider that is down must not block onboarding entirely. A customer who fails one check may pass on resubmission, and the system has to hold them in a state that is neither approved nor rejected without losing the work already done.
KYB is materially harder than KYC because a business is a structure rather than a person: directors, beneficial owners above a threshold, layered holding companies, and documents that differ by jurisdiction. Budget separately for it rather than assuming it is KYC with more fields.
And the manual review console is not optional. Every identity system produces cases a machine should not decide, and without a queue, a reviewer and a recorded decision, those cases become an inbox.
180 to 350 hours for one rail, and the published note is the important part: returns and exceptions included. That phrase is doing most of the work.
Sending a payment is the easy direction and it is what demonstrations show. The engineering sits in everything that comes back. A payment can be returned days later for an invalid account, a closed account, a name mismatch, or at the beneficiary bank's discretion, and each return reason needs its own handling because some are retryable and some are permanently fatal.
Then there is the ambiguous middle. A request that times out has an unknown outcome — it may have executed. Resolving that needs a status query against the rail and an idempotency key that makes a retry safe, because the alternative is either a double payment or a customer told their money did not move when it did.
Add the operational layer: cut-off times after which a payment lands the next business day, scheme holidays that are not your holidays, and limits that differ by rail and by customer. None of that is in a sandbox, which is why partner certification exists and why it sits on the critical path.
250 to 450 hours, and the three ways are the point: what your ledger says, what the rail reports, and what the bank account holds.
Those three should agree and routinely will not, for ordinary reasons. A payment settles the next business day. A return arrives a week later. A fee is deducted at the rail rather than booked by you. A transfer fails after your ledger recorded the attempt.
Each disagreement is a break, and breaks need a workflow rather than a report. Raised automatically, assigned, investigated, resolved with a reason recorded, and aged so that a break open for a week is visible as such. Without that, breaks accumulate silently until a month-end investigation that spans thirty days of transactions.
Our own costing is explicit that this runs from day one rather than being added at scale. The reason is practical: a reconciliation process introduced after six months of live transactions starts with six months of accumulated unexplained differences, and the first task is an archaeology project nobody budgeted for.
300 to 550 hours, flagged in our own costing as the one most often left out of quotes, and the omission is predictable: it is the only module no customer ever sees.
What it has to do is unglamorous and non-negotiable. Find a customer, see their transactions, understand a balance, investigate a break, freeze an account, action a complaint. Each of those is a support interaction that happens whether or not a tool exists, and when it does not exist the work migrates to engineers running database queries — which is slow, unauditable and a control failure in itself.
Access control inside it matters as much as the features. Not everyone who can view an account should be able to freeze one, or reverse a transaction, or export a customer list. Roles, approval for sensitive actions, and an audit log that records who did what to whose account are the substance of the module rather than decoration on it.
Cutting it to save a few hundred hours is the single most expensive economy available in this category, because the cost reappears as engineering time, support latency and an audit finding.
A useful minimum, if the budget is genuinely tight: read-only customer and transaction search, a break queue, and an action log. That is far short of a complete console and it removes the worst of the engineering-as-support pattern, leaving freezes and reversals as deliberately manual processes with a written procedure until the tooling catches up.
Not in the five modules, deliberately, but worth naming because it reaches into all of them.
Every money product needs limits — per transaction, per day, per customer tier — and the limits are a commercial decision before they are a technical one. Set them tight and you create support volume from legitimate customers; set them loose and you fund the losses. There is no neutral setting, only a chosen one, and the choice should be configurable rather than deployed.
Velocity rules sit alongside them: several attempts in a minute, a first transaction to a new beneficiary at an unusual size, a pattern that matches a known abuse. Each produces a hold, and a hold needs a human path out of it — which is another reason the back office console is not optional.
The part teams underestimate is that fraud controls and the ledger have to agree. A blocked transaction must not post. A reversed one must reverse completely, including any fee. An amount held against a pending review has to reduce available balance without moving the ledger balance. Those are ledger behaviours, which is why fraud cannot be bolted on afterwards as a separate service with its own view of the truth.
A question that changes the project more than any technical decision, and it belongs in discovery rather than later.
Holding customer money, issuing accounts or cards, or executing payments generally requires authorisation, and obtaining it is a programme measured in quarters with capital requirements attached. Most products do not start there.
The alternative is an arrangement where a licensed partner provides the regulated capability and you build the product on top. That changes what you build — their rails, their KYC requirements, their reporting obligations flowing to you — and it changes your economics, because their margin is in your cost base permanently.
Neither route removes the control core from your side. A partner's licence does not excuse you from a ledger you can prove, reconciliation you perform, or a console your support team uses. Teams sometimes assume partnering means the partner holds the records; it does not, and discovering that during a partner's own audit is an uncomfortable way to learn it.
There is a commercial consequence worth modelling early. A partner's pricing is usually per transaction or per account, which means your unit economics are set by somebody else and improve only when you renegotiate or leave. Both options depend on being able to move, and being able to move depends on owning your own ledger and customer records rather than reading theirs. The control core is therefore not only a control requirement; it is the thing that keeps a commercial conversation available to you in two years.
Once the five modules exist, the order of everything else follows from risk rather than from enthusiasm.
First, the smallest real money movement end to end — one rail, one direction, a small cohort, with reconciliation running and someone watching the breaks daily. The purpose is not the feature; it is proving the core behaves against real money, which no test environment establishes.
Then the customer experience, which can now be built against a ledger that is already correct. This is the part that is cheap to change and expensive to build on sand, which is why it comes second rather than first.
Then the second rail or the second product, and only once the first has run long enough to surface its exception patterns. A team that adds a second rail before understanding the first one's returns is building two integrations it does not yet understand.
The temptation throughout is to demonstrate progress with visible things, because a ledger is invisible and a screen is not. Resist it for one release. A product that can prove where money went is an asset; one that cannot is a liability that happens to look finished.
Not on the app, which is the part everybody budgets and demonstrates.
They fail when the ledger stored balances rather than entries, so a disputed figure cannot be reconstructed and support guesses. They fail when reconciliation was deferred, so unexplained differences accumulate and the first real investigation spans months. They fail when the back office was cut, so every support question becomes an engineering ticket and nobody can act within a control framework.
And they fail on rails, when a second one was assumed to be a copy of the first and turns out to be another full integration with its own exceptions, returns and certification schedule.
Every one of those is a control problem rather than a feature problem, which is the whole argument for building the core first and the customer experience second — the reverse of how these products are usually sequenced, and the reason so many of them arrive at launch unable to answer a simple question about a customer's balance.
The control core — the five modules that can move money and prove it afterwards — runs 1,380 hours at the floor and 2,600 at the ceiling. At the floor that is $55,200 at $40 per hour, about $89,700 at a $65 blended rate, and $138,000 at $100. The five are KYC and KYB onboarding at 250 to 450 hours, the double-entry ledger at 400 to 800, one payment rail at 180 to 350, reconciliation and break management at 250 to 450, and the back office console at 300 to 550. Quality assurance, user acceptance testing and partner certification add 15 to 25 percent.
Because it is the thing that makes the system provable, and it is strict in ways ordinary application code is not. Entries are immutable, corrections are reversing entries rather than edits, and any past balance has to be derivable by replay. On top of that it has to handle pending versus settled amounts, idempotency so a timed-out payment instruction cannot double-post on retry, and out-of-order arrival. A balance stored as a number on a customer record is a cache, not a ledger, and when it disagrees with reality nothing can say which transaction caused it.
It compares what your ledger says, what the payment rail reports, and what the bank account actually holds. The three disagree routinely for ordinary reasons — next-day settlement, returns arriving a week later, fees deducted at the rail, transfers that failed after you recorded the attempt. Each disagreement is a break needing a workflow rather than a report: raised, assigned, investigated, resolved with a reason, and aged. Introduce it after six months live and you begin with six months of accumulated differences to explain.
Because it is the only module no customer sees, so it is the easiest thing to cut when a number needs reducing. What it does is non-negotiable: find a customer, see transactions, understand a balance, investigate a break, freeze an account, action a complaint. Without it, that work migrates to engineers running database queries, which is slow, unauditable and a control failure. It also carries the access control — not everyone who can view an account should be able to freeze one.
Roughly the same as the first, 180 to 350 hours. Rails do not get cheaper with practice because the work is in the other side's exceptions rather than your own code: each scheme has its own return reasons, its own timing, its own failure modes and its own certification. Budget a second rail as a second integration rather than as a variation on the first, and expect the partner's certification schedule to be a dependency you do not control.
Usually not at the start. Holding customer money, issuing accounts or cards, or executing payments generally requires authorisation, which is a programme measured in quarters with capital requirements. The common alternative is building on a licensed partner's regulated capability, which changes your rails, your KYC requirements and your economics, since their margin sits permanently in your cost base. What it does not change is the control core: a partner's licence does not excuse you from a provable ledger, your own reconciliation, or a console your support team can use.
The control core, before anything customer-facing. That is the reverse of how most of these products are sequenced, and it is why so many reach launch unable to answer a simple question about a customer's balance. The customer experience can be rebuilt cheaply; a ledger that stored balances instead of entries cannot, because the history it needed to keep was never written. Build the thing that proves where money went, then build the thing that moves it.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
