How to Automate Merchant Underwriting with an AI Coding Agent

Picture an underwriter's screen on a Monday morning. Five tabs open. The KYB database. The MATCH list. The merchant's website. The processing history. The credit policy doc. A queue of applications waiting, and every single one means clicking through all five tabs again.

One compliance analyst put it plainly: their team needs "five different apps to search for info," and ends up spending more time gathering than analyzing. At Stripe, underwriters review over 100 businesses a day. At Global Payments, risk analysts use Excel and Access. The tools haven't caught up to the volume.

Four of those five tabs are assembly work. One of them is judgment. This guide covers what's actually possible when you build with a coding agent, Claude Code, Codex CLI, and Gemini CLI are the three most common choices right now, to hand off the assembly work, how the pieces fit together, and where the line has to stay with a human.

The Jobs That Hurt

Across the industry, from payfac risk analysts to underwriters at the biggest acquirers, the same jobs come up again and again as the ones that eat the day:

• Application triage under SLA pressure. Review the application, pull business credit, calculate exposure, decide. At Fiserv, underwriting workflows are tied directly to SLA performance, application by application.
• The screening trio. Sanctions, PEPs, and adverse media, run on every merchant and every beneficial owner. At one major processor, sanctions screening is a recurring batch job: upload the monthly OFAC file, check it against the active portfolio, repeat.
• Document chasing. CDD analyst roles are largely defined by this: collect the documents, verify them, follow up on what's missing, repeat until the file is complete.
• Website legitimacy checks. One underwriter with two decades in the seat lists the manual tells for a shell business: a default phone number of 1234567890, most links on the site not activated. That's pattern matching, done by eyeball, one merchant at a time.
• The periodic-review treadmill. At Fiserv, every retail entity gets a periodic annual review. At Chase, credit officers work to monthly review timelines. At Adyen, merchant data gets reviewed monthly. The calendar never stops generating work.
• Trigger-event reviews. At Worldpay, the CDD team re-reviews a merchant the moment something changes: an ownership update, unusual account activity, a negative media hit. Someone has to notice the change before they can act on it.
• Card network mandates. Acquirers work through thousands of network bulletins a year, and Visa's VAMP program now scores an acquirer's whole portfolio on dispute ratio, so one bad merchant can put the entire book at risk.

Every one of these jobs is either queue-shaped or calendar-shaped, which is exactly the kind of work a coding agent handles well. It's also not a coincidence that Adyen's own postings for its credit risk team now ask candidates to identify manual steps in underwriting and portfolio monitoring that are ready for automation. The industry already knows where this is going.

Anatomy of an Underwriting Agent

Strip away the buzzwords and an underwriting agent is three things: data it can reach, a playbook it has to follow, and a reason to wake up.

Data sources. This is the plumbing: read access to your merchant and transaction database, plus the APIs your team already pays for, a KYB provider, a sanctions and adverse-media screening tool, the MATCH terminated-merchant list. A coding agent working in its own sandboxed environment can hold these connections the same way an analyst's laptop does, except it doesn't need five separate logins open at once to use them.

Skills. A skill is just a written set of instructions the agent reads before it does a specific job, saved so it uses the exact same instructions every time. Think of it as your playbook, typed up once: your prohibited-business list, your reserve schedule for high-risk verticals, the thresholds that trigger enhanced due diligence, the format a decision memo has to follow. Right now, that playbook mostly lives in a senior underwriter's head, applied a little differently by whoever's on the queue that day. A skill is the same playbook, written down, applied identically by everyone, including the agent.

Triggers. An agent needs a reason to run: a schedule (every Monday at 7am, review the portfolio) or an event (a new application just landed). A well-set-up agent handles both, so the same agent that reviews new applications the moment they arrive can also run a calendar job every week without anyone remembering to start it.

Approvals. The piece that makes the other three safe to use. An agent can draft a decision and stop, waiting for a specific person to say yes before anything is recorded as final. This is what keeps a coding agent from ever quietly becoming the underwriter.

What's Possible

With those four pieces, four automations come up as the most obvious places to start:

1. Application triage. A new application arrives, the agent pulls KYB, runs the sanctions and adverse-media screen on the business and its beneficial owners, checks MATCH, reads the merchant's website against your prohibited-business list, and drafts a memo with a recommendation, before an analyst ever opens a tab.
2. A daily alert digest. Overnight monitoring alerts get enriched with merchant context, deduped, and pre-dispositioned, so the team starts the day with a short, ranked list instead of a raw queue.
3. A weekly portfolio review. Every Monday, the agent recomputes dispute ratios against network thresholds, flags merchants approaching a re-underwriting trigger, and lists accounts due for periodic review that week.
4. A network bulletin reader. Every week, the agent reads that week's card network bulletins and reports which ones touch your policy or an active merchant, so nothing gets missed in a stack of PDFs nobody has time for.

None of these need a big engineering project. They need your playbook written down and a coding agent pointed at it.

Try It: Create an Application Triage Agent

You don't need to build all four to see how this works. Here's roughly what setting up the first one, application triage, looks like in practice.

You'd open a sandboxed environment, launch your coding agent of choice inside it, Claude Code, Codex CLI, and Gemini CLI all work, and describe the job in plain language, something like:

"Connect to our merchant database and to [your KYB provider] and [your sanctions-screening provider]. When a new application arrives, pull KYB on the business, screen the business and its beneficial owners for sanctions, PEPs, and adverse media, check MATCH, and review the merchant's website against this prohibited-business list: [paste your list]. Draft a decision memo with findings, risk factors, and a recommendation, but don't record any final decision. Request approval from someone on the underwriting team first."

That's it, at a high level. The agent handles the connections, writes the checks, and produces a first draft of the memo every time an application comes in. You'd spend a couple of applications comparing its memo to what an analyst actually decided, tightening the instructions where they disagree, and that tightening is really just you making your own policy more explicit than it's ever had to be on paper.

Keep the Judgment

Here's what should never move to the agent: the decision itself. Declines, holds, reserve changes, MATCH filings. A person makes those calls, every time.

A good approval step enforces that as a hard stop, not a suggestion. The agent drafts and recommends, then waits. Nothing gets recorded as a final outcome until someone with the right role signs off.

That boundary pays for itself the first time a sponsor bank or a card network auditor asks why a merchant was approved. The answer is sitting right there: every source the agent checked, every finding, timestamped, in the same format, for every merchant reviewed, with a human's sign-off attached at the end.

Your analysts spent years learning what a bad merchant looks like. Nothing here replaces that. What it replaces is everything that was keeping that judgment from getting used: the five tabs, the document chasing, the queue that never empties.

Close the other four tabs. Keep the fifth.

Everything in this guide works with any coding agent in any sandboxed environment you set up yourself. Runtime just removes the setup: it gives your coding agent an isolated environment with the connections to your risk stack ready to go, runs your scheduled and triggered agents without you managing your own cron server, and keeps the approval gate and full run history built in, so the audit trail is there from the first run instead of something you bolt on later.

---