← All case studies

Rebuilding a MiFID II Investment Firm's Platform in Four Months

CTO at Assetera · 2026 - Present

How I took over Assetera's inherited platform as CTO and replaced it with a service-based, regulator-ready stack on Azure, without stopping a licensed business. Audit, cadence, 44 ADRs, about 15 services, and a legacy estate switched off step by step.

Regulated Fintech
MiFID II
DORA
Execution
Architecture
Tokenized Securities

Problem

Assetera is a European investment firm licensed under MiFID II. It gives retail and professional clients access to tokenized securities. Before my time the company had operated under a different licence model, and its platform still carried the systems of that earlier business.

When I joined in June 2026, the platform needed a new foundation. The core was an inherited .NET monolith, with earlier rewrite attempts next to it. The Azure estate had been clicked together in the portal across several subscriptions, and nobody could rebuild it from a description. There was no CI/CD, few tests, and many repositories left behind by contractor churn. The roadmap was ambitious, and the platform had to be rebuilt to carry it.

For a regulated firm this is more than an engineering problem. The supervisor expects you to show how the system works, who changed what, and how you recover when something fails. DORA makes that explicit.

Constraints

The business could not pause. Clients held real positions. Every change had to keep the live service running, and every migration had to be voluntary and guided.

The regulator sets the critical path, not engineering. A licence cannot be sprinted. The technology had to fit the licence Assetera holds, and not run ahead of it.

A small team. No large platform group, no separate DevOps or QA function. The architecture had to be operable by a few people.

Evidence by default. Record keeping, audit trails, change management, and third-party risk had to come out of how the system works, not out of a spreadsheet maintained after the fact.

Architecture

Identity first. Keycloak became the single identity provider, with a B2B2C tenancy model so partner brands can run on the same platform. The migration of existing clients is built and validated end to end: passwords and two-factor setups carry over, so nobody has to sign up again.

Services with clear ownership. About 15 TypeScript services, each with its own database and its own deploy: the marketplace API, compliance and enhanced due diligence, an admin API with a central audit log, an attestation signer, EVM and Stellar/Solana indexers, enrichment and trade projection, notifications, messaging, and a realtime stream for the frontends. Services talk through Azure Service Bus events where the coupling is loose, and through narrow HTTP APIs where it is not.

Frontends behind a BFF. Six Next.js frontends (marketplace, admin, issuer, tokenizer, wallet, learning) sit behind backend-for-frontend layers with server-side sessions. Tokens never live in the browser.

On-chain settlement that a supervisor can follow. A fresh, much simpler contract set replaced the inherited one. Primary sales of tokenized stocks run through request-for-quote with atomic on-chain settlement on four chains, with xStocks and Ondo as venues. A separate attestation signer authorises each trade after the compliance checks pass, and the contracts refuse anything without a valid attestation. A bank-transfer rail with payer verification runs next to it.

Everything as code. The whole Azure estate is OpenTofu: four environments, keyless deploys, image promotion from testnet to production. The details are in a separate case study.

Decisions written down. 44 Architecture Decision Records, from identity and tenancy to MiFID II record keeping and how to bound a compromised settlement signer. One decision per record, reviewed like code.

My role

I ran the audit and presented it to the executive team and to the engineers. I then ran my execution playbook: a Scrum cadence first, then the five engineering-foundation steps, with the rebuild in parallel from the first month.

I wrote the ADRs, designed the target architecture, and wrote a large part of the code myself: 950+ merged pull requests across 29 repositories in four months. I could only do this because I ran delivery with AI agents and reviewed every diff. That method is described in AI-native engineering.

I also owned the parts around the code: vendor selection and exit plans, cloud cost and billing structure, the legacy shutdown plan, and the work with compliance on what each control must prove.

Outcome

Tradeoffs

A fresh start instead of a migration in place. Deploying a new, simpler contract set meant clients had to move on their own initiative. The alternative was to keep and audit a complex inherited contract system that nobody fully understood. A guided migration was the cheaper and safer cost.

Container Apps instead of Kubernetes. Azure Container Apps gives less control than AKS. For a small team it removes a whole class of operational work. If the platform outgrows it, the services are plain containers and can move.

Speed moves the bottleneck to review. With agents writing most of the code, the limit is how fast a person can review with care. I chose to keep that limit. A fast team that merges code nobody has read is not a regulated team.

Shared database servers per environment. Each service has its own database, but services in one environment share a database server. That keeps cost proportional to traffic now. Splitting a hot service onto its own server later is a configuration change, not a redesign.