Build vs Buy a Payments Ledger: A Decision Guide for Regulated Fintechs

TL;DR: A payments ledger is not a table of balances. It is a set of enforced rules (balanced entries, immutability, idempotency, reproducible reconciliation) that your regulator, your auditor and your operations team all lean on. Buy a ledger when your money movement is conventional and your differentiation lives elsewhere. Build one when your product model, your multi-currency logic or your regulatory reporting does not fit a vendor's data model, and you are prepared to own the invariants for years. For most regulated fintechs in the UK and Singapore, the honest answer is a hybrid: buy or adopt the commodity parts, build the thin layer that encodes your own money rules. This guide gives you the criteria, the failure modes and a scoring approach to decide.

Why this decision is harder for regulated firms

If you run an unregulated app, a ledger mistake is a bug. If you hold customer money under a payments or e-money licence, a ledger mistake can become a safeguarding shortfall, a reporting breach or a problem in a wind-down.

Two things have changed the stakes recently. In the UK, the FCA's reformed safeguarding rules for payments and e-money firms (policy statement PS25/12, issued 7 August 2025) apply from 7 May 2026. According to law-firm commentary from Linklaters, firms need to be ready for new record-keeping, reconciliation and regulatory reporting requirements, and must be able to show ongoing compliance to their auditors and the FCA. Charles Russell Speechlys summarises the supplementary regime as including the ability to distinguish client funds at any time, a resolution pack to support an orderly wind-down, monthly safeguarding returns to the FCA, and annual audits by external auditors, with an exemption for firms that have never safeguarded more than £100,000 in the previous 53 weeks.

In Singapore, the Monetary Authority of Singapore (MAS) states in a written parliamentary reply of 15 October 2024 that major payment institutions must safeguard monies received, by depositing relevant money in a trust account with a safeguarding institution or bank, or by obtaining an undertaking or guarantee from one. The reply also says the money must be safeguarded by the end of the next business day after receipt from a customer.

We are not lawyers, and nothing here is legal advice. Your compliance team and counsel decide what your licence requires. But the engineering consequence is clear: whichever rules apply to you, the ledger is where you will prove that you knew, at any moment, whose money was where. That is the real test for any build-or-buy decision.

What a payments ledger actually has to do

Before comparing options, agree on what the thing is. Engineers who have built these systems describe a consistent core.

Balanced double-entry postings. Every event produces entries whose debits equal credits, per currency. One experience report describes enforcing this inside the database at commit time rather than in application code, because backfills, scripts and incident patches bypass application checks (Ralmeida, DEV Community). Another engineering guide makes the same argument and adds that cross-currency movement is modelled as two balanced postings joined by an FX conversion account (Dodo Payments engineering blog).

Immutability. A posted entry is never edited. Corrections are a reversal plus a new, corrected posting. The same sources frame append-only design as an audit model rather than a storage choice, since updates destroy the audit trail and make reconciliation non-deterministic.

Idempotency. Payment systems are at-least-once. Webhooks retry, clients double-click, queues redeliver. The ledger needs a hard uniqueness rule so one real-world intent can only ever become one transaction, ideally enforced by a unique constraint rather than a cache.

Integer money. Amounts are stored in the smallest unit of the currency, and not every currency has two decimal places. Fee remainders have to be assigned deterministically or the books drift.

Derived balances. Balances are a projection over entries. One test worth stealing: if you cannot drop the balances table and regenerate it exactly from the entries, something is writing balances directly.

Reconciliation as a first-class workflow. Matching your records against processor, scheme and bank statements is not a simple equality check. It becomes a matching engine with exact, windowed and tolerance-based strategies, with unmatched items going to a review queue.

None of these is exotic. The difficulty is that each rule is simple on its own and the failures appear only under production pressure: concurrent requests, partial outages, late data, a script someone ran at 2 a.m.

The three options, honestly compared

Option 1: Build in-house

You design the schema, the posting rules, the reconciliation and the reporting, and you operate it.

What you gain: A data model that mirrors your product exactly, including unusual fee structures, multi-party flows, wallets with sub-accounts, or programme-manager arrangements. Full control over reporting formats for your regulator. No vendor in your critical path. Deep in-house understanding of where every pound or dollar is.

What you take on: Every invariant above, permanently. Migration tooling when the model changes. Performance engineering as volume grows. A key-person risk if two engineers understand the ledger and one leaves. And an audit burden: your auditors will want to understand a bespoke system rather than a known product.

Option 2: Buy a ledger service or adopt a ledger product

You use a vendor's ledger API or a core banking or accounting-adjacent platform and configure it.

What you gain: Speed to a working double-entry core, vendor-maintained invariants, and an established audit conversation. Vendors in this space argue that accounting packages are poor persistence layers for a product, because their data can be stale and their chart of accounts may not suit product-level flows (Modern Treasury, 2021). Note that this is a vendor's own framing of its market, so read it as a position, not a neutral finding.

What you take on: A dependency in the money path. A data model you must fit into, which becomes the hard part at the edges. Data-residency and outsourcing questions that your regulator may care about. Exit cost: if you ever leave, you need to migrate history without breaking audit continuity. Treat the contract's data export and termination terms as engineering requirements.

Option 3: Hybrid

You adopt a proven open or commercial ledger core, or a well-understood pattern such as a Postgres-based double-entry schema, and build a thin domain layer on top: your posting rules, your account hierarchy, your reconciliation matching, your regulatory reports.

What you gain: You avoid reinventing the invariants while keeping the parts that are specific to your business. The domain layer is small enough to review line by line.

What you take on: Integration work, and the discipline to keep the boundary clean so the domain layer never bypasses the core's guarantees.

A decision framework you can actually use

Score each factor from 1 to 5 for your firm, write the reasoning down, and have compliance, finance and engineering score independently before comparing.

1. How unusual is your money model?

If you move money in the standard shapes (collect, hold, pay out, charge a fee), a bought ledger will probably fit. If you have pooled and segregated structures, marketplace splits, programme-manager roles or several legal entities in one flow, check whether the vendor's account model can express them without workarounds. Workarounds in the ledger are where reconciliation breaks live.

2. Where does your differentiation sit?

If customers choose you for the way money moves (speed, structure, pricing logic), the ledger is part of the product, and owning it is easier to justify. If they choose you for the experience, the data or the distribution, the ledger is plumbing.

3. How demanding is your regulatory reporting?

Ask a specific question: can the candidate system produce, on demand, a point-in-time position showing which funds belong to which customers, and can it reproduce last month's position exactly? Your safeguarding, resolution-pack and return obligations will depend on that. Whether you build or buy, the capability has to exist and be testable.

4. What are your multi-currency and cross-border flows?

Multi-currency is where homemade ledgers most often go wrong. Rates must be captured once and stored on the affected entries. A "current price" call inside the posting pipeline is a correctness bug, because replaying history then gives different answers. If you operate across the UK and Singapore, check how a vendor handles per-currency balancing, FX accounts and the rate timestamp.

5. What is your team's depth in ledgers specifically?

General backend skill is not enough. Concurrency, idempotency under retries and reproducible reconciliation are specialist problems. Be candid about whether you have people who have operated one at your expected volume.

6. What is your exit and concentration risk?

For a bought ledger, ask what happens if the vendor is acquired, degrades or fails. Your operational resilience plan should cover it. We cover that angle in our piece on operational resilience for fintech software across FCA, DORA and MAS.

7. How fast do you need to be live?

A bought core can shorten time to first transaction. But the schedule risk usually hides in the integration and the data-migration work, not the ledger itself.

A rough way to read your scores

We avoid false precision here, because every firm's weighting differs. As a guide: if your answers to questions 1 and 2 say "unusual model, differentiating", and question 5 says "we have the depth", building (or the hybrid with a heavy domain layer) is defensible. If questions 1 and 2 say "standard, plumbing" and question 5 says "we do not have the depth", buying is usually the safer route. Mixed scores point to the hybrid.

Write the decision and the assumptions behind it into your architecture decision records. Regulators and auditors respond well to a documented rationale, whatever you chose.

The failure modes that decide most projects

Concurrent writes and balance integrity

Two payouts debiting the same account at the same moment is the classic race. The engineering sources we reviewed describe enforcing balance rules through database constraints and unique indexes rather than coordination layers, but they do not go deep on locking and contention, so do not assume a pattern from a blog post survives your volume. Load-test with realistic concurrency on the account types that get hot, such as fee accounts and settlement accounts that every transaction touches.

Retries and duplicates

Derive idempotency keys from the source event (the processor's event identifier and the posting type) and not from each attempt. If the key changes on every retry, the retry becomes a duplicate. This single point causes more duplicate postings than almost anything else.

Late and out-of-order data

Settlement files arrive after the events they describe. Keep business time (when it happened) separate from recorded time (when you learned of it). Without both, you cannot reproduce a past position, which is exactly what an auditor will ask for.

Reconciliation drift

The usual sources of breaks, in rough order of frequency, are timing differences between capture and settlement dates, fees that were never modelled, rounding, and reversed disputes (Dodo Payments). Give rounding its own account so it is visible. Keep processor receivables and bank cash as separate accounts. And treat reconciliation as a scheduled job that emits a break report, not as a spreadsheet exercise.

If reconciliation is where your pain is today, read our guide to reconciliation automation for payment platforms, and see how we approach it on the reconciliations engine page.

Corrections done wrong

Editing a posted entry to fix a mistake feels efficient and destroys the audit trail. The pattern to insist on is reversal plus corrected posting, with a constraint that prevents the same entry being reversed twice, and no backdating into a closed period.

UK and Singapore: what changes in practice

United Kingdom. The new safeguarding regime puts pressure on three engineering capabilities: knowing at any time which funds are client funds, reconciling on a defined cadence with limited exemptions, and reporting monthly. Charles Russell Speechlys notes weekend and public holiday reconciliation exemptions and an alternative-methods route subject to independent auditor approval, but check the FCA's own rules and your adviser's reading before designing around either. We reviewed secondary commentary, not the full policy statement text, so treat our summary as a starting point for your compliance team.

Singapore. The headline engineering constraint from MAS's published position is timing: safeguarding by the end of the next business day, using a trust account, undertaking or guarantee. Your ledger needs a clear concept of "relevant money" owed to customers versus operating money, and the ability to show it. MAS's exemption proposals for certain cross-border flows were only a consultation in 2023 according to Allen & Gledhill, so confirm their current status before relying on them.

Both. Operational resilience, outsourcing and data security expectations apply to a bought ledger as much as a built one. Our article on data security architecture for fintech covers the control side.

Comparison table

A phased approach that limits regret

1. Write the invariants first. List your rules in plain language: balanced per currency, no edits, one intent one posting, reproducible position at any past time. Any candidate, built or bought, must satisfy them.
2. Model your five hardest flows on paper. Include a refund, a chargeback, a multi-currency payout, a failed settlement and a month-end correction. If a candidate cannot express them cleanly, you have learned something cheaply.
3. Run a time-boxed spike. Prototype the hardest flows on the finalist options, including a build spike. Measure concurrency behaviour, replay and reconciliation output, not demo polish.
4. Test the exit. Export a sample dataset and rebuild a past position from it.
5. Involve compliance and your auditor early. Show them the data model and the reports before you commit.
6. Keep the ledger behind your own interface. Whatever you pick, put a thin internal API in front of it so the rest of your platform never talks to the vendor or the tables directly. That is the cheapest insurance against changing your mind.

If you want a neutral partner for the vendor comparison step, our technology vendor evaluation and compliance and risk consulting services exist for that. For the build and integration side, see API development and integration and custom software development. Related reading on our blog: API-first architecture for fintech startups scaling beyond the MVP.

Common mistakes

• Treating the ledger as a reporting database. It is the system of record; reports read from it.
• Letting product teams write balances directly "for performance". Use projections and rebuild tests.
• Choosing a vendor on a demo. Demos show the happy path. Your risk is in the retries and corrections.
• Underestimating migration. Moving history later is far costlier than choosing the model carefully now.
• Skipping the auditor conversation. Surprises at year-end are expensive.
• Believing "days of modelling" claims. Vendor and blog estimates of how quickly a ledger can be built are not evidence about your case.

Conclusion

The build-or-buy question is really a question about where you want to carry risk. Buying moves some invariant maintenance to a vendor and adds a dependency. Building gives control and fit and makes you responsible for every guarantee, indefinitely. The hybrid works for many regulated firms because it limits the code you must defend while preserving what is distinctive about your money model.

Whichever way you lean, make the rules explicit, test the hard flows before you commit, keep the ledger behind your own interface, and involve compliance and your auditor early.

Want a second opinion on your ledger decision? We can walk through your money flows, the regulatory constraints for the UK and Singapore, and the trade-offs of each route. Pricing for any engagement is scoped after a consultation. Book a meeting with the Syslabs team and the booking page will show times in your own time zone.

Sources

• Linklaters, "Payments in 2026: safeguarding" (27 January 2026): https://financialregulation.linklaters.com/post/102mef0/payments-in-2026-1-safeguarding
• Charles Russell Speechlys, "Safeguarding overhaul: the FCA confirms new rules for payments and e-money firms": https://www.charlesrussellspeechlys.com/en/insights/expert-insights/financial-services/2025/safeguarding-overhaul-the-fca-confirms-new-rules-for-payments-and-e-money-firms/
• Monetary Authority of Singapore, written reply to parliamentary question on funds collected by payment service providers (15 October 2024): https://www.mas.gov.sg/news/parliamentary-replies/2024/written-reply-to-parliamentary-question-on-funds-collected-by-payment-service-providers
• Allen & Gledhill, MAS consultation on Payment Services (Amendment) Act 2021 regulations (24 May 2023): https://www.allenandgledhill.com/sg/publication/articles/24692/mas-consults-on-amendments-to-regulations-and-notices-to-operationalise-payment-services-amendment-act-2021
• Ralmeida, "Why building a ledger is harder than it looks", DEV Community: https://dev.to/tomasralmeida/why-building-a-ledger-is-harder-than-it-looks-21cm
• Dodo Payments, "Payment ledger design for billing systems" (vendor blog, 2026): https://dodopayments.com/blogs/payment-ledger-design/
• Modern Treasury, "Announcing Ledgers" (vendor post, 2021): https://www.moderntreasury.com/journal/announcing-ledgers