The first thing I tell any fintech client considering an embedded finance partner: the hardest part won’t be the technology. It’ll be the pace.
I’ve been leading an embedded finance engagement for a payment platform operating across four live markets — real transactions, regulated environments, and MAS-licensed infrastructure. Not a greenfield build. Not a prototype. A production environment where a wrong assumption doesn’t fail quietly in staging. It shows up as a transaction error on a real account.
That context shapes everything — what it means to actually work in fintech, and what separates an embedded finance partner that compounds trust from one that creates friction at exactly the wrong moment.
What an embedded finance partner actually does on Day 1
Sun* engineers don’t arrive with polished kickoff decks or a rigid plan. We arrive ready to read — the codebase, the system’s behavior in production, and how the team actually operates under pressure.
Before touching a single line of code, the priority is to build a mental model of the system that’s reliable enough to make safe decisions.
Being embedded means operating from within the client’s engineering organization – using the same tools, joining the same standups, and following the same standards. Not beside the team, but as part of it. Early contributions are intentionally small, tested, and reversible. Larger changes come later, earned by demonstrating a deep enough understanding of the system to evolve it without breaking it.
In engagements like this, Sun* teams start small by design.
A focused group of engineers steps into legacy systems — years of accumulated business logic, little to no documentation — alongside client teams running at an intensity most embedded partners simply can’t match.
How we operate inside a live payment system
Once we had enough of a mental model to act on safely, our approach came down to four things. Not as a methodology we arrived with, but as disciplines the environment forced on us.
We validated before promoting anything. Every change went through a staging environment built to mirror production load — same traffic patterns, same concurrency, same regulatory constraints.
In fintech, “it works on my machine” isn’t a standard – the way I see it, it’s more of a liability.
We documented as we went — never after. The value isn’t a clean architecture diagram written six months later. It’s in capturing the questions, the wrong turns, the validated assumptions — because that’s what the next engineer actually needs when they inherit a system that’s been running in production for years.
We flagged uncertainty explicitly and early. In a regulated environment, “I think this is how it works” is a risk statement, not an answer. When we didn’t know something, we said so, validated it fast, and never acted on an assumption we hadn’t confirmed.
Same tools, same standups, same standards. Not beside the client’s engineering organisation. Inside it. That distinction is everything in a live financial system.
The DNA factor: what no requirements document can specify
The client’s in-house team ran at a pace and intensity that most embedded partners couldn’t match. They didn’t write that down anywhere. They didn’t need to.
You either kept up, or you created drag — and in a live payment platform operating across four regulated markets, drag shows up at exactly the wrong moment.
A team with the right DNA reads the system before they ask questions. They surface improvements without being prompted. They treat the client’s codebase as their own — because for the duration of the engagement, it is. That’s not a cultural value statement.
That’s what production-grade embedded finance work actually requires.
This is why Sun* is deliberate about which engineers it selects for embedded finance roles.
Not every engineer is built for this environment. A DNA mismatch doesn’t just slow things down. In a live payment system, it creates operational and compliance risk.
What stays with your team when the engagement ends
After the initial phase — the information blackout, the slow reverse-engineering of an undocumented payment codebase, the careful first changes on a live system — we reached full operational ownership of the core infrastructure.
The team grew 250% over eight months — from 4 engineers to 10. That wasn’t a sales outcome. It was the client’s answer to the question of whether they trusted us to take on more.
When 6 engineers joined in early 2026, they onboarded faster than we did.
Why? Because every investigated bug, every traced transaction flow, every validated assumption had been documented and structured. The next engineer didn’t start from zero. They started from where we left off.
That’s what institutional knowledge looks like inside a real embedded finance engagement. It doesn’t walk out the door when an engineer rotates off. It gets captured, documented, and handed over — so the client’s team owns it completely, without depending on us to maintain it.
Every fintech leader evaluating an embedded finance partner is really asking two questions:
- Can this team operate the way we need them to?
- And what happens to what they learn when they leave?
Both questions have the same answer. It depends entirely on whether the DNA matches. When it does, trust doesn’t just hold. It compounds.
If you’re interested in how this approach translates into system-level outcomes, you can explore this core banking modernization case study, where we worked with a legacy platform to improve performance, scalability, and transaction efficiency in production.
🚀 Running a live fintech system requires an embedded finance partner built to operate from within — not beside. Sun* is built for that.
