In short
Buy a core banking ledger when your product records money in conventional ways and speed to market matters more than control; build one when your product needs settlement timing, balance structures or embedded controls that vendors do not sell. The decision matters more than most architectural choices because the ledger encodes the operating model and every product decision downstream inherits it. The more important discipline is portability: design so the ledger can be replaced, because the cost of being wrong is determined almost entirely by whether migration was made possible at the outset.
Why this decision carries more weight than it looks
Most architectural choices are reversible under pressure. Services get rewritten, APIs get versioned, front ends get replaced entirely every few years without anyone outside the team noticing. The ledger is not in that category, because it is not really a component. It is the formal record of what the institution believes to be true about money it is responsible for.
That record has legal weight, regulatory weight and operational weight simultaneously. Changing it means migrating balances that must never be wrong, in a system that cannot go down, under rules that require you to be able to explain every posting afterwards. This is why ledger replacement programmes are measured in years and why so many are abandoned.
The questions that separate the two
The standard build-versus-buy analysis of total cost of ownership, time to market and in-house capability is not wrong, but it does not discriminate here. Almost every input favours buying, right up until the product needs something the vendor does not model, at which point every one of those inputs inverts at once.
Three questions do discriminate. First: does your product require settlement or availability timing that differs from the conventional model, such as instant availability against uncleared funds, multi-stage holds, conditional release? Second: do balances need structure a vendor will not represent, such as multi-asset, multi-entity, sub-ledgers with independent rules? Third: does compliance need to sit inside the posting path rather than beside it, so that a transfer is refused before it is recorded rather than reported afterwards?
A clear no to all three means the market almost certainly sells what you need, and building is an expensive route to a solved problem. A clear yes to any one of them means the vendor evaluation will end in a customisation project that is a build with worse ergonomics and someone else's release cycle.
The double-entry discipline is not optional either way
Whichever side of the decision you land on, the invariant is the same: every movement of value produces balanced entries, and the system refuses anything that does not reconcile. Products that record balances as mutable numbers on an account row work perfectly until the first dispute, the first partial reversal or the first regulator asking how a figure was arrived at.
This sounds obvious and is routinely skipped, usually because the first version of a product does not feel like a bank yet. The cost of adding double-entry afterwards is not the schema change. It is the reconstruction of history that nobody recorded in the right shape.
The hybrid that usually is not one
Most teams, having found the decision uncomfortable, reach for a middle path: buy the core and build a thin layer around it for the parts that do not fit. This is sometimes exactly right and frequently the worst of both, and the difference is entirely about which direction the thin layer faces.
A layer that sits in front of the vendor, translating your domain language into theirs and owning the interface the rest of the system codes against, is genuine insurance. It costs little, it keeps the vendor replaceable, and it means product teams never learn the vendor's vocabulary in the first place.
A layer that sits beside the vendor, holding state the vendor does not model, is a second ledger. Two systems now believe things about the same money, and something has to reconcile them continuously and decide who wins when they disagree. That reconciliation is harder than the ledger would have been, it is invisible in the architecture diagram, and it is where a surprising number of long-running data-integrity problems actually live.
The test is whether the layer holds authoritative state. If it does, you have built a ledger without deciding to, and it deserves the design attention of one.
Design for replacement, whichever you choose
The most valuable thing to get right is not the choice. It is ensuring the choice can be revisited. That means the rest of the system talks to the ledger through an interface you own, not the vendor's SDK; that postings are expressed in your domain language and translated at the boundary; and that you can reconstruct balances independently from an event history you control.
Teams that do this can migrate in a difficult quarter. Teams that do not are quoting for a multi-year programme and usually decide, correctly, that they cannot afford it. Which is how an early integration convenience becomes a permanent constraint on the business.