Troubleshooting

Common errors

The table below outlines common errors that may occur during evaluation with Sigma First-Party Fraud. These issues can result from missing fields, configuration mismatches, or upstream provider behavior. Understanding these patterns can help fine-tune workflows, reduce false positives, and determine when escalation or fallback logic is appropriate.

Issue	Explanation	Suggested fix
400 Bad Request	Missing required parameters (often `disclosure_purpose` or SSN/PII).	Ensure all required fields are included and formatted correctly before submission.
403 Forbidden	API key not provisioned for FPF module or request not from allowlisted IP.	Verify provisioning with your Socure account team and confirm IP allowlisting is set correctly.
404 Not Found	Invalid endpoint or workflow name.	Check your RiskOS™ configuration and confirm the workflow name is valid.
500 Server Error	Occasional system outages or upstream provider issues.	Retry later; check status.socure.com for real-time system updates.
Schema / Field Mapping errors	Submitted request schema does not match the configured workflow.	Validate request payload against published schema and your RiskOS™ workflow configuration.
Decisioning anomalies	Unexpected result despite valid input.	Confirm all recommended PII is submitted (email, phone, address) and check data quality.

How to debug

To debug First-Party Fraud module behavior in RiskOS™:

Inspect the API response for error_code, reasonCodes, and signals fields.
Use the RiskOS logs or Developer Console to trace the most recent request/response cycle by eval_id.
In Workflow Builder, use Validate and Test features for point-in-time debugging.
If webhooks are not firing:
- Confirm endpoint registration
- Verify authentication settings
- Inspect webhook logs in the RiskOS™ Dashboard

Fallback strategies

If Sigma First-Party Fraud does not yield a confident result:

Route to manual review – Send inconclusive (REVIEW) cases to risk ops.
Retry – Reattempt API calls if network/transient failures occur; for 4xx errors, correct inputs before retrying.
Chain enrichments – Escalate to additional modules such as Document Verification or secondary ID checks.
Audit data quality – Periodically review PII completeness and field mapping to ensure high match accuracy.

Escalation path

For production-impacting issues or debugging edge cases:

Reproduce the issue – Ideally in sandbox or staging.
Capture identifiers – Collect:
- eval_id
- Full request payload
- referenceId from the First-Party Fraud enrichment (if available)
Open a support ticket – Contact Socure Support or your Solutions Consultant team with:
- Workflow name
- Input fields submitted
- Expected vs. actual decision
- Logs or screenshots (if applicable)
Urgent escalation – For severe cases, escalate via:
- Your TAM escalation channel
- Support SLAs: 1 hour for P1, 4 hours for P2

Known issues

Schema evolution – Risk signals and response schema may evolve; check release notes and changelogs for the latest mapping.
Latency spikes – Model deployments or retrains may occasionally cause short-lived latency spikes (see status.socure.com).
Consortium dependency – Performance depends on active consortium data contribution; gaps in participation may reduce coverage or signal accuracy.