How BlackRock Builds Custom Knowledge Apps at Scale

How do you build custom applications quickly when every step from incoming information to a completed trade requires specialized knowledge? At BlackRock, portfolio managers and analysts synthesize information, develop investment strategies, rebalance portfolios, and initiate trades. Investment operations supports that process: acquiring data, executing trades, handling compliance, and completing post-trade activities. Each domain needs internal tools, often with substantial complexity.

Infant Vasanth and Vaibhav Page organize these applications into four categories. Each offers opportunities to augment existing systems with LLMs:

The shared challenge is getting these domain-specific applications into users’ hands quickly.

A request from the new issue operations team, received three to four months before the talk, makes the problem concrete. When a company goes public or a stock splits, the team must set up the security in BlackRock’s internal systems before portfolio managers or traders can act on it. Reading the source document is only the beginning.

The simplified workflow has several handoffs:

1. Ingest a prospectus or term sheet into a processing pipeline.
2. Work with domain experts, including equity and ETF teams, to define what the complex instrument requires.
3. Produce structured output.
4. Have engineering implement transformation logic and integrate that output with downstream applications.

Extraction alone does not deliver an operational application. The output still has to become something the receiving systems can use.

Introducing model providers and trying new processing strategies adds iteration to an already lengthy process. Vasanth says the team tried agentic systems, but they did not work adequately for this use case at the time: too much instrument-specific knowledge remained in the experts’ heads. That experience motivates a framework that makes expert participation easier rather than assuming it can be removed.

The first bottleneck is expressing domain knowledge precisely enough for extraction. In one simple case, a prompt began as a couple of sentences and expanded to three paragraphs as the team described the financial instrument. Once prompts become substantial specifications, operators need to iterate, version them, compare alternatives, and evaluate performance against a dataset. Prompt editing without those surrounding capabilities leaves the team unable to tell whether a change helped.

The second bottleneck is choosing how to present the task and its evidence to the model. The options discussed include retrieval-augmented generation, chain-of-thought approaches, and direct in-context extraction. A vanilla corporate bond with a short source document may be simple enough to pass directly to a model. Documents thousands of pages long—and, in Vasanth’s examples, as long as ten thousand pages—create a different context-management problem.

Vasanth raises the question of sending more than a million tokens to OpenAI models. That is a model-specific capacity concern, not a universal current limit: GPT-4.1 had already been announced with up to one million context tokens before the talk. Capacity alone does not establish extraction reliability. The practical task remains to vary prompts and strategies together while accounting for context limits, model capabilities, and provider differences.

Experimentation can stretch into months, after which deployment introduces another set of decisions. The application still needs distribution, access control, and a way to reach its users. AI workloads also require a choice of execution environment.

Vasanth illustrates the compute decision with an equity team asking to analyze 500 research reports overnight; he proposes a GPU inference cluster for that request. This is a workload example, not a measured throughput result. For new issue setup, he instead describes using a burstable cluster.

These choices should be defined well enough that application deployment approaches a CI/CD process. Cost controls belong alongside the deployment configuration: a workflow that is easy to prototype can still be expensive to operate. The GPU and burstable-cluster examples illustrate workload-dependent choices, rather than requirements for every extraction application.

Vasanth reports that the framework reduced development time for a complex application from three to eight months to a couple of days. The talk does not specify measurement boundaries or a controlled comparison, so this is the team’s reported experience rather than a benchmark. The architectural change centers on two components: a sandbox and an app factory.

Shared platform components handle the surrounding data lifecycle. The data platform ingests data, and an orchestration layer transforms it into forms that can be distributed through applications or reports. Above those foundations, the framework exposes the pieces that repeatedly slow application development: extraction templates, LLM strategies, extraction plans, transformers, and executors.

The sandbox puts those modular pieces in the domain experts’ hands. Experts can iterate on their extraction logic and configuration, then pass the resulting definition to the app factory. Vasanth describes the factory as a cloud-native operator that accepts a definition and produces an application. The division gives experts a place to refine the work while giving deployment a repeatable input.

Page begins the demonstration with a reduced version of the internal tool. The sandbox lets operators build and refine extraction templates, run them against documents, and compare the results. Familiar prompt-template features provide a starting point: fields have prompts, expected output types, and associated metadata.

Operators also need QC checks, validations, constraints, and inter-field dependencies. A callable bond supplies the concrete example: if the security is callable, its call date and call price must have values. Independently extracting three correctly typed fields is insufficient if their combination violates that rule.

The example template contains issuer, callable, call price, and call date. When adding a field, an operator specifies its name, expected type, and whether its source is extracted or derived. A derived field can be populated by a downstream transformation instead of another model extraction. Required status, dependencies, and validations complete the configuration.

The callable-bond dependency can be expressed concretely with JSON Schema. This schema fragment captures the conditional validation rule; it is not the sandbox’s configuration format:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "issuer": { "type": "string" },
    "callable": { "type": "boolean" },
    "call_price": { "type": "number" },
    "call_date": { "type": "string", "minLength": 1 }
  },
  "required": ["callable"],
  "if": {
    "properties": { "callable": { "const": true } },
    "required": ["callable"]
  },
  "then": {
    "required": ["call_price", "call_date"]
  }
}

When callable is true, omitting either dependent field fails this rule. Validation detects the missing values; it does not invent them or establish that a supplied price or date is factually correct.

Document management supplies the other input to an extraction run. Documents arrive from the data platform, receive business-category tags and labels, and are embedded. The UI exposes these capabilities alongside the framework’s modular components so domain experts can assemble their applications.

After a demo interruption, Page continues the workflow verbally. Operators run extraction using the configured templates and document sets, then inspect the returned values. In tools they had previously used, the next steps remained manual: download CSV or JSON, apply an ad hoc transformation, and push the result to a downstream process.

Page describes a low-code/no-code framework that lets operators build transformation and execution workflows into the same pipeline. This capability was described rather than demonstrated. Its role is consequential: the operator’s configuration must cover not only what to extract, but also how those results become usable inputs to the next system.

Making the sandbox available does not eliminate the need to develop skills. Vasanth recommends investing in domain experts’ prompt engineering because financial documents are difficult to describe precisely. Teams also need to understand what different LLM strategies do and how the available components fit their particular use case.

Prototype success is only one part of the production decision. The team must evaluate ROI and compare the custom AI application with an off-the-shelf product that might deliver the same job faster or at lower cost. A framework that reduces development effort does not automatically make every proposed application worthwhile.

Design for human review first in highly regulated environments. Vasanth ties that recommendation to compliance, regulation, and four-eyes checks. Human participation is therefore an explicit workflow requirement, even when a fully agentic process looks attractive.

Page then returns to the app factory, which was also explained rather than demonstrated. It combines the extraction templates, transformers, and executors refined in the sandbox into custom applications exposed through BlackRock’s application ecosystem. End users do not have to configure templates or work out downstream integration. They upload documents, run extraction, and start the complete pipeline. The expert’s configuration becomes the user’s application.

The first audience question extends the workflow from IPO processing and ETL toward executive analytics. It asks how instrument-level features such as term, maturity, and duration could become higher-level asset-and-liability information, with decentralized data in mind. The suggestion that a CEO would be the main user is the questioner’s premise, not a deployment described by the presenters.

Vasanth narrows the scope: the framework targets investment operations domain experts who are building applications. An executive memo or an asset-and-liability analysis would be a different initiative, which might or might not use this framework. Components can be reused, but the answer does not specify an architecture for aggregating instrument features into executive analytics.

The final question comes from an insurance practitioner facing similar document-processing problems. How should extraction evaluations account for failures that begin with OCR, or for models that misunderstand domain terminology despite prompting? This asks about correctness across the processing chain, not simply whether a result satisfies its output schema.

Vasanth’s response addresses information security and boundaries: controls and policies apply at the infrastructure, platform, application, and user layers within the organization’s network. Those controls address security concerns, but they do not establish whether an extracted field matches its source document.

Page adds that the team selects among multiple providers, strategies, and engineering adjustments according to the use case, rather than applying one RAG recipe everywhere. The closing answer does not provide a concrete evaluation dataset, OCR test, extraction metric, or accuracy result. The framework makes expert iteration and application delivery more repeatable; the question of how to measure extraction correctness remains open in this account.