KYC fraud reduction

Foil sits alongside your KYC vendor, not in place of it. The vendor checks whether the identity is valid; Foil checks whether a real human at a real device is operating the form. Stacking the two catches fraud that passes each layer individually - especially synthetic-identity farms, anti-detect browsers, and repeat submissions from one device under many identities.

The threat

KYC-gated flows (fintech onboarding, crypto exchanges, gambling, lending, payouts, any “high-limit” account upgrade) attract some of the most well-funded browser automation on the public internet. The rewards per account are large enough to justify real investment: stolen identity kits bought on dark markets, anti-detect browsers ($100–$500/month retail), residential proxy pools, and increasingly LLM-driven agents that can fill forms and respond to vendor prompts autonomously. Four abuse patterns dominate:

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 Foil 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 visitor fingerprint betrays the pattern.
Anti-detect browser fraud. Anti-detect browsers exist specifically to defeat device fingerprinting, and fraud operations use them heavily. These environments push Foil’s overall risk_score up even when the behavioral profile looks human, and the stored session’s runtime_integrity object reports tampering and virtualization levels.
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 Foil’s virtualization and anti-tamper signals.

Against all four, Foil produces signal before the KYC vendor sees the request - cheap, high-precision, and useful in two ways: as a pre-check that stops obvious fraud before paying the vendor per-verification fee, and as an input to a layered decision for everything the vendor returns as “approved but we’re not sure.”

The flow

Start Foil when the KYC flow begins

This might be the “Upgrade your account” button or the start of a dedicated onboarding journey. KYC users spend time entering their details, which gives Foil time to collect evidence before they submit.

Call getSession() at submit

The handoff travels with the KYC payload. getSession() waits for fingerprinting to finish, so the token carries a visitor_fingerprint.id for cross-session correlation.

Pre-check the Foil verdict and risk score

Hard-block on bot. For human verdicts, apply a stricter risk_score threshold than you would on a lower-friction surface - a borderline score on a regulated flow usually warrants manual review.

Check the fingerprint's history

GET /v1/fingerprints/:visitorId - has this device run KYC before under a different identity?

Forward to the KYC vendor with Foil metadata attached

So the vendor’s own decision engine can incorporate the signal on their side.

Monitor post-KYC sessions

A verified account that starts behaving like automation later is a strong account-takeover or farming signal. Keep Foil on sensitive in-app actions.

Client integration

Start Foil when the KYC flow begins and call getSession() at submit. getSession() waits for fingerprinting to finish before it returns a handoff, so the token carries the visitor ID that the identity-farming checks below rely on. You don’t need to disable the submit button or call waitForFingerprint() first.

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

  async function getFoilHandoff() {
    try {
      const foil = await foilPromise;
      return await foil.getSession();
    } catch (err) {
      // Send the submission without a handoff. The server rejects it.
      return null;
    }
  }

  async function submitKyc(formData) {
    const foil = await getFoilHandoff();

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

If the script fails to load or getSession() fails, the page sends the submission without a handoff and the server rejects it, so the user sees an error instead of an unresponsive form.

Server verification

The pattern below uses a generic kycVendor.verify(...) placeholder. Substitute your identity-verification provider or your internal equivalent. The KYC_RISK_SCORE_THRESHOLD below is set at 30 as a starting point - well below Foil’s default bot verdict threshold (~70) but strict enough that genuinely suspicious sessions don’t auto-approve on a regulated flow. risk_score is an integer from 0 to 100; tune the threshold to your traffic.

const { Foil, safeVerifyFoilToken } = require("@abxy/foil-server");
const client = new Foil({ secretKey: process.env.FOIL_SECRET_KEY });

const KYC_RISK_SCORE_THRESHOLD = 30;

app.post("/api/kyc/submit", async (req, res) => {
  const tr = safeVerifyFoilToken(
    req.body.foil?.sealedToken,
    process.env.FOIL_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 Foil metadata attached.
  const vendorResult = await kycVendor.verify({
    user: req.body.user,
    documents: req.body.documents,
    metadata: {
      foil_session_id: tr.data.session_id,
      foil_verdict: decision.verdict,
      foil_risk_score: decision.risk_score,
      foil_visitor_id: visitor_fingerprint?.id ?? null,
    },
  });

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

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

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

from foil_server import Foil, safe_verify_foil_token
import os

client = Foil(secret_key=os.environ["FOIL_SECRET_KEY"])
KYC_RISK_SCORE_THRESHOLD = 30

@app.post("/api/kyc/submit")
def kyc_submit(request):
    tr = safe_verify_foil_token(
        (request.json.get("foil") or {}).get("sealedToken", ""),
        os.environ["FOIL_SECRET_KEY"],
    )

    if not tr.ok:
        return {"status": "rejected", "reason": "verification_failed"}, 403

    decision = tr.data.decision
    visitor = tr.data.visitor_fingerprint

    if decision.verdict == "bot":
        return {"status": "rejected", "reason": "automation_detected"}, 403

    if decision.risk_score >= KYC_RISK_SCORE_THRESHOLD:
        flag_for_manual_review(reason="elevated_risk_score", decision=decision)
        return {"status": "manual_review"}

    if visitor:
        prior = find_prior_kyc_by_visitor(visitor.id)
        if any(c["user_id"] != request.user.id for c in prior):
            flag_for_manual_review(reason="identity_farming", prior=prior)
            return {"status": "manual_review"}

    vendor = kyc_vendor.verify(
        user=request.json["user"],
        documents=request.json["documents"],
        metadata={
            "foil_session_id": tr.data.session_id,
            "foil_verdict": decision.verdict,
            "foil_risk_score": decision.risk_score,
            "foil_visitor_id": visitor.id if visitor else None,
        },
    )

    if decision.verdict == "inconclusive" and vendor.status == "approved":
        flag_for_manual_review(reason="foil_inconclusive_despite_vendor_approval")
        return {"status": "manual_review"}

    record_kyc_result(
        user_id=request.user.id,
        visitor_id=visitor.id if visitor else None,
        foil_verdict=decision.verdict,
        foil_risk_score=decision.risk_score,
        vendor_result=vendor,
    )
    return {"status": vendor.status, "verified": vendor.status == "approved"}

import foil "github.com/abxy-labs/foil-server-go"

const kycRiskScoreThreshold = 30

func kycSubmitHandler(w http.ResponseWriter, r *http.Request) {
    var body KycSubmitBody
    json.NewDecoder(r.Body).Decode(&body)

    tr := foil.SafeVerifyFoilToken(
        body.Foil.SealedToken,
        os.Getenv("FOIL_SECRET_KEY"),
    )
    if !tr.OK {
        writeJSON(w, 403, map[string]string{"status": "rejected", "reason": "verification_failed"})
        return
    }

    d := tr.Data.Decision

    if d.Verdict == "bot" {
        writeJSON(w, 403, map[string]string{"status": "rejected", "reason": "automation_detected"})
        return
    }

    if d.RiskScore >= kycRiskScoreThreshold {
        flagForManualReview("elevated_risk_score", tr.Data)
        writeJSON(w, 200, map[string]string{"status": "manual_review"})
        return
    }

    if v := tr.Data.VisitorFingerprint; v != nil {
        prior := findPriorKycByVisitor(v.ID)
        if hasOtherUsers(prior, currentUserID(r)) {
            flagForManualReview("identity_farming", tr.Data)
            writeJSON(w, 200, map[string]string{"status": "manual_review"})
            return
        }
    }

    vendor := kycVendor.Verify(body, tr.Data)
    if d.Verdict == "inconclusive" && vendor.Status == "approved" {
        flagForManualReview("foil_inconclusive_despite_vendor_approval", tr.Data)
        writeJSON(w, 200, map[string]string{"status": "manual_review"})
        return
    }

    recordKycResult(currentUserID(r), tr.Data, vendor)
    writeJSON(w, 200, map[string]any{"status": vendor.Status})
}

require "foil/server"

KYC_RISK_SCORE_THRESHOLD = 30

post "/api/kyc/submit" do
  body = JSON.parse(request.body.read)
  tr = Foil::Server::SealedToken.safe_verify_foil_token(
    body.dig("foil", "sealedToken"),
  )
  halt 403, { status: "rejected", reason: "verification_failed" }.to_json unless tr[:ok]

  decision = tr[:data][:decision]
  visitor  = tr[:data][:visitor_fingerprint]

  if decision[:verdict] == "bot"
    halt 403, { status: "rejected", reason: "automation_detected" }.to_json
  end

  if decision[:risk_score] >= KYC_RISK_SCORE_THRESHOLD
    flag_for_manual_review(reason: "elevated_risk_score")
    halt 200, { status: "manual_review" }.to_json
  end

  if visitor
    prior = find_prior_kyc_by_visitor(visitor[:id])
    if prior.any? { |c| c[:user_id] != current_user.id }
      flag_for_manual_review(reason: "identity_farming", prior: prior)
      halt 200, { status: "manual_review" }.to_json
    end
  end

  vendor = kyc_vendor.verify(body, foil: tr[:data])
  if decision[:verdict] == "inconclusive" && vendor.status == "approved"
    flag_for_manual_review(reason: "foil_inconclusive_despite_vendor_approval")
    halt 200, { status: "manual_review" }.to_json
  end

  record_kyc_result(current_user, tr[:data], vendor)
  { status: vendor.status }.to_json
end

use Foil\Server\SealedToken;

const KYC_RISK_SCORE_THRESHOLD = 30;

$body = json_decode(file_get_contents("php://input"), true);
$tr = SealedToken::safeVerify(
    $body["foil"]["sealedToken"] ?? "",
    getenv("FOIL_SECRET_KEY"),
);

if (!$tr->ok) {
    http_response_code(403);
    echo json_encode(["status" => "rejected", "reason" => "verification_failed"]);
    exit;
}

$d = $tr->data->decision;

if ($d["verdict"] === "bot") {
    http_response_code(403);
    echo json_encode(["status" => "rejected", "reason" => "automation_detected"]);
    exit;
}

if ($d["risk_score"] >= KYC_RISK_SCORE_THRESHOLD) {
    flagForManualReview("elevated_risk_score", $tr->data);
    echo json_encode(["status" => "manual_review"]);
    exit;
}

$visitorId = $tr->data->visitor_fingerprint["id"] ?? null;
if ($visitorId) {
    $prior = findPriorKycByVisitor($visitorId);
    foreach ($prior as $claim) {
        if ($claim["user_id"] !== currentUserId()) {
            flagForManualReview("identity_farming", $tr->data);
            echo json_encode(["status" => "manual_review"]);
            exit;
        }
    }
}

$vendor = kycVendor_verify($body, $tr->data);
if ($d["verdict"] === "inconclusive" && $vendor->status === "approved") {
    flagForManualReview("foil_inconclusive_despite_vendor_approval", $tr->data);
    echo json_encode(["status" => "manual_review"]);
    exit;
}

recordKycResult(currentUserId(), $tr->data, $vendor);
echo json_encode(["status" => $vendor->status]);

# Session readback - useful when reviewing a queued KYC submission later
curl https://api.usefoil.com/v1/sessions/sid_... \
  -H "Authorization: Bearer sk_live_..."

# Pull visitor fingerprint history for identity-farming investigation
curl https://api.usefoil.com/v1/fingerprints/vid_... \
  -H "Authorization: Bearer sk_live_..."

The server SDKs don’t check a token’s age. Reject a token whose decision.evaluated_at is more than a few minutes old, so that an attacker can’t reuse a token captured from one session for another submission. See Verify the token on your server for the check in each language. Store the session_id from the verified token with the KYC record, as the examples do, rather than the sessionId that the browser sent.

Layered decision matrix

The decision you hand back to your own business logic (and record on the KYC row) should be the product of Foil and the vendor verdict, not either one alone. risk_score is an integer 0–100. A human verdict always has a risk_score below 40, and a bot verdict starts at 70, so there’s a lot of useful gradient below the bot threshold, and KYC is the surface where you should care about it.

Foil verdict	`risk_score`	Vendor result	Recommended action
`human`	`< 30`	`approved`	Approve.
`human`	`< 30`	`declined`	Decline (vendor-driven).
`human`	`30 – 39`	`approved`	Manual review. Borderline scores on a regulated flow should not auto-approve.
`human`	`30 – 39`	`declined`	Decline.
`inconclusive`	any	`approved`	Manual review. Don’t auto-approve borderline sessions on regulated flows.
`inconclusive`	any	`declined`	Decline.
`bot`	any	any	Reject before the vendor. Log and rate-limit by IP and visitor fingerprint.

Two principles worth holding:

Never auto-approve on vendor-only signal for a KYC-gated flow. If Foil’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. Foil’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 30 as worth a human look.

Runtime integrity: deeper environment signal

When the sealed-token verdict isn’t enough - high-limit approvals, compliance-heavy jurisdictions, repeat-review queues - fetch the stored session and inspect runtime_integrity. Each field is a level that Foil computes server-side from the full observation stream, so you can write precise rules instead of thresholding a single aggregated score. A field is clean when Foil found no evidence, and it rises through notice and elevated to high_risk as the evidence gets stronger.

Node.js

const session = await client.sessions.get(sessionId);
const ri = session.runtime_integrity;
// Each field is "clean", "notice", "elevated", or "high_risk":
// {
//   tampering,
//   developer_tools,
//   emulation,
//   virtualization,
//   privacy_hardening,
//   identity_spoofing,
//   replay,
//   outdated_environment,
// }

Field	What it means on a KYC submission
`tampering`	Environment tampering, such as patched navigator properties, stealth-plugin artifacts, or injected globals. At `elevated` or `high_risk`, this is a strong manual-review signal regardless of the sealed-token verdict.
`emulation`	Device emulation, typically a mobile emulator on a desktop. At `elevated` or `high_risk`, treat it as a strong review signal when your vendor expects a real phone for document capture and liveness.
`virtualization`	The submission is coming from a VM. Legitimate in some corporate setups (Citrix, VDI) but overrepresented in fraud operations. Weight it; don’t auto-reject.
`developer_tools`	DevTools open during submission. Common on legitimate support calls and among advanced users - useful context, not dispositive.
`privacy_hardening`	Privacy-protecting settings, such as a hardened privacy browser or a Do Not Track or Global Privacy Control request. This field reaches `notice` for any request that sends `DNT: 1` or `Sec-GPC: 1`, so it’s common among legitimate users. Don’t use it to trigger review.
`identity_spoofing`	The device’s self-reported identity disagrees with itself - UA vs Client-Hints, locale vs keyboard, IP geo vs timezone, plugin set vs Chrome runtime. Common on KYC fraud rigs that swap UA strings without re-aligning the rest of the surface.
`replay`	The session’s snapshot, batch sequence, or anti-replay nonce looks reused or out of order - typically a captured-then-replayed submission rather than a live browser. Manual review when paired with any other risk signal.
`outdated_environment`	The browser claims a modern version but its capability surface (CSS @supports, Chrome API markers, TLS cipher suites, Sec-CH-UA-Full-Version-List) looks legacy. Common on automation kits that pin a stale Chromium build under a freshly-rotated UA string.

tampering, emulation, and identity_spoofing at elevated or high_risk deserve a manual-review route even when the sealed-token verdict is human and the risk_score is under threshold. They’re the signals most likely to be silent on the aggregated score when an attacker is specifically tuning against it.

Node.js

const REVIEW_LEVELS = new Set(["elevated", "high_risk"]);
const needsReview = ["tampering", "emulation", "identity_spoofing"].some(
  (field) => REVIEW_LEVELS.has(ri[field]),
);

Signed bot identity isn’t part of runtime_integrity. When a request carries a valid Web Bot Auth signature, the session detail reports it in the top-level web_bot_auth object (status and domain), and the sealed token carries a trust label with the value verified. This is a positive signal: the session is a self-identified, cryptographically attested bot, which usually explains an automated verdict rather than pointing to fraud. KYC flows generally still don’t accept these submissions, but you can reject them without an investigation. runtime_integrity is only available via GET /v1/sessions/:sessionId - it’s not on the sealed token. Two integration shapes work well:

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

Identity farming: cross-session correlation

The visitor fingerprint is the axis that catches farms. One device running KYC under five identities over two weeks looks human on every individual submission - it is human, just a human engaged in fraud. The tell is in GET /v1/fingerprints/:visitorId.

Node.js

const { FoilApiError } = require("@abxy/foil-server");

async function findSuspiciousKycHistory(visitorId) {
  let fingerprint = null;
  try {
    fingerprint = await client.fingerprints.get(visitorId);
  } catch (err) {
    // Foil returns a 404 when it has no stored record for the device yet,
    // which is the case for a brand-new device. Treat it as a new device.
    if (!(err instanceof FoilApiError && err.status === 404)) throw err;
  }

  // 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 ?? 0,
    firstSeenAt: fingerprint?.lifecycle.first_seen_at ?? null,
    distinctKycAccounts: priorKyc.rows.length,
    priorBotSessions: (fingerprint?.activity.sessions ?? []).filter(
      (s) => s.decision.verdict === "bot",
    ).length,
  };
}

Practical thresholds for flagging:

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" in that fingerprint’s activity.sessions → manual review. The device has failed Foil before. activity.sessions holds only the device’s latest 100 sessions, so on a very active device it may not reach back as far as you want. Filter on decision.evaluated_at if you need a fixed window such as 90 days.
lifecycle.seen_count > 50 with first-seen under 24 hours → auto-reject. That’s a headless browser being spun up repeatedly on one machine.

See Promo & trial abuse for a more general treatment of the cross-session correlation pattern; the KYC version is essentially that page with tighter thresholds and a manual-review default.

Attaching Foil signal to the vendor

Most KYC vendors expose a metadata or custom_fields parameter on their verification API. Putting Foil’s session ID and verdict there pays off in two ways:

Vendor-side rules. Many KYC platforms let you write decisioning rules on custom fields. “Decline if foil_risk_score >= 30 AND document score below 0.9” is a one-line rule that would otherwise require integrating Foil into the vendor’s system separately.
Post-hoc reconciliation. When a chargeback, SAR, or compliance audit surfaces a KYC approval months later, the Foil session ID stamped on the vendor record lets you pull GET /v1/sessions/:sessionId and recover the device evidence from the time of submission, including runtime_integrity. The signals_fired list is empty unless raw signal access is enabled for your organization.

Which fields to send:

{
  "foil_session_id": "sid_...",
  "foil_verdict": "human",
  "foil_risk_score": 12,
  "foil_visitor_id": "vid_...",
  "foil_attribution_category": "human"
}

foil_attribution_category is the value of the label whose kind is actor in attribution.bot.labels. A session can have no actor label, particularly when the verdict is human, so for consistency store "human" in that case and "unknown" when the verdict is bot or inconclusive.

Post-KYC monitoring

Getting a human verdict at KYC submission is necessary but not sufficient. Account takeover happens later - the KYC is clean, but six months on, someone logs in from a new device, hardens their settings, and starts draining the account or withdrawing funds. Keep Foil on:

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.

A KYC-verified account that suddenly starts producing bot verdicts or an elevated risk_score on withdrawals is a very strong ATO signal, and the fact that the account is KYC-verified makes the response more important, not less - the attacker has done the work to look legitimate precisely to unlock high-limit actions.

KYC is a regulated flow in most jurisdictions. How long you retain Foil verdicts and visitor fingerprints on KYC records is a compliance question, not just an engineering one. Confirm retention requirements with your privacy/legal team before you ship. See Privacy & data for Foil’s side of the data picture.

What’s next

Signup protection

Stop automated account creation before KYC even starts.

Promo & trial abuse

The same cross-session correlation pattern, at lower stakes.

Verdicts & scoring

Deep-dive on verdict, risk_score, and where thresholds come from.

Privacy & data

What Foil stores and for how long.

Overview

Get started

Integrate

Use cases

Learn

Resources

KYC fraud reduction

The threat

The flow

Client integration

Server verification

Layered decision matrix

Runtime integrity: deeper environment signal

Identity farming: cross-session correlation

Attaching Foil signal to the vendor

Post-KYC monitoring

What’s next

Signup protection

Promo & trial abuse

Verdicts & scoring

Privacy & data

​The threat

​The flow

​Client integration

​Server verification

​Layered decision matrix

​Runtime integrity: deeper environment signal

​Identity farming: cross-session correlation

​Attaching Foil signal to the vendor

​Post-KYC monitoring

​What’s next

Signup protection

Promo & trial abuse

Verdicts & scoring

Privacy & data

The threat

The flow

Client integration

Server verification

Layered decision matrix

Runtime integrity: deeper environment signal

Identity farming: cross-session correlation

Attaching Foil signal to the vendor

Post-KYC monitoring

What’s next