Build or Buy Your Fintech Ledger: The Decision No One Talks About Honestly

This is the continuation of How to Build an Accrual-Based Credit Ledger. That first article was about the architecture: events, accruals, postings, reversals, reconciliation, auditability, and all the boring things that keep customer money from becoming a philosophical debate.

This one is about the question I deliberately left open:

Should you build that ledger at all?

The honest answer is annoying: it depends where you are.

But “it depends” is too cheap. Most fintech architecture articles refuse to put a number on the decision because numbers make the advice falsifiable. So let me put numbers on it.

Every fintech eventually faces this decision. And unlike most architecture choices, getting it wrong in either direction is expensive.

Build too early and you pour 12 to 18 months of engineering into infrastructure while competitors ship product. The ledger becomes a monument to ambition, not a business asset.

Buy and stay too long and the vendor becomes your margin tax. Per-transaction pricing starts eating unit economics. Product rules no longer fit the vendor model. Migration becomes a multi-year crisis with finance, engineering, legal, compliance, and support all staring at the same monster.

Neither failure is hypothetical.

Company	Region	Scale	Ledger reality
Nubank	Latin America	130M+ customers	Home-built at scale. At that size, there is no real alternative.
Revolut	Europe / Global	50M+ customers, 35+ countries	Multi-currency and multi-jurisdiction complexity force internal control.
Chime	USA	20M+ customers	Built on partners and BaaS early, then had to evolve control as scale grew.
WeBank	China	300M+ users	Internal infrastructure from day one. The scale makes vendor abstraction unrealistic.
OPay	Africa	35M+ users	Mobile-first, high-volume, infrastructure-constrained markets require deep operational control.
Klarna	Europe / Global	BNPL at global scale	Deferred payment rules demand custom accounting semantics.
N26	Europe	~8M customers	Still a range where buying or abstracting can be defensible, depending on product complexity.
Monzo	UK	~9M customers	Near the threshold where the decision becomes much harder.

The point is not that everyone should copy Nubank or Revolut. Please do not. That is startup cosplay.

The point is that most companies do not talk openly about when they crossed the line from “vendor is fine” to “vendor is now the problem.”

So here is my practical version.

The three thresholds

There are three thresholds that matter more than company vanity, engineering ego, or conference-talk architecture.

1. Volume threshold: how many ledger-relevant events you process.
2. Complexity threshold: how custom your accounting rules are.
3. Control threshold: how painful it is when the ledger is wrong, slow, opaque, or externally constrained.

You do not need to cross all three before building. But if you cross two of them, the vendor is probably no longer your platform. It is your bottleneck.

Threshold 1: volume

If you are processing fewer than 100,000 ledger events per month, do not build a serious custom ledger unless regulation or product complexity forces you.

At that level, your biggest risk is not vendor cost. Your biggest risk is spending your best engineers on accounting infrastructure before you know whether the product deserves to exist.

Use a vendor. Use a banking partner ledger. Use Stripe Treasury, Unit, Synctera, Griffin, Mambu, Thought Machine, Formance, Modern Treasury, or whatever fits your geography and product. The specific vendor matters less than your discipline around boundaries.

But do not couple your product domain directly to the vendor API.

That is the real mistake.

Create your own internal ledger interface from day one:

Product event
   ↓
Internal ledger command
   ↓
Ledger abstraction
   ↓
Vendor ledger / partner ledger / internal ledger later

The abstraction does not need to be fancy. It needs to preserve intent.

A purchase is not just a vendor transaction. A fee is not just a row. Interest accrual is not just a balance adjustment. These are accounting facts. Model them as your facts, then translate them to the vendor.

At 100,000 to 1 million ledger events per month, you should still probably buy, but you must start measuring the exit.

This is the range where teams lie to themselves.

The vendor still works. The invoice is annoying but not fatal. Operations has some manual reconciliation, but people call it “process.” Engineers complain about missing features, but product still ships.

This is when you should build the migration muscle, not necessarily the ledger.

That means:

• export every vendor posting daily;
• replay it into your own analytical ledger store;
• reconcile vendor balances against your own derived balances;
• version your accounting rules;
• keep immutable product events;
• write migration playbooks before you need them.

You are not building the source of truth yet. You are building the ability to leave.

At 1 million to 10 million ledger events per month, the question becomes serious.

This is where per-transaction pricing starts to matter. This is where reconciliation delays become visible. This is where product teams ask for accounting behavior the vendor cannot express cleanly.

If your product is simple, you can still buy. A debit card product with straightforward holds, captures, refunds, and fees might survive longer on vendor infrastructure.

But if you have credit, installments, BNPL, merchant financing, wallet balances, multi-party settlement, cashback, rewards liability, chargebacks, interest accrual, delinquency, refinancing, or partial reversals, you are entering the danger zone.

At 10 million+ ledger events per month, if the ledger is core to your product, you should have a credible internal ledger strategy.

Not necessarily a full replacement already running everything. But a real strategy. Team. Roadmap. Shadow ledger. Reconciliation. Migration plan. Board-level understanding.

At 100 million+ ledger events per month, buying the core ledger is usually a temporary state, not a destination.

You can still buy surrounding systems. You can buy KYC, card issuing, payment rails, fraud tooling, reporting helpers, dispute tooling, operational dashboards. But your core ledger semantics probably need to belong to you.

Because at that point your ledger is not a back-office system.

It is the product.

Threshold 2: accounting complexity

Volume is the obvious number. Complexity is the one that sneaks up quietly and punches you in the face.

A simple prepaid wallet has relatively simple rules:

cash in  → increase customer liability
cash out → decrease customer liability

Still important. Still needs auditability. But the model is conceptually simple.

Credit is different.

Credit ledgers deal with time.

Interest accrues. Fees are incurred. Payments allocate across principal, interest, tax, penalty, insurance, and sometimes merchant receivables. A reversal might need to unwind only part of a previous event. A chargeback can arrive weeks later. A restructure can change the future without rewriting the past.

BNPL adds another layer because a single purchase can become several receivables with different due dates, merchant settlement timing, subsidy rules, late-fee treatment, and jurisdiction-specific constraints.

Multi-currency adds FX. Cross-border adds localization. Banking adds regulatory reporting. Business accounts add multi-user ownership and authorization rules.

This is where vendor ledgers often become uncomfortable.

Not because vendors are bad. Many are good. But vendors must support generic models. Your competitive product logic is usually not generic.

Here is my rule of thumb:

If your ledger can be described mostly as money movement, buy.

If your ledger must encode product-specific financial contracts, start preparing to build.

A financial contract is something like:

• “interest accrues daily but capitalizes monthly unless the account is delinquent”;
• “payments allocate to fees first in one market and principal first in another”;
• “merchant discount funds part of the installment cost”;
• “cashback is a liability until earned, then expires after a jurisdiction-specific period”;
• “a refinancing event preserves audit history but changes future accrual schedule”;
• “a disputed transaction freezes some ledger movements but not all of them.”

If these rules are your product, outsourcing the ledger can become outsourcing the shape of your company.

That is dangerous.

Threshold 3: control

The third threshold is control.

Ask a very direct question:

When the ledger is wrong at 2 a.m., who can explain it?

If the answer is “we open a vendor ticket,” that might be acceptable at the beginning.

It is not acceptable forever.

Control means you can answer basic questions quickly:

• Why did this customer balance change?
• Which product event caused this posting?
• Which code version produced the accounting entry?
• Was the movement reversed, adjusted, or corrected?
• Does finance agree with the customer-facing balance?
• Can we replay the account from origin and get the same result?
• Can we prove this to an auditor without asking engineering to manually stitch logs together?

If you cannot answer these questions, you do not control your ledger. You have access to one.

Those are different things.

This is also where compliance pressure matters. A vendor can give you reports. That is not the same as having a ledger model that reflects your business truth.

The Synapse collapse in 2024 was a brutal reminder that money movement without clear reconciliation is not just an operational inconvenience. It becomes customer harm. When a platform cannot clearly prove who owns what, the failure stops being a backend incident and becomes a financial crisis.

Your ledger is not only a database.

It is evidence.

The real build-vs-buy matrix

Here is the matrix I would actually use.

Stage	Monthly ledger events	Product complexity	Recommendation
MVP	<100k	Low	Buy. Do not waste engineering cycles.
Early product-market fit	100k–1M	Low / medium	Buy, but build your internal abstraction and export pipeline.
Scaling	1M–10M	Medium / high	Run a shadow ledger. Start serious build planning.
Growth	10M–100M	High	Build or migrate core ledger semantics internally.
Large-scale fintech	100M+	High / regulated	Own the ledger. Buy around it, not inside it.

This matrix is not universal. Geography matters. Regulation matters. Team quality matters. Vendor maturity matters.

But it is a better starting point than “always build because fintech is special” or “always buy because infrastructure is undifferentiated.”

Both slogans are lazy.

The mistake: making it a binary decision

The smartest companies do not decide build or buy once.

They design the transition.

A good fintech ledger journey usually looks like this:

Phase 1: Vendor ledger
Phase 2: Vendor ledger + internal domain events
Phase 3: Vendor ledger + shadow internal ledger
Phase 4: Internal ledger for selected products
Phase 5: Internal ledger as source of truth
Phase 6: Vendors become rails, processors, and reporting integrations

This is the part many teams miss.

You do not wake up one day and “migrate the ledger.” That is how you create a two-year program with no product output and infinite risk.

You make the future ledger inevitable by preserving the right data today.

That means every product event must be immutable. Every vendor posting must be exportable. Every balance must be reproducible. Every correction must be a new fact, not a database update. Every accounting rule must have a version.

If you do that, buying early is not a trap. It is a bridge.

If you do not do that, buying early becomes dependency debt.

Dependency debt is worse than technical debt

Technical debt is when your code is ugly.

Dependency debt is when your business cannot move because another company’s model became your architecture.

That is much worse.

You see dependency debt when:

• every new product requires vendor approval;
• finance has manual spreadsheets to compensate for missing ledger semantics;
• support cannot explain customer balances without engineering help;
• product avoids features because “the ledger cannot do that”;
• vendor invoices grow faster than revenue;
• data exports are incomplete, delayed, or lossy;
• migration is scary because nobody trusts the historical data.

At that point, the vendor is not saving you time anymore. It is renting back your own future.

The team question

There is another uncomfortable truth: even if you should build, you may not be able to.

A ledger team is not just a backend team with better table names.

You need people who understand:

• accounting semantics;
• distributed systems;
• idempotency;
• audit trails;
• reconciliation;
• financial operations;
• failure modes;
• migration strategy;
• regulatory evidence;
• product behavior.

This is rare.

If you do not have that team, buying is not weakness. It is risk management.

But if ledger correctness is core to the company and you never develop that capability, you are also taking a risk. You are betting that your vendor, your pricing, your product shape, and your regulatory environment will remain aligned forever.

That is not a strategy. That is hope with a contract attached.

The ugly middle

The hardest companies are not tiny startups or giant fintechs.

The hardest companies are in the middle.

They have enough scale for the vendor to hurt, but not enough engineering capacity to replace it cleanly. They have enough complexity to need custom rules, but not enough accounting maturity to encode those rules safely. They have enough incidents to know the current system is bad, but not enough confidence to migrate.

This is where leadership matters.

The wrong move is to approve a heroic rewrite.

The right move is to create a controlled ledger transition:

1. define the canonical product events;
2. export all vendor postings;
3. build a shadow ledger;
4. reconcile daily;
5. choose one low-risk product slice;
6. make the internal ledger source of truth for that slice;
7. expand gradually.

No drama. No rewrite mythology. No “big bang.”

Just accounting gravity.

My actual recommendation

If I were advising a fintech founder or CTO, I would say this:

Before product-market fit, buy.

Your mission is learning, not infrastructure purity.

After product-market fit, abstract.

Do not let a vendor API become your domain model.

At serious scale, shadow.

If you cannot independently reproduce balances, you are flying blind.

When financial contracts become your product, build.

Not because engineers like building systems. Because your accounting semantics are now part of your differentiation.

At massive scale, own.

Nubank, Revolut, WeBank, Klarna, and similar companies are not running internal ledger infrastructure because it looks good in architecture diagrams. They do it because the alternative eventually becomes impossible.

The uncomfortable final answer

So, should you build your fintech ledger?

If you are early: probably not.

If you are scaling: not yet, but prepare aggressively.

If you are complex: sooner than you think.

If you are huge: you probably should already have done it.

The mistake is not buying.

The mistake is buying in a way that makes building impossible later.

A vendor ledger can be a very good bridge. It can help you launch, learn, survive audits, and avoid wasting your best engineers on infrastructure before the business deserves it.

But a bridge is not a home.

At some point, if the ledger is where your product rules, customer balances, finance truth, regulatory evidence, and unit economics all meet, then the ledger is not infrastructure anymore.

It is the company’s memory of money.

And that is not something you want to rent forever.