Phone Risk Troubleshooting & FAQs

Common errors

The table below outlines common errors that may occur when calling the Phone Risk enrichment. These issues often stem from input formatting, incomplete or invalid data, velocity anomalies, or evolving model behaviors. Understanding these patterns can help you fine-tune workflows, reduce false positives, and determine when escalation or fallback logic is appropriate.

Issue	Explanation	Suggested fix
Low correlation or unexpected risk scores	Name and phone number do not historically correlate; international numbers have lower coverage; business/role-based numbers often show weak correlation.	Review troubleshooting page. If capturing address as a supporting signal, submit apartment/unit in a dedicated field, ensure USPS formatting, and validate with an address verification service before submission.
Missing or invalid output	Required fields (e.g., phone number) not provided; request payload not structured correctly; unsupported characters or encoding issues.	Confirm required fields are present (at minimum `data.individual.phone_number` in E.164). Check field names against docs. Ensure UTF-8 encoding; remove unsupported symbols and whitespace artifacts.
Frequent errors or API failures	Rate limits exceeded; authentication issues; incorrect endpoint usage.	Monitor request volume vs. rate limits. Verify API keys/tokens are valid/active. Confirm endpoint URLs and check for recent API updates in DevHub/Docs.
Unexpected model behavior after release updates	Model version changed with new logic or data sources; thresholds/decision rules not updated to align to latest version.	Check current model version returned in `phoneRisk.scores[].version`. Review release notes for scoring changes. Re-evaluate thresholds and rules; contact Socure for tuning recommendations.

How to troubleshoot results

If Phone Risk results appear unexpected or incomplete, start with the following checks:

Confirm inputs were provided correctly: Verify that the phone number was included in the request and formatted consistently, and that required supporting fields (such as country information) were provided where applicable.
Verify enrichment execution: Ensure that the Phone Risk enrichment was included in the workflow and executed as expected for the request being evaluated.
Review returned outputs: Check that risk scores, correlation values, or explanatory indicators were returned, and that they align with the inputs provided.
Evaluate correlation context: Name–phone correlation results depend on the availability and consistency of name attributes. If name information is missing or inconsistent, correlation outputs may be limited.
Assess results in context: Phone Risk signals are intended to be interpreted alongside other workflow signals and business rules, rather than in isolation.

Fallback strategies

If Phone Risk does not yield a clear result:

Reprompt for correction. Ask users to re-enter the phone number in E.164 format (+ country code + national number).
Chain enrichments. Use email risk, document verification, device risk, or address signals for additional confidence.
Step up verification. Trigger OTP or documentary verification when high-risk reason codes are present.
Escalate to review. Use tags or review_queues to route suspicious or inconclusive cases to analysts.

Escalation path

For production-impacting issues or debugging edge cases:

Reproduce the issue. Try in sandbox/staging with the same payload.
Capture identifiers. Collect:
- eval_id
- Full request payload
- referenceId from the Phone Risk enrichment
Open a support ticket. Contact Socure Support or your Technical Account Manager (TAM) with:
- Workflow name
- Input fields submitted
- Expected vs. actual decision
- Logs or screenshots (if applicable)
Urgent escalation. For high-severity cases, escalate via:
- Slack (if integrated)
- Your designated Socure escalation channel

Known issues

International coverage variability. Some markets have thinner data; correlation may be lower for certain country/number types.
Business/role-based numbers. Corporate PBX or shared service lines typically have weak name–phone correlation.
Number portability/recycling. Recently ported or recycled numbers can produce inconsistent signals until history stabilizes.
Formatting & normalization. Non-E.164 or unnormalized Unicode can cause validation failures; normalize before submission.
Durable vs. risky signals. Consider positive indicators (e.g., long-tenured carrier history) alongside neutral risk scores when tuning decisions.

📘

Note:

Use the Developer Console to view raw request/response logs in real time for debugging or validation.

FAQs

Phone Risk general product behavior

Which regions are supported?

Phone Risk is available in multiple regions, with coverage expanding over time. Availability and signal depth may vary by country. Refer to product documentation or contact Socure Support for the most up-to-date information on regional availability.

How does Phone Risk behave across different regions?

Phone Risk returns signals based on the data available for a given region. In some regions, certain scores or correlations may be limited or unavailable. Results should be interpreted in the context of regional data coverage and combined with other signals where appropriate.

Do integrations need to change for international use?

Phone Risk is accessed through the same integration regardless of region. Behavior and available outputs depend on the inputs provided and the supported capabilities for the evaluated country.

Are signals consistent across regions?

Signal availability and interpretation may vary by region due to differences in data sources and regional considerations. Where possible, outputs are aligned to a consistent schema to support unified workflow logic.

SIM Swap

What is SIM swap fraud?

SIM swap fraud occurs when control of a phone number is transferred without the subscriber’s authorization. This can allow attackers to intercept communications or bypass SMS-based verification.

What is SIM swap verification?

SIM swap verification is a risk signal used to identify whether a phone number has recently experienced a SIM change, which may indicate elevated fraud or account takeover risk.

How are SIM swap signals used?

SIM swap indicators are evaluated alongside other phone risk signals and can be used to inform review, escalation, or additional verification decisions within a workflow.

Who provides SIM swap signals?

SIM swap signals are derived from telecommunications data sources and integrated into Socure’s risk assessment capabilities where supported.

What are common use cases for SIM swap signals?

SIM swap signals are commonly used to strengthen risk assessment for sensitive actions such as account recovery, high-value transactions, or changes to authentication credentials.

Are all phone providers supported for SIM swap signals?

SIM swap signal availability depends on provider participation and data access. Coverage may vary across regions and providers.

Why is SIM swap coverage variable?

SIM swap data availability depends on how phone service providers manage subscriber information and expose relevant data for verification.

How long does it take to enable SIM swap support?

Enabling SIM swap support may require additional configuration and coordination, depending on region and provider capabilities.

What detection window is used for SIM swap signals?

SIM swap indicators evaluate recent activity based on configurable parameters defined during setup.

What is required to use SIM swap verification?

Use of SIM swap signals may require additional agreements or configuration steps, depending on regional and provider requirements.