What I Wish Someone Had Told Me Before Joining My First Fintech Project
"I thought I was building a payments app. I was actually building a regulated financial instrument that happened to have a UI."
My first week at a fintech startup, I was handed a Jira board, a laptop with twelve browser tabs already open, and the sentence: "You'll be working on the ledger service." I nodded like I knew what that meant.
I did not know what that meant.
I had spent three years building web apps. I knew React. I knew REST APIs. I knew how to write a migration and deploy a service. None of that prepared me for what a ledger actually is, why it works the way it does, or what happens to a team when it goes wrong.
What Nobody Tells You on Day One
In most software jobs, data is fairly forgiving. A user profile has a wrong field? Fix it, redeploy, move on. Nobody gets hurt. The system self-corrects and the user never knows.
In financial software, data is a record of truth. Not a record that can be patched and redeployed, a legal record of every penny that moved through your system, when it moved, where it went, and why. The ledger is not a balance column in a database. It is the source of truth for every financial event your product has ever processed, and it has to be correct not just today but auditable five years from now when a regulator asks to see it.
This sounds dramatic until the first time you see what happens when it is wrong. Our QA engineer found a scenario where a refund was processed but the corresponding debit entry wasn't created. The amount was £1.40. Objectively small. The incident still took two engineers three days to resolve, not because the fix was technically difficult, but because we had to prove to the compliance team, with evidence, that no real money had moved incorrectly and that the error had never reached production. The fix took an hour. The proof took three days.
That was my introduction to what fintech actually means at the engineering level. The code is almost never the hard part.
The Ledger Is Not What You Think
Most developers learn about databases in the context of storing and retrieving application state. You have a users table, an orders table, maybe a products table. You read from them and write to them. When something needs to change, you update the row.
A ledger does not work like this, and the reason it doesn't is not arbitrary, it comes from five hundred years of accounting practice that predates computers entirely.
Here is the core principle: in a ledger system, money is never created or destroyed. It moves. Every transaction creates at least two entries, a debit on one account and a credit on another. The sum of all entries across the entire ledger must always equal zero. Always. This is called double-entry bookkeeping, and it is not optional in regulated financial software.
I spent my first two weeks thinking this was an accountant's constraint that the software was forced to accommodate. It isn't. It is an engineering property that makes the system self-auditing. If your ledger doesn't balance, you know something went wrong. You don't need to compare it against an external source of truth, the math tells you. That property is enormously valuable in a system where correctness is non-negotiable.
The practical consequences for developers: you cannot UPDATE a balance. Updating loses the audit trail, you can see what the balance is now, but not what it was before and what caused it to change. You cannot DELETE rows. Deleting destroys the record of what happened. You store every amount as an integer in the smallest unit of the currency, pence, cents, paisa, because floating point arithmetic will eventually produce a result that is wrong by a fraction, and in a system that has to balance exactly, a fraction matters.
These aren't style preferences. They are constraints that the domain imposes on the engineering, and developers who treat them as optional create problems that are expensive and time-consuming to fix.
The Rounding Error That Wasn't
About six weeks in, I was asked to investigate why a batch job was producing totals that were off by £0.01 on roughly one in every 200 transactions. My first instinct was the obvious one: rounding error, easy fix, change the rounding mode.
It was not a rounding error in the conventional sense. The arithmetic was correct. The problem was subtler and more instructive.
We were applying a percentage fee to a transaction amount. The fee was calculated, rounded to two decimal places, and stored. The net amount, what the customer received after the fee, was calculated separately, also rounded to two decimal places, and stored alongside it. Over thousands of transactions, the rounding applied independently to each figure meant the two numbers didn't always sum back to the original amount. The difference was never more than a penny, but in a ledger, a penny is a discrepancy, and a discrepancy means the books don't balance.
The fix was not to change the rounding. It was to change the calculation order. Calculate the fee. Round it. Then derive the net as total minus rounded fee, not by rounding the net independently. This way, the two entries always sum exactly to the original amount, regardless of how the decimal falls. The constraint is enforced by the arithmetic, not by hoping both figures round the same way.
This is the kind of problem that doesn't exist in most software domains. In fintech it comes up regularly, and developers who haven't encountered it before tend to reach for the wrong solution because the problem pattern doesn't match anything in their prior experience.
Compliance Is Not the Enemy
Before this job, I had a loose understanding of compliance as a function that slowed things down. Legal and regulatory people who added friction to the roadmap. Checklists that delayed launches. Processes that existed because of some incident at a different company a long time ago.
What I actually found was something different. The compliance team at that startup understood the rules of the domain better than almost anyone else in the building, including the engineers. When they flagged a concern, it was usually because they had read a regulation we hadn't, or because they had seen what happened when the same shortcut was taken at a previous company, or because they understood the downstream consequences of a design decision that looked purely technical on the surface but had regulatory implications we hadn't considered.
The best engineers I worked with treated compliance requirements the same way they treated performance constraints or security requirements, as parameters that shaped the design, not obstacles that blocked it. The question was never "how do we get around this requirement" but "how do we build a system that satisfies this requirement without making everything else worse."
That framing makes compliance conversations productive. The compliance team knows what the rule is. The engineering team knows what's technically feasible. The job is to find the design that satisfies both. That's a collaboration, not a negotiation.
What I Would Tell Someone Starting Now
Learn the domain before you touch the code. Spend your first week understanding how the financial product actually works, what money flows in, what flows out, who holds what at each stage, what happens when something fails. Draw it on paper. Ask the most experienced person you can find to walk you through a transaction end to end, including the unhappy paths. Do this before you read a line of code, because the code will make more sense once you understand what it's trying to do.
Never mutate financial records. Append only. Every state change is a new record with a timestamp and a cause, not an update to an existing one. If the codebase you've joined does use mutable records, treat that as technical debt with regulatory implications, understand why it works the way it does, and don't add more of it.
Ask about the regulatory environment on day one. Is this product regulated by the FCA? Does it fall under PSD2? Are there AML screening requirements? GDPR data retention rules that conflict with audit trail requirements? Knowing which regulations apply tells you which parts of the system are load-bearing from a compliance perspective and which are ordinary business logic. They require different levels of care.
When something is off by a penny, take it seriously. In most software, a one-pence discrepancy is a rounding quirk you note and move on from. In fintech it is a signal that your accounting model has a structural flaw. Find it before it compounds. The discrepancy is small. The underlying problem often isn't.
Learn the vocabulary before you need it. Debit, credit, settlement, clearing, reconciliation, float, escrow, chargeback, nostro, vostro, these are not jargon you can look up when they come up. They are the language of the domain, and not understanding them fluently means every requirements discussion requires translation. Developers who speak the domain's language make fewer mistakes and are faster to become useful.
The Thing I Actually Learned
Eighteen months into that job, I noticed that I had stopped thinking of the product as a software system and started thinking of it as a financial instrument. The code was how we expressed the rules of that instrument in a form computers could execute. The correctness of the code wasn't a quality metric, it was the product. A payments system that is mostly correct is not a payments system. It is a liability.
That shift, from building features to implementing financial rules correctly, changed how I read requirements, how I reviewed code, how I thought about testing, and how I talked to the compliance team. It made me slower on the first pass and faster overall, because I stopped building things that had to be rebuilt after the compliance review.
If you are about to start in this domain, give yourself permission to go slow at the beginning. Read more than you code. Ask questions that feel embarrassingly basic. The developers who try to move fast before understanding the domain are the ones who create the incidents that take three days to resolve, not because they are bad engineers, but because they applied good engineering instincts to a domain with constraints they didn't yet know existed.
You do not want to be the person who moves £0.01 to the wrong account. Not because it's a large amount. Because of everything that has to happen next.
Tags