The most dangerous move on a regulated fintech system? Assuming you understand it before you actually do.
Rule number 1 in development: never assume anything.
Here's what it looked like when we extended a live institutional trading platform - AFSL-licensed, handling perpetuals, spot, options, and FX - without a single regression, in production, with people watching very closely.
We joined a live system that was already in production
This wasn't a startup with a blank slate. The platform was already live - real users, real trades, real regulatory obligations. The core system ran on C#/.NET and PostgreSQL, with a separate compliance portal handling KYC/AML and onboarding.
Our client needed three things: a multi-channel notification system, extended API capabilities, and an independent security assessment before scaling further.
What they didn't need was for us to arrive with opinions about how we'd have built it differently. Our mandate was to extend the system, not reimagine it.
We started by reading the system, not writing code
Every new module we shipped had to be architecturally indistinguishable from what already existed. Not just functional - indistinguishable. We matched naming conventions, followed established patterns, and held to a strict propose → approve → implement workflow before anything hit production.
So before anyone opened a ticket, we read the system. We used AI tooling - including Claude - to map architectural patterns, identify conventions, and build a mental model of how the system was designed to evolve. We documented every assumption. We validated every proposal before implementation. We shipped every PR with design rationale, not just a diff.
💡 This is not how most teams behave under delivery pressure. It is, however, the only approach that works when you're extending a production system you didn't build.
03 things that kept production stable
Test-first as structure. We enforced 100% unit test coverage, which forced us to understand every execution path before we considered a feature done. We used AI tooling to generate cases and surface uncovered paths. The byproduct wasn't just coverage - it was a genuine understanding of the system's edge cases.
Documentation in every PR. Not what we changed - why. The design decision, the alternatives, the tradeoffs. In a system where teams grow and engineers rotate, this is what stops the next person from repeating our mistakes.
AI for comprehension, not generation. We used it to read the codebase at scale - pattern recognition, consistency checking, spotting where a change might interact with existing behavior in non-obvious ways. We got better proposals and fewer surprises as a result.
💡 Our goal wasn't to move fast - it was to move correctly. Turns out that's also faster, just not immediately.
The compliance portal had 31 security findings
The compliance portal wasn't broken. It handled KYC/AML, onboarding, and document management without issue. From the outside, there was nothing to flag.
But we knew that functioning and secure are not the same thing. Scaling an institutional business on an unassessed compliance portal isn't just a technical risk - it's a strategic one. So we ran an independent assessment before our client expanded their institutional customer base further.
We found 31 findings across multiple severity levels. Several were critical: personal data protection, access control, and financial data handling - the exact areas where failure doesn't generate a support ticket. It triggers a regulatory event.
We delivered a structured remediation roadmap so our client could address these before scaling. That was the point - not to flag problems, but to give them a clear path forward.
💡 "Working fine" is not a security posture. It's just what failure looks like before it happens.
What made the engagement work
Three things explain most of what went right.
Understand before you improve. The hours we spent building a real mental model - of how the system actually worked, not how we'd design it today - were the hours that prevented expensive mistakes later. We protected that learning phase even when timelines were tight.
Different stacks, different risk profiles. A core trading platform and a compliance portal are not the same kind of system. We didn't apply a single risk standard universally. A medium-severity finding in one context can be critical in another depending on what data it touches.
Critical feedback is data. Fintech reviews are demanding by design. We responded with evidence and consistent judgment - and stopped being a vendor. We became the partner they trusted with the sensitive stuff.
In regulated fintech, trust is the product. The discipline is just how you earn it.
Inherited a live regulated system?
👉 What was the moment you realized "move fast" wasn't going to work here?
Drop it in the comments.
