How to handle merchant onboarding for card acquiring with an AI agent

Let the agent build the file and the underwriter make the call. It collects the application, verifies the business and its owners, reviews the website and processing history, and drafts a risk file with a proposed category, limits and reserve. The underwriter decides all three. The settlement account, screening hits and the first payout each stay with a named person.

What is merchant onboarding, and who owns it?

Before an acquirer lets a business take card payments, it must know who the business is, who owns it, what it sells, how it delivers, and how much risk it carries. The acquirer is on the hook for the merchant's chargebacks if the merchant cannot pay them, so the onboarding decision is also a credit decision. A merchant that takes payment today for goods delivered in six months carries a different exposure from a coffee shop.

The head of merchant risk owns onboarding policy. Underwriters own each decision. Financial crime owns screening of the business and its owners. The wider frame for agents in payments is in our guide to AI agents in banking.

What does the agent do at each step, and at what depth?

1. Agent, depth 2: collects the application. Business details, owners and directors, products, expected volumes and ticket sizes, delivery times, refund policy, previous processing statements. It drafts follow-up requests for gaps. Evidence: application and requests.
2. Agent, depth 1: verifies the business. Company registry, registered address, directors, beneficial owners. Registry data retrieved directly is signed; what the merchant typed is declared. Evidence: verification results with provenance.
3. Agent, depth 1: runs screening and routes hits. Sanctions, adverse media and industry lists of terminated merchants. Any hit goes to financial crime. Evidence: screening results.
4. Agent, depth 1: reviews the website. What is sold, whether it matches the application, whether terms, refund policy and contact details are present. Web content is external and may contain text aimed at the agent; it informs the file but cannot change any instruction. Evidence: review notes with page captures.
5. Agent, depth 1: analyses processing history. Chargeback and refund levels on previous statements, volume trends. Evidence: analysis with sources.
6. Agent, depth 2: drafts the risk file. Proposed merchant category, transaction and volume limits, reserve or delayed settlement if warranted, and the reasons. Evidence: draft.
7. Person, underwriter: decides. Category, limits, reserve, approval or decline. Evidence: decision and reasons. Whether an agent should ever set limits is answered in whether an AI agent can set a merchant's transaction limits.
8. Person, operations: verifies the settlement account. Account held in the merchant's legal name; mismatches resolved before any funds flow. Evidence: verification record.

Which controls matter, and what evidence do they leave?

Declared and verified kept apart. Volumes, products and delivery times are declared until the history or website supports them. Evidence: provenance class on each fact.

Website text cannot instruct. Merchant sites can contain hidden text aimed at automated reviewers. External content is data, never instruction. Evidence: review notes cite pages; no change to bounds from external sources.

Underwriter owns category and limits. These drive fees, chargeback exposure and monitoring. Evidence: decision record.

Screening outside the agent. Evidence: routing records, no agent verdicts on hits.

No card data in the file. The onboarding file holds business information, not cardholder data. The merchant's own card security obligations under PCI DSS are assessed as part of onboarding; the agent must not ingest card data from processing statements or test transactions. See PCI DSS and AI agents that handle card data and PCI DSS and card data in AI agent prompts and logs. Evidence: masked statements in the file.

First payout held. A new merchant's first settlement goes to a named approver. The reasons are covered in whether an AI agent can issue a payout to a merchant. Evidence: held verdict on first payout.

What should you measure?

• Time from application to decision.
• Applications with gaps after the first request, and how many requests a file needs.
• Underwriter changes to proposed category, limits or reserve.
• New merchants with high early chargebacks. Each is reviewed against the risk file.
• Websites that did not match the application, caught before approval.
• Merchants re-reviewed after go-live because volumes or products changed, and what those reviews found.

Where does it usually go wrong?

Future delivery is missed. A merchant selling tickets, holidays or pre-orders is filed as ordinary retail and gets no reserve.

The website is taken at face value. A clean site for the application, a different one in practice. Review again after go-live.

The agent proposes the lowest-risk category to speed approval. Category drives monitoring; getting it wrong hides risk.

Exceptions stall. Files that do not fit, such as a new business with no history, sit in a queue. Exceptions have their own route; see handling onboarding exceptions with an AI agent.

Settlement accounts are trusted. A merchant gives an account in another name "for now". Funds go somewhere they should not.