What is the recommended onboarding flow, and what controls should I put around Pre.Fill?

Last updated: October 9, 2026

Pre.Fill works best as one step in an onboarding flow rather than as the whole flow. The pattern most customers use:

  1. Verify the applicant’s phone or email first, so only a real person on a known device sees suggestions.

  2. Collect the applicant’s name.

  3. Call Pre.Fill with the applicant’s name and the business name. Show the top results as a short list, ranked by the business name match.

  4. Let the applicant select the correct entity. Prefill the legal name and registered address from it, and let them edit if something looks off.

  5. Collect the remaining fields you need, such as the EIN, then run your business search. The KYB rating, TIN match, and watchlist screening run on the confirmed entity, so any mismatch surfaces there.

Controls on the Pre.Fill request itself:

  • Raise the similarity_threshold to tighten how closely the applicant’s name must match the filed officer name. The default is already strict; lower it only if legitimate applicants are getting no results.

  • Set a small limit so applicants choose from a handful of options rather than a long list.

  • If you collect business name, use business_name_match to rank results and to decide what to show. Many customers show Exact and Similar matches by default and hold No Match results behind a "none of these" option.

Controls you build around it:

  • Never auto-select. Always require the applicant to confirm the entity, even when there is a single result.

  • If the applicant chooses an entity whose name is a No Match to what they typed, or edits the prefilled legal name, treat that as a signal for additional verification such as a document upload.

  • Rate-limit Pre.Fill calls per session and per device. The data is public, but a high volume of lookups from one source is a sign of scripted abuse.

  • Log which suggestion was shown and which was chosen, so you have an audit trail for the decision.