The Stack — Kensho
A technical teardown of Kensho: the models, infrastructure, and engineering decisions behind the product.
Kensho is the AI analytics infrastructure quietly powering institutional finance at scale
What It Is
Kensho, acquired by S&P Global in 2018 for roughly $550 million, builds AI-powered data extraction, entity linking, and financial analytics tools used by analysts, traders, and risk teams at major banks, asset managers, and government institutions. Its core products — Scribe, Extract, and Link — handle structured extraction from unstructured financial documents at enterprise volume. The user base skews heavily toward institutional clients who need auditable, citation-backed outputs rather than conversational fluency.
The Architecture
Model selection is defense-first, not capability-first. Kensho has not publicly disclosed which frontier models underpin its current stack, and it would be misleading to guess specific versions. What is confirmed through S&P Global engineering talks and product announcements is that Kensho operates a hybrid inference strategy: proprietary fine-tuned models for narrow, high-precision tasks (entity recognition, financial taxonomy mapping, document classification) layered underneath a frontier model tier for more open-ended summarization and synthesis. This separation is deliberate — fine-tuned smaller models are cheaper to run at high throughput and produce more auditable outputs on structured extraction tasks than a single general-purpose frontier model.
RAG is load-bearing, not supplementary. Kensho’s Link product, which connects extracted entities to S&P’s proprietary data assets (CUSIP identifiers, company hierarchies, ratings histories), is essentially a production RAG pipeline where the retrieval corpus is itself a competitive moat. The index isn’t Wikipedia or Common Crawl — it’s decades of S&P editorial and data work. This means retrieval quality is a function of S&P’s underlying data licensing position, not just embedding model choice. Kensho has confirmed in engineering blogs that they use dense vector retrieval with deterministic post-processing steps to enforce regulatory consistency in entity resolution.
Inference is almost certainly self-hosted or private-cloud for the sensitive tier. Financial services clients — particularly those regulated under FINRA, MiFID II, or SEC rules — cannot send raw document content to public inference APIs without data residency and confidentiality guarantees. Kensho’s enterprise contracts include data isolation commitments, which strongly suggests that the high-sensitivity document processing path runs on private infrastructure rather than shared API endpoints. The summarization and synthesis layer, handling less sensitive workloads, likely uses API access to a frontier model under a data processing agreement.
Latency architecture is batch-tolerant, not real-time. Unlike consumer AI products that compete on sub-second response time, Kensho’s core document processing workloads are batch-oriented. Scribe (automated transcription of earnings calls and financial events) operates on a publish-then-process model: a call ends, the transcript is generated and enriched within minutes, and that latency window is acceptable to institutional consumers. This allows Kensho to optimize for throughput and accuracy rather than p99 latency, which significantly changes the infrastructure calculus. High-accuracy reranking passes and multi-step validation pipelines that would be prohibitively slow in a consumer chat product are entirely viable here.
The Smart Decision
Kensho built on S&P’s data moat rather than competing on model capability alone.
The obvious play for an AI finance company is to chase frontier model performance — better summaries, more fluent answers, sharper reasoning. Kensho made a different bet: that the retrieval corpus and the entity graph matter more than the generation layer for institutional use cases. By deeply integrating with S&P’s proprietary identifiers (CUSIP, GICS classifications, ratings histories), Kensho’s outputs are linked to authoritative, legally defensible data sources that no model trained on public data can replicate.
This matters enormously in practice. When a risk analyst asks which companies in a portfolio were affected by a specific regulatory event, the value isn’t in the fluency of the answer — it’s in whether the entity resolution is correct and traceable. Kensho’s architecture ensures that “Company X” in an extracted document resolves to a specific, auditable CUSIP rather than a fuzzy string match. That’s not a model capability; it’s a data infrastructure decision. And it makes the product extremely difficult to displace with a general-purpose AI tool, regardless of how capable that tool becomes.
The Tradeoff
Betting on structured extraction over conversational flexibility creates real ceiling risk.
Kensho’s strength — deterministic, auditable, schema-constrained outputs — is also a constraint on what the product can become. As frontier models have gotten dramatically better at unstructured reasoning over documents, the gap between “fine-tuned extraction model” and “frontier model with a good prompt” has narrowed on many tasks. Clients who once needed Kensho’s specialized pipeline for earnings call extraction can now get surprisingly good results from general-purpose tools, and those tools are getting cheaper (GPT-6 Luna at $0.10/$0.50 per M, Haiku 5.5 at $0.10/$0.50 for short prompts) while Kensho’s value proposition still implicitly assumes that extraction is hard.
The deeper risk is product evolution speed. Infrastructure designed for batch, schema-constrained, auditable outputs is architecturally mismatched to the agentic, multi-turn, real-time workflows that institutional clients are increasingly asking for — the kind of persistent background research agents that products like Claude Cowork or Gemini Managed Agents now enable. Kensho’s architecture is excellent for what it was designed for, and that design is now partially upstream of where enterprise AI is heading.
What You Can Steal
- Separate your extraction layer from your generation layer. Use fine-tuned or constrained models for high-precision structured tasks; use frontier models only where open-ended reasoning adds value. This cuts cost and improves auditability.
- Your retrieval corpus is your moat, not your model. If you have proprietary, high-quality structured data, build RAG against that before competing on generation quality. The retrieval index is defensible; the model layer is not.
- Design for batch-tolerant latency early. Not every AI workload needs to be real-time. Accepting a 3–5 minute processing window unlocks reranking, validation passes, and accuracy improvements that real-time systems can’t afford.
- Post-processing is a first-class product decision. Deterministic post-processing steps (identifier lookups, schema validation, citation attachment) after model output are often what make AI outputs actually usable in regulated industries — treat them as architecture, not cleanup.
- Data residency is a sales requirement in regulated verticals, not a compliance footnote. Build private inference paths into your architecture before enterprise deals require it, or you’ll retrofit them under deadline pressure.