Tax law as a system requirement

The problem

Four years of Java and Spring, moving a monolithic reporting path onto Kubernetes microservices and designing the REST APIs that client banks integrated against — high-volume transaction processing for Tier-1 private banking clients. This is the most conventional engineering on this site, and the domain is what made it hard.

Avaloq's platform runs the back office of private banks. Tax is not a feature you bolt onto that; it is a body of law that changes on someone else's schedule, differs per jurisdiction, and has to be right — where "right" is defined by a regulator rather than by a test you wrote. I worked on the French tax law compliance module, and on EU tax localisation and reporting inside the Technical Framework.

The constraints

The specification is legislation. Requirements did not arrive as tickets. They arrived as law, and turning them into a system meant sitting between product, business analysts and the customers who would be audited against the result.

Correctness is not negotiable, and neither is change. The rules move. The architecture has to absorb that without a rewrite each time a finance act lands.

Existing systems carry their history. A banking core is not greenfield. Every design choice is a negotiation with what is already deployed and already correct.

What I did

Owned the analysis as well as the code. Working directly with product teams, customers and business analysts to get from statute to a design that survives an audit — then building it.

Led the team. I progressed into leading a cross-functional engineering team on the module: owning code review, designing and implementing new API services for EU tax localisation that cut integration time for client banking systems, and driving the transition to a Spring and Kubernetes microservice architecture so critical reporting components could be scaled and released independently of the core.

Taught it. Ran workshops and internal presentations as the subject matter expert, because in regulated domains the knowledge is the bottleneck more often than the code is.

What it meant

This is where I learned that the hardest requirements are the ones written by people who have never seen your system, and that the engineer's job is translation as much as construction. It is also where I first led other people through a migration rather than just doing one — the part I have kept doing since, at Omecu and at Zelim.

Four years of it in an area with very little velocity is also what sent me away from the field for a while. I went and studied philosophy at St Andrews, was pulled toward logic, took the advanced mathematical logic course, and came back to computability by way of Gödel. That is when I worked out that computers really were the thing, and that with the right problems I would give myself wholly to them. Everything since has been that decision being acted on.

Stack

Java, Spring, Kubernetes, microservices, API design, regulatory reporting.