Troubleshooting and FAQs

Common errors

The table below outlines common issues that may occur when using Socure Prefill in RiskOS™. These may stem from input formatting, incomplete data, provisioning gaps, or conflicting identity signals. Understanding these patterns helps fine-tune workflows, reduce null responses, and decide when fallback or escalation logic is needed.

Issue	Explanation	Suggested fix
No match / empty response	Inputs conflict, are incomplete, or do not resolve to a single SocureID.	Ensure consistent PII. Encourage users to provide accurate inputs. Prefill only returns data for a confident match.
Missing fields	Thin credit file, regional restrictions, or sparse data source coverage.	Anticipate incomplete attributes. Do not assume all fields will be populated.
Invalid input formatting	Incorrect formats (e.g., phone not in E.164).	Validate and normalize inputs before submission.
Not provisioned for Prefill	Workflow is missing entitlements for Prefill.	Confirm Prefill is enabled in your RiskOS™ environment.
API misconfiguration	Module not included in request (e.g., missing `"modules": ["prefill"]`).	Add correct module, confirm API key authentication, IP filtering, and workflow configuration.
Workflow rejection handling	Prefill data incorrectly exposed after a rejection.	Do not display Prefill results to end users if workflow returns a rejection.
Rate limiting / performance	High request volume or batch processing may hit rate limits.	Monitor API response times. Review rate limit documentation or consult support.
Third-party data variance	External data sources may return partial or inconsistent results.	Parse Prefill outputs carefully; handle nulls or partial matches gracefully in downstream workflows.

How to debug

To debug Prefill behavior in RiskOS™:

Use the eval_id to trace execution in the Developer Console or RiskOS logs.
Check the status_code in each data_enrichments[] block. 200 indicates success. Any other status should be flagged.
Confirm the "modules": ["prefill"] block is present in your request.
Review output carefully — an empty {} means inputs did not align with a single SocureID.
Check provisioning status if Prefill is missing from workflow execution.
Monitor latency: typical Prefill responses are 250–400ms in U.S. production.

Fallback strategies

If Prefill does not return data:

Normalize and retry. Remove accents, fix casing/whitespace, reformat phone/email.
Collect more signals. Supplying multiple PII fields (e.g., phone + email) improves resolution confidence.
Escalate gracefully. Route inconclusive cases to manual review or alternate enrichment modules.

Escalation path

For production-impacting issues or debugging edge cases:

Reproduce the issue. Do this in sandbox or staging if possible.
Capture identifiers. Collect the following:
- eval_id
- Full request payload
- Workflow name
Open a support ticket. Contact Socure Support or your Technical Account Manager (TAM) with:
- Workflow configuration
- Input fields submitted
- Expected vs. actual Prefill output
- Logs or screenshots (if applicable)
Urgent escalation. For high-severity cases, escalate via Slack (if integrated) or your designated Socure escalation channel.

Known issues

International support is phone-only. Prefill cannot use email, SSN, or address signals outside the U.S.
Prefill is enrichment only. It does not perform compliance-grade verification (use Verify/Verify Plus for CIP/KYC).
Thin-file variance. Limited coverage for minors, new-to-credit, or sparse-data identities is expected.
Normalization quirks. Non-standard characters or unnormalized Unicode may cause null results. Pre-process inputs before submission.
Provisioning gaps. Missing entitlements will result in silent failures or skipped enrichments.

ℹ️
Note: Use the Developer Console to inspect raw Prefill requests/responses and confirm module execution in real time.

FAQs

General product behavior

What is Prefill?

Prefill is Socure’s identity autofill capability that enriches user data from minimal PII (e.g., name + one identifier such as phone, email, SSN/ITIN, or address). It returns a best-matched identity record (full name, DOB, address, etc.) to accelerate onboarding, reduce manual entry, and enrich customer profiles. Prefill does not perform additional risk or device checks.

What is Advanced Prefill?

Advanced Prefill builds on Prefill by combining autofill with real-time risk intelligence. With just minimal inputs (e.g., phone + SSN last 4), it can:

Enrich identity data
Validate against Socure’s Identity Graph
Incorporate OTP flows
Add device risk signals to block fraud while maximizing conversion

For implementation details, see the Advanced Prefill Use Case Guide.

When should I use Prefill vs. Advanced Prefill?

Use Prefill for back-office workflows, pre-population, and agent review scenarios where speed and enrichment are the priority.
Use Advanced Prefill for consumer-facing onboarding and signup flows where you need both autofill and strong fraud prevention.

Does Advanced Prefill replace Prefill?

No. Prefill remains valuable for enrichment and internal workflows. Advanced Prefill is best when you need identity autofill plus fraud prevention in a customer-facing flow.

Why didn’t I get any data back?

This happens when inputs could not be resolved to a single identity, or when inputs pointed to multiple or conflicting identities.
In such cases, Prefill returns an empty object ({}) rather than a partial or ambiguous match.

Can Prefill return partial matches?

No. Prefill only returns data when all signals resolve to one trusted identity.
It will never return partial or inconsistent results.

What if some fields are missing in the response?

This is expected and usually results from:

Thin or limited credit files
Privacy-restricted data sources
Provisioning or configuration limits

What happens if there’s no match for Prefill?

If Prefill cannot confidently resolve inputs—or detects a synthetic identity—it returns an empty object ({}).
No error is thrown, and clients should handle empty/null responses gracefully.

Performance and usage

How fast is Prefill?

Typical response times:

U.S.: 250–400ms
International: Under 4s

How is Prefill different from Verify or Verify Plus?

Prefill is designed for form autofill and identity enrichment.
Verify and Verify Plus are designed for compliance-grade CIP/KYC coverage, including partial SSN handling.

Data return and customization

Can Prefill return only specific attributes (e.g., just address)?

Yes. Workflows can be configured to return only required attributes.

By default, Prefill outputs:

First and last name
Date of birth
Up to 3 phone numbers
Up to 3 addresses
SSN or national ID

Returning subsets (e.g., only address or name) reduces data exposure and optimizes pass rates.

Can Prefill return ITINs or national IDs when SSNs aren’t available?

Yes. Depending on the input PII and account provisioning, Prefill may return:

ITINs
Full SSNs
National IDs (for international users)

How can I use a prefilled SSN (or other prefilled data) to send to 3rd parties for my business needs?

If you display it to your consumer and ask them to confirm it, then it becomes consumer-submitted data subject to your internal policies.

Exposure and UX

Can prefilled data be shown directly to consumers?

Yes. With Advanced Prefill, B2C flows are supported where users can review and edit prefilled data.

Requirements include:

Proper consent language in the client UI
Compliance and carrier rules followed
Best-practice UI guidelines and T&Cs applied

Foundation / Background

What powers Socure’s Prefill capability?

Prefill is powered by Socure’s Identity Graph, which aggregates and resolves identity data across multiple trusted sources:

2,800+ enterprise customers spanning 40+ industries
Telco data for real-time phone and device intelligence
Credit bureau data for financial and historical context
External and third-party identity sources

This multi-source foundation enables Prefill to deliver verified, high-quality identity attributes with consistent coverage.

What if the identity looks synthetic?

Prefill will return no data.

The entry is flagged internally and may be removed from the identity graph.
Clients should log or flag these events for future analysis.