Fintech Build Decisions That Are Hard to Reverse

Most fintech products fail slowly rather than dramatically, and the cause is usually a decision taken in the first two months by someone reasoning about the product rather than about the regulated activity underneath it.

These are the decisions that harden fastest, and what each one actually commits you to.

The licensing route determines the product

Whether you hold a licence, operate under someone else's, or avoid regulated activity entirely is not a legal formality that runs in parallel with the build. It determines what the product can do, how long until launch, how much capital you need, and what your architecture looks like.

Operating as an agent of a licensed institution is the fastest route and constrains you to what your principal permits, including their risk appetite and their timelines for approving changes. Holding your own licence takes considerably longer and costs more, and gives you control over the product. Structuring to avoid regulated activity — never holding funds, never giving advice — is genuinely viable for some products and quietly impossible for others.

The mistake is designing the product first and asking the question afterwards, because the answer frequently invalidates parts of the design. This deserves counsel before the first sprint, not after the demo.

The ledger is the decision you cannot walk back

Storing a balance as a number on an account record is the intuitive design and the one that causes the most damage, because when it is wrong there is no way to establish what it should have been.

Double-entry accounting — immutable entries, balance derived by summation — costs slightly more up front and gives you the ability to answer every question you will later be asked. Why is this balance what it is. What was it at close of business on a given date. Which entry was incorrect and what corrected it.

Two details that cause real incidents: store amounts as integers in minor units, because floating-point arithmetic will eventually produce a balance that is wrong by a fraction and reconciliation breaks are expensive to chase. And give every entry an idempotency key derived from its originating event, so a retried request cannot create a duplicate.

Migrating a live system from mutable balances to a proper ledger is possible and unpleasant. It is worth a week of design at the start to avoid.

Your KYC provider becomes part of your funnel

Identity verification is almost always outsourced, and the choice has more product impact than its position in the architecture suggests. Pass rates vary substantially by provider and by customer demographic, and a provider that performs well for one population can perform poorly for another.

The consequence is that verification failures are a major source of onboarding drop-off, and the customers who fail are disproportionately those with thin credit files, recent address changes, or documents from less commonly handled jurisdictions. A generic failure message loses them permanently.

Two things are worth building regardless of provider: a manual review path with an operational queue, and specific enough failure handling that a customer knows what to do next. Both need staff, which is a cost that rarely appears in the original plan.

Reconciliation is a system, not a report

Every fintech product has at least one external party holding the authoritative record — a bank, a processor, a card issuer. Your view and theirs will diverge, routinely, for mundane reasons: timing differences, fees applied at their end, reversals you have not been told about yet.

Discovering divergence at month end means a month of accumulated discrepancies to unpick, and no ability to say when it started. Reconciling continuously against the external record, with exceptions raised as they appear, turns the same problem into a small daily task.

This needs designing in, because it requires holding both records in a comparable form. Retrofitting reconciliation onto a system that only stored its own view is one of the harder projects in this space.

Partial failure is normal, not exceptional

Payments involve several systems and any of them can time out. A timeout is not a failure — it is an unknown outcome, and treating it as either success or failure produces exactly the errors that cost money and trust.

Model payments as a state machine with an explicit pending state, and resolve pending states by querying the counterparty rather than by waiting for a callback. Callbacks are an optimisation; they get lost, duplicated and delivered out of order. The authoritative answer is always the one you ask for.

Data residency and PCI scope shape the architecture

Where data may live is a hard architectural constraint in most financial jurisdictions, and it narrows the managed services available to you, which in turn shapes everything above it.

Card data brings PCI DSS obligations whose weight depends almost entirely on scope. A design where card details never touch your servers — tokenised at the client, held by a processor — reduces scope dramatically. A design that handles them briefly for convenience expands it enormously. This is worth deciding deliberately, because it is one of the few places where a small architectural choice changes your compliance burden by an order of magnitude.

Sequence that avoids rework

Regulatory position first, with counsel. Then the ledger. Then one payment path end to end, including its reconciliation and its failure states, before adding a second. Then onboarding, with the manual review path built rather than deferred. The customer-facing product, which is where enthusiasm naturally goes, is genuinely the fastest part once the rest is settled.