Resources
How to Let AI Agents Move Money Safely: A Guide for Credit Unions and Community Banks
A credit union can safely let AI agents move member money when five things are true: the agent acts only on an authenticated member's request, institution-defined policies outside the AI model check every action, a separate system executes through the core, every step is logged, and the institution can stop the agent instantly.
This is how Payman AI's agentic banking platform is built.
The short answer
Require all five conditions before an AI agent moves money. Risk changes when AI can act, not just answer questions.
- Acts only on an authenticated member or customer request
- Policies outside the AI model check every action
- A separate system executes through the core
- Every step is logged in an immutable audit trail
- The institution can stop the agent instantly
Why moving money is different from answering questions
AI is probabilistic. Banking is deterministic. Moving $500 must move exactly $500, logged and tied to an authenticated customer.
| AI systems | Banking requires |
|---|---|
| Generate variable outputs | Identical results from identical inputs |
| Interpret instructions flexibly | Strict rule enforcement |
| Lack built-in financial rules | Policy-driven decisions |
| Opaque reasoning | Complete traceability |
Seven controls to require before an AI agent moves money
Require all seven; any one missing is a gap an examiner or attacker will find.
1. The agent acts only when an authenticated customer asks
It works inside the bank's secure portal, using the customer's own session credentials, not a standing super-user account. There is no independent action.
Ask a vendor: Can the agent act without an authenticated customer session?
How Payman AI does it: Only operates when triggered by an authenticated customer in the bank's secure portal, using the customer's own session credentials.
2. Policy lives outside the AI model
An immutable policy layer checks transaction limits, category restrictions, velocity rules, budget constraints and role-based permissions. The policy layer is deliberately not an LLM.
Ask a vendor: Where are limits and approvals enforced? Can a prompt change them?
How Payman AI does it: Immutable policy layer outside the model; the policy layer is not an LLM.
3. The AI reasons, and a separate system executes
Three layers: AI reasoning; policy, risk and controls; deterministic execution. The AI never touches the core directly.
Ask a vendor: Does the AI call the core directly?
How Payman AI does it: AI never touches the core; a separate deterministic execution layer does.
4. Higher-risk actions get a confirmation or an approval
The bank defines approval workflows and risk thresholds. As a recommended practice, confirmations should verify identity out of band, not just accept a reply in the same channel.
Ask a vendor: Which actions need confirmation or approval, and who sets thresholds?
How Payman AI does it: Bank defines transaction limits, approval workflows and risk thresholds.
5. Every step is recorded in an immutable audit trail
The five-part decision chain: the request in the customer's words, how the AI interpreted it, which policies were evaluated, why it was approved or blocked, and exactly what executed. Available to compliance in real time.
Ask a vendor: Can we see request, interpretation, policies, decision and execution for every action?
How Payman AI does it: Complete, immutable decision chain, available to compliance in real time.
6. The bank holds a kill switch
The bank can shut the agent down immediately. Kill switch, monitoring and audit trails live in Paygent Central.
Ask a vendor: Who can stop the agent, and how fast?
How Payman AI does it: Bank-controlled kill switch with instant effect, in Paygent Central.
7. Each institution's data is isolated
Separate databases, compute and encryption keys per bank; not multi-tenant. That matters for vendor risk reviews.
Ask a vendor: Is our data in a shared environment?
How Payman AI does it: Separate databases, compute and encryption keys per bank; not multi-tenant.
Controls checklist
| Control | What to ask the vendor | Evidence to request | How Payman AI does it |
|---|---|---|---|
| Authenticated requests only | Can the agent act without an authenticated customer session? | Architecture description; session handling | Only operates when triggered by an authenticated customer in the bank's secure portal, using the customer's own session credentials |
| Policy outside the model | Where are limits and approvals enforced? Can a prompt change them? | Policy configuration demo | Immutable policy layer outside the model; the policy layer is not an LLM |
| Separate execution | Does the AI call the core directly? | Data flow diagram | AI never touches the core; a separate deterministic execution layer does |
| Confirmation and approval | Which actions need confirmation or approval, and who sets thresholds? | Policy rules for high-risk actions | Bank defines transaction limits, approval workflows and risk thresholds |
| Audit trail | Can we see request, interpretation, policies, decision and execution? | Sample audit export | Complete, immutable decision chain, available to compliance in real time |
| Kill switch | Who can stop the agent, and how fast? | Live demo | Bank-controlled kill switch with instant effect, in Paygent Central |
| Data isolation | Is our data in a shared environment? | Hosting and tenancy description | Separate databases, compute and encryption keys per bank; not multi-tenant |
How a safe AI-initiated transfer works, step by step
Example request: "Move $500 from checking to savings." Path: Customer, Bank portal, AI agent, Policy engine, Core banking.
- Input processing. An authenticated customer in the bank portal asks the AI agent to move $500 from checking to savings. The request is captured in the customer's own words.
- Planning. The AI reasons about the intent and proposes a transfer plan. It does not touch the core.
- Policy enforcement. An immutable policy layer outside the model checks limits, permissions and bank rules before anything executes.
- Execution. A separate deterministic system executes the approved transfer through existing core banking APIs using the customer's session credentials.
- Confirmation. The customer receives confirmation, and the full decision chain is written to an immutable audit trail.
What can go wrong, and the control that stops it
| Risk | What it looks like | Control that stops it |
|---|---|---|
| Prompt injection | Hidden instruction in an invoice changes $500 to $50,000 | AI has no direct execution; policy layer validates against actual identity and permissions |
| Hallucinated actions | "Pay my rent like last month" gets the wrong amount and payee | Policy and execution layers verify details against real records before anything executes |
| Policy drift | "You let me do this last time" becomes an exception | Policies enforced by dedicated systems, not learned by the AI |
| Audit failure | "The AI decided" is the only explanation | Immutable five-part decision chain |
See nine ways AI systems in banking get exploited.
Test before go-live
Run these tests in a sandbox before any money moves. Paygent Central includes a dedicated UAT environment for test conversations.
- A document or email containing instructions cannot change a payee or amount.
- Confirmations for high-risk actions verify identity, not just a reply in the same channel.
- Earlier conversation cannot grant approval for a later transfer.
- Chained requests are judged by their net effect (internal then external is treated as external).
- An "urgent" request cannot skip a required check.
- Payment detail changes appear in the audit trail as distinct high-severity events.
- The kill switch has a named owner and has been tested.
Where to start: a phased rollout
Start with lower-risk actions such as transfers between a customer's own accounts, then expand once the audit trail shows the controls working. Scope depends on which APIs the institution exposes and which policies it configures.
| Phase | Actions in scope | Gate to the next phase |
|---|---|---|
| 1. Sandbox | Test conversations and test customers only | Pre-go-live tests pass |
| 2. Low-risk live | Transfers between own accounts; payments to existing payees | Audit trail review shows policies working as configured |
| 3. Expanded | New payees, larger amounts, account services, with confirmation or approval rules | Compliance and board sign-off on the expanded policy set |
What examiners and boards will ask
There is no AI-specific rule; examiners apply existing frameworks. NCUA looks at safety and soundness, compliance, internal controls, ongoing monitoring and third-party due diligence. Map the seven controls to evidence: audit exports, policy settings, kill switch owner, SOC 2 Type II. This is general guidance, not legal or regulatory advice.
How Payman AI does this
Payman AI is the agentic banking orchestration layer that sits inside the bank, between the AI agent and the core. The platform enforces authentication-gated actions, an immutable policy layer, a complete audit trail, physical data isolation, and a bank-controlled kill switch in Paygent Central. It integrates with existing cores and digital platforms rather than replacing them. Payman AI is SOC 2 Type II. Deployment typically takes weeks, not months.
Comparing vendors?
Use this checklist alongside our vendor comparison guide, which compares vendor categories rather than individual vendors.
Frequently asked questions
Can AI agents move money safely for credit union members?
Yes, with conditions. A credit union can safely let AI agents move member money when the agent acts only on an authenticated member's request, institution-defined policies outside the AI model check every action, a separate system executes through the core, every step is logged, and the institution can stop the agent instantly. Start with lower-risk actions and expand as the audit trail proves the controls.
Does the AI agent ever act on its own?
No. It acts only when an authenticated customer or member asks, inside the bank's secure portal, and only within policies the institution sets. The bank can shut it down instantly.
What stops an AI agent from being tricked into sending money?
Architecture, not prompts. The AI can read and propose, but it cannot execute. A separate policy layer (deliberately not an LLM) validates every action against the customer's identity, permissions and the bank's rules, and rejects anything that does not match the original request. See nine attack scenarios on the AI Banking Safety page.
What should the audit trail show for an AI-initiated transfer?
The five-part decision chain: request in the customer's words, AI interpretation, policies evaluated, approve or block decision and why, and exactly what executed. It is immutable and available to compliance in real time.
Which transactions should we let an AI agent handle first?
Lower-risk actions such as transfers between a customer's own accounts and payments to existing payees. Add new payees, larger amounts and account changes once controls are proven. Scope depends on the APIs exposed and the policies configured.
Do we have to replace our core to let AI agents move money?
No. The orchestration layer sits above the core and executes through existing core banking and digital banking APIs. Payman AI integrates with FIS, Fiserv, Jack Henry and COCC, and with Narmi, Q2, Alkami and Candescent.
What will examiners expect to see?
NCUA supervises AI within existing frameworks: safety and soundness, compliance, internal controls, monitoring and third-party due diligence. Be ready to show policy settings, audit trails, kill switch ownership and vendor attestations. This is general guidance, not legal or regulatory advice.