Markets are messy. Buyers describe their problems in one language, vendors describe their products in another, regulators describe obligations in a third, and practitioners try to hold all of it in their heads at once. Finding trusted market intelligence is hard enough; agreeing on what we’re even looking at is harder still.
That’s what a market taxonomy is for: one structure that connects what buyers need to what vendors offer, with regulations and market forces shaping the picture at every level.
We built this taxonomy to be the shared map from which we can all navigate. It’s not an academic exercise; it’s the scaffolding underneath every recommendation, comparison, and insight you’ll pull from Liminal.
Why a taxonomy at all
Borrow a page from how the best data platforms think about ontology: the value isn’t in the elegance of the model, it’s in what the model lets you do. A good taxonomy turns a chaotic market into something you can navigate, compare, and act on. It gives every team a common vocabulary, so when someone says “use case” or “solution segment,” we all mean the same thing. It lets us connect a buyer’s problem to the vendors who solve it without re-deriving the relationship every single time.
In other words, a taxonomy is a decision on where to draw the lines so that everyone can find their footing. That decision is worth far more than any individual data point, because it makes every data point actionable.
The big picture: two mirrored sides
The taxonomy has two mirrored halves that meet in the middle.
The demand side describes the problems buyers are trying to solve. The supply side describes what vendors offer. They meet at the use case, where a buyer’s problem connects to the solutions that serve it.
Read down the demand side, and you trace a buyer’s world. Read down the supply side, and you trace a vendor’s world. The magic is that the two are built to line up, level for level, so you can always cross from one to the other.
Here’s the structure, level by level.
01 · Universe ↔ the total market under analysis
The universe is the top layer and the thing that ties both sides together. It’s the broadest frame: the entire market we’re analyzing.
02 · Domain ↔ Solution Segment
On the demand side, a universe breaks into domains, distinct problem spaces framed by buyer need. On the supply side, the mirror is the solution segment, the category of offerings vendors compete in. A domain is how a buyer carves up their problems; a solution segment is how a market carves up its products. Same territory, two vantage points.
03 · Use Case ↔ Solutions
This is the meeting point. A use case is a specific buyer problem to solve. Its mirror is solutions, vendor offerings, mapped to the use cases they serve. When you connect a use case to the solutions that address it, you’ve crossed the bridge between demand and supply. Everything above this level organizes the market; everything at and below it makes it actionable.
04 · Requirements ↔ Product Capability
Under each use case sit requirements, what any solution must do to address that specific problem. Their supply-side mirror is product capabilities, what a product demonstrably does to meet those requirements. Requirements are the demand side’s spec sheet; capabilities are the supply side’s answer to it.
The industry lens: sectors, verticals, and sub-verticals
Running through every level is an industry lens, because the same problem looks different across markets. We read the whole structure through where a buyer actually operates, narrowing from broad sectors (e.g. financial services, healthcare) to distinct verticals within them (e.g. banking, payments) to specialized sub-verticals (e.g. regional banks, card networks)
This is more than a filter, and every use case is attached to a vertical. Account Takeover Prevention in Banking is a different problem than Account Takeover Prevention in Gaming. Liminal’s use cases take on vertical-specific flair the moment it’s expressed in a market: the regulations that apply, the data that’s available, the workflows, and the requirements all shift. That’s why the vertical isn’t an afterthought; it’s part of how a use case is named, scoped, and understood.
Across it all: regulations and standards
Regulations and standards shape requirements and scope use cases by jurisdiction, from national and multi-jurisdictional frameworks down to state and regional rules. The same use case can carry very different obligations depending on the geography and sector in which a buyer operates.
How to actually use this (you don’t need to memorize it)
You don’t need to study this taxonomy to benefit from it. In practice, that means you can enter from wherever your question lives. If you start from a problem (“I need to solve money mule detection in banking”), the taxonomy walks you up to the domain and down to the requirements, then hands you across to the solutions and the vendors that meet them. If you start from supply (“who competes in transaction monitoring?”), it walks you the other way, from solution segment to solutions to the use cases they serve. You don’t have to know which door you came in. The structure connects them for you.
So treat the taxonomy the way you’d treat a well-organized library. You don’t need the cataloging system memorized to find the right book, but you’re glad someone built it, because it’s how the book is findable at all.
The honest part: what a taxonomy can and can’t be
A taxonomy’s whole job is to draw firm lines so that everyone has something to root themselves in. But markets don’t actually have firm lines; they blur, overlap, and shift. Some solutions live comfortably in two segments. Some use cases bleed across domains. New categories appear faster than any structure can absorb them. We’ve made deliberate calls about where the boundaries go, knowing that any single call will occasionally feel imperfect at the edges.
That’s the trade-off: a shared, stable framework that everyone can build on, in exchange for accepting that it isn’t infinitely malleable. A model that bends to fit every exception stops being a model. So when you hit an edge case that doesn’t slot in cleanly, let us know. Because this is a living framework, those edges are exactly what we listen to as we evolve it.
