KYC fraud reduction

​

The threat

• Synthetic identities. Fabricated or Frankenstein PII (real SSN, fake name; real name, fake DOB) submitted through automated browsers. Individual submissions may pass the KYC vendor’s checks because the underlying data points look plausible; the tell is the browser operating the form, which Tripwire sees.
• Identity farming. Operator runs dozens or hundreds of accounts through KYC on one device using different PII each time, then resells the verified accounts. Every individual submission looks fine; the durable visitor fingerprint betrays the pattern.
• Anti-detect browser fraud. Multilogin, GoLogin, Kameleo, and similar tools specifically exist to defeat device fingerprinting — the KYC fraud market is their primary customer base. These environments push Tripwire’s overall risk_score up even when the behavioral profile looks human, and the durable session’s runtime_integrity surface explicitly flags tampering and virtualization.
• Liveness / video bypass. Virtual cameras, deepfakes, and face-swap tooling target the selfie/liveness step. This is primarily the KYC vendor’s problem, but the browser environment used to run the bypass often trips Tripwire’s virtualization and anti-tamper signals.

​

The flow

​

Client integration

<script type="module">
  const tripwirePromise = import("https://cdn.tripwirejs.com/t.js").then(
    (Tripwire) =>
      Tripwire.start({
        publishableKey: "pk_live_your_publishable_key",
      }),
  );

  const submitButton = document.querySelector("#kyc-submit");
  submitButton.disabled = true;

  tripwirePromise.then(async (tripwire) => {
    tripwire.onError((error) => {
      console.error("Tripwire error", error.code, error.message);
    });

    await tripwire.waitForFingerprint();
    submitButton.disabled = false;
  });

  async function submitKyc(formData) {
    const tripwire = await tripwirePromise;
    const { sessionId, sealedToken } = await tripwire.getSession();

    return fetch("/api/kyc/submit", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        ...formData,
        tripwire: { sessionId, sealedToken },
      }),
    });
  }
</script>

​

Server verification

const { Tripwire, safeVerifyTripwireToken } = require("@abxy/tripwire-server");
const client = new Tripwire({ secretKey: process.env.TRIPWIRE_SECRET_KEY });

const KYC_RISK_SCORE_THRESHOLD = 0.3;

app.post("/api/kyc/submit", async (req, res) => {
  const tr = safeVerifyTripwireToken(
    req.body.tripwire.sealedToken,
    process.env.TRIPWIRE_SECRET_KEY,
  );

  // 1. Fail closed — no valid token, no KYC.
  if (!tr.ok) {
    return res.status(403).json({ status: "rejected", reason: "verification_failed" });
  }

  const { decision, attribution, visitor_fingerprint } = tr.data;

  // 2. Hard block obvious automation before paying the KYC vendor.
  if (decision.verdict === "bot") {
    await logKycRejection({ reason: "bot", decision, kycPayload: req.body });
    return res.status(403).json({ status: "rejected", reason: "automation_detected" });
  }

  // 3. Human verdict but elevated score — KYC is a stricter surface than
  //    signup or checkout. A borderline score warrants manual review even
  //    when the top-level verdict is "human".
  if (decision.risk_score >= KYC_RISK_SCORE_THRESHOLD) {
    await flagForManualReview({ reason: "elevated_risk_score", decision });
    return res.json({ status: "manual_review" });
  }

  // 4. Identity farming — has this device already completed KYC?
  if (visitor_fingerprint?.id) {
    const priorClaims = await findPriorKycByVisitor(visitor_fingerprint.id);
    if (priorClaims.length > 0 && priorClaims.some((c) => c.userId !== req.session.userId)) {
      await flagForManualReview({ reason: "identity_farming", priorClaims });
      return res.json({ status: "manual_review" });
    }
  }

  // 5. Forward to the KYC vendor with Tripwire metadata attached.
  const vendorResult = await kycVendor.verify({
    user: req.body.user,
    documents: req.body.documents,
    metadata: {
      tripwire_session_id: req.body.tripwire.sessionId,
      tripwire_verdict: decision.verdict,
      tripwire_risk_score: decision.risk_score,
      tripwire_visitor_id: visitor_fingerprint?.id ?? null,
    },
  });

  // 6. Layered decision — inconclusive Tripwire + vendor "approved" = manual review.
  if (decision.verdict === "inconclusive" && vendorResult.status === "approved") {
    await flagForManualReview({ reason: "tripwire_inconclusive_despite_vendor_approval" });
    return res.json({ status: "manual_review" });
  }

  await recordKycResult({
    userId: req.session.userId,
    visitorId: visitor_fingerprint?.id ?? null,
    tripwireVerdict: decision.verdict,
    tripwireRiskScore: decision.risk_score,
    vendorResult,
  });

  res.json({ status: vendorResult.status, verified: vendorResult.status === "approved" });
});

​

Layered decision matrix

• Never auto-approve on vendor-only signal for a KYC-gated flow. If Tripwire’s risk_score is elevated or the verdict is inconclusive, the vendor saying “approved” is not enough to promote an account to its full permission set.
• Use a stricter risk_score threshold than you would on other surfaces. Tripwire’s default bot/human cutoff is tuned for broad use across signup, login, and content surfaces; KYC’s false-negative cost justifies treating anything above roughly 0.3 as worth a human look.

​

Runtime integrity: deeper environment signal

const session = await client.sessions.get(sessionId);
const ri = session.runtime_integrity;
// {
//   tampering_detected: boolean,
//   developer_tools_detected: boolean,
//   emulation_suspected: boolean,
//   virtualization_suspected: boolean,
//   privacy_hardening_suspected: boolean,
// }

• Durable read on every KYC submission. One extra API call per verification; negligible next to the cost of the KYC vendor itself.
• Durable read only on borderline cases. Fast path on clean human + low-score submissions; fetch the durable session for everything else, including the manual_review paths in the code above.

​

Identity farming: cross-session correlation

async function findSuspiciousKycHistory(visitorId) {
  const fingerprint = await client.fingerprints.get(visitorId);

  // Count distinct accounts that have run KYC from this device
  const priorKyc = await db.query(
    "SELECT DISTINCT user_id, submitted_at FROM kyc_submissions WHERE visitor_id = $1 ORDER BY submitted_at DESC",
    [visitorId],
  );

  return {
    seenCount: fingerprint.lifecycle.seen_count,
    firstSeenAt: fingerprint.lifecycle.first_seen_at,
    distinctKycAccounts: priorKyc.rows.length,
    priorBotSessions: fingerprint.activity.sessions.filter(
      (s) => s.decision.verdict === "bot",
    ).length,
  };
}

• 2+ distinct accounts from the same visitor fingerprint completing KYC → manual review. Real households exist, but KYC-gated flows rarely involve two adults on the same device.
• Any prior verdict: "bot" on that fingerprint in the last 90 days → manual review. The device has failed Tripwire before.
• lifecycle.seen_count > 50 with first-seen under 24 hours → auto-reject. That’s a headless browser being spun up repeatedly on one machine.

​

Attaching Tripwire signal to the vendor

• Vendor-side rules. Modern KYC platforms (Alloy, Sardine, Socure, Sumsub rules engine) let you write decisioning on custom fields. “Decline if tripwire_risk_score >= 0.3 AND document score below 0.9” is a one-line rule that would otherwise require integrating Tripwire into the vendor’s system separately.
• Post-hoc reconciliation. When a chargeback, SAR, or compliance audit surfaces a KYC approval months later, the Tripwire session ID stamped on the vendor record lets you pull GET /v1/sessions/:sessionId and recover the full device evidence — including runtime_integrity and signals_fired — from the time of submission.

{
  "tripwire_session_id": "sid_...",
  "tripwire_verdict": "human",
  "tripwire_risk_score": 0.12,
  "tripwire_visitor_id": "vis_...",
  "tripwire_attribution_category": "human"
}

​

Post-KYC monitoring

• Every login (see Login & credential stuffing).
• Payout / withdrawal / transfer initiation.
• Limit-increase requests (the typical next step after compromise).
• Any sensitive setting change — email, password, 2FA, beneficiary.

​

What’s next