Post Trade Management Platform
Replaced a low-code SaaS post-trade platform with an in-house build, while strangling the internal API that grew up beside it into services.
- Duration:
- 2026
- Role:
- Lead Engineer
- At:
- Macquarie
Problem
The problem
Post-trade operations ran on a low-code SaaS platform. It was built by dragging components onto large forms, which made the first version fast to produce and every version after that slow. Interactions on the heaviest forms took over thirty seconds. Trading Ops felt every one of those seconds, several hundred times a day.
The cost was not only latency. Data governance meant the platform’s own database could not be the system of record, so an internal API had been built and was being maintained alongside it, a second system carrying the weight of the first. The interface did not follow the internal design system. And because the platform needed specialist vendor engineers, every change had to be scheduled and funded externally.
Challenge
What made it hard
Rebuilding in-house is the obvious answer, and the obvious answer had a trap in it: nobody could say precisely what the existing system did. In a low-code platform, behaviour lives in configuration, not specification. Validation rules, conditional logic and years of accreted edge cases were held by a vendor rather than a team. You cannot write a spec for software whose only description is itself.
Architecture
How it is put together
Angular against the internal design system, Python services on Kubernetes, PostgreSQL as the single system of record, with Entra SSO for identity. The platform feeds a downstream system of record, runs scheduled batch work, serves static assets from S3 and mails Trading Ops over SMTP.
The internal API that had been built to sit alongside the SaaS survived, and was decomposed rather than discarded: off EC2 into containers, split into microservices by domain and feature. Two migrations ran concurrently on the same system, and neither got to assume the other had finished.
Tradeoffs
What we chose, and what it cost
We chose
To rebuild as a faithful replica first, then optimise. Parity before improvement meant we could prove the new system did what the old one did, and cut over without asking Trading Ops to accept new behaviour and new software on the same day.
We gave up
Speed. Replicating first meant temporarily inheriting the SaaS’s data model and interaction assumptions, including the ones we had rebuilt the thing to escape. It also meant touching several surfaces twice: once to match, once to improve. We bought a safe cutover with duplicated effort, knowingly.
Outcome
What changed
30s+ → under 5s
on the interactions that hurt most
One estate
integrated with internal systems and the internal design system
Design intent, not a measured result.
Lower maintenance
change no longer requires contracting external low-code specialists
Design intent, not a measured result.
Lessons learned
What this changed
The thirty seconds were never a technology problem.
The old system fetched everything so the user could search it. Filling a single dropdown meant ten or more API calls to the source system, several of them sequential because the next depended on the previous cursor. No amount of tuning fixes that, because the shape is wrong: it retrieves the whole world and then asks the person which part they wanted.
We had no UX designer, so we wore the hat. That meant sitting with the business and asking how they actually use the screen, and the answer changed the architecture. The dropdown became a progressive search: type two or three characters, query the database, return what matches. The performance win came out of a conversation about usability, not out of an optimisation pass.
Usability and performance looked like two problems and were one, and the only way to see that was to ask the people using it. It was also where I picked up Python and FastAPI properly.
Read alongside