How to Switch From Reality Defender to Neural Defend

Before you start: decide what you are replacing

List every place Reality Defender runs today and what each result controls. A typical estate includes onboarding selfie checks, recovery or re-verification video, uploaded-file screening by an investigations team, and sometimes call or meeting monitoring. Neural Defend maps these to NeuroVerify for identity checks on face images, video and audio, NeuroDetect for forensic review, and NeuroCall, in Beta, for voice calls. Neural Defend's meeting product is not yet available, so keep Reality Defender in place for live meeting monitoring if you depend on it.

For each flow, record the media types and sizes, current thresholds, decision owner, daily volume and the false-positive rate you see now. Those numbers become the acceptance criteria for the new vendor. Note any videos above 250 MB or 30 minutes that you currently split to fit Reality Defender's documented limits; NeuroVerify's video endpoint accepts up to 1.5 GB, so that splitting logic may become optional.

Step 1 and 2: inventory calls and map the integration

Reality Defender's documentation describes a two-stage pattern: submit a file or URL through an SDK, receive a requestId, then retrieve the analysis by event or polling. NeuroVerify's image endpoint (POST /detect/image) and video endpoint (POST /detect/video) return the result in the response body. In practice, the polling worker or event handler you built for Reality Defender can often be removed for selfies, while long video may still run from a background job so the user is not holding a connection.

Swap the SDK at an adapter boundary rather than throughout the codebase. Both vendors offer Python, TypeScript, Go and Java SDKs, so most teams keep the same language. NeuroVerify adds Android/Kotlin, iOS/Swift and Flutter SDKs for capture apps and an MCP server for AI agents. Store the NeuroVerify API key in a secret manager and keep it server-side.

Step 3: run a side-by-side test on your own media

Build a test set from your own traffic: a few hundred genuine captures that reflect your real devices, lighting, compression and customer demographics, plus a matched set of attacks such as face swaps, fully generated faces, replays and, if you can produce them safely, injected streams. Send every sample to both APIs.

Score each vendor with MCC and specificity, not accuracy alone, because attack sets are usually smaller than genuine sets. Count false positives per 1,000 genuine sessions at the threshold you would actually ship, and record p95 latency from your own region. For context, the public VendorBench-100 benchmark (v2, July 2026) scored Neural Defend at MCC 0.876 and Reality Defender at 0.646 on 100 adversarial still images; one of its authors also co-authored Neural Defend's ARCAS 1B paper, and the results are public. Your own data should decide.

Keep the test honest. Label every sample before either vendor sees it, freeze the set once testing starts, and have someone other than the integration engineer review the disagreements. Look closely at cases where the two vendors disagree: those files show where each model is weak, and they make a good regression set for future model updates.

Steps 4 to 6: shadow traffic, staged cutover and rollback

Shadow live traffic before NeuroVerify makes any decision. Send each production request to both vendors, act only on Reality Defender, and log both results with the same case ID. Two to four weeks usually covers weekday and weekend patterns and a marketing peak or two.

Cut over one flow at a time, starting with the lowest-risk one. Keep Reality Defender credentials active and a feature flag ready so you can route back within minutes. Define rollback triggers in advance, for example false positives above an agreed rate per 1,000 genuine sessions, p95 latency above the screen's tolerance, or error rates above an agreed threshold.

• Week 0: inventory, adapter and field mapping complete; staging credentials issued.
• Weeks 1 to 2: side-by-side test on your labelled set; thresholds agreed with the decision owner.
• Weeks 2 to 5: shadow traffic on every flow being migrated.
• Weeks 5 onward: staged cutover by flow, with rollback triggers monitored daily.
• After the last flow: decommission Reality Defender keys and archive its results under your retention policy.

Mistakes that cause trouble after cutover

The most common error is reading a missing score as a pass. NeuroVerify returns a rejected status, with no score, when an image has no face or several faces, and that can arrive on HTTP 200. Treat it as a retake or review case. The second is copying thresholds numerically from the old vendor; score scales differ, so derive new ones from the side-by-side test. The third is stacking retries. NeuroVerify's API is not idempotent, the official SDKs already retry selected 429, 500 and 503 responses, and they deliberately do not retry timeouts, because an outer loop can create duplicate billable transactions.

What you gain after the switch

Teams that finish the move get six signals in one call, including Live Presence Verification and Face Manipulation Detection, with one risk score and signal-level evidence. Neural Defend reports under 200 ms p95 on eligible image requests under defined test conditions. Deployment can move to private cloud, on-premises or air-gapped if your data rules tighten, and Neural Defend's ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II certifications support the vendor review. NeuroVerify does not analyse ID documents, so keep your document verification provider in the flow.