This article was originally published on JustSoftLab Insights.

We've shipped RAG systems for regulated fintech clients across the past two years — fraud detection augmentation, compliance documentation Q&A, regulatory filing analysis, internal policy assistants. Across those engagements one pattern keeps repeating: the same ten architecture mistakes show up in roughly 9 out of 10 first production deployments, and they show up in a predictable order.

This isn't a list of bad models or weak engineers. The teams that ship these systems are usually capable. The mistakes are systemic — patterns the public RAG tutorials ignore because the demo data doesn't expose them, and patterns the vendor marketing actively obscures because admitting them would soften the sell.

If you are about to greenlight a RAG build inside a fintech, this is what we'd flag before you sign the SOW.

Why fintech RAG fails differently from generic RAG

A consumer-facing RAG demo can tolerate a 5% hallucination rate, a missing citation, a slow query, or a stale corpus. Users will retry, refine, or move on. The economic cost of a wrong answer is a slightly worse session.

A fintech RAG cannot tolerate any of those. A wrong answer in a regulated context is, depending on the use case, an audit finding, a regulatory fine, a loan extended on bad data, a fraud signal missed, or a compliance officer reading a transcript at deposition. The economic cost of a wrong answer can run into seven or eight figures, and the legal cost is sometimes existential.

This changes what "good architecture" means. The dominant requirements stop being retrieval quality, latency, and cost (those still matter, just not first). They become traceability, abstention behavior, audit trails, and update integrity. Most public RAG content optimizes for the wrong thing because it was written for a different threat model.

The ten mistakes below are ranked by how often we see them and how expensive they are to undo once production traffic is hitting them.

Mistake 1 — Treating RAG as a retrieval problem, not a system problem

The first mistake is conceptual, and it's the one that determines whether the next nine even register as problems.

A naive RAG architecture has three boxes: ingestion, retrieval, generation. Most public tutorials draw it that way. Most engineering teams scope it that way. Most vendor demos show it that way.

A production fintech RAG has at least eight boxes, and the missing five are where compliance lives:

• Ingestion (corpus collection from regulated sources)
• Document parsing and structure extraction (turning a SEC filing into addressable units)
• Chunking with provenance (every chunk linked back to source document, page, section)
• Embedding (with versioning — see Mistake 10)
• Indexing (vector + metadata, and we'll get to why hybrid matters)
• Retrieval (vector + filter + keyword combined)
• Re-ranking (cross-encoder for accuracy bar)
• Context assembly (token budget, ordering, citation injection)
• Generation with abstention (the model needs the option to say "I don't know")
• Audit trail capture (what did the user ask, what did we retrieve, what did we cite, what did we generate, who saw it, when)

Teams that scope a fintech RAG as a 3-box system end up bolting on the missing five components after launch, when audit conversations make their absence visible. That bolted-on architecture is fragile and expensive to maintain. The traceability story is incomplete. The compliance officer is unhappy.

If you remember nothing else from this piece: scope the system, not just the retrieval. We've expanded on the infrastructure layer specifically — see our pgvector vs Pinecone production benchmark for the data layer.

Mistake 2 — Generic chunking on regulatory documents

Most RAG tutorials show fixed-size chunking — 512 tokens, 1024 tokens, 50 token overlap, ship it. That works on a Wikipedia corpus. It actively destroys regulatory documents.

A typical 10-K filing, FINRA notice, or internal compliance manual has structure that the document author put there deliberately — section numbers, sub-clause hierarchy, defined terms, cross-references to other sections. A fixed-size chunker treats that structure as noise and slices through it. The result is chunks that look fine when you spot-check them and fail systematically when retrieval needs to surface a specific sub-clause.

What goes wrong in production:

• A retrieval for "what counts as material non-public information under our policy" returns the chunk after the definition (the chunker cut between "Material non-public information shall be defined as:" and the actual definition).
• A retrieval for "section 4.2.b of the trading manual" can't find it because section headers are in one chunk and section content is in the next.
• Cross-references between chunks (See Section 3.1 above) become unresolvable because Section 3.1 isn't in the retrieval set.

What to do instead:

• Structure-aware chunking — parse the document into its native units (section, sub-section, defined term, paragraph), chunk at unit boundaries, preserve hierarchy as metadata.
• Multiple chunk granularities indexed in parallel — short chunks for precise retrieval, longer parent chunks for context. Retrieve short, expand to parent before generation.
• Defined-term sidecar — financial documents define terms once and reference them dozens of times. Extract definitions into a separate index that gets joined into context whenever its term appears.

The library for parsing varies — Unstructured.io for general document parsing, LlamaParse for complex PDFs, custom parsers for specific filing formats. The library is the easy part. The decision to chunk by document structure rather than token count is the architecture move that matters.

Mistake 3 — No metadata filter strategy

This is the mistake that quietly breaks the most fintech RAG systems, and it's the one we lean on most heavily in our pgvector vs Pinecone benchmark — Postgres beat Pinecone by 30-37% on filtered queries specifically because vector + metadata filtering is a join, not a sequence.

In a fintech context, almost no useful retrieval is unfiltered. Every realistic retrieval looks like: "Find the 10 most similar chunks where jurisdiction is US, tenant_id is 7842, document_type is in regulatory_filing or internal_policy, and effective_date is on or before 2024-Q3."

There are three ways to handle this, with very different production characteristics:

1. Post-retrieval filtering. Retrieve top-1000 by vector similarity, filter down to ~10 by metadata in application code. Works for small corpora. Breaks at scale because you waste retrieval bandwidth on chunks that will be filtered out, and you may not even have the right answer in your top-1000.
2. Pre-filter then vector-search the survivors. Filter metadata first, then vector-similarity within the filtered set. Works when filters are highly selective. Slow when filters are broad (millions of rows still in scope).
3. Index-aware joint filter + vector. The query planner reasons about both at once, prunes aggressively using whichever is more selective at query time. This is what Postgres + pgvector with HNSW + appropriate B-tree indexes on filter columns does natively. It's also what Pinecone's metadata filtering attempts but performs worse on at production scale.

The teams that get this wrong almost always pick (1) because every public RAG tutorial shows it. They discover the problem in week 4 of production when retrieval latency starts climbing as the corpus grows. By then the application code has assumed retrieval-then-filter ordering and the rewrite is expensive.

If your retrieval queries are going to be filter-heavy (and in fintech they will be — multi-tenant, jurisdiction-segmented, date-bounded, doc-type-typed), the metadata filter strategy is the architecture decision, ahead of vector DB choice. Pick a stack where filters are first-class and bake them into the retrieval primitive from day one.

Mistake 4 — Vector-only retrieval (no hybrid search)

Pure vector similarity is excellent at finding semantically related content. It's bad at finding exact-match content. In fintech, exact-match content is often what the user actually needs.

Specific failures we've seen in production:

• A user searches "FINRA Rule 4530". Vector search returns 10 chunks about FINRA reporting obligations. None of them are Rule 4530 specifically. They are conceptually related, semantically near, and substantively wrong.
• A user searches by ticker symbol, account number, or transaction ID. Vector search has no idea what those tokens mean and returns approximately random results.
• A user searches a defined term ("Restricted Person" with capital R, which has a specific meaning under US securities law). Vector search returns chunks discussing restricted persons in lowercase — generic narrative passages, not the regulatory definition.

The fix is hybrid search — combine vector similarity with a lexical retrieval channel (BM25, ElasticSearch, or Postgres' built-in tsvector full-text search) and merge the results before re-ranking.

The merging strategy matters more than people think. Three patterns:

1. Reciprocal Rank Fusion (RRF) — a simple, robust default. Merge two ranked lists by combining reciprocal positions. Works well when you don't have time to tune relative weights.
2. Weighted score combination — assign explicit weights to vector vs lexical scores. Requires offline tuning against your eval golden set (see Mistake 6 below).
3. Conditional routing — detect query intent and route to vector, lexical, or both. "Show me chunks about ESG disclosure trends" → vector-heavy. "FINRA 4530" → lexical-heavy. Adds complexity but accuracy bumps are significant in production.

Vendor capability check before scoping a fintech RAG: confirm your retrieval layer can do hybrid natively. Postgres handles this trivially with vector + tsvector. Most managed vector DBs handle it awkwardly or not at all. This is a decision that gets made at the data-layer choice and is expensive to undo.

Mistake 5 — Insufficient re-ranking

HNSW (or any approximate nearest neighbor index) is approximate by design. The top-K it returns is "the K most similar chunks we found while traversing the index, with high probability." It is not "the K most similar chunks in the corpus." For consumer use cases, the difference is invisible. For fintech accuracy bars, the difference compounds.

The fix is a re-ranking pass. After approximate retrieval surfaces top-50 or top-100, run those candidates through a more accurate but more expensive scoring model — typically a cross-encoder. Cross-encoders score query and candidate together (rather than independently like a bi-encoder embedding) and produce significantly better ordering at the cost of more compute per query.

Two production-grade options:

• Self-hosted reranker. BAAI/bge-reranker-large or similar. Runs on a single GPU instance, ~50ms latency for 100 candidates. Free, you operate it.
• Managed reranker API. Cohere Rerank, Voyage AI, or similar. Sub-50ms, higher accuracy on most benchmarks, ~$1-2 per 1k queries. Cheaper than the engineering time to operate your own at small scale.

Either way, the re-rank step usually buys 10-20% accuracy improvement on ground-truth Q/A evaluation — and that 10-20% is exactly the gap between "demo quality" and "fintech production quality." Skipping it is the most common reason a RAG that passes internal demo fails internal compliance review.

Mistake 6 — Skipping the eval golden set

This is the methodology mistake, and it's the one that determines whether any of the previous five mistakes even get caught.

A golden set is a fixed collection of query/expected-answer pairs that represents real production usage. For a fintech RAG, the golden set typically has 100-500 entries, each curated by a domain expert (compliance officer, legal, senior analyst), each documenting:

• The user query (verbatim or paraphrased)
• The correct answer
• The source document(s) and section(s) that should appear in retrieval
• The acceptable failure mode (preferred wrong answer if retrieval fails — usually "I don't know," see Mistake 8)
• Tags (intent class, jurisdiction, doc type) for slicing accuracy by segment

The golden set is the system's pacing tool. Every architecture change (new chunker, new reranker, new embedding model, new context window strategy) gets evaluated against the golden set before it ships. The team gets to say "this change improved retrieval accuracy from 87% to 91% on the golden set" with a number, instead of "this feels better" with a vibe.

Teams skip the golden set because it takes 2-4 weeks of senior domain expert time to build, and that time isn't billable to the build team. So it gets deferred. Then it never gets built. Then the system runs in production with no measurable accuracy floor, and every regulatory question becomes a faith-based discussion.

We require a golden set before we ship a fintech RAG to production. Our MLOps practice has standardized templates and tooling for this. If a client doesn't have domain expert time available to build it, that's the gating issue and we surface it early — building a measurable RAG is much harder than building an unmeasurable one.

Mistake 7 — Missing audit trail and citation tracking

Every AI answer in a fintech context needs three things attached to it that consumer RAG systems usually skip:

1. Source provenance — which specific chunks (and therefore which documents, sections, paragraphs) were used to generate this answer.
2. Generation context — what was the full prompt, what was the model version, what were the inference parameters (temperature, top-p, etc.) at the moment of generation.
3. Audit retention — how long do we store this trail, and can we reconstruct any past answer when an auditor or regulator asks?

The architectural fix is straightforward and almost always missed: every generation is wrapped in a transaction that records the trail before the answer is returned to the user. Most teams record this after the response is sent (async logging) and discover, six months later during an audit, that several thousand interactions are missing trace records because of network blips, queue backpressure, or a bug in the logging code.

The transactional discipline matters: if the audit write fails, the response should fail. This is the same discipline financial systems apply to settlement records — you don't ship the trade and then pray the trade record persists. You write the trade record first.

Two implementation patterns:

• Inline audit row in Postgres before generation completes. Postgres transactions cover both the audit write and any other state mutation (lead capture, conversation log, etc.) atomically. We tend to default to this for compliance-sensitive deployments.
• Append-only event log (Kafka, Kinesis) with strict at-least-once delivery and downstream materialization. More operational complexity, useful when audit volume is high and read patterns differ from transactional store.

Either way, the principle is the same: the audit trail is part of the answer, not metadata about the answer. Treat them as one unit and the system is auditable. Treat them separately and you'll discover gaps when the auditor finds them.

Mistake 8 — Hallucination tolerance treated as a model problem

The framing teams default to is "the model hallucinated, we need a better model." The framing that actually solves it is "the architecture lacked an abstention pathway."

A well-designed RAG should produce one of three outputs at generation time:

1. An answer with citations — confident, sources attached, falls within the model's grounded knowledge.
2. A scoped answer with caveats — partial information available, model surfaces what it has and explicitly flags what's missing.
3. An abstention — "I don't have a confident answer for this. Here's what I checked. A human reviewer should look at this."

Most production RAGs only have output (1). When the model lacks grounded information, it falls back to its parametric knowledge (training data) and produces an answer that looks confident, cites no sources, and might be completely wrong. In fintech, that's the failure mode that ends careers.

Architectural mechanisms that drive abstention behavior:

• Confidence score on retrieval. If top-1 retrieval similarity is below a tunable threshold, the system shouldn't generate a substantive answer. It should abstain or escalate.
• Citation-required prompting. Instruct the model to cite source chunks for every factual claim. If it can't cite, it shouldn't claim. We use this approach across our LLM development engagements and tune the threshold per use case.
• Self-consistency check. Run generation twice with different seeds or temperatures. If outputs diverge meaningfully, surface the divergence rather than picking one.
• Domain-expert escalation pathway. Some queries genuinely need a human. The system should know which queries those are (regulatory ambiguity, novel scenarios, low retrieval confidence) and route them, not paper over them.

This is one of the architecture decisions that distinguishes a system you can ship to production from a demo. It's also one of the easiest to communicate to non-technical stakeholders — "the model can say 'I don't know'" is intuitively a feature, even though most RAGs are deployed without it.

Mistake 9 — Cost economics modeled wrong

Cost models for fintech RAG usually focus on the visible line item: LLM inference per query. That's typically $0.005 to $0.05 per query depending on context length and model choice. Annualized at production volume, that's a manageable number.

The cost lines that get missed and dominate at scale:

• Embedding cost on initial corpus + ongoing updates. A 10M-chunk corpus at OpenAI text-embedding-3-large is roughly $1,300 just for the initial embed. Updates running quarterly add another $300-500 per cycle. We've seen teams budget zero for this and discover the line item the day before they ship.
• Storage cost on vectors at full precision. 10M chunks × 3072 dims × 4 bytes is 120GB just in raw vectors, before HNSW index overhead (roughly 1.5-2× depending on m parameter). At production scale this is non-trivial. We dug into this specifically in our Postgres + pgvector vs Pinecone benchmark.
• Egress cost on managed vector DBs. Pinecone egress at production query volumes can reach $1,000+ per month, often missed in initial budgets because the marketing pricing page doesn't surface it.
• Re-ranker compute. Self-hosted re-rankers need a GPU instance. Managed re-rankers cost per query. Either way it's not zero.
• Logging and audit storage. Every query, every retrieval set, every generation, every citation — at production volume you're storing tens to hundreds of GB per month, and storing it under retention policies that may be longer than your other application data.

Honest fintech RAG TCO comes out at 2-4× what naive LLM-cost-only models suggest. Our project estimator breaks this out by component for the standard fintech RAG profile, and we walk clients through it in scoping calls because the surprise version is uncomfortable for both sides.

Mistake 10 — No re-embed and update strategy

Financial corpora change continuously. New regulations, new SEC filings, new internal policies, new product documentation, new customer agreements. Embedding models also change — text-embedding-3-large replaced ada-002, future generations will replace text-embedding-3-large. Every change is a question about index integrity.

Three failure patterns we've seen:

1. Stale corpus. New documents stop getting embedded because the ingestion pipeline broke six months ago and nobody noticed (because the search still returns something). Users get answers from yesterday's reality. Compliance officer eventually asks why a 2026 question is being answered with 2024 content.
2. Mixed embedding versions. Half the corpus is embedded with the old model, half with the new. Vector similarity scores aren't comparable across embedding spaces. Retrieval ranking becomes effectively random for queries that span both halves.
3. No versioning. Someone re-embeds the corpus with a new model. Old query logs and audit trails reference vectors that no longer exist. You can no longer reproduce yesterday's answer to satisfy today's auditor.

The architectural discipline that prevents all three:

• Versioned embedding tables. Every chunk row has an embedding version. The retrieval layer queries by version. Migrations re-embed in parallel with the old version still serving, then atomically cut over.
• Ingestion pipeline observability. Every new document into the corpus should produce a metric. Ingestion outages should page someone.
• Re-embed cadence policy. Quarterly review of whether the embedding model has materially advanced is a reasonable default. Most fintech corpora don't need monthly re-embedding; almost none can tolerate "we'll deal with it later."

This is one of the things we wire in by default on engagements that go through our Senior Delivery Pods — it's invisible until it's broken, and at that point the cost to fix exceeds the cost to have built it correctly the first time.

The fintech RAG architecture we recommend

Across the ten mistakes, a coherent architecture emerges. The version we deploy by default for fintech engagements:

Data layer: Postgres 16 with pgvector for combined vector + structured metadata + full-text search in a single query plan. Parallel HNSW index build (Postgres 16+ feature). PITR enabled for 35-day audit replay. We've documented the case in detail in our pgvector vs Pinecone production benchmark.

Ingestion layer: Document-structure-aware parsing (Unstructured.io for general documents, custom parsers for regulatory filing formats). Defined-term sidecar extraction. Versioned chunk and embedding writes. Pipeline observability with paging on ingestion failures.

Retrieval layer: Hybrid search (vector + BM25 via Postgres tsvector) with Reciprocal Rank Fusion as a default merging strategy. Metadata filters baked into the query plan, not post-applied.

Re-ranking layer: BGE reranker large self-hosted on small GPU instance, or Cohere Rerank if zero-ops is preferred. Top-50 → top-10 reduction with measurable accuracy lift.

Generation layer: Citation-required prompting. Confidence-threshold-driven abstention. Self-consistency check on high-stakes queries. Model choice tuned per use case — frontier model for complex regulatory reasoning, smaller open-weight model for high-volume routine queries, both wrapped behind a single internal API.

Audit layer: Inline transactional audit write before any user-visible response. Structured log captures full prompt, retrieval set, citations, model version, inference parameters, response, and timestamp. Retention policy aligned to applicable regulatory regime (SEC: 7 years for relevant communications; HIPAA: 6 years; PCI: variable).

Observability layer: Per-segment accuracy tracking against golden set, run on every deployment. Latency p50/p95/p99 by query class. Hallucination flag rate (citation-missing generations) tracked as a leading indicator.

This isn't the only valid architecture, but it's the one we recommend by default because every component is justifiable to a regulator, the operating story is simple (a Postgres database your team already knows how to operate, plus a few well-bounded auxiliaries), and the cost model is predictable.

Migrating from a flawed RAG

If you already have a RAG in production and you're recognizing yourself in some of the ten mistakes above, the migration is achievable in a defined window. We've done this for several clients in the past 18 months.

Typical sequence (3-6 weeks depending on corpus size and starting state):

1. Build the golden set first. No migration without a measurement floor. Two weeks with domain experts is the gating activity.
2. Quantify the current system's accuracy on the golden set. This is your baseline. If it's 60%, you know your improvement target. If you can't measure it, you can't migrate it.
3. Stand up the new architecture in parallel. Same corpus, new chunker, new index, new retrieval pipeline. Don't migrate the user traffic yet.
4. Run both systems on the golden set. Compare per-segment accuracy. Identify regressions and resolve them before user-traffic migration.
5. Shadow mode. New system runs on real production queries but doesn't return answers — just logs. Compare to legacy system answers offline for a week.
6. Cutover. Atomic flag flip. Legacy system stays running for 30 days as a fallback. Audit log retains links to both for that window.

The most common reason migrations stall is skipping step 1 (no golden set) — without it, every other step becomes a vibe-based discussion. We'd rather spend the first two weeks slowly than the next three months in a low-confidence rebuild. Our 15-day Pilot Engagement is specifically scoped for the golden set + baseline measurement work as a fixed-price entry point.

Conclusion

The ten mistakes above aren't theoretical. They show up in roughly 9 out of 10 first fintech RAG production deployments we audit, in the order they're listed, and they compound — each one makes the next one harder to fix.

The good news is they're addressable. The architecture isn't novel; it's discipline applied to known components. Postgres has done versioned writes for forty years. Cross-encoders have been published for half a decade. Audit trails are settled engineering. None of this requires research-grade AI work.

What it requires is the operational seriousness to treat RAG as a system rather than as a retrieval problem, and the institutional honesty to keep a golden set instead of running on intuition.

If you're scoping a fintech RAG engagement and want a vendor-neutral check on the architecture before you commit, we offer a fixed-price 15-day pilot specifically for this. The deliverable is a working artifact, a baseline measurement against your golden set, and a written assessment of where the architecture is solid and where it isn't. Senior team, no junior fillers, week-1 production code.

If your corpus is healthcare or regulated industry adjacent rather than fintech specifically, the healthcare RAG case study on our case studies page covers the same architecture with HIPAA-specific compliance overlays applied — most of the principles transfer cleanly between regulated verticals.

Originally published at JustSoftLab Insights.