Security Questions to Ask Before Sending User Data to a Fraud Detection API

Every sign-up check, lead form score, and email risk lookup sends personal data to a third party. An email address, an IP address, and sometimes a phone number or a session fingerprint leave your systems and land in someone else's. That makes fraud detection API security a vendor-review question, not just an integration detail. Before you wire a risk API into your registration flow, your security and compliance team should know how the vendor authenticates requests, who can reach the dashboard, what happens to the data, how vulnerabilities get reported, and what independent assurance actually exists today. This guide gives you the questions to ask, explains what a credible answer looks like, and then shows how Opportify answers each one right now.

Why Identifier Data Deserves a Vendor Review

Fraud and risk APIs are unusual among third-party services. They are called on your most sensitive entry points, often before a user has an account, and the payload is made of identifiers: emails, IPs, device and behavioral signals. Those identifiers are personal data under most privacy regimes.

Under the GDPR, a vendor that processes personal data on your behalf is a processor, and Article 28 requires controllers to use only processors "providing sufficient guarantees to implement appropriate technical and organisational measures," under a written contract. In practice, that means your team needs evidence, not adjectives.

The API itself is also an attack surface. The OWASP API Security Top 10 (2023) lists Broken Authentication as API2, and flags APIs that send "sensitive authentication details, such as auth tokens and passwords in the URL." A fraud vendor that handles credentials or identifiers carelessly becomes a new risk in the flow you were trying to protect.

The Fraud Detection API Security Question List

Use the questions below as a starting point for your own review. They are grouped so that different owners (security engineering, compliance, legal) can take a section each.

Authentication and Access to the API

1. How are API requests authenticated? Look for a key or token sent in a header, never in the URL or query string.
2. Can we create, scope, and rotate multiple keys? You want to rotate a key without downtime and revoke one integration without touching others.
3. Can we restrict which networks can call the API? IP allowlisting is a simple, effective control for server-side integrations.
4. Does the API fail closed? If authorization cannot be confirmed, the request should be refused rather than served.
5. Is there per-account rate limiting? Rate limits protect both the vendor and you from a leaked key being abused at volume.

Access to the Dashboard

1. Does the dashboard support SSO, and with which identity providers? Ask for the list as it stands today, not a roadmap.
2. Is multi-factor authentication available for customer accounts? The OWASP API Security Top 10 advises: "Where possible, implement multi-factor authentication."
3. Is there an account activity log? Logins and new-device access should be visible to you, with a stated retention period.
4. How is the vendor's own workforce access controlled? Ask whether staff use SSO with enforced MFA, role-based access, and whether long-lived production credentials exist.

Data Handling and Retention

1. What exactly is stored, in what form, and for how long? "We take privacy seriously" is not an answer. Hashing, retention periods, and what is never persisted are answers.
2. Is data encrypted at rest and in transit?
3. Who are the sub-processors, where are they, and how will we hear about changes? A published list and a notice period for new sub-processors are good signs.
4. Is there a Data Processing Addendum you can read before signing? A public DPA lets legal review terms early.
5. What happens to our data when the contract ends?

Vulnerability Disclosure and Incident Handling

1. Is there a published vulnerability disclosure policy? It should define scope, how to report, and how researchers acting in good faith are treated.
2. Is there a security.txt file? RFC 9116 defines this machine-parsable format "to help organizations describe their vulnerability disclosure practices."
3. How will you notify us of a personal data breach? Look for contractual language in the DPA, not only a marketing page.

Independent Assurance

1. What attestation or certification do you hold today? Ask for the report or certificate itself.
2. If none yet, what is mapped and what is on the roadmap? A clear, dated status is more useful than vague "alignment."
3. Which completed questionnaires can you share, and under what terms? Standard questionnaires save both sides time.

Outputs and Decisions

1. Are the vendor's outputs advisory or automated decisions? This matters for your own obligations around automated decision-making.
2. Can we see why a score is high? Explainable reason codes let your team review edge cases and handle false positives.
3. Who sets the thresholds? Your policy should stay yours.

What Good Answers Look Like: Evidence, Not Adjectives

Some answers can be checked in minutes. Others need documents under NDA. Here is how to tell them apart.

Self-Assessment Versus Independent Attestation

These are often blurred together in sales conversations, so it helps to be precise.

• A self-assessment questionnaire is completed by the vendor about itself. The Vendor Security Alliance publishes VSA-Core, which covers "the most critical questions on vendor security in addition to privacy." The Cloud Security Alliance STAR program offers the Consensus Assessment Initiative Questionnaire (CAIQ). These are useful and standardized, but they are statements by the vendor.
• An independent attestation is an examination by an outside auditor. A SOC 2 report, as described by the AICPA, reports on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy.
• A control mapping shows how a vendor's controls line up with a framework such as the SOC 2 Trust Services Criteria. It is preparation work, not an audit result.

A vendor that tells you plainly which of these it has, and which it does not, is giving you something you can put in a risk register.

Green Flags and Red Flags

Green flags:

• Public pages you can link in your review: a security page, a vulnerability disclosure policy, a DPA, and a sub-processor list.
• Specific statements: named controls, retention periods, and status labels such as "on the roadmap."
• Response targets described honestly as targets rather than dressed up as contractual commitments.

Red flags:

• "Compliant with" a framework, with no report to share.
• Uptime numbers presented as commitments with no service level agreement behind them.
• Credentials accepted in query strings.
• A vulnerability disclosure process that only exists as a general contact form.

How Opportify Answers Today

Opportify provides fraud and risk intelligence through Fraud Protection, Email Insights, and IP Insights. Below are our current answers, each linked to the public page where you can verify it.

API Authentication and Access Controls

• Header-based API keys. Requests authenticate with an x-opportify-token header, as shown in the quick start in our documentation.
• No secrets in query strings. Our FAQ states that "secrets or personal information should never be included in query parameters. Always send them in headers or the request body."
• Key rotation. The FAQ describes rotating keys by generating a new key, deploying it, and removing the old one after confirming it works, with a brief overlap to avoid downtime.
• IP restriction. Our FAQ describes ACL Rules as "optional allowlists of IP addresses," so only requests from listed IPs are accepted.
• Fail-closed authorization and rate limiting. Our Trust Center lists "Fail-closed API authorization with optional IP allowlists," "Signed, time-bound tokens" designed against replay and cross-origin reuse, and "Per-account rate limiting and quota enforcement."

Dashboard SSO and MFA

Our Trust Center lists, under access control:

• "Customer SSO with Google, Microsoft, and more, plus two-factor authentication and login rate limiting"
• "Account activity log of logins and new-device access, retained for 12 months"
• "Workforce SSO with enforced MFA, role-based access, and no long-lived production credentials"

Data Protection and Sub-Processors

• Encryption and storage. The Trust Center lists "Encryption at rest and in transit; customer-managed keys for sensitive data" and "Emails and fingerprints stored as one-way hashes; raw IPs not persisted," with short retention on cached identifiers.
• Infrastructure. Production and staging run in separate AWS accounts, with data in private subnets and a database that is not publicly reachable.
• Public DPA. Our Data Processing Addendum covers breach notification without undue delay, at least 30 days' notice before engaging a new sub-processor, Standard Contractual Clauses for international transfers, and deletion or return of data at the end of the agreement. For Fraud Protection, analysis results are retained for 120 days by default, configurable in the dashboard, and raw behavioral signals are not stored beyond the session.
• Sub-processor list. Our sub-processors page names the platform sub-processors that handle analyzed data and separately lists operational vendors that do not receive it. You can subscribe there to be notified of changes.

Vulnerability Disclosure

Our Vulnerability Disclosure Policy covers our website, dashboard, and public APIs. Reports go to security@opportify.ai, and our PGP key is published through security.txt. The policy includes a safe harbor statement for good-faith research, a coordinated disclosure window of up to 90 days, and, if you would like, credit by name or handle when a report leads to a fix.

We aim to acknowledge valid reports within five business days. As the policy states, these are target response times, not a contractual service-level commitment.

Attestation and Questionnaire Status

We prefer to be exact here. As our Trust Center says, "We do not yet hold independent certifications."

Item	Status today
Data handling aligned with GDPR, UK GDPR, and CCPA principles	Active
VSA-Core and CSA CAIQ	Completed self-assessments, shared under NDA on request
CSA CCM, SOC 2 Trust Services Criteria, ISO/IEC 27001	Controls mapped via a control matrix
SOC 2 attestation, ISO/IEC 27001 and CSA STAR certification	On the roadmap
Third-party penetration test summary	On the roadmap

Our Security Overview, completed questionnaires, security policies, and a shared responsibility guide for API customers are available on request under NDA through the Trust Center.

Uptime

We run on reliable, high-availability infrastructure with independent uptime monitoring. Uptime figures for self-serve accounts are service goals, not a service level agreement. A formal SLA applies only when agreed in a separate written addendum signed by both parties.

Advisory Outputs

Opportify scores and flags. Your team decides. Our Terms and Conditions state that the services "provide automated risk assessment signals only and do not make automated decisions regarding individuals," and that output scores are advisory. Scores come with reason codes (in Email Insights, the Explainable Risk Report), so reviewers can see why a score is high, and you set the thresholds and actions that fit your policy.

Getting Started With Your Review

1. Collect the public evidence first. Save links to the vendor's security page, disclosure policy, security.txt, DPA, and sub-processor list.
2. Send the question list above. Ask for answers with links or documents, and note which items are on a roadmap.
3. Request NDA documents. Ask for completed questionnaires and any security overview or shared responsibility guide.
4. Test the integration controls. Confirm header authentication, key rotation, and IP restrictions in a non-production environment.
5. Decide on your policy. Agree internally how scores map to actions, and who reviews flagged cases.

To start a review of Opportify, visit our Trust Center or read about Fraud Protection. See pricing for current plans.

Key Takeaways

• Fraud and risk APIs process personal identifiers at your most sensitive entry points, so they deserve a full vendor review.
• Ask specific questions about API authentication, dashboard SSO and MFA, data retention, sub-processors, disclosure, and attestation.
• Distinguish self-assessments, control mappings, and independent attestations. They are not interchangeable.
• Treat response times and uptime figures as targets unless a contract says otherwise.
• Keep decisions with your team: a fraud API should score, flag, and explain, while your policy sets the response.