Anthropic's Financial Services Reference Repo: Building Production AI for Finance

The anthropics/financial-services repository is an open-source reference implementation published by Anthropic. ^{[anthropics/financial-services — GitHub]} It is not a product, a managed service, or a model. It is a collection of working code patterns that show developers how to integrate Claude into financial-sector applications — the kind of applications where a wrong number, an unattributed claim, or a missing disclosure can carry regulatory and legal consequences.

Think of it as an opinionated starter kit that already handles the hard parts: connecting Claude to live data sources, keeping answers within regulatory guardrails, producing auditable tool-call chains, and structuring outputs that downstream systems can parse reliably.

The most important pattern the repository demonstrates is function calling (also called tool use). Here is why it matters.

Claude, like every LLM, has a training data cutoff. It does not know today’s stock prices, your portfolio’s current composition, your firm’s proprietary risk metrics, or last quarter’s earnings. If you ask it these questions without tool use, it guesses — and guessing about financial data is dangerous.

Tool use changes this. You register a set of functions with the Claude API. When Claude determines it needs live data to answer the question honestly, it returns a structured function call instead of a prose answer. Your backend executes that function, returns the result, and Claude synthesises the final answer grounded in real data.

Every regulated financial institution operates under a web of rules: MiFID II ↗ in Europe, FINRA and SEC regulations in the US, and internal compliance policies layered on top. The reference repo shows how to encode these constraints into the system prompt and output structure so Claude’s behaviour stays within the regulatory envelope by default. ^{[FINRA Report on Artificial Intelligence (AI) in the Securities Industry (2020)]}

The three main mechanisms are:

1. System-prompt constraints — Instructions that prevent Claude from offering personalised investment advice (a licensed activity), speculating on future prices, or omitting legally required disclosures. These are encoded as explicit rules, not relied upon from model training.

2. Structured output schemas — Financial reports and compliance-sensitive responses are generated as typed JSON that downstream systems can validate. If Claude attempts to produce an invalid field (say, a fabricated ISIN number), the schema catches it before it reaches the user.

3. Retrieval grounding — Answers are required to cite source passages. Claude is instructed to refuse to make claims it cannot ground in the provided documents. This dramatically reduces the hallucination surface.

The trade-off is real: more constraint means more guardrails to maintain, more tokens in the system prompt, and slightly higher latency. The widget below lets you explore this directly.

Retrieval-Augmented Generation (RAG) is the pattern that lets Claude answer questions grounded in your firm’s proprietary documents — 10-K filings, earnings call transcripts, internal research, compliance manuals — without those documents ever being used to train the model or leaving your infrastructure. ^{[anthropics/financial-services — GitHub]}

The pipeline has six stages:

flowchart LR
  Q[User query] --> E[Embed query]
  E --> V[Vector search
corpus]
  V --> R[Rerank
passages]
  R --> A[Augment
prompt]
  A --> G[Claude
generates]
  G --> ANS[Cited answer]
  style G fill:#1d4ed8,color:#fff
  style ANS fill:#166534,color:#fff

The key insight is that Claude never needs to be fine-tuned on your documents. The documents stay in your vector store. Claude only ever sees the top-k most relevant passages for the specific question being asked — nothing more. This is crucial for firms handling non-public information: the model never ingests MNPI, it only reads what your retrieval layer decides to surface.

The reference implementation is the right starting point when:

• You are building a Claude-powered feature for a regulated financial institution.
• Your use case involves live or proprietary data (not just reasoning over public knowledge).
• You need a structured audit trail for compliance purposes.
• Your output will be consumed by downstream systems that need typed, validated data.

It is overkill or the wrong fit when:

• You are building an internal, low-stakes productivity tool (document summariser for internal memos, meeting note taker) where hallucination consequences are low and regulatory scrutiny is absent.
• Your primary use case is reasoning over well-known public information (explaining a concept, answering general economics questions) where grounding is not required.
• You need a rapid prototype to test if Claude can understand your domain — use the raw API first, then layer in the reference patterns once you’re confident.