Troubleshooting and FAQs

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.

FAQs

Usage & Access

How can this product be used outside of RiskOS™?

Sigma First-Party Fraud is available through Socure’s API-based integrations in addition to RiskOS™ workflows. Availability depends on your product configuration and enabled integrations.

Integration and input formatting

Are certain data inputs required?

Sigma First-Party Fraud evaluates the identity and account attributes provided with each request. Core identity attributes typically include name, date of birth, government identifiers, and address. Providing more complete inputs improves matching and overall risk assessment.

What is expected latency and performance?

Response times and performance characteristics vary based on integration type, input completeness, and request volume. High-throughput or batch use cases may require coordination with Socure to ensure appropriate configuration.

Can thresholds or other configuration options be customized?

When used within RiskOS™, Sigma First-Party Fraud can be incorporated into workflows that route activity based on scores, reason codes, and supporting signals. Organizations define usage according to their fraud policies and operational requirements.

Output and interpretation

How are reason codes and risk signals interpreted?

Reason codes highlight contributing factors associated with elevated first-party fraud risk, while risk signals provide additional context across identity, account, application, and transaction activity to support investigation and decisioning.

What is the difference between third-party and first-party fraud detection?

Third-party fraud typically involves misuse of stolen or synthetic identities, while first-party fraud involves abuse or misuse by individuals operating under their own identity, often reflected through behavioral patterns over time.

Testing and validation

Are there standard test scenarios?

Socure provides testing and validation resources to support implementation and evaluation of Sigma First-Party Fraud. Available options depend on your integration type and configuration.

Does the solution support batch or portfolio analysis?

Sigma First-Party Fraud supports a range of evaluation approaches depending on customer needs and configuration. Contact Socure to discuss available options.

Troubleshooting and support

What should I do if results appear unexpected?

If results appear incomplete or unexpected, verify that required inputs are being provided and that the integration is configured as intended. For additional assistance, contact Socure Support.

Compliance and usage considerations

How should Sigma First-Party Fraud be used in regulated environments?

Sigma First-Party Fraud is designed to support fraud risk assessment. Organizations are responsible for ensuring usage aligns with applicable laws, regulations, and internal policies.