Akintola Steve Profile picture
Apr 11 16 tweets 3 min read Read on X
A Nigerian fintech startup raised $3.2M, spent 14 months building a “bulletproof” payment platform, and launched with 40k users in week one.

Investors were celebrating.

Then in one weekend… everything collapsed.

Here’s the security blind spot that destroyed them, and the system design lessons every backend engineer in 2026 must understand.
Week one looked perfect.

Transactions flowing, dashboards stable, users happy.

Then support tickets exploded:

“Someone drained my wallet.”
“My balance shows -₦2.8M.”
“Unauthorized transfers at 3 am”
They thought it was a bug.
It wasn’t.
They traced it.

It wasn’t random.

It was structured exploitation.

SQL injection on a weak endpoint exposed user balances.

Replay attacks duplicated old transfer requests.

Session hijacking bypassed authentication entirely.

The system wasn’t “hacked once”.

It was systematically broken.
The real mistake?

Security was treated as a feature to add later.

Classic “we’ll secure it after MVP” thinking.

They had microservices, caching, load balancing…

But zero secure-by-design thinking from day one.

That decision broke everything.
What they missed is simple but critical:

Security is not a layer.

It is a system design requirement, like scalability or availability.

If your architecture starts without threat modeling, you are already exposed.
First principle: STRIDE threat modeling.

Every component must be analyzed:

Spoofing
Tampering
Repudiation
Information disclosure
Denial of service
Elevation of privilege
Because in reality, every system has an attacker model, whether you define it or not.
Example they ignored:

A login endpoint like:

SELECT * FROM users WHERE email = '$email' AND password = '$password'

One input change:

' OR 1=1 --

And suddenly authentication is bypassed.

No password needed.

That’s SQL injection.

Still happening in 2026.
Another failure:

A transfer API that accepted:

{ amount, recipient, timestamp }

Attackers intercepted a valid request and replayed it multiple times.

Same payload. Different outcomes.

Result: one ₦10,000 transfer became ₦100,000 in seconds.

No nonce. No signature validation. No protection.
Then authentication cracks:

Session tokens never expired properly.

Attackers stole JWTs from compromised devices and reused them across IPs.

No device binding. No token rotation.

So even after password changes, access remained active.

That is not a bug.

That is broken auth design.
Fixing this requires more than patches.

You move to Zero-Trust Architecture:

mTLS between services
Short-lived tokens
Request signing (HMAC or asymmetric)
Replay protection using nonces + timestamps
Device-bound sessions

Every request must prove it belongs.
Minimum baseline if you’re not there yet:

Input validation everywhere
WAF with OWASP Core Rules
Prepared statements only
Strict CORS + CSP policies
Rate limiting at gateway
Dependency scanning (Snyk, Dependabot)
Security chaos testing

No shortcuts.
The startup rebuilt everything.

STRIDE modeling first.
Replay protection added.
SQL injection eliminated via strict ORM + prepared queries.
JWT system redesigned with rotation + expiration enforcement.
Anomaly detection introduced for transaction spikes.

Attacks dropped by 94%.

Same product. Different assumptions.
Most systems are designed for ideal conditions.

Fast networks. Clean inputs. Trusted users.

But real systems face:

injected SQL payloads
stolen sessions
replayed requests
compromised clients

If you don’t design for attackers, you are designing for failure.
Bookmark this.

If you’re building anything serious in 2026, be it fintech, healthtech, e-commerce, or govtech.

Security is not optional.

It is system design.

Not a patch. Not a feature.

Architecture itself.
If this made you rethink your backend design, share it.

Tag an engineer who might need to learn from this too.
NB:
Fictional but real technical lessons shared.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Akintola Steve

Akintola Steve Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Akintola_steve

Apr 11
Do you understand what it means to say a distributed system in system design?

In plain, simple terms, a distributed system, as the name implies, is not just one server. It is multiple machines working together as a single system.

Let me use GTBank as a very relatable example.

You do not have just one server sitting in Lagos.
There are servers in Lagos, Abuja, and possibly even outside Nigeria.

When you check your balance or send money, your request can hit any of these servers.

They coordinate, sync data, and respond as one unified system.

That is a distributed system.

Seems interesting, right? Yes, it is.

But have you ever asked questions like:
“What happens when there is a network issue?”

That is where CAP theorem comes into play.

Let’s continue 👇🏿
Now the real problem starts when network issues happen.

Welcome to CAP theorem:

Consistency: everyone sees the same data

Availability: the system always responds

Partition Tolerance: the system survives network failure

In a distributed system, network issues are not “if”, they are “when”.
Because here in Nigeria, someday, sometime, it will definitely happen.

So when a partition, which is a network failure, happens, you must choose:

Consistency or Availability.

Not both.
Let me explain a Nigerian scenario using what we’ve covered:

You transfer ₦50,000 using OPay.
Your account is debited.
The receiving bank has not updated yet due to network delay.

Now the system must decide:

Option 1: Consistency
Delay everything until all systems agree, meaning you won’t see the transaction immediately.

Option 2: Availability
Show success instantly, but the receiver might not see the money yet.
Read 6 tweets
Apr 9
Every time your bank transfer fails in Nigeria, there’s a high chance it has nothing to do with your bank.

It failed because of one system.

One piece of infrastructure that every bank, fintech, and POS terminal depends on at the same time.

It’s called NIBSS.

And most engineers building Nigerian fintech don’t fully understand what it actually does
NIBSS = Nigeria Inter-Bank Settlement System.

Founded in 1993 by the CBN and commercial banks.

Simple way to think about it:

If Tunde (GTBank) sends money to Emeka (Access Bank), those banks don’t talk directly.

They both talk to NIBSS.

NIBSS is the translator, validator, and settlement engine behind every inter-bank transfer.

Without it, banks are isolated systems.
Two rails you use daily without knowing:

NIP (Instant Payment)
→ Real-time transfers (seconds)
→ Introduced in 2011

NEFT (Electronic Funds Transfer)
→ Batch processing (slower)
→ Used for payroll & bulk payments

Instant transfer? That’s NIP.
Salary credit? Likely NEFT.

Two rails. One backbone.
Read 12 tweets
Apr 8
The “We’re Building for Nigerians” Lie
Let’s read.

A Nigerian startup raises $2M. The press release says “built for Nigerians, by Nigerians.”

The app requires 4G to load the dashboard. It crashes on a Tecno Spark. It times out during payment.

Meanwhile, the founders are demoing it on a MacBook Pro in a co-working space with fibre internet.

Let’s talk about this.
There are two versions of “building for Nigeria.”

The first is the pitch deck version. Inclusive language, local characters in UI illustrations, naira signs everywhere, and a founder speaking Yoruba in a TechCabal interview.

The second is what actually gets shipped.

They are rarely the same product.
The average Nigerian user is not Emeka in Yaba with a 5G SIM and a Samsung S24.

The average Nigerian user is Tunde in Ikorodu. Tunde has a Tecno Camon with 2GB RAM. He is on 1.5GB of data that he bought for ₦1,500. His battery is at 34 percent.

Then your app asks him to enable location services for a better experience.
Read 18 tweets
Apr 3
So, out of boredom, I decided to break down something I built recently

not a tutorial, not a flex
Just me explaining how I approached authentication in a real system.

NB: this is not a fictional thread
This is a real system I built, just written as a thread

Read till the end
bookmark it, you’ll need it sooner or later
And if it helps, do me a favour and repost before you dive in.
The architectural diagram is at the end of the thread
Make sure you save that too
What I built had real consequences if anything went wrong.

So I couldn’t afford to treat auth as just email and password

I had to think in systems
layers, fallbacks, failure handling, and attack resistance
The first thing I changed was the registration flow

Most people do email, then password, and call it a day

I went phone first
OTP verification before anything else
then email and password after

Because realistically, phone numbers are more reliable for identity in my environment, everyone has a phone number; most people ( old ones ) might have difficulties with emails
Read 16 tweets
Apr 1
There’s something we don’t really talk about enough.

Nigeria is connected to some of the most powerful undersea cables ever built:
MainOne, WACS, ACE, Glo-1.
Billions of dollars of infrastructure sitting right off our coastline.

Yet most of my mutuals and I are still buying 1GB for ₦1,000, and it’s finishing in 2 hours.

Something is just so deeply wrong, and most people don’t even know where to point the finger.
It’s very easy to assume the problem is the cables, like maybe there isn’t enough international bandwidth coming in.

That’s never been the problem.

The problem starts the moment the signal leaves the water and tries to travel inland. That’s where everything collapses.
A lot of what’s carrying your data across Nigeria isn’t even fiber buried underground.

It’s microwave. Tower to tower. Like a radio signal bouncing across the country.

Cheaper to deploy? Yes. But slower, congested, and breaks down in bad weather.

That’s why your internet gets worse every time it rains. Not network maintenance, so stop blaming these guys.
Read 12 tweets
Mar 31
Bookmark this tweet right now.

Not after reading. Now.

At some point, you will build a payment system, work on one, or inherit one that is already broken.

When something goes wrong, and it will, you will need exactly what I am about to show you.

This is the most complete payment system breakdown I have ever written.

Every flow. Every edge case. Every trap. One thread
In 2023, I built a payment system for a marketplace.

First month: ₦127 million processed.

I was celebrating.

Then my finance person called.

“Stephen, the numbers don’t add up. There’s a ₦4.3 million discrepancy.”

No duplicate charges. No missing webhooks. No obvious bug.

Just ₦4.3 million sitting somewhere between the user’s bank and my merchant wallet.

Unaccounted for.

I aged five years that week.

Let me save you from that. 👇
Before anything else, understand this:

A payment is not one event.

It is a journey through multiple systems. Every single one can fail.

Every box in this flow is a place where money can disappear.

We are going through all of them. Image
Read 20 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(