I help fintech companies bridge the gap between complex requirements and working systems — writing specs that developers can actually ship, integrating APIs that don't break, and turning data into decisions.
I work across the full lifecycle — from understanding what a business needs to making sure the technical implementation actually delivers it.
End-to-end ownership of API ecosystems — versioning strategy, partner onboarding, breaking change analysis, and phased rollouts across multiple environments.
Implementation-ready specs with user stories, acceptance criteria, exact API field mappings, UI behaviour rules, edge cases, and compliance requirements — in one document developers trust.
Systematic comparison of what exists vs. what's needed — across system versions, regulatory requirements, or competing vendors. Prioritised and evidence-backed.
Managing integrations with multiple external parties simultaneously — setting expectations, tracking commitments, identifying delivery risks before they become blockers.
Custom pipelines from raw API responses, logs, and financial data to structured reports and dashboards — including automated reconciliation and anomaly detection.
Hands-on configuration of Kafka topics, Keycloak OAuth2 flows, and API gateway setups — bridging the gap between infrastructure teams and business requirements.
A repeatable approach that keeps projects moving and stakeholders aligned — without the usual chaos.
Not the stated requirement — the underlying need. I map stakeholders, identify constraints, and document what success looks like before a single line of spec is written.
Regulatory requirements (MiFID II, AIFMD, local law) and technical risks are surfaced upfront — not discovered after delivery. I build them into the spec, not onto it.
Every specification includes exact API field names, display logic, edge cases, dependency flags, and prioritisation. No ambiguity left for interpretation at implementation time.
I track actual progress against weighted scope — not hours spent or tickets created. If 39% is delivered, I say 39%, and I explain what the remaining 61% means for the project.
Every significant decision — why it was made, who made it, what the alternatives were — is recorded. In multi-vendor projects, undocumented decisions become future disputes.
Not just business analysis — I build the tools I need when they don't exist, and I speak to engineers in their language.
Most analysts can't write a Keycloak token exchange flow. Most engineers can't cite MiFID II as a business argument. I do both.
Regulatory requirements are built into specs from day one — not retrofitted after delivery. I know the laws and use them as arguments, not ornaments.
I include exact field names, display logic, edge cases, and dependency flags. When I hand over a spec, developers don't need to guess or come back with questions.
Response time isn't "slow" — it's "4.66s on asset-graph." Delivery progress isn't "mostly done" — it's "39% of weighted scope." I measure before I conclude.
I identify structural problems — fragmented communication, scope creep, vendor inertia — and address the pattern, not just the latest symptom.
I explain Keycloak token exchange to product owners and business risk to architects. No translation layer needed — I speak both languages fluently.
If a tool is needed to manage API versions, track partner integrations, or generate financial reports — I build it. Practical Python, not slides about Python.
Not a generalist who landed in finance. Built from the ground up in investment platforms, regulatory compliance, and multi-party API ecosystems.
A few examples of the kind of work I do — and what it actually delivers.
A vendor delivered a demo of a major platform release. The team was under pressure to accept it into testing and move forward. No one had formally assessed what was actually delivered vs. what was promised.
I created a weighted scope matrix — assigning business impact weights to each feature area. I evaluated each item delivered during the demo against the original scope and calculated actual delivery coverage per area.
The assessment showed 39% delivered for CZ, under 20% overall. I formally recommended not accepting the release into testing — preventing the team from spending weeks finding issues that were the vendor's responsibility to fix first.
A vendor submitted 12 change requests — implying significant additional cost and timeline impact. The items were presented as requirements that hadn't been specified, creating pressure to accept them as out-of-scope additions.
I systematically reviewed each CR against existing specification documents, previous communications, and acceptance criteria. For each item I documented the original source — exact file, section, and wording — that already covered the requirement.
9 of 12 CRs were demonstrably already specified. The rebuttal analysis gave the business a documented, evidence-based position to push back — protecting scope, timeline, and budget without a single item being genuinely new work.
Clients on an investment portal were seeing heavily distorted performance figures — in one case −93% instead of the actual +4%. The issue was escalated but the root cause hadn't been identified. It was causing client complaints and eroding trust in the platform.
I traced the calculation through the API response data, mapped the performance formula against actual account data, and identified that uninvested cash held in a virtual account was entering the calculation denominator without appearing in the numerator.
Root cause identified and documented with concrete data. I proposed three solution variants — an immediate hotfix, a calculation standardisation, and a disclosure approach — giving the product owner a clear decision to make rather than an open investigation.
Whether you're building a product, scaling integrations, improving delivery processes, or looking for an experienced business analyst who understands both business and technology, I'd be happy to hear about it.
Long-term collaborations, consulting engagements and strategic projects where I can help bridge the gap between business goals and technical execution.
I've spent years at the intersection of financial services, API design, and regulatory compliance — in environments where getting it wrong has real consequences. That's shaped how I work: precise, documented, and always with the end user in mind.
I write specifications that developers trust, build tooling when it doesn't exist, and manage vendor relationships without losing sight of what the business actually needs. I'm equally comfortable in a technical architecture discussion and a business requirements workshop.
Outside of work I follow the intersection of regulation and technology closely — because that's where the most interesting problems in fintech live.
Whether you need a spec written, an integration managed, or someone to make sense of a complex system — I'd like to hear about it.