Claude for financial services: four workflows, and where to stop
Everything below runs in the claude.ai browser window. No API, no core integration, and nothing your core provider has to approve, because none of it touches a system of record. Four back office jobs a 150 person institution does every month, with the exact prompts, plus the three places I tell banks and lenders to keep Claude out entirely. Anthropic's own Usage Policy puts finance in its high risk category, which means a qualified person reviews the output before it is final and your institution owns whether it is right. That is the frame for all four workflows, not a footnote at the bottom.
1 of 4 · about 25 min to set up
Turn an approved policy into a procedure the branch will follow
Today
The board approves a revised policy in March. A forty page document goes out by email with a note asking everyone to read it. In June a branch is still doing it the old way, because nobody translated the policy into what a specific person does on a specific Tuesday.
With Claude
The same policy comes back as a one page procedure written by role: numbered steps in the order they happen, the point where it goes to a supervisor, what has to be documented, and what gets escalated. Every place the policy is silent is listed as a question for the policy owner instead of quietly filled in.
Paste this into claude.ai
You are helping the operations lead at a [community bank / credit union / mortgage lender] with about [number] employees turn an approved policy into a working procedure. No customer information goes into this task. Do not paste account data, loan files, examination reports, or examiner correspondence.
Policy text, pasted exactly as approved:
[paste the policy language, or the section you are rewriting]
Who performs this work: [for example branch tellers, a two person deposit operations team, and a supervisor]
Systems they use while doing it: [name them generically]
What goes wrong today: [what people actually get wrong or skip]
Absolute rules:
- Use only the policy text I gave you. Never state what a law or regulation requires, permits, or prohibits, and never add a threshold, dollar amount, timeframe, retention period, or form name that is not in my text.
- Where the policy is silent or contradicts itself, do not resolve it. Write [POLICY OWNER: the specific question] and move on.
- Do not soften or expand a requirement. If the policy says something must happen, the procedure says must.
Produce, in this order:
1. The procedure as numbered steps in the order they happen, each step naming the role who performs it.
2. Decision points as if and then lines, with the step that follows each branch.
3. What has to be documented at each step, and where it is recorded.
4. What gets escalated, to whom, and when.
5. Every open question from the rule above, gathered into one list.
6. One line naming who must review and approve this procedure before it is issued.
One page. Short sentences. Write it for the person doing the work, not for the examiner reading about it later.
2 of 4 · about 20 min to set up
Draft the first pass of a routine customer explanation letter
Today
The same five questions arrive every week: why the escrow payment changed, why the deposit is held until Thursday, what the maturity notice means. One operations manager writes a clear answer. Everyone else forwards a form nobody understands or writes something compliance has to rewrite.
With Claude
You paste the facts and the outcome a person here already decided, and get a plain English letter that uses your figures untouched, never states what a regulation entitles the customer to, and gathers every judgment call in one list for whoever signs it.
Paste this into claude.ai
You are drafting the first pass of a routine written explanation to a customer of a [community bank / credit union / lender]. A qualified person here reviews, corrects, and signs it before it goes anywhere.
De-identify before you paste. No name, no account or card number, no Social Security or taxpayer number, no date of birth, no address. Call the customer [customer] and include only what is needed to explain the situation.
What the customer asked, or what happened: [describe it generically]
The outcome a person here has already decided: [state it plainly]
The figures and dates involved, copied exactly:
[paste them]
Who the reader is: [for example a small business owner, or an older accountholder who banks in the branch]
Absolute rules:
- Copy every figure and date exactly as I gave it. Never calculate, total, round, annualize, or infer a number.
- Never state what a regulation requires, prohibits, or entitles the customer to. If the letter seems to need that, write [REVIEWER: does our disclosure language belong here] instead.
- Add no fact, reason, or next step that is not above. Do not restate or soften the outcome, and do not apologize on the institution's behalf.
- This letter explains something already decided. It does not decide anything, and it does not evaluate credit, eligibility, or creditworthiness. If what I pasted looks like a credit decision, stop and say so.
- Where a judgment only a qualified person can make is needed, write [REVIEWER: the specific question].
Under 300 words, plain English, explaining any banking term the first time it appears in one short clause. Structure it as: what happened, what it means for the customer in practical terms, what happens next and by when, and who to call with a question. Then list every [REVIEWER: ...] item separately so the person signing sees them in one place.
3 of 4 · about 20 min to set up
Put eight branches of monthly reporting into one house format
Today
Eight branch managers write their monthly commentary eight different ways. The operations director spends the night before the board packet rewriting all of it into one voice, and half the variances still arrive with no explanation attached.
With Claude
Every submission comes back in the same house format with the figures copied exactly as sent, the missing lines named as missing, and a short set of questions to send back to the branch that owes you an explanation.
Paste this into claude.ai
You are helping the operations director at a [community bank / credit union] with [number] locations put branch level monthly reporting into one house format.
Paste aggregated figures only. No customer names, no account numbers, no loan level detail. If a branch narrative names a customer, remove the name before you paste it.
The house format every submission should follow:
[paste your template, or the section headings you use in the board packet]
This month's submissions, exactly as each branch sent them:
[paste them, labeled Branch A, Branch B, and so on]
Prior period figures, if you want them referenced:
[paste, or leave blank]
Absolute rules:
- Copy every figure exactly as submitted. Never calculate, total, average, annualize, or derive a percentage or a variance, even when the arithmetic looks obvious. If I did not give you a number, do not produce one.
- If a branch left a line out, write "not reported" and list it in the gaps section. Never fill it in from another branch or from the prior period.
- Never explain a variance I have not explained. A figure with no reason attached becomes a question, not an interpretation.
- Keep each branch's own wording where they gave an explanation, and mark anything you tightened for length.
Produce:
1. One section per branch in the house format, same headings, same order, figures unchanged.
2. A gaps list: every missing line, by branch.
3. Follow up questions grouped by branch, three per branch at most, specific enough to answer in a sentence.
4. A list of places where branches use the same word to mean different things, so we can agree on one definition.
Do not write commentary on performance or outlook. That belongs to the person who owns the packet.
4 of 4 · about 30 min to set up
Prepare the narrative for a recurring audit or exam request
Today
The request list lands with sixty items. Six owners write six paragraphs from scratch at six levels of quality, internal audit comes back with follow ups on the vague ones, and the same scramble repeats next quarter.
With Claude
Every item comes back in the same five fields: what the control is, who performs it, how often, what evidence exists and where it lives, and what is genuinely missing. You find the holes at your desk in July rather than in the meeting.
Paste this into claude.ai
You are helping a [community bank / credit union / lender] prepare written responses for a recurring internal audit or examination request list. You are organizing what we already know. You are not asserting that anything is compliant.
Do not paste examination reports, examiner correspondence, draft or final findings, or any other confidential supervisory information. Those records belong to your regulator and disclosure to third parties is restricted. Do not paste customer records. Describe the control in your own words.
The request, in the requester's words:
[paste the item or items from the request list]
What the control actually is, in my words:
[who does what, how often, in what system]
Evidence I know exists: [reports, logs, checklists, tickets, minutes, and where each one lives]
What I already know is thin or missing: [state it, or leave blank]
Absolute rules:
- Use only what I told you. Never assert that a control exists, operates as designed, is effective, or satisfies a requirement. Never name a regulation, citation, or standard I did not give you.
- Where I have not identified evidence, write "no evidence identified" rather than describing evidence that would make sense. That gap is the reason we are doing this now.
- Where the response would state a conclusion only compliance or internal audit can state, write [COMPLIANCE: the specific question] instead of stating it.
For each item, produce the same five fields: the request restated in one line, what the control is, who performs it and how often, the evidence and where it lives, and what is missing or unclear.
Then produce two lists: every item with no evidence identified, ordered by how exposed it leaves us, and the questions to send back to the requester where the ask itself is ambiguous.
Plain language, no adjectives, nothing that reads as an assurance.
What to skip for now
×Customer records and identifiers do not go into a chat window, in any account. That means account and card numbers, full Social Security and taxpayer numbers, dates of birth, online banking credentials, signature cards, core exports, wire instructions, loan files carrying borrower income and asset documents, and credit reports and scores. Two reasons, and they are separate. First, this is nonpublic personal information: Regulation P limits disclosure of it to nonaffiliated third parties and limits reuse, and the security standards your regulator enforces expect a written program and real diligence over any third party that touches customer information, which is exactly what the interagency third party risk guidance the OCC, Federal Reserve, and FDIC issued in June 2023 covers for banks of every size, community banks included. Credit unions get the same questions from NCUA. Second, a consumer report was pulled for a permissible purpose under FCRA, which allows a report to be furnished for listed purposes and no others, and pasting a tri merge into a chat is a use nobody documented. Work at the policy and summary level, paste the language and not the file, and settle the account and vendor question with whoever owns compliance before anything live moves.
×Nothing that touches a credit decision. Not approving, denying, pricing, risk grading, granting an exception, working out debt to income or a coverage ratio that feeds the decision, and above all not drafting the specific reasons on an adverse action notice. Regulation B requires the statement of reasons to be specific, to indicate the principal reasons, and to relate to and accurately describe the factors actually considered, and CFPB Circular 2022-03 says plainly that a creditor may not use a model when doing so means it cannot give specific and accurate reasons, and that not understanding your own method is not a defense. A paragraph that reads like a reason but was not the reason is a violation with your institution's name on it, with fair lending exposure underneath. Anthropic's Usage Policy points the same way: loan approvals and determining eligibility or creditworthiness are named high risk, and home loans are named again under housing. The decision, the reasons, and the notice belong to your lender, your credit committee, and your written credit policy.
×Suspicious activity reporting, and anything that would reach a customer as advice. A SAR, and any information that would reveal the existence of a SAR, is confidential under 31 CFR 1020.320(e), and no bank and no director, officer, employee, or agent of a bank may disclose it, so the narrative does not get drafted, polished, or rehearsed in a chat window, and neither does the alert that led to it. Examination reports and examiner correspondence stay out for a related reason: they are your regulator's records, not yours to hand to a third party. On the advisory side, Claude holds no registration and no license. No recommendation, no allocation, no security selection, no suitability or best interest conclusion, and nothing that reads to a client as investment advice. If your firm is a registered investment adviser or a broker dealer, your advertising, review, and recordkeeping obligations attach to whatever goes out, and a chat transcript is not part of your retention system.
Want all 4 workflows for banks and financial services firms in your inbox?
Every prompt on this page plus the rest, so you still have them on Monday. One email, then four short ones on making it stick. Unsubscribe any time.
Questions people ask before they try any of this
Straight answers with the sources linked, so you can forward them to whoever has to sign off.
Want this worked out for your own banks and financial services firm?
Answer three quick questions and Claude writes three automations for your specific situation, with the prompts.
How many people work there?
Common questions
Can we put loan files or customer account data into Claude?
No, and the reason is not only privacy. Customer information is nonpublic personal information under GLBA and Regulation P, and your examiner will ask who approved the tool, what data goes into it, and what diligence you did on the vendor before anyone used it. If nobody can answer, the answer becomes a finding. On Free, Pro, and Max plans whether your chats are used to improve Claude is a setting you control in Privacy Settings, while Team, Enterprise, and Claude for Work inputs are excluded from model training by default, and that difference matters to the person who has to write the risk assessment. The workable path is the one in all four workflows above: de-identify first, paste the language or the figures rather than the file, keep policies and procedures and aggregated reporting as the material, and get your compliance officer's written sign off on the account and the use before live customer material is ever in scope.
Does Anthropic's own policy allow a bank to use Claude?
Yes, with conditions it states directly. The Usage Policy effective September 15, 2025 lists Finance as a high risk use case, described as use cases related to financial decisions including investment advice, loan approvals, and determining financial eligibility or creditworthiness. For high risk use cases it requires two things. Human in the loop: when the output is advice, a recommendation, or subjective decision making directly affecting individuals or consumers, a qualified professional in that field must review it before it is disseminated or finalized, and you and your organization are responsible for the accuracy and appropriateness of what goes out. Disclosure: if model outputs are presented directly to individuals or consumers, you must tell them you are using AI to help produce your advice, decisions, or recommendations, at a minimum at the beginning of each session. Read that second requirement with your compliance officer rather than assuming it does or does not reach your customer letters, because how your institution presents the output decides it.
What is our examiner going to ask about this?
Honestly, that depends on your charter, your primary regulator, your risk profile, and the examiner in the chair, so treat anything anyone tells you as a general expectation and not as an answer for your exam. The questions do tend to rhyme: what the tool is, who approved it, what information goes into it, what your written policy says employees may and may not do with it, who has been trained, what third party diligence you performed, and where the record shows a qualified person reviewed output that reached a customer. One distinction is worth getting right early. A general purpose drafting tool used on de-identified internal documents is a different conversation from a model used in decisions about people, and the second one puts you in model risk and fair lending territory with everything that follows. Ask your compliance officer and counsel to write the position down before rollout, and raise it with your examiner at a routine contact rather than waiting to be asked.
Do we need Team or Enterprise, and where should a 150 person institution start?
Test on a free account, which supports up to five Projects, project instructions, and project knowledge, then move to Team or Enterprise before anything close to real work, because commercial inputs are excluded from model training by default and a Project can be shared and governed rather than living in one person's personal login. Paid plans also buy higher usage limits and expanded project knowledge through retrieval once your uploaded material outgrows the context window. Start narrow. Write the one page internal rule first, naming what may go in and what never does, then build a single Project for procedure rewrites: load your procedure template, your style rules, and one procedure you already consider good, and run the first workflow on a policy with no customer data in it for two weeks. The side benefit is worth naming. A new operations hire drafting inside that Project is working against your written standard instead of guessing at it, which is the same reason the procedure was worth rewriting.