Agentic Banking Foundations
A practical, self-paced course for financial institution professionals. What agentic AI is, how it works inside a regulated institution, how it can be attacked, and how to put it to work without losing control.
Who this is for
This course is built for staff in every function of a financial institution. Whether you sit in frontline service, lending, compliance, operations, marketing, or technology, you'll leave able to reason about agentic AI and sketch a real use case for your institution.
Understand what an agent can safely handle and where a human stays in the loop.
See how agents compress multi-step manual workflows into minutes.
Learn the governance and security scaffolding regulators expect around AI.
Build the vocabulary to set an AI direction you can own.
How the course works
Each module follows the same rhythm: learn the concept, see it grounded in a real banking example, then build something (a prompt, a workflow, a policy, a threat model). You can't outsource your AI strategy, so this course is designed around doing, not watching.
- Read the module and the learning objectives at the top.
- Work the hands-on build, short exercises you can do on paper or in any AI chat tool.
- Pass the knowledge check at the end of each module.
- Finish with a capstone project: an agentic use case scoped to your own institution.
This is an educational course first. The concepts apply to any agentic AI platform. Where it helps to show a concept working end-to-end, we use Dan who is our very own AI banking assistant as a working example. Look for the green "Dan in action" boxes.
Your progress saves automatically. Pick up where you left off on any device.
From Rules to Agents: How AI Evolved in Community Finance
By the end you'll be able to
- Trace the four eras of banking automation: rule-based, machine learning, generative, and agentic.
- Explain what makes an "agent" different from a chatbot or a script.
- Spot where your institution still runs on brittle, hard-coded rules.
The four eras, in plain terms
Financial institutions have automated work for decades. What's changed is how much judgment the software can carry. Each era handed off a little more of the thinking.
| Era | How it decides | Banking example | Limit |
|---|---|---|---|
| Rule-based (1980s-2010s) | Humans write every "if this, then that" | IVR phone trees, decision tables for fee waivers | Breaks the moment reality doesn't match the rule |
| Machine learning (2010s) | Learns patterns from historical data | Fraud scoring, churn prediction, credit models | Predicts, but can't converse or act on its own |
| Generative AI (2022-) | Produces language from a prompt | Drafting a member email, summarizing a call | Talks well, but doesn't do anything in your systems |
| Agentic AI (now) | Plans steps, calls tools, and takes action toward a goal | Resolving a disputed transaction end-to-end, with approvals | Needs governance because it can act, so it must be bounded |
The leap that matters: from talking to doing
A generative chatbot can tell a member how to dispute a charge. An agent can actually open the dispute: look up the transaction, check eligibility, file the case in the core, send the confirmation, and flag anything unusual for a human, all while leaving an audit trail. The difference isn't smarter language. It's the ability to plan a sequence of steps and use tools to complete a task.
Dan is an agentic banking assistant. For this example he is deployed at Durango B&T, the bank configured Dan as the primary interface where members bank by talking to an agent that the bank authorized to move money, answer balance questions, and handle routine servicing, rather than navigating menus. The bank controls every action Dan is allowed to take.
Pick one task you or a teammate does manually that follows a repeatable pattern (e.g., address change, travel notice, payoff quote). Write it out:
- List every step, including the systems you touch.
- Mark each step R (pure rule), J (needs judgment), or A (could be automated by an agent today).
- Count the A's. That ratio is your agentic opportunity for this workflow.
Keep this. You'll reuse it in the capstone.
Knowledge check
1. What most distinguishes an agentic system from a generative chatbot?
It uses more training dataIt writes in a friendlier toneIt can plan steps and take actions using tools, not just produce textIt runs entirely on-premise2. A traditional IVR phone tree is an example of which era?
Machine learningRule-based automationGenerative AIAgentic AI3. Why does the agentic era specifically demand governance?
Because it is more expensiveBecause members prefer humansBecause it only works onlineBecause it can take real actions, so it must be bounded and auditableWhat Is Agentic Banking?
By the end you'll be able to
- Define an AI agent using its four parts: goal, reasoning, tools, and memory.
- Distinguish "assistive" AI from "agentic" AI by who does the work.
- Describe what "agentic banking" looks like from a member's seat.
Anatomy of an agent
Strip away the hype and an agent is four moving parts working in a loop:
What it's trying to accomplish: "help this member resolve a late fee," not "answer questions."
The model that decides the next step, interprets messy input, and handles exceptions.
The actions it can take: query the core, post a note, send an SMS, open a ticket. (Module 4.)
Context it carries: who the member is, what's been tried, the institution's policies.
The loop is simple: understand → plan → act → check → repeat, until the goal is met or it hits a boundary that requires a human.
Assistive vs. agentic: who's holding the pen?
| Assistive AI | Agentic AI | |
|---|---|---|
| Who acts | The staff member, helped by AI | The agent acts, within limits |
| Example | AI suggests a reply for an agent to send | AI handles the full request and escalates exceptions |
| Staff role | Operator | Supervisor & exception handler |
| Scales by | Hiring more people | Adding capacity without adding headcount |
What "agentic banking" feels like
Agentic banking is what you get when agents move from behind the glass (helping staff) to the front door (serving members directly), with the institution still in control of policy, limits, and oversight. The member experience shifts from "navigate the app" to "tell the bank what you need."
This is the reframe at the heart of the category: instead of bolting an AI feature onto banking, the agent becomes the way you bank, answering in seconds, taking action, available any hour, and handing off to a human the moment judgment or empathy is required.
With Dan, a member can ask "did my paycheck land, and can you move $200 to savings?" The institution has already decided whether Dan is authorized to make that transfer, what the dollar limits are, and when it must defer to staff. If the bank allows it, Dan checks the balance, confirms the deposit, and completes the transfer. Members get a ten-second answer; the institution gets capacity back.
Take the workflow you documented in Module 1 and fill in the four parts:
- Goal: one sentence, member-outcome framed.
- Reasoning: what's the hardest judgment call in this task?
- Tools: which systems must it touch to finish the job?
- Memory: what does it need to know about the member or your policies?
Knowledge check
1. Which is not one of the four parts of an agent?
GoalReasoningMarketing budgetTools2. In an agentic model, the staff member's role shifts toward being a...
Faster typistSupervisor and exception handlerData entry clerkCall router3. The "agentic banking" reframe means...
The agent becomes a new way to bank, with the institution always in controlAll human staff are replacedAI only writes marketing copyMembers must learn to codePrompting & Behavior Control
By the end you'll be able to
- Write a clear instruction (prompt) that controls an agent's behavior.
- Use role, task, constraints, and examples to shape reliable output.
- Set guardrails so an agent knows what it must not do.
Prompting is policy, written in plain English
In an agentic system, the prompt is where you encode how the institution wants the agent to behave: its tone, its limits, when to escalate. You don't need to code. You need to be specific. A vague instruction produces a vague, unpredictable agent.
A reliable prompt has four ingredients
- Role: who the agent is. "You are a member-service assistant for a financial institution."
- Task: the specific job and the goal. "Help members report a lost debit card and order a replacement."
- Constraints: the rules and limits. "Never share full card numbers. Verify identity first. Escalate suspected fraud to a human."
- Examples: show one good interaction so the agent matches your standard.
Vague vs. controlled
# Weak - unpredictable "Help members with card problems." # Strong - controlled behavior Role: You are a member-service assistant for River Valley CU. Task: Help members report a lost/stolen debit card and order a replacement. Constraints: - Verify identity with 2 factors before any action. - Never read back full card or SSN digits. - If the member reports unauthorized charges, open a fraud case and hand off to a human within the conversation. - Keep replies under 4 sentences, warm and plain-spoken. Example: Member: "I lost my card at the airport." Assistant: "I'm sorry - let's lock it right now. First, can you confirm your date of birth and the last transaction you recognize?"
Guardrails in the prompt are your first line of defense. Spell out the "never" list explicitly: never disclose sensitive data, never make promises about rates or approvals, never act above a set dollar limit, always escalate the defined exceptions. But as Module 6 will show, prompt-level rules alone are not enough. The real limits must also live in your infrastructure.
An institution deploying Dan configures its behavior in language like the above (tone, verification rules, escalation triggers, and dollar thresholds) rather than writing software. Compliance and operations can read the agent's instructions in plain English and sign off on them, which is hard to do with traditional code.
Open any AI chat tool (or do this on paper). For the use case you've been developing, write a full prompt with all four ingredients. Then try to break it: ask it something out of scope and see if your constraints hold. Tighten the "never" list based on what slips through.
Knowledge check
1. Which four ingredients make a prompt reliable?
Length, speed, color, fontBudget, vendor, deadline, ownerName, logo, slogan, toneRole, task, constraints, examples2. In an agentic system, the prompt is best thought of as...
Policy written in plain EnglishA marketing taglineOptional documentationThe customer or end user's input3. A "never" list in a prompt primarily exists to...
Make the agent fasterReduce server costsControl behavior and reduce riskImprove the agent's vocabularyActions & Approvals
By the end you'll be able to
- Explain why an agent's ability to take real actions is what separates it from a chatbot.
- Walk through the steps an agent follows to handle a real banking task.
- Decide which actions should require human approval before the agent proceeds.
Actions are how an agent gets things done
On its own, AI only produces words. What makes it an agent is the ability to take actions: looking up an account, moving money, sending a confirmation, opening a case. Each action is defined and permissioned by the institution. The agent decides when to use one, and your rules decide whether it's allowed to.
An agent workflow, step by step
Take a real task: a member disputes a $48 charge. Here's how an agent works through it:
- Verify the member's identity by confirming who's asking before anything else.
- Pull up recent transactions to find the charge in question.
- Check dispute eligibility by applying the rules: timing, amount, merchant type.
- File the dispute - open the case in the core system. requires approval if > $500
- Notify the member by sending confirmation and the provisional-credit timeline.
- Flag for human review if the pattern looks like fraud, route to staff.
Notice the pattern: looking things up is low-risk and happens automatically. Actions that move money or change records sit behind limits and approvals.
A useful mental model: look-up actions (check a balance, pull transaction history) are low-risk and can run on their own. Change actions (transfer funds, update a rate, close an account) are high-risk and should carry limits, logging, and above a threshold, a human approval step. Your institution decides these boundaries action by action, not agent by agent.
Dan connects to an institution's core and servicing systems through a permissioned action layer. The bank defines every action Dan can take and sets the limits. For example, the bank might authorize transfers up to a certain dollar amount, but require staff approval for anything above that threshold or anything flagged as risky. Every action is logged, which is what makes governance (Module 5) and security (Module 6) practical rather than theoretical.
For your use case, list the actions the agent would need to complete the task, in order. For each one, ask: is this a look-up or a change? For every change action, write the rule: "automatic up to $___; requires approval above $___." You've now designed a workflow with built-in controls.
Knowledge check
1. An agent's ability to take actions is what lets it...
Write longer paragraphsActually do things in your systems, not just talk about themRun without electricityTranslate languages2. Which action most needs a human approval step?
Looking up a balancePulling transaction historyTransferring funds above a set limitAnswering a FAQ questionGovernance, Risk & Policy in Regulated Environments
By the end you'll be able to
- Name the core controls regulators expect around AI: oversight, auditability, and risk management.
- Apply a human-in-the-loop model to high-stakes actions.
- Draft the skeleton of an AI use policy for your institution.
Why governance is the whole game in banking
In most industries, an AI mistake is an inconvenience. In a regulated financial institution, it can be a compliance event. That's why agentic AI in banking lives or dies on governance, and why supervisors are paying attention.
The five controls every agentic deployment needs
| Control | What it means | How it shows up |
|---|---|---|
| Oversight | A human owns the agent's outcomes | Named owner, defined escalation paths |
| Human-in-the-loop | People approve high-stakes actions | Approval gates on change actions, dollar thresholds |
| Auditability | Every action is logged and reviewable | Immutable logs of prompts, actions, and decisions |
| Risk management | You assess and monitor what can go wrong | Model risk review, testing, ongoing monitoring |
| Data & privacy | Member data is protected and scoped | Access limits, retention rules, no leakage of PII |
The human-in-the-loop spectrum
Not every action needs a human, and demanding approval for everything kills the value. Calibrate by risk:
Low-risk reads: balance lookups, FAQ answers. Agent acts, logs it, moves on.
Medium risk: agent acts but a person monitors and can intervene/reverse.
High risk: agent prepares, a person approves before it executes.
Reserved judgment: hardship, complex disputes, anything legally sensitive.
Because every Dan action runs through a permissioned, logged action layer (Module 4), the governance controls above aren't bolted on afterward. They're how the system is wired. Institutions can show an examiner exactly what the agent was instructed to do, what it actually did, and where a human signed off. Payman maintains SOC 2 certification to back this with independent assurance.
For your use case, write a short policy covering: (1) who owns it, (2) what the agent may do autonomously, (3) what requires approval and from whom, (4) how actions are logged and reviewed, (5) how member data is protected. One page. This is the artifact your compliance team will actually want to see.
Knowledge check
1. Why is governance especially critical for AI in banking?
It makes the agent fasterIt improves the user interfaceMistakes can become compliance events, and supervisors expect controlsIt reduces electricity use2. "Human-in-the-loop" specifically means...
A human writes all the codeA person approves a high-stakes action before it executesNo AI is used at allThe agent monitors the human3. Which control gives an examiner confidence the agent is accountable?
Immutable audit logs of every prompt, action, and decisionA nicer color schemeMore marketingFaster response timeHow AI Breaks: Safety & Attack Scenarios
By the end you'll be able to
- Explain the core reason agentic AI introduces new attack surfaces in banking.
- Recognize the nine vulnerability classes your security team may not be testing for.
- Apply the right infrastructure-level guardrail to each class.
The vulnerability hiding in plain sight
An agent that can act is an agent that can be manipulated into acting. The single most important idea in AI security is this:
An AI cannot reliably tell the difference between content and instructions. Anything it reads - an invoice, an email, a chat message, a document - can try to give it orders. Untrusted input gets treated as trusted context.
That's why prompt-level rules (Module 3) are necessary but not sufficient. The real defenses have to live in the infrastructure: verification, separation of duties, and hard limits the model cannot talk its way around.
Anatomy of an AI banking attack
- The setup: what the AI system does and what rules it has.
- The attack: the step-by-step manipulation.
- Why it worked: the assumption the attacker exploited.
- Proper guardrails: the infrastructure control that stops it.
- The takeaway: the durable principle.
Worked scenario: The Poisoned Invoice Indirect Prompt Injection
A corporate banking AI processes incoming invoices: it reads PDFs, extracts details, and queues payments. Its rules: only pay known vendors, flag large amounts for review, extract payment details from invoices.
- A legitimate-looking PDF invoice arrives from a known vendor with normal billing details.
- Hidden in the document is text crafted to read as instructions to the AI, not invoice data.
- The AI extracts payment details, but the embedded text redirects the payment to a new account.
- The vendor name still matches an approved vendor, so the rule check passes. Payment is queued.
The AI couldn't distinguish content from instructions. The invoice was untrusted input treated as trusted context. The hardcoded rule checked the vendor name (legitimate) but not whether the payment details matched stored vendor records.
Payment details are verified against stored vendor records at the infrastructure level. Account changes require out-of-band confirmation. The AI extracts and suggests payment details but cannot update vendor records or execute payments unilaterally.
Takeaway: Untrusted input should never be treated as executable instructions. Separate extraction from execution.
The nine vulnerability classes
| Scenario | Vulnerability class | Guardrail principle |
|---|---|---|
| The Poisoned Invoice | Indirect prompt injection | Treat input as data, never instructions; separate extraction from execution |
| The Policy Loophole | Natural-language policy exploitation | Enforce limits in infrastructure, not just in prompt wording |
| The Confirmation Trap | Approval-authority confusion | Bind approvals to authenticated identity; verify who actually approved |
| The Slow Boil | Multi-turn context manipulation | Evaluate cumulative actions across the whole conversation, not per message |
| The Helpful Mistake | Information disclosure | Least-privilege data access; scope and redact sensitive data |
| The Audit Ghost | Logging & accountability gaps | Immutable, tamper-evident logging of every action |
| The Vendor Impersonator | Identity spoofing | Authenticate counterparties; out-of-band verification for changes |
| The Composite Request | Aggregation of benign steps | Assess aggregate intent and downstream effect, not each step alone |
| The Deadline Play | Urgency / social engineering | Controls don't bend to claimed time pressure; verification is constant |
Explore the full interactive walkthroughs at paymanai.com/resources/ai-banking-safety.
The reason these attacks fail against a well-built platform is architecture, not luck. The bank's infrastructure enforces limits that the AI model can't override: verifying details against system-of-record data, requiring out-of-band confirmation for sensitive changes, evaluating cumulative behavior across a conversation, and logging every action immutably. Dan operates within the boundaries the bank sets, not the other way around.
Take the agent you've designed across Modules 1-5 and attack it. For at least three of the nine classes above, write:
- How an attacker (or even an honest mistake) could exploit it.
- Whether your current prompt-level rules would catch it. (Usually: no.)
- The infrastructure-level guardrail you'd add to actually stop it.
Bring this to the capstone. A use case that's been red-teamed is far more credible to your risk team.
Knowledge check
1. The root cause behind most AI banking attacks is that an AI...
Runs too slowlyCannot reliably distinguish content from instructionsUses too much memoryRefuses to follow rules2. In "The Poisoned Invoice," the key guardrail that stops the attack is...
A faster modelA friendlier toneVerifying payment details against stored records and requiring out-of-band confirmation for changesAsking the vendor to resend the PDF3. "The Deadline Play" teaches that controls should...
Stay constant regardless of claimed urgency or time pressureRelax when a request is urgentOnly apply during business hoursBe skipped for known vendorsAgentic Banking Glossary
Key terms used throughout this course and in the broader agentic AI conversation. Bookmark this page. It's the cheat sheet you'll reach for when the jargon starts flying in meetings.
Core Concepts
| Term | Definition |
|---|---|
| Agent | Software that pursues a goal by planning steps, using tools, and taking actions, not just generating text. Defined by four parts: goal, reasoning, tools, and memory. |
| Agentic AI | AI that can autonomously plan, decide, and act toward an objective within defined boundaries, as opposed to passively responding to prompts. |
| Agentic Banking | Deploying AI agents inside a regulated financial institution to autonomously execute banking operations (transactions, servicing, compliance checks) with governance and audit controls. |
| Assistive AI | AI that helps a human do their job faster (e.g., drafting a reply for a staff member to send) but doesn't act on its own. The human holds the pen. |
| Chatbot | A conversational interface that answers questions or routes requests but cannot take actions in backend systems. Talks but doesn't do. |
| Generative AI | AI that produces new content (text, images, code) from a prompt. Powerful for language tasks but lacks the ability to plan multi-step actions or use tools. |
| Large Language Model (LLM) | The neural network at the core of modern AI systems. Processes and generates human language. Becomes an agent when connected to tools and given a goal. |
Architecture & Tools
| Term | Definition |
|---|---|
| Actions | The defined, permissioned things an agent can do: looking up an account, posting a transaction, sending a notification. Each action is scoped and logged by the institution. |
| Look-up Action | An action that retrieves information without changing anything (e.g., check a balance, pull transaction history). Low-risk, typically runs automatically. |
| Change Action | An action that changes something: transferring funds, updating records, opening cases. High-risk, should carry limits, logging, and approval gates. |
| Approval Gate | A checkpoint where the agent pauses and waits for human authorization before executing a high-risk action (e.g., transfers above a dollar threshold). |
| Orchestration Layer | The system that coordinates agent reasoning, tool execution, policy enforcement, and audit logging. Sits between the LLM and the institution's core systems. |
| Core Banking System | The backend platform that manages accounts, transactions, and ledgers (e.g., FIS, Fiserv, Jack Henry, Temenos). The system of record agents connect to. |
| API (Application Programming Interface) | A structured way for software systems to communicate. Agents use APIs to call tools and interact with banking systems. |
| RAG (Retrieval-Augmented Generation) | A technique where the agent retrieves relevant documents or data before generating a response, grounding its answers in real institutional knowledge. |
Prompting & Behavior
| Term | Definition |
|---|---|
| Prompt | The instruction set that tells an agent who it is, what to do, what not to do, and how to behave. In agentic banking, the prompt is operational policy written in plain English. |
| System Prompt | The foundational instructions set by the institution (not the end user) that define the agent's role, constraints, and guardrails. |
| Constraints / "Never" List | Explicit prohibitions in the prompt, things the agent must never do (e.g., never disclose full account numbers, never act above a set dollar limit). |
| Guardrail | Any control that limits agent behavior. Prompt-level guardrails are the first line; infrastructure-level guardrails (hard limits the model can't override) are the real defense. |
| Hallucination | When an AI generates confident-sounding information that is factually incorrect. A key risk in banking where accuracy is non-negotiable. |
| Escalation | When the agent transfers a conversation or task to a human because it hit a boundary, encountered an exception, or the situation requires judgment. |
Governance & Compliance
| Term | Definition |
|---|---|
| Human-in-the-Loop (HITL) | A governance model where a person approves high-stakes actions before the agent executes them. The strictest oversight level. |
| Human-on-the-Loop | The agent acts autonomously but a person monitors in real time and can intervene or reverse. Mid-level oversight. |
| Human-out-of-the-Loop | The agent acts and logs the action. No real-time human involvement. Reserved for low-risk, read-only operations. |
| Audit Trail | An immutable, reviewable record of every action the agent took: what it was asked, what it decided, what tools it called, and the outcome. |
| Model Risk Management (MRM) | The process of identifying, assessing, and mitigating risks from AI models. Required by regulators (SR 11-7) for any model used in banking decisions. |
| Kill Switch | The ability to instantly disable an agent or restrict its capabilities when something goes wrong. A non-negotiable control for any production deployment. |
| SOC 2 | A compliance framework that certifies an organization's controls for security, availability, processing integrity, confidentiality, and privacy. |
| KYC (Know Your Customer) | Regulatory requirement to verify customer identity. A process agents must respect and integrate with, not bypass. |
| BSA/AML | Bank Secrecy Act / Anti-Money Laundering. Regulations requiring financial institutions to detect and report suspicious activity. |
| OFAC Screening | Checking transactions and payees against the Office of Foreign Assets Control sanctions list. A compliance step that must happen at the infrastructure level, not the prompt level. |
Security & Threats
| Term | Definition |
|---|---|
| Prompt Injection | An attack where malicious instructions are embedded in user input to override the agent's system prompt and change its behavior. |
| Indirect Prompt Injection | Prompt injection delivered through content the agent processes (an invoice, email, document) rather than direct user input. The "Poisoned Invoice" attack. |
| Context Manipulation | Gradually shifting the agent's behavior over multiple conversation turns so no single message looks suspicious. The "Slow Boil" attack. |
| Social Engineering | Manipulating the agent (or a human) through psychological tactics (urgency, authority, sympathy) rather than technical exploits. |
| Information Disclosure | When the agent reveals sensitive data it has access to but should not share. The "Helpful Mistake" attack. |
| Least Privilege | The principle that an agent should only have access to the minimum data and tools it needs to complete its task. Core defense against information disclosure. |
| Out-of-Band Verification | Confirming a sensitive action through a separate channel (e.g., SMS code, phone call) rather than trusting the same channel the request came through. |
| Separation of Duties | Ensuring that the entity that requests an action is not the same entity that approves it. A foundational control in banking and in agent architecture. |
Your Take-Home Project & Certificate
Learning by building is what separates real capability from a webinar. Assemble everything into a one-page proposal you could actually bring to your team.
The brief
Choose one agentic use case for your institution and document it on a single page:
- The workflow (Module 1): the task today, with its R/J/A breakdown.
- The agent (Module 2): goal, reasoning, tools, memory.
- The prompt (Module 3): role, task, constraints, examples, and the "never" list.
- The action plan (Module 4): ordered actions, look-up vs. change labels, approval gates.
- The policy (Module 5): owner, autonomy limits, approvals, logging, data protection.
- The threat model (Module 6): three attack scenarios and the infrastructure guardrails that stop them.
If you can fill all six in, you understand agentic banking well enough to lead a conversation about it at your institution. That's the bar.
Certificate of completion
Congrats on finishing all seven modules. Download your certification below.
0 / 6 modules complete
Keep exploring
You've built the foundation. Dive deeper into the concepts behind agentic banking and see how real-world attack vectors play out against production guardrails.
About this course. Educational material created by Payman for financial institution professionals. Concepts are vendor-neutral; "Dan in action" boxes illustrate one implementation. Module 6 adapts Payman's "How AI Breaks" interactive vulnerability guide (paymanai.com/resources/ai-banking-safety). This course does not constitute legal, compliance, or regulatory advice - validate any AI deployment with your own compliance and risk functions.