Blog
The Model Is the Commodity. The Pipe Isn't.
Two teams. Same model. Same compute budget, roughly. One has clean, licensed financial data flowing through a purpose-built pipe. The other doesn't.
The model doesn't save the second team.
Frontier capability has converged fast. Eighteen months ago the gap between leading models was real and consequential. Now, that gap is quite narrow. When two builders call the same API, the only variable that remains is what they fed it.
The model is the commodity. The pipe is not.
The pipe is everything that happens before the model sees your data: the connections to financial institutions, the normalization of what comes back, the enrichment that makes raw transactions meaningful, and the licensing agreements that make every output compliant. This stack is the actual differentiator in AI-powered financial services. That’s substantially harder to build.
The market built for the wrong bottleneck
The International Energy Agency (IEA) forecasts AI data center electricity demand more than doubling by 2030, to roughly 945 TWh. Entire investment theses are organized around that number. Grid upgrades, nuclear restarts, dedicated compute clusters.
Nobody is building the same way around the astronomical demand for clean data. The asymmetry is strange, because power is fungible and financial data is not. A watt is a watt. Transaction data can take on many shapes.
LLMs read schemas, not production reality
This is the first version of "the pipe is hard" that most teams encounter, usually in production.
An agent can read your API documentation. It can understand the expected format for a balance field or a transaction object. What it cannot account for is the gap between those docs and what comes through a live connection. A major data provider may document several hundred connection error codes. At massive scale, our system observes hundreds more that appear nowhere in the documentation. A large bank may have six separate login portals, each behaving differently. The same account arrives with structurally different field names depending on which provider retrieved it and what data-sharing agreements exist between them and the account aggregator.
The docs are not wrong because engineers wrote them carelessly. They are incomplete, because production financial data is far more complex than static documentation can capture.
This is also why the model being non-deterministic matters so much for everything upstream. LLMs are probabilistic by design. That is the feature. It is also exactly why inputs have to be deterministic. Probabilistic reasoning sitting on top of probabilistic data does not produce an answer you can underwrite, reconcile, or show a regulator.
"An agent can just figure it out" isn’t sufficient. The agent can read the docs, but cannot know whether the docs are actually reflective of reality in production. .
Two steps. Neither optional.
The first step is understanding that the inputs are messy. Fixing them, consistently, at scale, is step two. Most teams find that the gap between those two steps is where product quality lives.
Normalization is structural: reconciling field-name mismatches across providers, reliably extracting account identifiers using models trained across the full connection fleet. Around 30 to 40 extraction rules, weighted by features. The patterns that make normalization accurate only become visible at volume. A single fintech sees its own users' banks. Across millions of connections, edge cases accumulate into extractable rules no individual customer could build alone.
Enrichment is semantic: clean merchant names, logos, spend categories, cash flow signals, built through experienced providers like FinGoal, MX, Pave, and Prism Data.
Together, this is what turns a raw feed into something a model can reason over the same way twice.
Capital doesn't solve the licensing problem
There is a version of the pipe problem that most AI teams have not thought through yet.
Provenance is inherited. If your model is reasoning over data obtained without proper licensing and permissioning, every output carries the liability attached to how that data was collected. Every customer decision made on those outputs inherits the same exposure. Regulators will not care that it was technically someone else's pipeline.
The barrier here is contractual, not technical. Bank data-sharing agreements run to several hundred pages and can take years to negotiate. Preferred-partner and reseller relationships take years to build. AI doesn’t provide shortcuts for this.
The regulatory forcing function most people were waiting for is gone. Rule 1033 as originally proposed is effectively dead as a standardizing force. Fragmentation is the steady state. The FDX AI Exploratory Task Force is actively working through what consent and data scope even mean for agentic systems. The proposed solutions are still under construction.
The contractual layer of the pipe is a moat precisely because it cannot be replicated in a quarter.
Coverage compounds
The last piece: breadth matters as much as quality.
At Quiltt, we route across over 20,000 deduplicated institution portals, over 30,000 provider-portal combinations, and nearly 4,000 OAuth connections. The difference is not marginal. Additional coverage alone drives roughly 10 to 15 percent higher connection success. Fallback routing adds another 5 to 10 percent. A fully loaded orchestration setup delivers 15 to 25 percent better end-to-end success than a single-aggregator configuration, across the same institutions.
More connections make routing smarter. Smarter routing makes coverage better. Coverage compounds.
Build the pipe
Nobody builds a data center and hopes the power shows up. But that is how most AI products treat the data layer.
We built Quiltt on the premise that clean, licensed, permissioned financial data would be the scarce input for the next wave of fintech products. The last year of AI-native companies coming through our pipeline has been that thesis proving out. Every one of them arrived needing the same thing: a pipe worth building on.
The model is a commodity. Build the pipe.
Want to go deeper? Read our primer on fintech data orchestration, or book time with the team.
Frequently Asked Questions
What is financial data normalization and why can't individual fintech companies build it themselves?
Normalization reconciles the structural differences in financial data returned by different aggregators, like field names for the same account attribute, identifier formats, and ways of representing pending versus posted transactions. Doing this accurately requires exposure to edge cases that only accumulate at scale. A single fintech sees its own users' banks. Across millions of connections spanning thousands of institutions and multiple aggregators, patterns emerge that aren't visible from any individual dataset. The extraction rules that make normalization reliable (roughly 30 to 40 rules weighted by observed features) can only be built from that volume. A unified API layer like Quiltt is best-positioned to create that normalization.
What is the difference between data normalization and data enrichment, and why do AI applications need both?
Normalization is structural. It reconciles field-name mismatches across providers, resolves inconsistent account identifiers, and ensures that the same underlying financial object looks the same regardless of which aggregator retrieved it. Enrichment is semantic. It layers on clean merchant names, spend categories, cash flow signals, and other derived attributes that give raw transaction data meaning. For AI applications, normalization ensures the model sees consistent structure; enrichment ensures the model has enough context to reason usefully over that structure. Neither substitutes for the other.
How does data licensing affect the outputs of AI models trained or reasoning over financial data?
Provenance is inherited. If an AI model reasons over financial data that was obtained without proper licensing and permissioning, every output carries the liability attached to how that data was collected. That exposure extends to every customer decision made downstream. Contractual compliance can’t simply be retrofitted after the fact; it has to be embedded in the data pipeline itself. Bank data-sharing agreements are substantial documents that can take years to negotiate, and reseller relationships involve additional authorization layers. Capital and engineering resources don't accelerate that timeline.
If AI models are increasingly similar, what actually differentiates AI-powered financial products?
The models themselves are no longer the differentiator. Frontier capability has converged to the point where two teams calling the same API get roughly equivalent reasoning performance. What separates them is the quality, completeness, and licensing status of the data those models are reasoning over. In financial services specifically, that means the connections to institutions, the normalization layer that makes data consistent across providers, the enrichment that turns raw transactions into meaningful signals, and the contracts that govern what can be done with the output. That data pipeline is where product quality actually lives.
Why can't an AI agent figure out inconsistent financial data on its own?
An AI agent can read API documentation and understand expected data formats. It can’t account for a gap between published documentation and what data actually comes through live connections. A single bank may have multiple login portals that each return differently structured data. The same account can arrive with different field names depending on which aggregator retrieved it. Error codes appear in production that don't exist anywhere in published specs. The agent is essentially following incomplete documentation. Clean, normalized inputs aren't optional for reliable AI outputs.
Why do AI applications in financial services require deterministic inputs?
LLMs are probabilistic by design, which makes them useful for reasoning. But probabilistic reasoning sitting on top of inconsistent, unnormalized data doesn't produce outputs you can underwrite, reconcile, or show to a regulator. The more ambiguous the inputs, the wider the variance in outputs. For financial applications where decisions carry real liability (e.g. credit decisions, income verification, cash flow analysis), the data layer has to be deterministic so that the model's probabilistic reasoning is operating on a stable foundation.
Why does financial data coverage breadth matter for AI model performance?
Coverage breadth affects routing intelligence, which in turn affects connection success rates, which determines how much data the model actually has to work with. Single-aggregator setup may fail to connect a user's institution, producing a gap in the data. Multi-aggregator orchestration with fallback routing means more connections succeed. We see roughly 15-25% better end-to-end success when using multiple providers. More successful connections also create more observational data for improving routing logic over time. Coverage compounds: better breadth produces better routing, which produces better coverage.
.avif)
