Insights · 9 min read
FinTech products live or die on their money path. Here is the architecture to plan first: the ledger, idempotency, consistency, compliance, and reconciliation, before you write a line of code.
By GGP Editorial
Founders building a fintech product usually start with the feature list and the design, then discover the architecture when something breaks or an auditor shows up. The architecture is the part that decides whether the product can hold real money, pass a review, and survive a bad day. It deserves to be planned first, not last.
I run a software development company and have built financial systems across payments, trading, and property management. The pattern I see in projects that go well is the same every time: they treat the money path as a first-class design problem. Here is how to think about it before you write a line of code.
A standard web app can afford to be loose about a few things. If a comment gets posted twice, nobody is ruined. A fintech system cannot. It moves money, holds balances, and has to explain every movement to a regulator or an auditor on demand.
That difference shapes every architectural decision. Fintech systems care about correctness over convenience, about a clear audit trail over clever shortcuts, and about surviving partial failures without ever losing or duplicating money. The rest of this article walks through the pieces that make those things true.
Whatever your product does on the surface, the inside of a fintech system is a ledger. Every movement of money is recorded as a pair of entries that always balance: one account is debited and another is credited, by the same amount, at the same time.
This sounds like accounting trivia, but it is the thing that saves you. With a double-entry ledger you can reconcile anything, because every balance in the system is the sum of a set of entries you can inspect. When something goes wrong, and something always goes wrong, you can find the exact entry that broke and correct it without reconstructing history.
If you are building a wallet or a payment product, the ledger is not a feature you add later. It is the foundation. Our guide to building a multi-currency wallet goes into what that ledger has to hold when you add currencies on top of it.
Payments fail in the worst possible way: the money may have moved, but the response got lost, so the sender retries. Without idempotency, that retry moves the money twice.
Idempotency means the system can accept the same request twice and apply it once. In practice every money-moving operation carries a unique key, and the system checks that key before it applies anything. This one habit prevents the class of bug that ends with a customer seeing a double charge and a support queue on fire.
It is also the difference between a demo and a product. A payment demo can ignore idempotency because nobody retries during the demo. A payment product cannot, because real networks drop responses all the time.
A useful way to split a fintech architecture is into the money path and everything else. The money path is the set of operations that create or move balances. Everything else, onboarding, dashboards, reporting, can be slower, less strict, and cheaper to build.
This split lets you spend engineering effort where correctness matters and use ordinary, faster approaches everywhere else. It also sets the priority order for hardening. If the system has a bad day, the money path is the part that must keep working and stay consistent.
Financial systems need strong consistency on the money path and can tolerate eventual consistency almost everywhere else. The practical version of that is a database with real transactions for balances and entries, and message queues for the work that can lag, like sending notifications or updating a dashboard.
Events matter here. When a payment is made, you emit an event and other parts of the system react to it. That keeps the ledger as the single source of truth and lets everything else hang off it. The alternative, where every module writes to every other module, is how you get a system nobody can debug.
We have written about the broader choice between monolith and microservices. For fintech, the answer is usually not pure microservices. It is a strong transactional core with a small number of well-defined services around it, and you can grow into more splitting later.
In fintech, security is not a checklist item you bolt on at the end. It is part of the data model. Every sensitive action is logged, every log entry is tamper-evident, and access is limited to the people and systems that need it.
Auditability means you can answer who did what, when, and why for any money movement, months later, without reconstruction. Auditors and regulators ask exactly that question, and the time to make it answerable is during design, not during an audit.
There is a regulatory layer on top of this that varies by market. If you handle card data, the PCI DSS standard applies to how you store and transmit it. If you handle customer identity, you will run into KYC and anti-money-laundering requirements, which our KYC integration guide covers. These requirements differ by jurisdiction, so treat them as something to verify with counsel for your specific market, not something this article can decide for you.
Reconciliation is the process of matching your internal ledger against the records of the banks and payment providers you work with. It is unglamorous, and it is where fintech products either stay honest or quietly fall apart.
Every day, or more often, you compare what you think happened with what the external system says happened, and you resolve the differences. Skipping this is how a discrepancy that starts at a few cents becomes a real loss months later, long after anyone remembers the original transaction.
Design for reconciliation from day one. It means keeping the external reference for every transaction, storing raw responses, and making the match process a scheduled, reviewable job rather than a manual spreadsheet.
The order matters. Before you write code, pin down these five decisions.
| Decision | Why it comes first | What you need to decide |
|---|---|---|
| Ledger model | everything else reads and writes balances | double-entry, accounts, entries, currencies |
| Idempotency | prevents double money movement | unique keys on every money operation |
| Consistency boundary | sets where correctness is non-negotiable | transactional core, queues for the rest |
| Compliance scope | changes the data you store and the review you face | card data, KYC/AML, licensing, jurisdiction |
| Reconciliation | keeps you matched to external systems | daily match process, raw responses kept |
None of these require a line of code to decide. They require a few hard conversations about what the product really does and where the money goes. Getting them right before development starts is what separates a fintech build that ships from one that gets stuck in rework.
The mistakes cluster around a few themes. Building the feature list before the ledger, so the data model gets bolted on later. Skipping idempotency, then discovering it after the first double charge. Spreading money logic across many services without a clear owner, so nobody can say exactly where a balance changed. Treating compliance as a phase at the end, when it should shape the data model from the start.
Each of these is cheap to avoid at the beginning and expensive to fix later. The most expensive word in fintech is later, because later usually means after real money and real users are involved.
GlobeSoft is a China-based software company with a global delivery model, 40-plus engineers, and more than 300 delivered projects. Fintech is one of the areas we build in most, and it is where the architecture-first habit pays off hardest.
We have delivered a multi-market brokerage trading system covering HK, US, and A-shares, along with payment systems, financial management platforms, and property rental payment systems. In every one the pattern is the same: a double-entry ledger at the center, idempotent money operations, a transactional core, and reconciliation built in from the start. Our clients own their source code, and we work in English and Portuguese across time zones.
If you are planning a fintech product and want to talk through the architecture before you commit to a build, that is the right conversation to have early. It is the cheapest time to get the money path right.
Do I need microservices for a fintech product?
Usually not at the start. A strong transactional core with a few well-defined services is enough, and it is easier to debug and audit. You can split further as the product and team grow.
What is the single most important part of fintech architecture?
The ledger. A double-entry ledger gives you balances you can reconcile and an audit trail you can trust, and everything else in the system hangs off it.
Why does idempotency matter so much?
Because payment networks drop responses and senders retry. Idempotency makes sure a retry applies once, not twice, which is the difference between a product and a double-charge incident.
How do I handle compliance in the architecture?
Decide what data you handle, card data, customer identity, regulated money movement, and where you operate, then design storage, logging, and access around those requirements with counsel for your specific jurisdiction.
What should I build first in a fintech MVP?
The money path: a ledger, idempotent core operations, and the smallest product flow that moves money end to end. Everything else can wait.
A fintech product lives or dies on its money path. Plan the ledger, the idempotency, the consistency boundary, and the reconciliation before you build, and the rest of the product becomes a matter of execution rather than a series of rescues.
Tell us what you are building and where you are today. We typically reply within 24 hours.
