How to Automate KYB and KYC Reviews with AI Agents

A merchant application can be almost complete for days. The business record matches, but one owner's document needs another look. A screening result uses a slightly different name. Someone has to open the original files and work out which discrepancy matters.

That is the useful starting point for an onboarding agent: the evidence-gathering work between a vendor result and your team's decision.

This guide shows how to build that agent with Claude Code or Codex and run it in Runtime. The agent follows your KYB and KYC procedure, assembles the evidence, and identifies the questions that still need an answer.

The short answer. Define the required checks for one onboarding segment. Give the agent scoped access to application documents, business records, related-person verification results, and screening evidence. Have it compare fields across sources, preserve discrepancies, and prepare a review packet. Keep onboarding decisions, exceptions, and account activation with your authorized team.

Define the review

Know Your Business, or KYB, concerns the business being onboarded. Know Your Customer, or KYC, commonly describes customer identity checks, including checks on relevant people in a business application. The exact requirements depend on your institution, product, jurisdiction, and approved program.

Keep business and related-person findings separate. A successful business lookup doesn't resolve an owner's identity discrepancy. Synctera's KYB case documentation makes that distinction explicit for its workflow.

Begin with one customer segment and one jurisdiction. Give the agent a checklist already approved by your compliance team instead of asking it to generate a universal onboarding policy.

Walk through a case

The fictional Northstar Supply application has a business record, an ownership discrepancy, and a related-person document that needs refreshing under the sample procedure. The agent collects those findings into a pending review packet.

The case stays open. The demo illustrates preparation and review, not an automated decision that the merchant is safe to onboard.

The stack

Use your existing verification vendors and application system. Confirm tool availability, field-level access, and document handling before connecting them to the agent.

Job	Example tools
Read application and verification status	Alloy
Read business verification evidence	Middesk
Read identity and document results	Persona
Check screening evidence	LexisNexis
Store the application and review	Your restricted onboarding case system
Agent infrastructure	Runtime

You don't need every vendor in this table. You need a reliable way to retrieve the evidence your procedure requires and show it to the right reviewer. The onboarding, KYB and KYC solution shows how that fits together in Runtime.

Step 1: Write the checklist

For each required check, define the accepted evidence, the source, the person responsible for exceptions, and the conditions that keep the application pending.

Include the effective version of your policy. The agent should know which procedure applied when the review started and flag a version change before finishing. Compliance owns that change, including whether earlier cases need another look.

Use your institution's current requirements rather than hardcoding a rule from a blog post. FinCEN's customer due diligence resources are an official starting point for applicable US requirements. Have your compliance team determine their relevance to the particular product and institution.

Then define the output. A useful packet contains an application summary, the completed check list, linked evidence, discrepancies, outstanding requests, and a proposed next review step. It should be possible to inspect a claim without searching the whole application again.

Step 2: Create the agent with Claude Code or Codex

Start from anonymized approved, rejected, and incomplete cases. Include examples where the final decision was easy but the evidence was messy.

Build an onboarding evidence agent for our approved merchant-review procedure. Read the assigned application's business records, ownership documents, related-person verification results, and screening evidence through the permitted tools. Compare the fields without changing the source records. Produce a review packet with supported findings, discrepancies, missing evidence, and source references. Leave the application pending. Don't approve, reject, activate an account, or contact the applicant.

Ask Claude Code or Codex to make separate helpers for extracting document fields, retrieving vendor results, comparing records, and generating the packet. That keeps one problematic extraction from silently affecting every later step.

Save the approved procedure as a versioned skill or instruction set. Claude Code skills and Codex skills provide ways to package reusable instructions. Configure and test each implementation with its own tools and permissions.

Keep credentials out of prompts and sample files. Use your approved secrets interface and start with access that can read evidence and save drafts, without changing application decisions.

Step 3: Compare the evidence

Extraction is a claim about what a document says. Verification requires comparing that claim with the relevant source and your procedure. Preserve that distinction in the packet.

For each extracted field, retain the document reference, page or section, original text, and normalized value. If the agent reads "Northstar Supply LLC" and normalizes it to "Northstar Supply," the reviewer should still see the legal suffix in the source.

In the sample application, ask the agent to identify exactly which ownership values disagree. It should not quietly choose the most recent-looking document or assume two similarly named people are the same person.

Compare the ownership information in this application with the approved source documents. Show the conflicting values side by side with document dates and references. Separate a missing field from a contradictory field. If an identity document needs refreshing under our policy, identify the relevant policy check and prepare a request for reviewer approval.

For screening, preserve the vendor's potential-match result and the identifiers supporting or weakening the match. A shared name alone shouldn't become a conclusive identity statement. If a key identifier is absent, show the gap and route the case to the appropriate specialist.

Step 4: Protect the documents

Identity records deserve a smaller audience than general operational notes. Decide which fields the agent needs to read, which may enter the model context, and which should only be linked for an authorized reviewer.

If you deploy Runtime in your VPC or self-host, still review the model endpoint, network access, retention settings, and vendor data flows. Hosting the agent's computer in your network doesn't by itself mean that every model request stays there.

Treat uploaded documents as untrusted input. A PDF that tells the agent to skip screening or email a copy elsewhere must not change the approved workflow. Test this boundary directly with harmless adversarial sample documents.

Step 5: Run a reviewed pilot

Trigger the agent for one manual-review queue. Have it save the packet and assign the designated reviewer. Preserve the application version and evidence retrieval time so the reviewer can tell what the agent actually examined.

When a new document arrives, create a linked revision. Re-run the checks affected by that document and show the differences. Avoid presenting a previously reviewed packet as current when its source evidence has changed.

Define what happens when a vendor is unavailable, an image is unreadable, or two records conflict. The agent should keep the case pending with a specific reason and an owner. It should not turn "couldn't check" into "passed."

Test the exceptions

Use a fixed test pack before adding live cases. Your acceptance criteria should cover correctness and access, not just whether a packet was generated.

Have reviewers check whether the packet contains enough evidence to make the decision. A page count or completion percentage can't establish that.

What stays human

Your designated reviewers own the onboarding decision, policy exceptions, screening disposition, and any communication that requests or discloses sensitive information. The agent can prepare the work needed for those decisions.

If the case expands into merchant business-model or underwriting questions, keep that review explicit. The merchant underwriting guide covers the broader investigation. Completing identity checks doesn't automatically complete underwriting.

Measure review quality

Track time to a complete packet, reviewer minutes, missing-document rework, and factual corrections. Break results down by the exception type and customer segment.

Measure whether reviewers can reach every source and whether application revisions are handled correctly. Keep incorrect identity matches and unauthorized access attempts visible as separate quality measures.

The pilot succeeds when preparation becomes dependable and reviewers spend more time on the actual judgment. Use that evidence to decide which additional checks the agent should handle.

The point

Make the evidence easy to review and the unresolved checks hard to miss. That's a useful onboarding agent, even before it touches any additional part of the process.