When I was 26 and relatively early in my career, I had a clear mental model of how compliance teams worked. They were the people who showed up at the end of a project and said no to things. They slowed everything down. They asked questions that felt disconnected from engineering reality and required documentation nobody wanted to write.
I'm 32 now. That mental model was wrong, and it cost me - and one of my teams - more than I want to admit.
What compliance actually is
Compliance, in financial services, is the function responsible for making sure the firm operates within the law and within the regulations that govern its industry. In asset management, those regulations cover things like how client data can be stored and moved, how investment decisions need to be documented, how conflicts of interest are managed, and a long list of other requirements.
The specifics vary by jurisdiction, firm type, and which regulators are watching. But the overall point is that financial firms operate under significantly more regulatory oversight than most other industries, and the compliance team is responsible for navigating that.
A compliance finding - a regulator determining that the firm broke a rule - can result in fines, reputational damage, and in serious cases, personal liability for senior people at the firm. The compliance team is not being bureaucratic for fun. They are managing real risk.
I understood this intellectually at 26. I didn't really feel it until something went wrong.
The incident
My team was building a data pipeline that moved trade reconciliation data between two internal systems. The engineering was solid - good test coverage, clear data schemas, thoughtful error handling. We were proud of it.
Compliance raised a flag early in the project about data residency. In simple terms: the data we were moving was subject to regulations that specified where it could be stored and processed. One of our planned hops took the data through a processing layer that sat in a different jurisdiction than the regulations required.
We acknowledged the flag, said we'd address it before go-live, and kept building. We had other priorities. The compliance concern felt theoretical and the technical work felt urgent.
We didn't address it before go-live.
The pipeline went live. Six weeks later, we had a regulatory finding. The pipeline was taken offline. We rebuilt it with the data residency controls compliance had asked for from the beginning. The total delay to having a working, compliant pipeline was roughly six months longer than it would have been if we'd just had the conversation properly at the start.
What changed after that
The next project I led, I scheduled a compliance conversation in week one. Before any architecture decisions were made, before anyone had written a line of code.
What I found - genuinely surprised me at the time - was that the compliance team knew things that were useful. They knew which aspects of our planned design were going to be problematic and why. They knew what the regulators were currently paying attention to, which is not the same as what the regulations say. They had seen other projects fail in ways that were instructive.
The conversation was two hours. It changed several of our architectural decisions in ways that made the final system simpler, not more complex. And it meant that when we went to compliance for final sign-off at go-live, there were no surprises.
The practical advice
Involve compliance at the design stage. Not after you've built something. Not in the final review. At the whiteboard, when you're still drawing boxes.
Ask them specifically: what are the things about this design that are going to cause you problems? Not "is this compliant" - you're not asking for a verdict, you're asking for problems to solve. That framing tends to get better answers.
Write down what they tell you. Not for the compliance file (though that helps) - for your own reference. Compliance officers remember conversations. If you come back three months later with a design that ignores what they said, that conversation will be referenced.
I still find some compliance processes genuinely inefficient. Change management windows that haven't been reconsidered in a decade. Approval chains that require sign-off from people who can't meaningfully evaluate the decision. I'm not arguing those problems don't exist.
But the instinct to work around compliance rather than with them is how you end up rebuilding a data pipeline six months after you thought it was done. I learned that the expensive way.
