Access controls

VPN Detection API for Sanctions Compliance

Check whether the calling client — or any IP address — is connecting through a VPN before you trust its location. A clear true / false / unknown signal that keeps geo-blocking effective for sanctions compliance.

Get your free API key Read the documentation

GET /api/v1/vpn/{ip}

# Omit the IP to evaluate the calling client
curl https://api.compliapi.com/api/v1/vpn/172.217.22.14 \
  -H "Authorization: Bearer $COMPLIAPI_TOKEN"

import requests

resp = requests.get(
    "https://api.compliapi.com/api/v1/vpn/172.217.22.14",
    headers={"Authorization": f"Bearer {COMPLIAPI_TOKEN}"},
)
print(resp.json())

const resp = await fetch(
  "https://api.compliapi.com/api/v1/vpn/172.217.22.14",
  { headers: { Authorization: `Bearer ${process.env.COMPLIAPI_TOKEN}` } },
);
console.log(await resp.json());

Response

{ "ip": "172.217.22.14", "vpn": false }

An honest tri-state signal

Responses are true, false, or "unknown" when privacy data is unavailable for an IP — no false confidence.

Caller or arbitrary IP

Evaluate the requesting client directly, or pass any public IP from your own systems.

Pairs with geolocation

Use alongside the geolocation endpoint to judge how much to trust a location signal.

Metered and logged

VPN checks use the same tokens, quota and request logging as every other CompliAPI endpoint.

Why geo-blocking alone fails OFAC expectations

Geo-blocking works by mapping an IP address to a country and refusing service where sanctions apply. A VPN breaks that mapping silently: a user in a sanctioned jurisdiction connects through an exit node in a permitted country, and every downstream control sees the wrong location.

Regulators know this. OFAC's 2021 sanctions compliance guidance for the virtual currency industry discusses IP-based location controls as a core measure and treats VPN use as a known evasion vector, and public enforcement settlements have cited location-control gaps. Nothing in the regulations names VPN detection as a requirement — the expectation is that controls are effective, not nominal. A geo-block that any free VPN defeats is hard to defend as effective.

Checking for a VPN at the moments that matter — signup, wallet connect, checkout, withdrawal — closes the gap: when the location signal is untrustworthy, your policy can step up verification or decline instead of trusting the apparent country.

Crypto geofencing API →Sanctions screening for crypto exchanges →

One request, one answer

GET /api/v1/vpn evaluates the calling client's IP; GET /api/v1/vpn/{ip} evaluates any public IPv4 or IPv6 address — from your logs, a webhook payload, or a queued review. Either way the response carries the one field that matters: vpn.

The signal is deliberately tri-state: true, false, or "unknown" when privacy data is unavailable for that IP. Uncertainty is reported instead of hidden, so your policy decides what to do with it explicitly — a defensible design when someone asks how the control behaves at its edges.

VPN detection API reference →

What the signals tell you

VPN detection is one signal in a layered location control. Here is what each signal in the stack tells you, and where it comes from:

Signal	Where it comes from	What to do with it
VPN exit	GET /vpn returns vpn: true	Treat the session's apparent location as low-trust: step up verification or apply your restricted-jurisdiction policy.
No privacy data	GET /vpn returns vpn: "unknown"	Decide explicitly — never let "unknown" silently default to false.
Sanctioned-country location	GET /geo returns the country with a sanctioned flag	The jurisdiction decision itself: block or restrict per your policy.
Country mismatch	Your comparison of the /geo country against the user's declared country	An integration pattern built from the two endpoints — flag the account for review.

IP geolocation API reference →

Using VPN detection with sanctions screening

The endpoint returns a VPN signal, and only that. It is not proxy or datacenter classification, device fingerprinting, or fraud scoring — an IP lookup that promises all of those at once is usually overstating what IP data can say.

Where it earns its place is as one layer of a sanctions control: screen the identifiers you can see — wallet addresses, emails, government IDs — against the SDN and other sanctions lists, geolocate the session and check the sanctioned-country flag, and weigh both against the VPN signal that says how much the location can be trusted.

All three checks run on the same API token, draw from the same quota, and appear in the same request log — so when an auditor or banking partner asks whether the check ran, the trail is already there.

OFAC screening API →Crypto geofencing API →

Pricing

VPN checks are metered like every other CompliAPI request: the free tier includes a monthly quota and a dashboard-issued API token, with no credit card to start. Production plans raise the quota — the endpoint and the signal are identical on every plan.

See plans and pricing →

Know when a location signal deserves less trust

Geofencing and jurisdiction rules assume an IP address reflects where a user actually is. VPNs break that assumption, and building your own VPN-detection capability means sourcing and maintaining IP privacy data that changes constantly.

CompliAPI gives you the VPN signal as a one-request check. Call it where location matters in your flow — signup, wallet connect, high-value actions — and feed the result into your own policy: block, step up verification, or record it.

No VPN signal is infallible, and CompliAPI does not decide your policy. It reports the signal; your application chooses what a VPN result means for the user.

How it works

Send a request
Call /vpn to evaluate the calling client's IP, or /vpn/{ip} for any public IP address.
CompliAPI checks IP privacy data
The IP is evaluated against current privacy data to determine whether it appears to be a VPN exit.
Apply your policy
Branch on true, false or "unknown" — block, require additional verification, or simply record the signal.

What you can screen

The calling client's IP (no argument needed)
Any public IPv4 or IPv6 address

Where teams use it

Strengthening geofencing

Treat a restricted-jurisdiction decision differently when the location signal comes from a VPN.

Step-up verification

Ask for additional verification on sensitive actions when a session arrives over a VPN, instead of blocking outright.

Onboarding risk signals

Record VPN usage at signup as one input to your review process.

Session context for reviews

Attach the VPN signal to logged sessions so reviewers have the context later.

Scope and limitations

VPN detection is a signal for your access-control decisions, not a verdict. Design your policy around these realities:

No signal is infallible

New VPN exits and residential proxies appear constantly. A false result does not prove a direct connection, and detection data always trails the newest infrastructure.

"Unknown" is a real state

When privacy data is unavailable for an IP, the API says so rather than guessing. Decide explicitly how your policy handles "unknown".

You set the policy

Whether VPN usage means blocking, step-up verification, or just a log entry is your organization's decision — legitimate users use VPNs too.

Scope

The endpoint reports a VPN signal for an IP address. It is not device fingerprinting, bot detection, or fraud scoring.

Frequently asked questions

Is VPN detection required for OFAC compliance?

No regulation names VPN detection as a requirement. What OFAC expects is that sanctions controls — including geo-blocking — actually work, and its virtual-currency guidance treats VPN evasion as a known weakness of IP-based controls. Many teams add the VPN signal to make their geo-controls defensible. This is context, not legal advice.

How accurate is VPN detection?

No provider detects every VPN — new exit nodes and residential proxies appear constantly. That is why the response is tri-state rather than falsely confident: true and false reflect current privacy data, and unknown is reported honestly. Treat the result as one input to your policy, not a verdict.

Does VPN detection flag corporate VPNs?

It can — a VPN exit is a VPN exit, and the signal does not distinguish a corporate network from a consumer privacy app. That is a reason most teams step up verification on a VPN result rather than hard-blocking.

What does the VPN detection API return?

A JSON object with the IP and a vpn field that is true, false, or "unknown". Unknown means privacy data is unavailable for that IP — reported explicitly rather than defaulting to false, so your policy can handle the case.

Should I block all VPN users?

That's a policy decision, not a technical one. Many legitimate users browse through VPNs, so teams often use the signal to step up verification or weight other signals rather than hard-blocking.

Can I check IPs from my own logs?

Yes. Pass any public IP explicitly as GET /api/v1/vpn/{ip}; omit it to evaluate the calling client.

Access controls

Crypto geofencing API

Geolocate requests, flag sanctioned countries automatically, and apply jurisdiction rules in your crypto app.

Sanctions screening

OFAC API — screen against the official SDN list

Screen crypto wallets, emails, IDs and countries against the official US Treasury OFAC SDN list, refreshed every 15 minutes.

Use case

OFAC compliance API for DeFi

Add sanctions screening, geofencing and VPN detection to a DeFi frontend: screen connecting wallets against the OFAC SDN list and apply jurisdiction rules with simple GET requests.