integrations
AI Agents for Lithic Card Program Operations
How card program teams use AI agents on Lithic: dispute prep, authorization and Auth Rules investigations, KYB reviews, ACH return checks, and settlement reconciliation, with human approvals.
AI agents can take the investigation work on a Lithic card program: preparing disputes, explaining declines and Auth Rules decisions, assembling KYB reviews, checking ACH returns, and reconciling settlement reports. They read through Lithic's API, Events API, settlement reports, and hosted MCP server, and they hand a person a drafted action to approve. Runtime is the AI agent harness for payment and fintech teams, and it is where those agents run with guardrails and a full record.
Lithic gives a program team a lot of control: real-time authorization decisioning, programmable Auth Rules, its own ledger and ACH access. More control means more operational surface. This is a guide to letting agents carry that surface while your team keeps the decisions.
The ops work on Lithic that agents can take
| Queue | What the agent does | What stays human |
|---|---|---|
| Disputes | Pulls the transaction events, cardholder history, and prior disputes; drafts the claim and evidence; watches status and evidence upload failures | Filing, withdrawing, accepting a loss |
| Declines and authorizations | Explains a decline: your ASA response, an Auth Rule, a velocity limit, a 3DS outcome, or a timeout | Changing ASA logic or Auth Rules |
| Auth Rules tuning | Reads shadow-mode results, backtests, and performance reports; summarizes false positives and caught fraud | Promoting a rule from draft to active |
| Account holders and KYB | Reviews PENDING_REVIEW cases, lists missing documents and beneficial owners, drafts the request | Approving or rejecting the account holder |
| ACH and returns | Traces an ACH payment, its holds, and any return; drafts the customer reply and next step | Originating, reversing, or releasing funds |
| Settlement and balances | Ties settlement summaries and network totals to financial account balances and your ledger | Booking adjustments, moving money between accounts |
How agents connect to Lithic
API. Cards, transactions, disputes, account holders, financial accounts, book transfers, ACH payments, and Auth Rules are API resources. Authentication is an API key in the Authorization header, with a dated api-version header. Every account gets a free sandbox key with all endpoints at sandbox.lithic.com.
Webhooks and the Events API. Lithic signs webhooks with HMAC-SHA256, retries failed deliveries on a schedule over roughly a day, and keeps 90 days of events retrievable through the Events API. It can resend failed messages and replay ones your endpoint never received, which helps an agent catch up after downtime instead of missing cases. Dispute, dispute evidence, 3DS, tokenization, and ACH events are all available.
Reports. Settlement reporting (daily summary, details, and network totals) is an Enterprise product in production only, so plan reconciliation agents against production read access. Auth Rules have their own performance reports covering the last three months.
MCP server. Lithic hosts a remote MCP server at docs.lithic.com/mcp. Search and endpoint exploration need no login; the execute-request tool calls the live API with your key, and Lithic recommends a sandbox key. It is useful for building and testing an agent. For production ops, keep the agent on a tool layer you control.
Browser. For tasks that only exist in the Lithic Dashboard, an agent can use a dedicated login with a limited Dashboard role. Lithic documents org and program level roles, including Read-Only.
Least privilege. Lithic API keys are per program, and we found no read-only or per-endpoint key scoping in its docs. That makes the agent's environment the place to enforce limits: masked credentials, an allowlist of read calls, and every write call routed through an approval.
Workflow: dispute preparation
Lithic's Managed Disputes ties each dispute to a card transaction event and records workflow, financial, and cardholder liability events, including provisional credit. The work that eats time is the evidence.
A cardholder says they never received an order from a merchant charged on card ending 2208. Pull the settled transaction and its events, the cardholder's history with this merchant, and any prior disputes on the account. Draft the dispute with reason, timeline, and evidence list. Don't file it; post the draft to #card-ops and note whether provisional credit applies under our policy.
Workflow: Auth Rules review
New Auth Rules run in shadow mode before promotion, and Lithic supports backtests. An agent can turn those results into a decision memo.
Our velocity rule for online electronics purchases has been in shadow mode for two weeks. Summarize what it would have declined, how many of those later became disputes or fraud reports, and how many look like good customers. Recommend promote, adjust, or drop, with examples. Don't change the rule.
Workflow: ACH return investigation
An ACH debit from a customer's external account came back returned yesterday. Find the payment, its hold period, the return code, and whether funds were already made available. Draft the customer message and the recovery step per our policy. Don't originate or reverse anything.
Guardrails
- Restrict in the environment. Since keys are program-wide, the agent only gets read tools until a workflow has an approval step.
- Approvals before anything changes. Filing disputes, promoting Auth Rules, closing cards, approving KYB, and originating ACH wait for a named approver. Lithic notes ACH cannot be cancelled once originated.
- Sandbox first. Build and test every workflow on sandbox.lithic.com before production.
- No card numbers in prompts or logs. Strip PANs and SSNs from what the agent sees.
- Record every run. Keep the trigger, every API call, the evidence, the approval, and the result.
Where Runtime enters the picture
Lithic gives you the controls for a card program. It doesn't run the investigation that crosses your other systems. A returned ACH payment that funded card spend touches support (the customer), card ops (the account and its cards), finance (the negative balance and the recon line), and risk (whether to keep the account open). Runtime is the AI agent harness for payment and fintech teams: one agent works the case across Lithic, your ledger, and your help desk, and every team sees the same record. Runtime has no official Lithic integration or partnership; agents use Lithic's public API, events, and MCP server with credentials you control.
- No single vendor to depend on. Agent computers run in your AWS, GCP, or Azure account or fully self-hosted, on the sandbox provider you choose, with Claude, GPT, Gemini, or open-weight models and harness routing across Claude Code, Codex, and OpenCode, with fallbacks when a provider goes down.
- Guardrails you set. Agents start read-only, filing a dispute or originating ACH waits for approval, access follows roles, credentials are masked, card numbers and SSNs are stripped, and every run is recorded for your sponsor bank or auditor.
- Built for teams. Card ops, support, finance, risk, and compliance share agents, templates, and one memory, so the return, the ticket, and the recon break are worked once.
- An engineer, not an account executive. A forward-deployed AI engineer who built payment infrastructure at Hulu's payments team at Disney, Finix, Modern Treasury, and BlackRock maps your Lithic queues and builds the first agents with your team.
Create a banking ops agent that handles RFIs, hold-harmless requests, and returns of funds from our partner bank, verifies against our ledger, and drafts replies for my approval.
bank-ops-agent
Tools picked from your prompt
A realistic timeline
| Stage | Time |
|---|---|
| First read-only agent against the Lithic sandbox | Minutes on Runtime; days if you build the infrastructure yourself |
| Dispute prep agent on production, read-only | One to two weeks, mostly agreeing on the evidence template |
| Auth Rules review memos | One to two weeks, once the team defines a good catch and a false positive |
| ACH return and settlement agents | Two to four weeks, depending on ledger access |
| Write actions behind approvals | After the read-only versions have earned the team's trust |
Frequently asked questions
Can AI agents work with Lithic?
Yes. Lithic exposes its API, an Events API with webhooks and replay, settlement reports, and a hosted MCP server. An agent can read transactions, disputes, account holders, Auth Rules performance, and ACH payments, then draft the next step for a person to approve. Runtime is the AI agent harness for payment and fintech teams that runs those agents with approvals and an audit trail.
Does Lithic have an MCP server?
Yes. Lithic hosts a remote MCP server at docs.lithic.com/mcp. It searches the docs and API reference without a login, and its execute-request tool makes live API calls with your Lithic API key. Lithic recommends a sandbox key. It is built as a developer tool rather than an ops agent.
Can I give an agent a read-only Lithic API key?
Not from what Lithic documents today. API keys are per program, and we found no per-endpoint or read-only key scoping, so a production key carries that program's full API access. Put the restriction in the agent's environment instead: a tool layer that only allows read calls, with write calls routed through an approval.
What Lithic work should stay human?
Filing or withdrawing a dispute, promoting an Auth Rule out of shadow mode, closing a card or account, approving a KYB case, and originating ACH. Lithic notes an ACH payment cannot be cancelled once originated, so origination should always sit behind an approval.
Where does Runtime fit next to Lithic?
Lithic is the issuing platform and ledger for your card program. Runtime is where your ops team builds and runs agents that work Lithic queues alongside your help desk, internal ledger, and bank data, read-only by default, with approvals before money moves and a record of every run. Runtime does not have a native Lithic integration; agents use Lithic's public API, events, and MCP server.
Put an agent on your Lithic queues
Start with one queue, like dispute prep or Auth Rules review. Runtime runs the agent read-only, in your cloud, with approvals before anything changes. Spin one up yourself, or talk with the founders about your program.