Skip to main content
This guide provides best practices for implementing Pre.Fill safely and effectively, covering identity verification requirements, match evaluation strategies, edge case handling, and user experience optimization. For API implementation details, see Pre.Fill: API Quickstart.

​
Critical: Run KYC/ID Verification First

The most important Pre.Fill best practice is to verify the applicant’s identity BEFORE running Pre.Fill. This prevents fraudsters from using Pre.Fill to discover and impersonate legitimate businesses.

​
Why Identity Verification Must Come First

Pre.Fill returns business registrations based on an officer’s name. Without verifying the applicant is actually that person, you create a fraud vector: Correct Flow: ID Verification → Pre.Fill → Select Business → Business Verification
  • Only verified individuals can access Pre.Fill
  • Name from verified ID is used for Pre.Fill search
  • Prevents discovery-based fraud
Do not call Pre.Fill without completing identity verification first.

​
Evaluating Match Quality

Pre.Fill returns multiple indicators to help you determine which registrations to display. Understanding how to use these indicators is critical for a good user experience.

​
Similarity Score Thresholds

The similarity_score ranges from 0 to 1, indicating how closely the officer name in the registration matches the search query. Recommended thresholds:
  • 1.0: Exact match - always show
  • 0.90+: Very close match - show by default
  • Below 0.90: Weak match - don’t show unless no alternatives

​
Business Name Match Priority

When applicants provide a business name, use business_name_match to prioritize results: Match types (in priority order):
  1. EXACT: Perfect business name match
    • Always show first
    • Highest confidence this is the correct business
  2. SIMILAR: Close business name match
    • Show prominently
    • Likely the correct business with minor naming differences
  3. NO_MATCH: Different business name
    • Show only if similarity_score is 1.0
    • Useful in case of manual errors in applications

​
Registration State Consideration

Consider the registration state when evaluating matches:
  • Same state as applicant: Higher relevance
  • Adjacent state: May be relevant for cross-regional businesses
  • Distant state: Lower relevance except for national businesses
Use this as a tiebreaker when multiple high-score matches exist.

​
Requesting EIN After Selection

After an applicant selects a business from Pre.Fill results, always request the EIN (Tax ID) before proceeding with verification.

​
Why Request EIN

  1. Confirms business ownership: Only actual officers/owners know the EIN
  2. Enables comprehensive KYB: EIN is required for IRS TIN matching
  3. Standard KYB input: Your Business Search should include EIN in most cases anyway

​
Handling Edge Cases

Pre.Fill works for most business types, but some scenarios require special handling.

​
Sole Proprietorships

Challenge: Most states don’t record sole proprietorship registrations. Pre.Fill behavior: Will return no results or incorrect matches. Best practice:
  • Direct them to a specialized sole proprietorship flow
  • Always offer manual entry option
  • Read the Sole Proprietorship Verification recommendations for further details

​
New Jersey and Similar States

Challenge: Some states (particularly NJ, WY) don’t consistently record officer names in business registrations. Pre.Fill behavior: Returns fewer or no results even for valid businesses. Best practice:
  • Expect manual entry more commonly
  • Provide clear messaging for these states

​
Large Organizations

Challenge: Low-level employees won’t appear as officers in registrations. Pre.Fill behavior: Returns no results or returns businesses unrelated to the applicant. Best practice:
  • Confirm applicant’s role before running Pre.Fill
  • Message: “Are you an owner, officer, or authorized signatory?”

​
Very Common Names

Challenge: Names like “John Smith” may return 50+ unrelated businesses. Pre.Fill behavior: Returns maximum limit (50) with many low-relevance matches. Best practice:
  • Require business name input for common names
  • Use business name matching to narrow results

​
No Results Returned

Challenge: Pre.Fill returns empty results array. Possible reasons:
  • Sole proprietorship without records
  • Name doesn’t match SOS records
  • Business in state with poor officer coverage
Best practice:
  • Always provide clear manual entry option
  • Redirect applicants to manual entry option if no results
  • Don’t treat no results as an error - it’s an expected scenario

​
User Experience Best Practices

​
Optimal Number of Options

Show 1-3 options to applicants, not all matches. Why limit display?
  • Reduces cognitive load
  • Faster decision making
  • Higher completion rates
Existing customer flows show: 3 options is the sweet spot for choice satisfaction.

​
Manual Entry Positioning

Always make manual entry easy to access. Good patterns:
  • “None of these? Enter manually” button below results
  • Link at top: “I’d rather enter details myself”
  • Automatic redirect if zero results

​
Pre-Filling Fields

When applicant selects a business:
  • Pre-fill: Legal business name, address
  • Still require: EIN, contact info, other application details
  • Allow editing: Consider allowing address correction if needed

​
Fraud Prevention Strategies

​
Public Data Clarification

Important context: Pre.Fill uses only public Secretary of State data that is already freely available to anyone, including fraudsters. Key points to understand:
  1. Pre.Fill doesn’t expose new information: All data returned is public record
  2. Fraud risk isn’t increased: Every person already have access to this data
  3. The value is convenience: You’re making legitimate applicants’ lives easier
Common misconception: “Pre.Fill makes fraud easier by showing business details” Reality: Fraudsters can already access SOS websites to get this information. Pre.Fill simply provides legitimate applicants with better UX.

​
Where Fraud Prevention Matters

Pre.Fill itself isn’t a fraud vector, but protect against fraud by:
  1. Verifying identity first (covered above - most important!)
  2. Requesting EIN (fraudsters may know business names but not EINs)
  3. Running full Business Search (don’t skip Business Verification after Pre.Fill)
  4. Monitoring for velocity (unusual numbers of Pre.Fill requests)

​
Summary

Pre.Fill best practices focus on security and user experience: Security:
  • Always verify identity before Pre.Fill
  • Request EIN after business selection
  • Run full Business Search verification
  • Monitor for unusual usage patterns
Match Evaluation:
  • Use similarity threshold ≥ 0.90
  • Prioritize business name matches
  • Consider registration state
  • Show 1-3 top options only
Edge Cases:
  • Always provide manual entry option
  • Account for sole props and certain states
  • Confirm applicant is an officer
  • Handle common names appropriately
User Experience:
  • Prominent manual entry fallback
  • Pre-fill selected fields
  • Request EIN after selection
By following these practices, Pre.Fill becomes a powerful tool for reducing friction and improving conversion while maintaining strong fraud prevention and verification standards.