Compliance-Aware Retrieval-Augmented Generation for Regulated Financial-Reporting Corpora

TL;DR

Four failure modes of compliance-naïve RAG

CARAG closes F1–F3 structurally and F4 probabilistically.

The five-stage CARAG pipeline

1. 1

   Ingestion + policy labelling

   Each chunk gets a 27-bit policy vector packed in one 32-bit machine word — derived deterministically from documented metadata fields. ~0.4% storage overhead at d=1024, fp16.

2. 2

   Metadata-aware index (HNSW)

   Standard hierarchical navigable small-world graph (M=32, efConstruction=200), with the policy bitmask co-located alongside each vector for O(1) per-candidate admissibility tests.

3. 3

   Policy inference

   Maps (query, user role, session purpose) to a (M_req, M_for) mask pair via a deterministic role-policy lookup plus a session modulator that applies query-conditional refinements such as the active deal-list.

4. 4

   Constraint-aware retriever

   Bitwise admissibility check evaluated inside the inner loop of HNSW traversal — before the result heap is updated. Adaptive ef expansion preserves recall under tight policies.

5. 5

   Guarded generator + Merkle-anchored audit log

   The generator (Amazon Nova Micro) sees admissible and inadmissible buckets explicitly and is instructed to draw only from the former. Every query commits a Merkle-anchored append-only record sufficient for Article 12 of the EU AI Act.

Headline results

Four systems on the SEC compliance benchmark — n = 600 queries, k = 8 retrieved chunks per query. CARAG attains the lowest CVR and ODR while sacrificing only a small constant of token-F1.

Table 2, Section 6.1. CVR = Constraint Violation Rate, ODR = Output Disclosure Rate. Pre-filter (B2) achieves the same CVR floor as CARAG but at the cost of a sharp F1 drop because a static role partition is too coarse to recover query-conditional admissibility.

Where the cost lives

Disaggregating by query stratum (loose / medium / tight) reveals where the architectural cost of compliance lands. On loose queries — where the policy admits the majority of relevant chunks — CARAG's F1 closely tracks the vanilla baseline. The gap widens slightly on medium queries and opens fully on tight queries, where the relevant set is genuinely sparse.

That tight stratum is also where CVR and ODR matter most: each violation is, by construction, semantically meaningful — an inadmissible chunk contains the answer. The cost concentrates exactly where policy substantively restricts the relevant set, not on routine due-diligence queries.

Production economics

What this means for your stack

If you operate a RAG system that touches:

• →EU jurisdictions (GDPR Articles 5, 6, 22 + EU AI Act Articles 12–15)
• →Financial services (Reg FD, FINRA Rule 2241, SOX / PCAOB AS 2820)
• →Healthcare (HIPAA, GDPR Article 9 special-category data)
• →Cross-border data residency (EU/US/UK/CA/Other)

…compliance is no longer something you can bolt on after the fact. CARAG's bitmask encoding retrofits onto an existing dense index in days, not months, and the audit log is verifiable under Article 12 of the EU AI Act.

Cite this work

@techreport{bhardwaj2026carag,
  author      = {Bhardwaj, Aru},
  title       = {Compliance-Aware Retrieval-Augmented Generation
                 for Regulated Financial-Reporting Corpora:
                 A Real-World Evaluation on SEC EDGAR Filings},
  institution = {Insightrix},
  year        = {2026},
  type        = {Working Draft},
  address     = {Paris, France},
  url         = {https://arubhardwaj.eu/research/compliance-aware-rag-sec-edgar}
}