Fintech software development is priced and scheduled like ordinary software development right up until somebody asks who is authorised to hold the money. At that point the project stops being an engineering exercise and becomes a regulatory one with an engineering component, and the timeline you had in mind stops being achievable.
The technology is rarely the hard part. Moving money is a solved problem with mature providers. What lengthens a fintech build is the authorisation position, the audit obligations, and the fact that several architectural decisions are made for you by whoever holds the licence.
The question that sets your timeline: are you authorised, working under someone else’s permissions as an agent, or avoiding regulated activity entirely? Those three answers produce projects of completely different length, and the difference is measured in months of waiting rather than weeks of building. Answer it before you scope anything.
FCA Authorisation Is the Critical Path
If you need direct authorisation, that process, not the build, determines your launch date.
The FCA has a statutory duty to determine applications within fixed periods, and those periods changed recently. From January 2026 the FCA reduced its statutory deadlines for new firm authorisations and variations of permission to four months for a complete application and ten months for an incomplete one, down from six and twelve. For variations closely aligned to an existing business model it has committed to three months complete and six incomplete. Senior manager applications aim for at least half within 35 days. These are the UK regulator’s statutory deadlines and apply only to business falling inside that regime.
Two things follow. The clock starts when the application is complete, not when you first submit, so an application with gaps effectively pauses until you fill them. And even the improved four months is longer than most MVP builds, which means the sensible order is to start the authorisation work first and build alongside it rather than building and then applying.
Most early-stage fintechs avoid this entirely by operating as an agent of an authorised firm or by building on a provider that holds the permissions. That is a legitimate and common route. It is also a commercial dependency: your product lives inside somebody else’s risk appetite, and their compliance team can change your roadmap.
Fintech Software Development Starts With the Rails
Which rail you use is not an implementation detail, it decides your data model, your failure handling and your reconciliation burden.
Card payments are fast to integrate and bring chargebacks, which means you need a dispute lifecycle in your data model from day one rather than bolted on later. Faster Payments settles in seconds but is push-only, so collecting money requires the payer to act and your system must handle the wait. Direct Debit collects reliably on a schedule and brings mandate management, failed collections and the guarantee scheme. Open banking offers payment initiation and account information with strong authentication and consent expiry that your system has to track and renew.
Most products end up with two or more, and that is where the engineering cost sits. Reconciling one rail is straightforward. Reconciling three, each with its own settlement timing, failure modes and identifiers, is a substantial subsystem that nobody budgets for because it is invisible from the outside.
Assume settlement is asynchronous and reconciliation is a first-class feature. Systems that model payment as a synchronous request that either succeeds or fails need rebuilding the first time a payment settles late.
What Regulated Software Adds to the Build
Four obligations that ordinary software does not carry.
An immutable audit trail. Every state change to a financial record needs recording with who, what, when and why, in a form nobody can quietly edit. That means append-only design rather than updating rows in place, and it shapes the schema.
Client money separation, if you hold funds. The rules are strict and the reporting is specific. Firms usually underestimate the reporting rather than the segregation.
Financial crime controls. Identity verification, sanctions screening and monitoring for suspicious activity. Most of this is bought rather than built, but the integration, the case-management workflow and the audit of decisions are all yours.
Data protection with a higher bar. Financial data is sensitive, retention periods are set by regulation rather than preference, and deletion requests interact with statutory record-keeping in ways that need deciding early. Our guide to GDPR technical compliance covers the mechanics.
None of this is exotic engineering. All of it takes time, and all of it must be demonstrable to somebody who will ask.
What It Costs in the UK
| Shape | Typical range | Timeline |
|---|---|---|
| Agent model, one rail, no direct authorisation | £60,000 to £120,000 | 3 to 5 months |
| Own permissions, two rails, financial crime controls | £150,000 to £400,000 | 6 to 12 months |
| Multi-rail platform, client money, reporting | £400,000 upwards | 12 months plus |
These are build costs. Authorisation carries its own legal and consultancy spend, and the waiting period has a burn rate whether or not anyone is writing code. Our custom software development cost guide covers the general bands, and healthcare software development covers the comparable pattern in a different regulated sector.
The band that surprises people is the middle one. Adding your own permissions and a second rail roughly doubles a project, and almost none of the increase is user-facing.
How to Sequence It
Settle the regulatory position first, in writing, with someone qualified. Everything downstream depends on it and the answer changes the architecture.
Then build the smallest thing that moves real money on one rail, because the second rail is far easier once reconciliation exists. Treat the audit trail and reconciliation as features with acceptance criteria rather than infrastructure to add later, since retrofitting an append-only history onto a system that updates rows in place is close to a rewrite.
Mecanik builds regulated financial software through our software development team, including the parts auditors ask about. If your fintech timeline assumes the build is the long pole, the authorisation position is worth checking before you commit to a date.
Related reading: MVP Software Development: Scope, Cost and Timeline , Custom Software Development UK - The Complete Buyer’s Guide , How to Build a Web App in 2026 - The UK Developer’s Guide and AI Agents for Business: What They Cost and Where They Fail .
Frequently Asked Questions
How long does FCA authorisation take? From January 2026 the FCA’s statutory deadlines are four months for a complete application and ten months for an incomplete one, reduced from six and twelve. Variations closely aligned to an existing business model target three months complete and six incomplete. The clock starts when the application is complete, not when first submitted, so gaps effectively pause it.
How much does fintech software development cost in the UK? An agent-model product on a single rail without direct authorisation typically runs £60,000 to £120,000 over three to five months. Adding your own permissions, a second rail and financial crime controls moves it to £150,000 to £400,000 over six to twelve months. Multi-rail platforms holding client money start around £400,000.
Do I need FCA authorisation to build a fintech product? Not always. Many early-stage products operate as an agent of an authorised firm or build on a provider that already holds the permissions, which avoids the wait entirely. The trade-off is a commercial dependency: your product operates inside another firm’s risk appetite and their compliance decisions can change your roadmap.
Which payment rail should a UK fintech use? It depends on the direction and timing of the money. Cards are fast to integrate and bring chargebacks. Faster Payments settles in seconds but is push-only, so collection requires the payer to act. Direct Debit collects on a schedule and brings mandate management. Open banking offers payment initiation with consent expiry your system must track.
What does regulated software need that ordinary software does not? An immutable audit trail recording every state change to a financial record, client money separation and its reporting if you hold funds, financial crime controls covering identity verification and sanctions screening, and data protection where retention periods are set by regulation rather than preference. None is exotic engineering, but all of it must be demonstrable.
Comments