Mexico's Data Protection Law and Device Fingerprinting for Fraud

If your product serves users in Mexico, from a fintech in Monterrey to a SaaS tool with a Mexican customer base, the device signals in your fraud stack fall under Mexico’s federal private-sector data protection law, the Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP). This post covers what that means in practice for fingerprinting used to stop fraud. It’s an engineering-oriented overview, not legal advice. The details below need a check with Mexican counsel before you rely on them.

The legal landscape changed in 2025

Mexico’s private-sector data protection law dates from 2010. In March 2025 a new LFPDPPP replaced it, as part of a broader reform that dissolved the former regulator, INAI, and moved its data-protection functions to a federal ministry, the Secretaría Anticorrupción y Buen Gobierno. The core architecture is familiar: guiding principles, a privacy notice, consent, and the rights known by the acronym ARCO.

Two practical consequences. First, older guidance that cites INAI or the 2010 text may be out of date in details. Second, secondary regulations and enforcement practice under the new structure are still settling, which is one more reason to document your reasoning now rather than later.

Device signals are personal data

The law applies to personal data, meaning any information concerning an identified or identifiable natural person. A device fingerprint on its own is a hash of browser and hardware attributes. The moment you link it to an account, which is the whole point for multi-accounting and account takeover, it identifies a person. Even before that link, a stable identifier that recognizes the same individual across visits makes that individual identifiable.

Design as if the full framework applies. The same conclusion holds under Brazil’s law (LGPD and device fingerprinting) and under GDPR, so it costs you nothing extra if you operate across Latin America.

The privacy notice does most of the work

The aviso de privacidad is the center of compliance in Mexico. It must be made available to people before or at the time you collect their data, and it has to say, among other things, who is responsible for the data, what data you process, and for which purposes.

For device intelligence, the notice should state clearly:

• What you collect: device and browser characteristics, network information such as the IP address, and a device identifier, collected when the person uses your site or app.
• Why: to prevent fraud, protect accounts, and detect automated abuse and duplicate accounts.
• Who processes it for you: device intelligence is usually provided by a processor acting on your behalf.
• How to exercise rights: the channel for ARCO requests.

Mexican practice distinguishes primary purposes, which are needed for the relationship with the person, from secondary purposes, which they must be able to refuse. Fraud prevention and account security are strong candidates for a primary purpose: keeping the service and its users safe is part of providing it. Reusing the same device data for marketing, ad targeting or cross-site profiling is a different purpose that needs its own disclosure and opt-out, and it undermines the argument that your fraud processing is proportionate.

Consent: tacit for ordinary data, with exceptions

The Mexican framework is built around consent, but not necessarily the click-through kind. For ordinary personal data, consent can generally be tacit: you make the privacy notice available, and the person doesn’t object. Sensitive personal data requires express, written consent. Device signals collected for fraud prevention are not sensitive data in the legal sense, but some categories, such as financial and patrimonial data in some contexts, and certain uses can require express consent. The law also includes exceptions where consent isn’t needed. Your counsel should map your specific flows to these rules.

What this means technically: you need to be able to run identification after the notice is available, and to stop if the person opts out. Prynt’s browser agent supports both modes:

const prynt = await Prynt.load({
  apiKey: 'pk_live_…',
  requireConsent: true,   // no identification until consent is given
  respectGPC: true,       // default: Global Privacy Control means no event stored
});

// after the person accepts your notice or banner:
prynt.setConsent(true);
const { requestId } = await prynt.identify({ tag: { action: 'signup' } });

If tacit consent is enough for your case, you can drop requireConsent and rely on your notice, while still honoring opt-out signals like GPC.

Proportionality and minimization

The proportionality principle limits you to the data that is necessary for the stated purpose. For fraud work that argues for:

• Collecting at decision points, such as signup, login, checkout and payout, rather than on every page view.
• Minimizing IP data. Self-hosted Prynt deployments can truncate stored IPs or drop them entirely (PRYNT_IP_MODE=truncate or none) when full addresses aren’t needed for your rules.
• Bounded retention. Keep event data only as long as your fraud use needs it. Retention is set per plan.
• No secondary use. Keep device data inside fraud and security workflows.

Data minimization for fraud signals goes through each of these in detail.

ARCO rights: find, export, delete

ARCO stands for Access, Rectification, Cancellation and Opposition. A person can ask to see the data you hold about them, correct it, have it deleted, or object to its processing. For device data, the hard part is finding it. You need to locate every event tied to a person, and those events are keyed by a device id they’ve never seen.

Plan for both keys:

• By account. In Prynt, a request about a user maps to their linkedId, the account id you attached to their events. Erasure by linkedId removes every event, label and list entry carrying it. The devices that account used stay, because they may belong to other people too.
• By device. Export and erasure by visitorId cover a person who never created an account, or whose device you identify from a support conversation. For an access request about an account, find the devices it was linked to and export those.

Erasure by either key, and export by visitorId, are available from the Prynt console, so a privacy request doesn’t need an engineering ticket. On the opposition side, honoring GPC and setConsent(false) gives people a way to opt out of collection going forward.

Rectification is the odd one out for device data. A fingerprint isn’t something a person can “correct.” The meaningful version is correcting outcomes: if a person was wrongly labeled as abusive, change the label. That links privacy rights to your false positive appeal process.

Processors and transfers

If a vendor processes device data on your behalf, Mexican law treats it as a processor (encargado) acting under your instructions, which needs a contract that limits its use of the data. Prynt offers a DPA for this. Two questions to answer in your notice and your contracts: where is the data processed, and is it ever shared beyond the processor? Prynt’s cross-customer reputation network is opt-in. If you turn it on, describe it in your notice. Teams that want data to stay in their own infrastructure can self-host.

A short checklist

1. Update the aviso de privacidad to cover device and network data for fraud prevention as a primary purpose.
2. Decide with counsel whether tacit consent covers your case, and configure the agent accordingly.
3. Collect only at decision points, minimize IPs, and set retention.
4. Make ARCO requests answerable by linkedId and visitorId.
5. Sign a processing agreement with your vendor and record where data lives.

For the wider legal picture, see is device fingerprinting legal, and the privacy page for how Prynt handles data by default.