Fintech software development services, built to be provable

What is the one design decision you cannot undo?

The ledger. Money should be recorded as immutable, append only, double entry records with balances derived from them, never as a balance column that gets updated. Teams that store a balance and update it discover the problem months later, during an incident, when the balance and its own history disagree and nobody can say which is right.

The practical consequence of append only is that you never fix a wrong entry by editing it. You write a compensating entry, so the error and its correction both live in the record. That feels bureaucratic for about a week and then it is the reason you can answer a customer's question about a transaction from eighteen months ago without a database archaeology project.

A related distinction worth holding onto: a transaction log is not a ledger. Logs record that something happened. A ledger enforces that the books balance, which is a constraint the database should refuse to violate rather than a property your application code hopes to maintain.

If you are early and the product is a lending or budgeting experience rather than money movement infrastructure, consider buying the ledger rather than building it. There are good ones. Building your own is justified when the ledger is the product, and much less often than engineers would like.

Why does money sometimes move twice?

Because a request was retried and the endpoint had no idempotency key. Every operation that moves money needs one: the server stores the response against the key and returns that same response on a retry, rather than performing the action again. Without it, a timeout on the client side becomes a second payment.

This is the most common serious bug in young payment systems, and it is almost always invisible in testing, because testing does not produce the network conditions that cause it. A mobile client on a poor connection sends a payout request, gets no response, and retries. Two payouts leave.

There is a subtler version worth knowing about, because it catches teams who did implement idempotency. If a retry reuses a key for an operation that previously failed partway, you can end up booking the same transfer twice internally while the provider only ever created one. You now hold a phantom record the provider has never heard of, which surfaces at reconciliation and is unpleasant to unpick.

The rules that avoid both: generate the key on the client before the first attempt and reuse it for every retry of that same intent. Store the response, not just the key. Make the key specific enough that two genuinely different payments can never collide. And treat a key collision with different parameters as an error rather than quietly serving the old response.

Why do your numbers disagree with the provider's?

Usually because the comparison is wrong rather than the money. Authorisation and settlement are separate events on separate clocks, webhooks arrive late or twice, and foreign exchange moves between the two. A reconciliation job that assumes everything is simultaneous and exact will produce a stream of false alarms that your team learns to ignore.

The design that works treats reconciliation as a first class part of the system rather than a report. Every external movement carries the provider's reference. Matching runs on a schedule and records its result, including what it could not match and why. Unmatched items age and escalate rather than sitting in a view nobody opens.

The operational test is simple: can somebody who is not an engineer answer, this morning, how much is unreconciled and how old the oldest item is? If that takes a developer and a database query, reconciliation is not built yet, whatever the architecture diagram says.

How do you keep card data out of your systems?

By never receiving it. Redirect to a hosted page or embed the provider's hosted fields so the card goes directly to them, then store only a token you cannot reverse. A business that never stores or transmits card data typically qualifies for the shortest self assessment questionnaire, while one that stores full card numbers lands on the longest.

Two things we see teams get wrong often enough to call out. The first is treating encryption as scope reduction: as Stripe's own guidance spells out, encrypted card data is still card data, and a value that can be reversed is not a token no matter what it is called in your schema. The second is the payment page itself. Under PCI DSS 4.0 the scripts loaded on a page that collects card details are in scope, so adding a marketing tag to that page is now a compliance decision rather than a growth one.

Sources differ on the exact number of requirements in each questionnaire, so treat any specific count you read online, including from vendors, as approximate. The authoritative versions are the PCI Security Standards Council's own documents, and your acquirer or assessor decides which applies to you. We design to keep you in the smallest scope available and we do not assess compliance, because the assessor has to be independent of whoever built it.

If you also need SOC 2 for enterprise customers, that is a related but separate programme, and we cover it on our SOC 2 readiness page.

Should you partner with a bank or pursue licensing?

Partner, almost certainly, at least to start. A US bank charter is widely described as a three to five year undertaking requiring substantial capital, while a sponsor bank arrangement can take a launch from twelve to eighteen months down to three to six. The trade is speed and simplicity in exchange for dependence on a partner who can end the programme.

This is a decision for your counsel rather than your engineers, and we say so on first calls. What we can tell you is how each path changes the software, because that is where it lands on us.

Sponsor bank or banking as a service. The charter, the deposit insurance and the regulatory responsibility stay with the bank. Middleware providers that sit between you and the bank hold no licence themselves. Practically, your architecture is shaped by their API, their diligence requirements and their appetite, and card programmes in particular run on the bank's network membership and card range.

Your own licensing. State by state money transmitter licensing is the usual alternative for a payments focused business. It is slower and heavier, and it removes the dependency.

Two things worth knowing before choosing. Regulators sharpened their focus here: a 2024 joint statement from the Federal Reserve, FDIC and OCC restated that banks remain responsible for the activities carried out through their fintech partners, which is why bank diligence now asks for audited financials, runway and written policies covering anti money laundering, customer and business verification, card data handling and personal data. And several banks have since exited or restricted these programmes, so the stability of the partner you pick is a real risk rather than a theoretical one.

The engineering implication of that last point is concrete. Design the integration so the provider is replaceable: your own ledger as the source of truth, provider references stored alongside your records, and no business logic that lives only in their system. Teams that skip this discover the cost when the relationship changes.

What will a regulator or auditor expect from the software?

Regulators and auditors expect you to reconstruct what happened and show who did it. In practice that means an immutable record of every money movement, an audit trail of administrative actions, access control that is enforced rather than documented, and data retention that matches your obligations rather than your storage preferences.

These are engineering requirements with compliance consequences, and the cheapest moment to build them is before launch.

Administrative actions are money movements too. If a support agent can adjust a balance, refund a payment or change a limit, that action needs the same immutability and the same attribution as a customer transaction. This is the gap we find most often in products built quickly.

Access control enforced in the data layer. A permissions check in the user interface is a suggestion. The question an auditor asks is whether an agent could see an account they should not, and the honest answer depends on where the check lives.

Retention by policy, not by default. Know what you are required to keep, for how long, and what you must be able to delete on request. These pull in opposite directions and the resolution is a decision your compliance lead makes, which we then implement.

We build to support these. We do not certify them, and no firm that implemented your controls can independently attest to them.

What do you build for fintech companies?

Payments and wallet systems, lending and credit tooling, banking front ends, onboarding and verification flows, back office tooling, and the reporting that has to reconcile to the ledger. Mostly ordinary product engineering, built carefully on top of infrastructure that has to be exact.

The one on that list that gets neglected is back office tooling, and it is worth arguing for. Every support question your team cannot answer from a screen becomes an engineer interrupted, a database query and a risk of someone editing production data by hand. Building the operations screens early is the cheapest headcount decision in a young fintech, and it is almost always deferred.

What is different about banking software development services?

Integration constraints and change control. Banking software development services usually mean working against a core banking system or a sponsor bank's API that you cannot change, on their release schedule, with their diligence applied to your design. The engineering is often simpler than a consumer fintech product. Working within the constraints is the job.

Three practical differences from greenfield fintech work.

The integration surface is fixed. You design around what the core or the partner exposes, including its gaps. Where a modern API exists this is straightforward. Where it is a file based interface on a nightly cycle, that cycle becomes a product constraint your customer will feel, and it is better to design for it openly than to pretend it is real time.

Change control is external. Releases may need the partner's approval or their testing window. A two week sprint cadence meeting a monthly release gate is a planning problem, not an engineering one, and it should be in the timeline from day one.

Their diligence shapes your architecture. Requirements on data residency, access, logging and incident handling arrive as a document and translate directly into design decisions. Read it before architecture, not after.

What does custom fintech software development actually involve?

Custom fintech software development means building the money path yourself rather than assembling a product from someone else's components: your own ledger, your own idempotency and reconciliation, and integrations you control. It is worth doing when the way money moves is your product, and a poor trade when it is plumbing behind a product that competes on something else.

The question to answer before commissioning any of it is which part is actually yours. Most fintech products contain three layers and only one of them is a differentiator.

The regulated rails. Card networks, bank accounts, payment processing. Nobody builds these and you should not try. You pick a provider and integrate.

The money infrastructure. Ledger, transfers, reconciliation, limits. This can be bought or built. Custom fintech software development is justified here when your money model genuinely differs from what off the shelf ledgers assume, for example multi party splits, unusual settlement timing, or balances that behave in ways a standard double entry product does not express cleanly.

The experience and the operations. Onboarding, dashboards, decisioning, support tooling. This is almost always custom, because it is where products actually differ, and it is where most of the engineering budget should go.

Teams that get this wrong usually get it wrong in the same direction. They build the middle layer because it is the interesting engineering, and buy or neglect the third layer where their customers actually experience the product. We would rather talk you out of that on the first call than deliver it well.

How do you handle fraud, limits and risk in the build?

Make risk decisions explicit, recorded and reversible. Every automated decision to block, hold or allow should be written down with the rule that caused it and the data it saw, so you can explain a decision to a customer, change a rule without archaeology, and show a regulator that the system behaves the way your policy says.

Fraud tooling is usually bought rather than built, and that is the right call. What stays with you is the integration and everything around the decision, and that part is frequently under designed.

Record the decision, not just the outcome. Storing that a payment was blocked is nearly useless six weeks later. Storing which rule fired, what the inputs were and what version of the ruleset was live lets you answer complaints and tune the system with evidence.

Every automated decision needs a human path. A customer will be wrongly blocked. If the only remedy is an engineer editing a row, you have built an operational problem that scales with your growth.

Limits belong in the ledger layer. A velocity or balance limit enforced only in the application can be bypassed by any other path into the data. Enforce where the money is recorded, and the rule holds regardless of which service called it.

Test the unhappy paths deliberately. Partial failures, provider timeouts, a hold that expires while a settlement is in flight. These are rare in testing and routine in production, and they are exactly where money goes missing.

One honest limit on our part: we build the system around risk decisions, and we are not a fraud modelling firm. If your product needs genuine fraud modelling rather than rules, that is a specialist and we will say so.

Does it matter where your engineers are based?

In fintech, sometimes yes, and it is better established in the first conversation than after an interview. Data residency rules, a sponsor bank's diligence requirements, or a customer contract can all restrict who may access what, and those constraints are commercial facts rather than technical preferences.

We are a remote team with engineering based in Pakistan, working US business hours. For most products this is unremarkable. For some fintech work it is a real constraint, and the honest thing is to surface it early.

What usually matters in practice is narrower than people assume. It is rarely about where code is written. It is about who can access production systems and customer records, and where that data is stored and processed. Those are separable concerns, and the separation is often what makes an arrangement workable.

That is one of the reasons we decline production access to customer financial data as a matter of course. We work against test environments and synthetic data, which removes the hardest version of this question before it is asked. Where a sponsor bank's diligence document specifies something more restrictive, we build to it or we tell you we are not the right firm.

The pattern we would warn against is discovering this at diligence. A bank partner asking who has access to what, three weeks before a launch, is not the moment to find out that the answer needs to change.

When should you not build custom fintech software?

When the ledger you need already exists and is not your differentiator, when the regulatory path has not been chosen, when nobody has read the sponsor bank's requirements, or when the question you actually have is a legal one. We check all four before quoting.

There is a fifth case that deserves its own sentence. If you are pre revenue and the product can be tested without moving real money, test it that way first. A waitlist, a manual process behind a simple interface, or a product that calculates but does not transfer will tell you whether anyone wants this, at a fraction of the cost and with none of the regulatory weight.

What should you have ready before the architecture call?

Four answers, none of them technical. Which provider or sponsor bank you are talking to, what your counsel has said about the regulatory path, who the first hundred customers are, and what money actually does in your product. With those, the architecture conversation takes an hour. Without them it takes a month.

The provider or partner. Even a shortlist is enough. Their API shapes the integration, their diligence shapes the access model, and their settlement timing shapes your reconciliation. Designing provider agnostic sounds prudent and in practice produces an abstraction that fits nobody.

What your counsel has said. Not a legal opinion, just the direction: partnering, licensing, or still deciding. Still deciding is a legitimate answer and it changes what we build first, because there is useful work that does not depend on it.

Who the first hundred customers are. Consumer or business, one country or several, one currency or several. Multi currency and multi entity are the two requirements that are cheap on day one and expensive in month eight, and the answer is almost always known even when nobody has written it down.

What money actually does. One paragraph in plain words: it arrives from here, sits here, moves to there, and this is who is owed what at each point. That paragraph is the ledger model, and writing it is the single most useful hour you can spend before engaging anyone.

What you do not need is a specification. Specifications written before the provider is chosen tend to encode assumptions the provider will overturn, and then the document becomes something to defend rather than a plan to follow.

How does a fintech project run with Voliom?

Architecture decisions first, in week one, because ledger shape and provider boundaries are the expensive things to change. Then a fixed line by line quote, then weekly releases you can click. We work in your repository and you own everything from the first commit.

1. 01

   Decisions, not discovery theatre

   Week 1

   Ledger model, provider boundaries, idempotency strategy, reconciliation design and what your compliance lead requires. Four or five decisions, written down, with the reasoning kept.

2. 02

   Fixed scope and a date

   Week 1

   A line by line quote and an explicit out of scope list. Changes get priced before they are built rather than absorbed and argued about later.

3. 03

   Build, with the money path first

   Weeks 2 onward

   The ledger, idempotency and reconciliation before the polish, because every later feature sits on them. Weekly demos throughout.

4. 04

   Operations before launch

   Before go live

   Support tooling, the unreconciled view, and a tested runbook for the first incident. Launching without these is how a small problem becomes a weekend.

One thing we insist on: we do not want production access to customer financial data, and we do not want live credentials. We work against test environments and synthetic data, and if a problem genuinely cannot be reproduced that way, we fix the observability so that it can be. Holding your customers' financial data makes us a risk to you, and the cost of that is higher than the inconvenience.

What do fintech software development services cost?

Scope decides it and we quote line by line after the architecture conversation. A first production payment flow with a ledger, idempotency and reconciliation is typically eight to twelve weeks. We run a blended squad at roughly 24 to 45 dollars an hour and a senior only pod at roughly 75 to 120 where the money path is involved.

For anything touching the ledger, provider integration or reconciliation we would recommend the senior track and say so, because the cost of a subtle mistake in that layer is not measured in engineering hours. The surrounding product work, dashboards, onboarding screens, marketing pages, is ordinary and sits comfortably on the blended rate.

Indicative until we have scoped the work. We are a small remote team working US business hours with engineering based in Pakistan, which matters here because data residency and partner diligence may constrain where your engineers can sit. Establish that early rather than after an interview. You can read about the team, and if you need capacity alongside your own engineers rather than a delivered outcome, IT staff augmentation is the lighter engagement.

• Custom software for fintechLedgers, payment flows, back office
• Dedicated development teamsEngineers who learn the money path and stay
• SOC 2 readinessWhen enterprise customers start asking
• Secure code reviewAuthorisation, secrets, multi tenancy
• SaaS developmentMulti tenant products built to be sold
• QuickBooks integrationKeeping the books in step