A compliance agent can pull up the right rule, quote the right line, and still be wrong in the way that matters. Everyone says these agents need better context. Getting a model to say something about a regulation is easy; the hard part is whether the context behind that answer holds up when a compliance officer checks it.
That’s hard because a banking rule is rarely one document. The obligation might start in a statute, get written into the CFR, explained in agency guidance, tested in an exam manual, narrowed by a state rule, and narrowed again by a company’s own policies and controls. So good context isn’t more text. It’s knowing how the sources connect, which ones apply to this business, and how to trace each one back to the law.
That’s why we built an LLM wiki for banking compliance. It’s the core that powers RegLyr, our regulatory graph: a focused layer of context that shows an agent how the rules fit together before it answers, screens, drafts, or recommends.
What an LLM wiki is
An LLM wiki is a set of plain markdown pages that the model itself reads, writes, and keeps current, each one covering a single thing and linked to the pages around it. The idea comes from Andrej Karpathy, who described it in April: instead of searching a pile of documents fresh on every question, you keep the wiki and feed that.
The point is that this knowledge compounds. The links are already drawn, the contradictions already flagged; every new source sharpens the whole thing instead of rebuilding it from scratch. The model handles the upkeep that usually gets a wiki abandoned. You just decide what goes in and what to ask.
What this means for compliance
It’s a great fit for compliance in banking, because compliance questions are usually about an activity, and every answer depends on how a stack of sources fit together.
Take an agent reviewing an adverse action notice. It doesn’t just need Regulation B. It might need the statute behind it, the rule that implements it, the FCRA overlap, what an examiner expects, and enough about the business to know if the issue even applies. A normal search tool finds some of that, but it can’t tell the agent what each source is doing: which one creates the obligation, which sets the timing, which spells out examiner expectations, which only applies to a certain product, company type, or state.
And a rule isn’t useful until the system knows where it applies. SAR filing doesn’t apply like TILA disclosures or HMDA reporting. Some rules cover the whole company; some kick in only for a product or activity; some depend on the state or a dollar threshold. So each page carries the conditions too: company type, product, activity, jurisdiction, thresholds.
When an agent reviews a workflow, it shouldn’t start from every rule on the books. It starts from the part of the map that fits this company, this activity, this situation. That changes the question from “what text looks like this prompt?” to “what rules actually govern this workflow?” In compliance, that’s the difference between an answer that sounds right and one that holds up.
Inside a wiki
A wiki page is a readable slice of the regulatory graph, narrowed to one activity. Each one covers a single compliance activity (adverse action notices, SAR filing, EFT error resolution, debt collection messages, marketing review, HMDA reporting), and to earn its place it has to do three things: keep the chain of authority straight, show how the layers interact, and stay tied to the actual documents so every claim points back to its source.
Here’s the page for adverse action notices on a credit decision:
# Adverse Action Notices for Credit Decisions
**Domain:** fair-lending-cra
**Sources:** comps-260-consumer-credit-protection, ecfr-title12-part1002, cfpb-exam-ecoa
**Synthesized:** 2026-05-31
---
## Authority Chain
### Statute — 15 U.S.C. § 1691(d) / Equal Credit Opportunity Act [comps-260-...]
ECOA requires creditors to give a statement of reasons for adverse action, or
disclose the applicant's right to request those reasons. This is the statutory
basis later implemented in Regulation B.
> **Verbatim — 15 U.S.C. § 1691(d):**
> "Each applicant against whom adverse action is taken shall be entitled to a
> statement of reasons for such action from the creditor..."
### Regulation — 12 C.F.R. § 1002.9 [ecfr-title12-part1002]
Regulation B makes the notice mechanics operative: notify within 30 days, in
writing, with the action taken, the ECOA notice, the Federal regulator, and
either specific reasons or the right to request them...
### Examination Handbook — CFPB Exam Manual, ECOA [cfpb-exam-ecoa]
Examiners test whether notice workflows actually meet Reg B's timing and
content rules...
## Who this applies to
Any creditor under Regulation B — all depository charter types, mortgage
lenders, finance companies, and fintechs that extend credit. No product gate
applies; the duty turns on taking adverse action, not on the product...
## Clarifications
### specific-reasons
- **Ambiguity:** Is "did not meet underwriting standards" specific enough?
- **Resolved by:** 12 C.F.R. § 1002.9(b)(2)
- **Practical:** The notice must give the principal, specific reasons; generic
references to internal standards or a failing score are not compliant.The authority chain steps down the layers in order: the ECOA statute that creates the duty, Regulation B that sets the 30-day timing and required content, and the CFPB exam manual that shows how an examiner tests it. Each layer gets a plain read plus the verbatim source text, so nothing drifts from the words on the page. “Who this applies to” names who’s covered; “Clarifications” takes the questions that trip people up and gives the rule that settles each one.
Every page follows that shape, and none ships without at least two layers of authority, so a lone statute with no implementing rule isn’t enough. Today the wiki runs to a few hundred pages, one per activity, often split by institution type so a national bank and a broker-dealer each get the version that fits. The agent gets context it can work with; the compliance team gets something it can check.
We run this in-house. Our compliance agents read the wiki before they work, so they start from the right map instead of hunting for it. In our own evaluations that cut tool calls by roughly 50% while holding the same 90%+ accuracy bar: fewer round trips through the raw regulations, the same quality of answer, because the context was already sorted.
The challenge
The biggest challenge is keeping all of this correct. A generated layer like this can drift: a page can cover too much, miss a source, overstate guidance, or apply a rule to the wrong kind of business, and sound confident in exactly the way a reviewer learns not to trust.
So we keep the format tight: sources listed, authority chain spelled out, conditions explicit, one place to update when a rule changes. But a few hundred pages is more than any team can hand-check every time a rule moves, so we built a linting agent that reviews every page: whether the sources still hold, whether each claim traces back, whether the applicability is right. Experts calibrate that linter. They review a sample, decide what correct looks like, and tune the agent until its judgment matches theirs. Then it runs across the whole wiki and catches drift before it reaches a compliance agent.
It’s the lesson we keep hitting with compliance AI: the model isn’t the whole system. It can draft, search, and reason over evidence, but the answer is only as good as what’s around it. Agents don’t need every regulation in the prompt. They need the right map before they act.