OBI PASCAL BANJUARE
Sr. Software Engineer || FinTech Engineer || Tech Advisor
Ready for work
OBI PASCAL is ready for their next project!
One of the most expensive lessons I learned building fintech products wasn't about APIs, infrastructure, or scaling.
It was about data types.
Years ago, while building a bill payment startup, I discovered we had silently lost over ₦3 million to fractional rounding issues.
No hacks.
No fraud.
Just floating-point arithmetic doing exactly what it was designed to do.
The Facts
In JavaScript, numbers are stored as floating-point values.
That means something as simple as:
0.1 + 0.2
doesn't equal 0.3.
It equals:
0.30000000000000004
For a shopping cart, that tiny difference may not matter.
For a fintech system processing thousands of transactions daily, those tiny fractions accumulate into real money.
What I Initially Did
Like many developers, I used decimal currency values directly:
It looked clean.
But calculations, fee deductions, settlements, and balance updates gradually introduced rounding inconsistencies.
Over time, the system started leaking funds through fractions.
What Fixed It
I switched to storing monetary values in the currency's smallest unit using BigInt.
Instead of:
Store:
Now every operation becomes integer math.
No hidden fractions.
No rounding surprises.
No disappearing money.
Pros
- Precise calculations
- Predictable accounting
- Easier reconciliation
- Safer ledger systems
Cons
- Requires conversion when displaying values
- Slightly more discipline from developers
- BigInt cannot be mixed directly with Number types
Do's
> Store money in the smallest currency unit (Kobo, Cents, etc.)
> Use BigInt or dedicated decimal libraries where appropriate
> Convert only at the presentation layer
> Build your ledger around integer arithmetic
> Never convert BigInt to number on runtime to perform arithmetic operation. Perform the arithmetic operation on the BigInt Type. You can build an api transformer layer to return response in the integer form or leave value in the smallest unit while frontend do the conversion by dividing the value by 100.
Don'ts
X Store money as floating-point values
X Compare currency values using decimal calculations
X Round repeatedly during transaction processing
X Assume tiny fractions won't matter
Fun Fact
This is the same principle used by companies like Stripe. Amounts are represented in the smallest currency unit (such as cents) rather than floating-point dollars.
Wrap Up
In fintech, every fraction belongs to someone.
If your system cannot account for every smallest unit of currency, eventually those fractions become real losses.
The best time to fix monetary precision is before your first transaction. The second-best time is today.
0
7
When you're a FinTech Engineer and you're excited about AI. A called around 11pm NGT and said:
Friend👱♂️ : Hey Obi, I've got this client from Canada there want an AI Fitness app Its really an exciting project you should add it to your portfolio.
At first I was a bit reluctant, but after a lot of persuasion as someone who enjoys working with me, he keeps talking about the project every single opportunity he has for a good friendly conversation.
I finally agreed! 4-months down the line - Find Your Fitness was born!
As a Sr. Engineer on the team, one of my core responsibility was to coordinate the project from spring planning, task assignment and follow-ups on ticket to make sure the team were on track with schedule. Jira was my home screen 😂 every morning 😭 .
The design team where my friends heading did a great job, but I almost got a heart attack at one time 😂 .
It was an exciting adventure indeed, am glad I took my friend up on the offer.
0
21
"If money touches your system, a ledger should touch it first."
Your backend should be ledger-first by design.
If there's even a 0.00001% chance that money, balances, fees, commissions, credits, refunds, rewards, or anything involving an amount will flow through your system, every movement should be recorded in a ledger using double-entry accounting principles.
This isn't just for banks, fintechs, or payment processors.
Whether you're building:
=>A payment rail
=> An e-commerce platform
=> A marketplace
=> A grocery delivery app
=> A subscription service
You need to be able to answer:
> Where did this money come from?
> Where did it go?
> Who owns it right now?
> Why did this balance change?
> Can we prove it months or years later?
A ledger provides an immutable audit trail, complete traceability, and financial correctness. It eliminates balance drift, simplifies reconciliation, and gives your team confidence when investigating disputes or anomalies.
You don't need to hold funds to need a ledger. The moment your system represents value, tracks balances, calculates fees, records payouts, or reports financial activity, you're already dealing with accounting.
Design for auditability from day one. Retrofitting a ledger later is one of the most expensive engineering decisions you'll make.
1
108
Backend Developer
0
0