building a fintech business is not trivial
The thing about fintech is that, at the layer most people are thinking about, it looks like a banking app. A nicer banking app. Modern frontend, instant onboarding, no branch visits, push notifications when money moves. If you build software, you can probably picture the rough shape of one. CRUD on top of a Postgres, an integration with a banking partner, a KYC vendor, a card processor, some risk rules, some dashboards. You could probably scope an MVP in a planning meeting and have it in production within a quarter.
This is roughly the mental model that most non-fintech engineers, most product folks new to the space, and a sizeable share of the LinkedIn fintech-founder population start with. It is also the mental model responsible for most fintech failure.
I've spent most of my career in fintech and seen it from a few different angles. I worked on the consumer wallet at Shopee, where the dominant constraint was scale: tens of millions of users, payments flowing in and out of every corner of Southeast Asia. I worked at a web3 custodian responsible for $2B+ of institutional digital assets, where the work was dominated by security: HSMs, multi-sig, key ceremonies, the kind of operational paranoia that doesn't really exist anywhere else in software. I consulted for an AI personal-finance tool that pulled from multiple banks via aggregator APIs, and the painful lesson there was data quality, because nothing about retail bank feeds is consistent across institutions. I was a product engineer at a web3 neo-bank operating in a regulatory environment that hadn't yet figured out what to do with stacks like ours. And I'm currently fractional CTO at a cross-border FX gateway for agencies and freelancers, doing virtual bank accounts, multi-currency settlement, tax handling, and merchant-of-record, basically all the load-bearing pieces of "moving money internationally" stitched together for SMB customers.
Five different shapes of fintech. The thing they share, in retrospect, isn't a technology stack or a regulatory regime or even a customer profile. It's that each was much harder than its outside-in description suggested, and not because any individual feature was hard to build. (Most fintech features are pretty boring under the hood.) The hard part is that the surface-area of work required to keep a fintech actually working is much larger than the surface-area of work required to ship one to its first hundred users. The MVP-to-business gap is wider in fintech than in any other category I've worked in.
This piece is about that gap. Not a cautionary tale, not a hot take, just a structural read for product people inside fintechs (or thinking about joining one). Six categories of compounding work. Most of it doesn't show up at the demo stage. All of it decides whether you have a business.
Regulatory and compliance
The first thing that kills a fintech, if it gets killed early, is regulatory. The second thing that kills a fintech, if it survives early, is also regulatory.
Almost every category of fintech sits inside a regulatory perimeter. Payments, lending, custody, brokerage, insurance, digital assets, each has its own license regime, its own activity restrictions, its own ongoing supervisory burden. The licenses are not "fill in a form" licenses; they are credentials that take 12-24 months to acquire, require a regulated entity, demand compliance hires before the company has revenue to support compliance hires, and impose ongoing reporting obligations that most product orgs don't budget for.
The thing that's hard to internalise about regulation, if your prior startup experience is in non-regulated software, is that the speed at which a regulator approves something has nothing to do with the speed at which a product team wants to ship something. They are operating on different clocks. A product team can decide to build a feature on Monday and have it in production on Friday. A regulator looking at that same feature, even one well-aligned with existing rules, can take six months to come back with comments. If the feature touches a license boundary, say a money transmitter wanting to extend credit, or a custody platform wanting to do staking, you might be looking at a license amendment that costs more than your seed round.
The asymmetry matters most. The cost of getting compliance right is high but bounded: hire some lawyers, build some controls, hire a compliance officer, pay an annual audit, write a lot of policies. The cost of getting it wrong is unbounded. License revocations, frozen funds, customer-harm headlines, criminal liability for officers in extreme cases. There is no fintech equivalent of "move fast and break things," because the things that break, when they break in fintech, are usually customer money or customer trust, and you don't get either back.
Most fintechs underestimate this in roughly the same way: they treat compliance as a function (someone you hire) rather than a property (something the whole org has to internalise). It's a bit like security in 2010. You couldn't ship a website that took credit cards while treating security as Someone Else's Problem then, and you can't ship a fintech treating compliance that way now.
Engineering
Fintech engineering looks like CRUD until the day it doesn't, and that day usually arrives via a category of bug nobody on the team has seen before.
Money has properties that ordinary application data does not. The first is that it has to be conserved across boundaries. If $100 leaves your system, it has to arrive somewhere; if it doesn't, you have a discrepancy that is not a bug in the cosmetic sense (something is rendering wrong) but in the existential sense (someone's funds are missing). This is what double-entry accounting is for, and why mature fintechs run a ledger system separate from their product database. Most early-stage fintechs don't; they have a column called balance on a users table, which is fine until a payment partially fails and you find out you can't reconstruct the right balance from incomplete logs.
The second property is that money operations have to be idempotent. If a network call to a banking partner fails midway, your retry has to either complete the original operation or do nothing, never duplicate. Most application code in non-money domains doesn't really sweat this; the worst case of a duplicate API call to a CRM is a duplicate row, easily cleaned up. The worst case of a duplicate API call to a payment processor is a customer charged twice, who has just discovered that you cannot easily reverse a payment. Idempotency keys, deterministic transaction IDs, and write-ahead logs are not engineering decoration in fintech. They are the price of entry.
The third property is that operations have settlement timing. The fact that an authorisation succeeded does not mean the funds have moved. The funds may take 1-3 business days to settle. The funds may be reversed within a chargeback window of 120 days, sometimes longer. The user balance you are showing in the app is, in some real sense, a forecast. Mature fintech ledgers track at least three states per balance, pending, available, settled, and the product layer has to know which one to show in which context. Junior engineers who haven't seen this before tend to flatten everything into a single number; the resulting bugs look harmless until the day a chargeback comes back from 90 days ago and you have already let the user withdraw the funds.
None of this is impossible. The foundational engineering effort to do it correctly is just roughly an order of magnitude more than what a non-fintech engineer would budget for the same surface-area of features. And every shortcut compounds: a balance bug today becomes a regulatory issue when the regulator asks for proof of customer-fund segregation in two years.
Operational
If you draw a fintech as an org chart, the part nobody talks about is the ops team.
Ops in a fintech is not customer support. Ops is the function that makes sure that what your system thinks is true, and what your bank partners think is true, and what your card networks think is true, and what your custody providers think is true, are actually all true at the same time. This is reconciliation. It runs daily, sometimes hourly. It is tedious. And there is no fintech I've ever encountered where it doesn't break, frequently.
The reason it breaks is that the systems involved disagree about basically everything. Different banks send transactions in different formats. Card networks have batch settlement files that arrive on different schedules. Different vendors define "transaction" differently; some include fees, some don't, some include reversals as separate rows, some net them. When you reconcile a day's transactions, you are asking five different counterparties to all describe the same thing the same way. They can't, so they don't. Someone has to look at the breaks and figure out which side is right and what to do about it.
Most of the ops org is dedicated to this. People who manually approve outliers, watch fraud queues, and deal with banking partners when something is "stuck in their system," a phrase that, in fintech, can mean anything from "transient API issue" to "the partner's compliance team has unilaterally frozen the funds and you'll learn why in three weeks." The product team typically has no visibility into how much of this is happening. The ops team has full visibility, and the gap between the two is where most internal company drama originates.
The cost of ops scales worse than linearly with volume. More transactions means more breaks. More partners means more break categories. More products means more reconciliation surfaces. Most fintech founders don't model this; they model COGS as a fixed percentage and assume operating leverage will arrive somewhere around series B. It usually doesn't, because the ops cost line is more entwined with regulatory and partner risk than the founder thinks, and you can't stop hiring there without things slipping.
Capital, unit economics, and treasury
The fintech P&L is structurally weird, and most fintech founders don't realise this until later than they should.
The biggest weirdness is that revenue often isn't what it looks like. A 3% take-rate on a $100 transaction is not 3% margin; it is 3% gross, of which the network takes some, the issuer takes some, the processor takes some, the FX layer takes some, the chargeback reserve takes some, the fraud loss takes some, the operational cost takes some, and what's left, often, is somewhere between 30 and 80 basis points. There is a whole category of fintechs whose pitch decks describe revenue as "take rate × volume" and who learn, painfully, somewhere around their first formal audit, that operating margin is much smaller and much more volatile than that simple math suggests.
Then there is float. Float is the working capital that sits in your system between when you receive funds and when you have to pay them out. In the right business model, float is a free funding source. (At one point, PayPal's float was generating more income than its take-rate did.) In the wrong business model, float is a regulatory hot potato: money you have to segregate, can't touch, and that sits on your balance sheet as a customer liability rather than your cash. The line between "useful float" and "regulatory landmine" depends on your license, your jurisdiction, and the specific rules around segregated customer funds.
Then there is the FX layer, if you do anything cross-border. Cross-border fintechs typically borrow currency exposure from a bank, a liquidity provider, or a stablecoin pool, and pass it on to customers at a markup. The markup looks like revenue. It is also a real risk position: if you sell USD to a customer at 9 AM and don't buy the matching position until 11 AM, you are running a two-hour FX bet. Most cross-border startups don't think of themselves as having an FX trading desk, but they do.
The treasury side is where this all has to be reconciled at the company level: how much cash is in which currency, in which bank, in which jurisdiction, available to which entity. Most fintechs have many more bank accounts than other startups; sometimes the count is in the dozens, in some cases the hundreds. Each one comes with its own concentration risk. If your operating account is at one bank, and that bank pauses outbound transfers for compliance review for three days, you stop being able to pay vendors. If your customer-funds-segregated balance sits with one banking-as-a-service partner, and that partner files for bankruptcy, your customers may not see their funds for months. (See: Synapse, 2024. Also not a hypothetical.)
Distribution and trust
Fintech CAC is structurally higher than other categories, and it is higher in a particular way.
Fintech is high-trust. People will give you their email for free, a credit card for a small commitment, and they will not give you direct-debit access to their bank account, or move their salary, or hold meaningful balances with you, on the basis of a clever Twitter ad. Trust gets built up via reputation, regulatory visibility, time-in-market, and (often) third-party validations like banking-partner names that customers recognise. None of those are things you can spin up in a quarter.
Fintech reputation is also asymmetric. A great experience produces a passive customer who keeps using you. A bad experience, especially one involving lost or delayed money, produces a passionate customer who tells the internet about it for years. The Reddit threads about "X fintech is holding my funds and won't respond" are an entire genre. Whether the company is actually at fault is largely irrelevant for the marketing impact; the asymmetric weight of "they took my money" stories means a single bad incident can take you out of consideration for thousands of would-be customers.
And the channels available to fintech marketing are narrower. Major ad platforms restrict financial-services advertising heavily, so you can't run the same growth playbook as a B2B SaaS. Influencer-driven growth is fragile, because financial influencers are a regulatory category in some jurisdictions. Referral programs are great except when you have to underwrite the referred users for fraud and KYC. Most of the cheap distribution levers are unavailable, more expensive, or load-bearing on regulatory exposure.
Net of all this, fintech distribution is largely about institutional trust, not consumer marketing. The companies that win tend to win on partnerships, regulatory positioning, and being-around-long-enough, not on a great landing page. This is partly why fintech consolidation is so chunky: the moats are slow to build, but once built, they hold.
Fraud
Fraud in fintech is, in spirit, what spam was to email in the early 2000s and what bot abuse is to consumer apps today. A category of work that is asymmetric, adversarial, and that the rest of the org will consistently underestimate the cost of.
Start with the math. A 1% fraud rate sounds small. On a payments business with a 1% take-rate, a 1% fraud rate consumes 100% of revenue. Most consumer fintechs operate at fraud rates somewhere between 0.05% and 0.5%, depending on the product, the geography, and how aggressive the underwriting is. Fraud loss is typically the second-largest cost line after card-network fees and ahead of cloud hosting, in many cases by an order of magnitude. Most fintech founders have not internalised this when they start.
Fraud is also adversarial in a way that ordinary product development isn't. Real adversaries iterate against your defences faster than you iterate. The day you ship a new fraud rule, someone is probing the boundaries. The day you publish your fee structure, someone is figuring out how to refund-fraud the difference. There is a small and surprisingly skilled professional class of people whose job is to extract money from fintechs, and most consumer fintechs eventually meet them.
And the categories of fraud are wider than people expect. Classic third-party fraud, where someone uses stolen card details, is the obvious one. First-party fraud is a real customer disputing a real transaction they actually made, sometimes called "friendly fraud," though there is nothing friendly about it, and it is the largest category of chargebacks for many merchants. Account takeover is when someone hijacks a real customer's account. Synthetic identity is fictional persons stitched together from real and fabricated information, increasingly easy to generate and increasingly hard to detect. Bonus and incentive fraud is against your own marketing. APP fraud is where the customer is the victim and your platform is the channel; in jurisdictions with reimbursement rules (the UK from October 2024 onwards, for instance), you may have legal liability for the customer's loss even though you didn't commit the fraud.
The cost of fraud isn't just dollar losses. It is the team you have to staff to handle disputes, the reserves you have to hold to absorb chargebacks, and the trade-off between false positives and false negatives in every model. Every percentage point of "tighter" rules costs you customers, and every percentage point of "looser" rules costs you money. Most fintechs underestimate all of it in their first 18 months. Some get a chance to fix it. Some don't.
So
The fintech business is, from outside, a banking app with better design.
From inside, it is a regulatory entity built around a multi-year license, an engineering team that spends half its time on properties of money other engineers don't think about, an ops team reconciling daily against five disagreeing counterparties, a treasury function spread across dozens of bank accounts and currencies, a fraud team in a permanent adversarial loop, a marketing function that can't run the cheap channels, and a customer-trust position that takes years to build and one viral incident to lose. Each layer compounds on the others. Each is its own job. None of them defers cleanly to next quarter.
Five different fintechs, five different shapes of business, and the same conclusion in each. The trivial-looking version of fintech is the demo. The actual job is everything underneath, and the actual job doesn't fit on a slide.