AI customer onboarding with verified steps

Onboarding a new customer is a document problem wearing a compliance costume. Somebody collects forms and identity documents, reads them, types the contents into three systems, works out who actually owns the entity, runs names against lists, assigns a risk rating, and opens the account. An LLM can do all of it, and faster than the team doing it now. It can also read a company name off the wrong page, miss a 30 percent shareholder buried in a holding structure, clear a name that should have been escalated, or assign a low risk rating with a paragraph of confident reasoning attached. An examiner reviewing that file six months later does not want the reasoning. They want to know which control caught it, and if none did, why not.

Pebble builds onboarding as a verified environment: the intake process mapped into numbered steps, each step with its own verification check, run by an AI model inside that structure. The model does the work. The checks decide whether the work counts.

Which kind of customer onboarding is this?

This is the back-office kind: collecting an application, verifying who the customer is, resolving ownership, screening, risk-rating, and opening the account with the right entitlements. It is the process a bank, a fintech, a broker, an insurer, or any B2B company with a real credit and compliance function runs before a customer can transact.

It is not product onboarding. If you are looking for AI that personalizes a product tour or nudges new users toward activation, that is a different market and a different page. Everything below assumes a file that someone may have to defend.

How does a verified environment onboard a customer?

It walks numbered steps, and each step must pass its check before the run moves on. Here is a plausible step map for onboarding a legal-entity customer, with the check type at each step.

Step 1: Collect the application and required documents. The run gathers the application, formation documents, ownership charts, identity documents, tax forms, and any authorizations. Check: computed. Code confirms the required document set for that customer type is present, that nothing is expired on the date of review, and that the legal name on each document matches the name on the application. No model grades this. Either the certificate of incorporation is in the file or it is not.

Step 2: Extract the customer record. The model reads the documents and produces structured fields: legal name, registration number, formation jurisdiction and date, registered address, business activity, officers, ownership percentages, tax identifiers. Check: classified. A small model, trained for this one job and scored against held-out examples before it is trusted, flags illegible and ambiguous fields - a registration number that could be read two ways, an address that does not parse to a real jurisdiction. A field that fails the classifier does not flow silently into screening. It fails the step.

Step 3: Verify identity and entity against authoritative sources. Extracted values are checked against the sources you already rely on: the company registry, the tax authority format rules, the document issuer's own validation, your identity vendor's response. Check: computed. Does the registration number resolve to an active entity with that exact legal name in that jurisdiction. Did the identity provider return a match or a mismatch. This is lookup and comparison, verified by code, not by a model deciding whether the numbers feel right.

Step 4: Resolve beneficial ownership. The model reads the ownership chart, computes indirect ownership through intermediate entities, and produces the list of individuals who have to be identified. The rule this is graded against is written down: under 31 CFR 1010.230, a covered financial institution must identify each individual who directly or indirectly owns 25 percent or more of the equity interests of a legal entity customer, plus a single individual with significant responsibility to control, manage, or direct it, and must maintain written risk-based procedures for verifying the identity of each one. Checks: computed and classified. Computed does the arithmetic - do the ownership percentages at each layer sum correctly, is every individual at or above the threshold present in the record with the required identifying information, is the control prong satisfied by exactly one named person. Classified handles the ambiguity - an ownership chart that could be read as two different structures fails the step and goes to a person rather than resolving itself quietly.

Step 5: Screen against sanctions, PEP, and adverse media. Every name from steps 2 and 4 is screened. Checks: computed and judged, split deliberately. Computed confirms the screening actually ran against the current list version for every required name, with no name skipped, and captures exact matches. Judged handles what screening always comes down to, which is whether a fuzzy hit is the same person: your compliance analysts annotate pass and fail examples of correct match adjudication, Pebble trains a judge on them, and reports judge-human agreement on held-out hits. Where agreement is too low, an analyst stays in the check. Confirmed and near-miss matches escalate to a person by design, permanently.

Step 6: Risk-rate and route for approval. The run assigns a customer risk rating using your methodology and routes the file to whoever can approve that rating. Checks: classified for the rating, trained on your historical ratings and scored against held-outs so the disagreement rate is a number rather than a hope. Computed for routing - code confirms the file landed with an approver whose authority covers that rating and that no rating was applied outside its permitted range. Judged for the written rationale, against analyst-annotated examples of an acceptable one.

Step 7: Open the account and set entitlements. Products, limits, permissions, and monitoring rules are provisioned. Check: computed. Code confirms the provisioned entitlements match the approved rating and product set exactly, that ongoing monitoring is switched on, and that the record is complete.

What happens when a step fails?

The run stops at the failed step, gets fixed, and resumes at that step, not from scratch. If step 4 cannot resolve an ownership chain to unambiguous percentages, the run halts there. An analyst reads the chart, the structure is corrected, and the run resumes at step 4. Screening, rating, and provisioning never operated on an incomplete owner list, because an incomplete owner list never got past its check.

When something goes wrong you get a step number, not a transcript to scroll through. "File 5120 failed at step 5, match adjudication below threshold" is something a compliance lead can act on the same day. The methods behind each check type are covered in how to verify agent work.

What does compliance actually get?

A run record per customer file: every step, every check result, every escalation, every human decision, in order, tied to the list version and document versions in force at the time. When an examiner asks how a specific customer was onboarded, the answer is the record rather than a reconstruction from emails. Remediation gets cheaper too, because a failed control shows up as a step that failed across a set of runs, which means you can name exactly which files to re-review instead of re-reviewing all of them.

The thing that makes this hold up is that the checks are external to the model. A logged chain of model reasoning is not evidence of a control, and treating it as one is the most common mistake in AI compliance work right now. Verified agent audit trail explains the difference between a log that proves the system was allowed to act and a record that proves it acted correctly.

What do you own afterward?

A dataset of your onboarding runs, and eventually an open-source model post-trained on it that belongs to you. Every completed file is a worked example of your onboarding process done correctly, with verified checkpoints at each step, which is exactly the shape of data reinforcement learning with verifiable rewards needs. Once the history is deep enough, that dataset post-trains a model you own, running onboarding at a fraction of frontier API cost per file, that no one can reprice or deprecate out from under you.

How does an engagement start?

With a scoping call, and if an environment is the wrong tool for your onboarding process, Pebble says so on the call. From there: about a week of discovery inside your systems under your access model - Pebble keeps the step map and none of your data - ending in a written proposal with a fixed price per work package. Then the build, exercised against real files before it is called done. Then it runs, on your infrastructure or Pebble's, with a retainer.

Onboarding is one process. The same structure applies to claims processing and to order to cash.

Ready to see your onboarding process as a step map? Book a scoping call: [email protected].