Fraud consent

The fraud module collects passive signals (device characteristics, behavioral patterns) to support fraud detection on your platform. By default, it does not start. Collection begins only after the applicant explicitly grants consent through a consent gate you control.

Host responsibility: you are responsible for presenting a meaningful consent disclosure to the applicant before calling onConsent. What you disclose and how must satisfy your applicable privacy regulations. The SDK does not render a consent UI.

What is collected

The fraud module collects browser and device signals that can help identify automated or anomalous behavior. No biometric data is collected by the fraud module. No personal identifiers beyond what your session already contains are sent.

The exact signal set is subject to change as the module evolves. For a complete list of data collected and the applicable privacy disclosures, see the data processing section of the console under Settings -> Data and privacy.

Wiring the consent gate

The fraud module is consent-gated by design. What happens when onConsent is missing or declined depends on how you mount; see Default-deny behavior below.

Via mountProvisioned (recommended):

client.mountProvisioned({
  target: document.getElementById('idv-container'),
  onConsent: async () => {
    // This callback is called when the declared session modules include
    // the consent-gated fraud module. You must present a disclosure to
    // the applicant and resolve only if they grant consent.
    const granted = await showConsentDialog();
    if (!granted) {
      throw new Error('consent_denied'); // fraud module stays off
    }
    // Resolve without throwing to start the fraud module.
  },
  onEvent: (event) => console.log(event),
});

Via explicit mount:

client.mount('fraud', {
  // No `target` here: the fraud module has no visible UI.
  onConsent: async () => {
    const granted = await showConsentDialog();
    if (!granted) throw new Error('consent_denied');
  },
  onEvent: (event) => {
    if (event.type === 'checktiv.fraud.started') {
      // Collection is active.
    }
  },
});

Default-deny behavior

What happens when onConsent is missing or declined depends on how the fraud module was mounted:

mountProvisioned (and the mount() convenience, which mounts through it): if the session’s declared modules include fraud but no onConsent option was passed at all, the SDK emits a loud, developer-actionable checktiv.fraud.error (sdk_load_failed) explaining that the fraud module needs a consent gate, and continues rendering the other modules (IDV, custom form) normally. This is a developer integration mistake, not an applicant consent decision: the session declared fraud, and the gate was never wired up.

mount('fraud') explicitly, or an onConsent that resolves falsy or throws: the fraud module is a silent no-op. No agent starts, no error event is emitted, and no signals are sent. This applies whenever consent was actually asked for and declined (or the hook itself failed), regardless of which mount path asked for it.

In both cases the fraud outcome never affects the IDV module or the session verdict: a declined or omitted consent gate never blocks the applicant’s verification. Fraud signals are supplemental; the session proceeds normally with or without them.

On the CDN script-tag path, default-deny now reaches further than “does not start”: the fraud module’s code is not downloaded at all until onConsent resolves affirmatively. The script tag registers the module, but its collection code lives in a separate file the SDK fetches only after the gate is granted, so an applicant who declines never receives it. Nothing to configure and nothing to opt into. If you install from npm, your bundler resolves @checktiv/sdk-web/fraud at build time as before, so the code is present in your own bundle and the gate is what stops it running.

Consent disclosure guidance

Your consent disclosure should cover:

• That passive behavioral and device signals are collected during the verification session.
• The purpose: fraud prevention and platform integrity.
• How long the data is retained.

Review the data processing addendum in your Checktiv agreement and your own privacy policy to ensure alignment.

Related pages

• Quickstart - see how fraud consent fits into the full integration
• React - wire fraud consent from a React app via useChecktiv() and client.mount('fraud', { onConsent })