The Hidden Cost of Decisions Made on Assumptions
Over more than 30 years in financial markets, I worked across trading, eFX, product development, client strategy, and senior leadership within banks, brokers, and technology vendors. That mix gave me a clear view of how trading systems behave, how products are built, and how commercial value is created. It also led to frequent requests from investors needing deeper insight during platform assessments. Over time, a consistent pattern emerged: major decisions were often taken without the quantitative depth needed to understand real performance, scalability or commercial drivers. Seeing the same gaps across very different organisations is what led me to start Isomiq.
Across financial markets, these issues appeared consistently regardless of the organisation or technology stack.
Across banks, brokers, investors, and technology firms, major decisions were often based on surface-level information:
- platforms selected for features rather than fit
- valuations built on headline KPIs rather than real revenue mechanics
- product builds guided by opinions instead of system behaviour
- client requirements understood differently by each team involved
This was not a failure of intelligence.
It was a failure of visibility.
Complex systems hide their truth well. Narrative hides it even better.
I started Isomiq to help organisations understand how their systems, products, and processes really work, and to ensure decisions are built on clarity, not assumption.
The Four Gaps I Saw Repeated Everywhere
Across three decades, the same four problems kept surfacing.
Different organisations. Different technology stacks. Same outcomes.
Businesses Valued Without Understanding the Real Quantitative Levers
In financial markets, headline KPIs often hide the operational constraints, data dependencies and scalability limits that shape real commercial outcomes.
Too many capital raises, acquisitions, and investments relied on:
- selective KPIs
- marketing narratives
- simplified financial assumptions
- surface-level assessments of technology and process
Headline KPIs were often accepted at face value, while the underlying data, dependencies, and operational bottlenecks were rarely examined.
Example:
I once analysed a platform claiming a 40 percent gross margin based on aggressive volume forecasts. When I unpacked the mechanics, half the flow was being handled manually. That manual dependency meant the business could not scale as projected, and the headline metric bore little resemblance to reality.
2. Wrong Technology Choices by Banks
Regional banks understood their goals but often struggled with the practical reality of execution. What they needed was clarity on:
- a clear understanding of which platform genuinely fit their needs
- what the technology could (and could not) do
- how to translate an idea into a practical, realistic plan
- which features mattered first — and why
Vendors sell capability.
Banks need truth.
Example:
I was asked to validate a bank’s platform choice. They had selected one vendor because a specific feature appeared to be the differentiator for their commercial banking clients, where volumes are smaller but ticket counts are much higher. Once I unpacked the mechanics and reviewed the architecture, it became clear that the chosen provider could not support that transaction profile and that the cheaper vendor was actually the better fit. The risk only became visible once the underlying mechanics were examined.
This challenge is common across financial markets, where technology choices are often influenced by assumed capabilities rather than actual architectural constraints.
3. Tech companies were building the wrong things — or in the wrong order
Technology companies often struggled not with effort but with sequence.
I saw teams:
- building client-facing features before validating foundations
- adding functionality the architecture could not support
- planning roadmaps around assumptions rather than behaviour
- misunderstanding how clients actually used the system
They didn’t need more engineers.
They needed clarity on what to build and why.
This sequencing issue appears across financial markets, especially where product teams are under pressure to deliver quickly without full visibility of system behaviour.
Example:
A pricing engine was redesigned for speed, but the real bottleneck was the data pipeline feeding it. The work solved the wrong problem because the mechanics were not examined early enough.
4. Delivery That Did Not Match Client Expectations
One of the most common and costly issues was the interpretation gap between clients and vendors.
- clients described the outcome
- vendors implemented the functionality
- both assumed they meant the same thing
They rarely did.
Delivery is delayed because
- requirements were not mapped to actual system behaviour
- timelines were not grounded in real dependencies
- underlying limitations were not known early
- no neutral party aligned intent with capability
Example:
The client requested a spread control and the vendor built a version of it, but it did not meet the requirement. I was brought in to prevent another delayed release. The root cause was the data layer, not the UI: the logic sat inside fixed database structures that could not deliver the intended behaviour. The problem surfaced immediately once the mechanics were examined.
Major technology decisions in financial markets often align with broader industry expectations, such as those outlined by the Bank for International Settlements.
What Isomiq Was Built to Deliver
Isomiq brings evidence-grade clarity to the decisions that shape trading, technology, and valuation. The firm is built around four core disciplines, matching the four areas where the industry repeatedly failed.
1. Mechanics & Valuation Drivers
For companies raising capital or investors deploying it, we uncover:
- the real business drivers
- scalability limits
- margin mechanics
- architectural strengths and weaknesses
- the difference between perceived and actual value
The result is a valuation grounded in mechanics, not narrative.
2. Technology Selection for Regional Banks
We translate a bank’s goals into a clear, achievable, and correctly sequenced technology plan matched to platforms that can actually deliver.
Independent, practical, and market-grounded
3. Product and Architecture Validation for Technology Firms
We help vendors and platforms make the right product decisions in the right order:
- what to build
- the sequence to build it in
- what the architecture must support
- how clients will actually use it
The result is a roadmap aligned with commercial reality and system behaviour.
4. Delivery Alignment Between Clients and Vendors
We close the gap between requirement and reality by clarifying:
- intent
- capability
- limitations
- timelines
- dependencies
- expected outcomes
It’s product assurance and expectation alignment — without politics.
The Mission Behind Isomiq
In financial markets, the wrong assumption costs more than the wrong decision.
Assumptions break:
- valuation models
- technology selection
- liquidity strategies
- product builds
- delivery timelines
- client relationships
Clarity at Isomiq is not opinion. It is a measurable, evidence-based view grounded in data, mechanics, and commercial truth.
For organisations operating in financial markets, the cost of unclear system behaviour or incorrect assumptions compounds quickly across products, clients and infrastructure.
Precision prevents expensive mistakes.
Isomiq was never meant to be a large consultancy. It was built to be a useful one, a partner that understands markets, mechanics, technology, architecture, valuation, client behaviour, and commercial reality all at once.
Clarity is not a deliverable.
It is a competitive advantage.
That is what Isomiq exists to create.
You can read more about how Isomiq supports technology, valuation and product decisions on our Services page.
