Business analysis for regulated, technically complex environments.

What I Do

I work in the gap between what a regulation requires, what a process document says, and what a system actually does.

Most organisations have this gap. The regulatory obligation is clear enough on paper. The internal policy references it. But somewhere between the policy and what people actually do every day, something breaks down. Controls exist on paper but not in practice. Process documentation describes what was designed, not what happens. Systems behave in ways that no one has mapped against the obligations they are supposed to enforce.

I find those gaps. Then I make them traceable, testable, and fixable.

This is what that looks like in practice:

Regulatory requirements, decomposed. I read technical standards and legislation - MiFID II, RTS 6, REMIT II, MAR - and break them down into operational obligations that teams can actually implement. Not regulatory summaries. Functional requirements, testable controls, and traceability maps that connect what you do to what the regulation demands.

Systems, understood as they are. I analyse how complex systems actually work, not how they are documented. Insurance platforms, trading systems, BSS/OSS stacks, ERP environments. This means I can sit in a room with your IT architect and have a substantive conversation, not a translating one.

Processes, tested against reality. I find where documented processes diverge from operational reality. Where the control has a gap. Where the handoff fails. Where the workaround became the real process years ago and nobody updated the documentation.

New domains, learned fast. I enter unfamiliar environments and build a genuine working model of them quickly - through SME engagement, regulatory source material, and pattern recognition from 15 years across multiple industries. I do not just document what I am told. I build enough understanding to challenge assumptions and contribute to decisions.