Every device-intelligence call processes personal data: IP addresses, browser characteristics, and derived identifiers all describe a person, however indirectly. The question compliance teams ask is not whether that processing is allowed but where it happens and who touches the data along the way. When a SaaS fraud vendor sits in the path, your users’ raw signals leave your infrastructure and cross a boundary you do not control.
Self-hosting changes that geometry. Instead of shipping raw signals to a vendor’s cloud, you run the collection and scoring engine yourself, in a region you choose, under your own retention rules. This article explains what data residency actually requires, where a hosted vendor creates friction, and how a self-hosted architecture resolves it without giving up detection quality.
What data residency actually demands
Data residency is the requirement that certain data be stored and processed within a defined geography. It shows up in several forms:
- Statutory residency. Some jurisdictions require that citizens’ personal or financial data stay within national borders. Cross-border transfer is restricted or forbidden.
- Contractual residency. Enterprise customers increasingly demand in-region processing in their contracts, regardless of what the law strictly requires.
- Sectoral rules. Finance, health, and public-sector work often carry stricter localization obligations than general commerce.
The related concept, data sovereignty, asks whose laws govern the data. A dataset stored in one country but operated by a company subject to another country’s disclosure laws can be sovereign-exposed even when it is resident in-region. Self-hosting addresses both: you place the data where you want it and keep it under your own legal control. For the deeper treatment, see self-hosting for data residency and privacy-preserving fraud detection.
Where a hosted vendor creates friction
A typical SaaS device-intelligence flow sends raw client signals to the vendor, which computes an identifier and returns it. That path introduces several compliance headaches:
| Concern | SaaS reality | Self-hosted resolution |
|---|---|---|
| Where raw signals go | Vendor cloud, often cross-border | Your infrastructure, your region |
| Sub-processor disclosure | Vendor added to your DPA | No third-party processor for signals |
| Retention control | Vendor’s schedule | Your schedule and deletion |
| Transfer mechanism | SCCs, adequacy decisions | No transfer to manage |
| Audit scope | Depends on vendor cooperation | Fully within your audit boundary |
None of these are insurmountable with a SaaS vendor, but each is ongoing work: a sub-processor to disclose, a transfer mechanism to maintain, an audit dependency you cannot fully control. Self-hosting removes the third party from the signal path, which collapses several of these obligations at once. That is the compliance case for why self-hosting fraud detection is more than a preference.
The self-hosted architecture
A self-hosted device-intelligence deployment keeps every stage of the pipeline inside your boundary:
- First-party agent serving. The client SDK loads from your own domain, not a vendor CDN, so even the collection script is under your control. See first-party agent serving.
- In-region API. The collection and scoring API runs in your chosen region. Raw signals hit your endpoint and never leave it.
- Local storage and retention. Identifiers and events land in your database, under your retention and deletion policy.
- Your keys, your logs. Sealing keys, access logs, and audit trails stay inside your environment.
# Deploy the engine in the region you require
services:
prynt-api:
image: prynt/api:latest
environment:
REGION: eu-central
DATA_RETENTION_DAYS: "90"
RAW_SIGNAL_STORAGE: "false" # keep derived IDs, discard raw signals
ports:
- "5050:5050"
Because Prynt is MIT-licensed and ships as containers you run yourself, the entire path from agent to storage sits inside your compliance boundary. There is no vendor endpoint receiving raw signals and no cross-border hop to paper over. See the device fingerprinting engine and the docs for deployment specifics.
Compliance is more than location
Self-hosting solves the “where” cleanly, but residency is one requirement among several. A defensible program still needs the rest of the privacy stack:
- Lawful basis. Fraud prevention is often a legitimate interest under GDPR, but you must document it. See GDPR and device fingerprinting.
- Data minimization. Collect and retain only what the fraud decision needs. Discard raw signals once the identifier is derived if you do not need them for tuning. See data minimization for fraud signals.
- Retention limits. Define how long identifiers and events live, and enforce deletion automatically.
- Transparency and rights. Users have access and deletion rights; self-hosting makes fulfilling them easier because the data is yours to query and purge.
- Regional rules. For the US, review CCPA fingerprinting compliance. For the general legality question, see is device fingerprinting legal.
Self-hosting is the enabler that makes the rest of these easier, not a substitute for them. It removes the hardest structural problem, the third party in the data path, and leaves you free to enforce minimization and retention on your own terms.
Frequently asked questions
What is data residency versus data sovereignty?
Data residency is where data is physically stored and processed. Data sovereignty is whose laws govern that data. Self-hosting in a chosen region addresses residency directly and strengthens sovereignty by keeping data out of foreign-controlled clouds.
Does self-hosting fingerprinting make me automatically GDPR compliant?
No. Self-hosting removes a third-party processor and keeps data in-region, which helps, but you still need a lawful basis, minimization, retention limits, and transparency. It is an enabler, not a certificate.
Is self-hosted device intelligence slower than SaaS?
Not inherently. Running the agent and API in-region can reduce latency versus a distant SaaS endpoint. Performance depends on your infrastructure, not on the fact that you host it yourself.
Data residency is ultimately a question of control: where the data lives, who can reach it, and whose rules apply. A hosted vendor asks you to manage that control across a boundary you do not own. Self-hosting brings the whole pipeline inside your walls, which is why teams with serious residency obligations increasingly run device intelligence themselves. Compare the models in self-hosted versus SaaS fraud, and see the pricing page for what running Prynt yourself involves.
Run it yourself
Prynt is open-source, self-hostable device intelligence — visitor IDs, bot & fraud Smart Signals, and behavioral biometrics you own end to end.