Beyond “LLM + Plaid”: The Infrastructure Moat Behind Ask Linc

A view of the financial data, computation, and evidence infrastructure behind Ask Linc—and why the product is materially more than an LLM connected to a bank-data API.

Many financial AI products can be summed up as “LLM + Plaid.” Connect an account aggregator, place account data in a prompt, and let a capable model produce advice.

That architecture can give a convincing, confident-sounding answer. It is not enough to build a dependable financial reasoning product.

Ask Linc’s technical thesis is that the durable value sits between raw provider data and the model: a canonical financial truth layer, a controlled evidence-routing system, deterministic calculators, explicit provenance, output-level grounding, and operational infrastructure that keeps the same answer explainable when providers or models fail.

The model remains important. It interprets intent, identifies relevant context, connects facts, and explains tradeoffs. But it is deliberately downstream from the systems that decide what a financial number means, whether it is current, how it was calculated, and whether it is safe to show.

In one sentence:

Ask Linc is building financial reasoning infrastructure, not a conversational wrapper around an aggregation API.

Why “LLM + Plaid” is an incomplete product architecture

A bank-data connection can provide balances and transactions. A serious household decision can also require brokerage holdings, security metadata, liabilities, fund look-through, market prices, interest-rate benchmarks, housing values, public rules, historical return series, and user-supplied assumptions.

Even after those sources are connected, the application still needs to answer questions the model should not improvise:

• Which of two apparently similar accounts is the same economic account?
• Is a transfer spending, income, or neither?
• Should a brokerage account total come from its reported balance or from itemized holdings?
• What does “current” mean when the evidence has several source dates?
• Which numbers may appear in an answer, and what caveats must travel with them?
• What should happen when one provider succeeds and another fails?
• Can a fallback model be evaluated fairly if it receives different evidence?

These are not merely prompt-engineering questions. They are data contracts, reconciliation rules, calculation engines, failure policies, and validation systems. Ask Linc treats them as application code.

Provider diversity at the edge, canonical truth at the core

No single provider is authoritative for an entire household financial picture. Ask Linc therefore uses multiple specialized sources at the edge while normalizing their outputs into one internal financial model.

The inference layer does not receive provider responses and decide what they mean. Provider identity is preserved at ingestion; canonical services then normalize accounts, transaction cash-flow semantics, investment totals, liabilities, source dates, and quality states before the facts reach a model.

That distinction is central to the moat.

APIs can be licensed by competitors. The accumulated rules for reconciling those APIs are application knowledge. For example, Ask Linc treats human-readable account similarity as an attribute rather than identity, preserves unknown values instead of turning them into zero, and reconciles a brokerage account’s reported balance with the value of its itemized holdings. If the reported total exceeds the itemized positions, the difference remains in net worth as “Not itemized” rather than being assigned a fictional asset class.

These rules reduce silent financial errors and create a stable interface for every downstream surface: dashboards, calculators, retrieval, and generated answers.

A financial truth layer that compounds

The canonical layer defines what important concepts mean once:

• account identity across providers;
• income, spending, transfers, refunds, and investment activity;
• cash, debt, investment value, and net worth;
• modeled versus unmodeled portfolio value;
• fresh, stale, partial, and unavailable evidence;
• the difference between when a result was computed and when its oldest contributing observation was measured.

This is less visible than a model upgrade, but it is more cumulative. Every new integration, edge case, validation rule, and regression test strengthens a common substrate. New product surfaces can inherit the same definitions instead of rebuilding financial semantics inside prompts.

The result is a compounding engineering asset: normalization and correctness work done for one use case improves the reliability of the next calculator, the next integration, and the next class of user question.

Custom RAG as controlled evidence routing

Ask Linc’s retrieval system is not primarily a vector search over documents. Its core task is deciding which classes of evidence a financial decision requires.

The production pipeline uses two semantic passes.

1. Semantic preflight

An OpenAI planning model reads the active question and recent conversation context. It returns structured output selecting from an application-owned vocabulary of data packs, identifying supported scenarios and user-stated inputs, deciding whether secondary review is appropriate, and—when open-ended public evidence is needed—proposing up to three standalone search queries.

2. Primary-model evidence audit

Before answering, the primary Claude model calls a constrained request_data_packs tool. It can widen the plan if it recognizes missing evidence, but it cannot request arbitrary database access, remove packs already selected, bypass dependencies, invent a calculator, or perform the authoritative computation itself.

Application code validates both passes.

The current allowlist contains nine packs:

Dependencies are expanded deterministically. For example, retirement analysis brings the investment, profile, and market context on which it depends. Foundational aggregate truth—such as net worth, cash, debt, investment totals, asset allocation, and average cash flow—remains available without an optional pack.

This architecture controls cost, latency, and sensitive-data exposure at the same time. The model makes a semantic decision about what it needs; the application retains authority over what can be loaded.

Live retrieval with a privacy and reliability boundary

When a question needs a current law, limit, rate, benefit rule, or other public fact, Ask Linc does not forward the user’s raw private prompt to a search provider.

Planned queries must be self-contained, bounded, and free of obvious private identifiers. If the planner selects search but cannot produce a valid public query, the search path fails closed. Each valid query is cached independently with its freshness requirement, and the evidence record tracks cache hits, provider calls, results, and per-query failures.

The Brave integration adds request pacing, bounded retry behavior, concurrency-safe rate limiting, and explicit handling of 429 backpressure. Successful sibling queries can survive even when another query fails, and final results are deduplicated by URL.

This is representative of the broader product: retrieval is treated as operational infrastructure, not a prompt accessory.

Deterministic calculation is separate from inference

The most important boundary in Ask Linc is that a language model does not compute authoritative financial outcomes.

Application code computes net worth, cash flow, savings rates, portfolio allocation, withdrawal metrics, depletion distributions, survival rates, and registered what-if scenarios. The model receives those results and explains them.

For scenarios, the semantic layer proposes a typed plan. The application checks the plan against a registry, validates supported override names and bounds, verifies that numeric overrides are traceable to the user’s wording, loads the required canonical data, and invokes a versioned calculator.

The current registry includes retirement-withdrawal analysis and target-home affordability. Each calculator owns its version, required packs, supported inputs, defaults, output contract, executor, unavailable-state behavior, canonical-fact projection, and assumption disclosures.

Natural-language question
        ↓
Typed, validated scenario plan
        ↓
Canonical financial inputs
        ↓
Versioned deterministic calculator
        ↓
Scenario facts + assumptions
        ↓
Model explanation

This design creates a repeatable extension path. Adding a new calculator is not a matter of teaching the model a longer prompt. It means implementing a typed, testable decision engine behind the same planning, provenance, validation, and evidence interfaces.

Canonical facts form the contract with the model

After data gathering and calculation, Ask Linc builds a canonical fact pack rather than handing the model an unstructured bag of JSON.

A fact can carry an ID, label, value, unit, displayability, caveat, and provenance. Provenance distinguishes observed snapshot values, deterministic calculations, user inputs, external context, scenario inputs, and scenario calculations. Calculated facts can identify both their formula and the input fact IDs that produced them; scenario facts can name the calculator and version.

That structure turns raw context into citable financial claims.

It also creates a clean boundary for future integrations. A new provider does not need bespoke prompt logic everywhere. Once its observations have been normalized and projected into canonical facts, the rest of the reasoning stack can consume them through the same interface.

Output-level grounding: the model is checked after it speaks

Good evidence in does not guarantee grounded prose out. A model can receive correct context and still introduce a plausible but unsupported number.

Ask Linc therefore validates the generated response after inference. Structured key numbers are canonicalized back onto server-side fact definitions, and monetary and percentage claims in user-facing prose are checked against the displayable fact pack.

The grounding logic accounts for normal presentation behavior—such as rounding—while distinguishing financial claims from numeric identifiers and common language patterns. If a claim is unsupported, the system first tests whether evidence was under-fetched. It can widen to the remaining allowlisted packs and re-check the answer. If the issue remains, the model gets one retry with validation feedback. If the retry is still ungrounded, server code attempts to salvage the supported portions before falling back to an unavailable response.

Generate
   ↓
Ground against canonical facts
   ↓
Expand allowlisted evidence if necessary
   ↓
Ground again
   ↓
Retry with validation feedback
   ↓
Salvage supported content or replace

This recovery ladder matters because two failures can look similar: the model may have hallucinated, or the planner may have under-fetched. The system does not assume they are the same problem.

For sufficiently complex questions, Gemini can serve as an independent reasoning reviewer. That role remains separate from deterministic grounding: one check asks whether every financial claim has evidence; the other asks whether the reasoning built on those facts is sensible.

“Show the Math” is built underneath the model

Explainability is not implemented by asking the model to write a more confident rationale. The analysis pipeline records an evidence manifest.

The manifest can include:

• canonical facts and calculation provenance;
• snapshot computation and source timestamps;
• initial, selected, and final context packs;
• primary-model widening decisions;
• scenario plans, executions, versions, and assumptions;
• search queries, cache/provider routing, and outcomes;
• deterministic and secondary-validation results;
• model-call outcomes and operational timings.

Ask Linc’s “Show the Math” experience is built from this evidence. The product can answer where a number came from, when its source was observed, whether it was measured or calculated, which formula and inputs produced it, and which scenario assumptions were active.

This makes transparency a property of the system rather than a style choice made by the model.

Fallback without evidence drift

Ask Linc currently uses Claude for primary financial reasoning, with OpenAI available as a provider fallback. The strategically relevant detail is that fallback happens after evidence has been prepared.

If the primary provider fails, the fallback receives the same built system prompt and user context. The application does not refresh providers, rerun retrieval, or recompute the financial snapshot simply because the inference vendor changed.

That keeps model comparisons observable and prevents “fallback” from silently becoming a different financial analysis performed on a different snapshot. It also makes model vendors more replaceable because the product’s financial semantics, retrieval policies, calculators, and evidence are not encoded exclusively in one model’s prompt.

The compounding technical moat

None of the individual components is impossible to copy. Competitors can license aggregation APIs, call the same model vendors, and implement calculators.

The moat is the integrated and accumulating system of correctness:

1. More provider coverage creates more reconciliation knowledge. Each integration contributes edge cases around identity, freshness, partial data, pagination, classification, currency, and failure behavior.
2. Normalization creates reusable truth. Once a financial concept is defined canonically, dashboards, reasoning, and new calculators share it.
3. More decision engines expand the product without expanding model authority. New calculators inherit planning, inputs, provenance, disclosures, validation, and evidence recording.
4. More production usage hardens validation. Unsupported claims, under-fetch patterns, rounding behavior, provider warnings, and partial states become testable application rules.
5. Operational infrastructure protects the evidence path. Source-specific caching, backpressure, retries, partial-failure semantics, and immutable prepared context reduce silent drift.
6. Evidence manifests create a feedback surface. The team can observe what was planned, what was loaded, which model saw it, what failed validation, and how the final answer was recovered.

That flywheel is more defensible than a prompt alone. It takes time to build because it is made of accumulated domain decisions, failure cases, tests, and operational behavior—not because it depends on one secret algorithm.

Extensibility as a product advantage

The architecture is designed so that growth does not require turning the model into an unrestricted agent.

A new provider can enter through the data plane, preserve its identity and source timestamps, normalize into the truth layer, and project into existing canonical facts. A new evidence type can become an allowlisted pack with explicit dependencies and cost. A new decision domain can become a registered calculator with typed inputs, outputs, versions, and disclosures.

This creates several advantages:

• product breadth can expand without rewriting the core reasoning model;
• model vendors can improve or change without redefining financial truth;
• provider substitutions can occur behind canonical interfaces;
• new capabilities inherit existing validation and evidence infrastructure;
• costly or sensitive data is loaded only when semantically relevant.

The long-term asset is therefore not a fixed set of integrations or calculators. It is the architecture for adding them without losing correctness, privacy boundaries, or explainability.

A credible view of the opportunity

Ask Linc’s architecture is intentionally more expensive to build than a prompt-first prototype. It requires reconciliation logic, source-quality tracking, canonical snapshots, semantic planning, allowlisted capabilities, calculator registries, output grounding, recovery paths, and evidence persistence.

That complexity is justified only if users value answers that can support real financial decisions.

The investment case is not that language models become infallible. It is that a carefully bounded model becomes far more useful when surrounded by a system that owns the facts, the math, and the audit trail.

As model capabilities commoditize, those surrounding layers become more—not less—important. Better models can improve interpretation and communication, while Ask Linc’s accumulated financial truth, decision engines, validation rules, integration behavior, and evidence infrastructure remain reusable.

Conclusion

“LLM + Plaid” describes access to a model and one important source of data. It does not describe a trustworthy financial reasoning system.

Ask Linc’s differentiated asset is the infrastructure between ingestion and explanation: provider diversity at the edge, canonical financial truth at the core, semantic evidence planning, deterministic scenario execution, canonical facts with provenance and caveats, output-level numeric grounding, evidence manifests, and fallback behavior that preserves the same underlying record.

Each new provider, calculator, edge case, and validation rule strengthens that system.

The model is the reasoning interface. The compounding moat is the application that makes its reasoning financially coherent, inspectable, and extensible.