Ecuador LOPDP and Fraud Prevention: Device and IP Signals

Ecuador’s Ley Orgánica de Protección de Datos Personales (LOPDP) was published in 2021, its corrective-measures and sanctions regime applied two years later, and the implementing regulation (Reglamento General) followed in late 2023. Oversight sits with a dedicated supervisory authority, the Superintendencia de Protección de Datos Personales. For any business with users in Ecuador, the law now has both rules and an enforcer.

Fraud prevention sits in an interesting spot under it. Device and IP signals are personal data, and fraud tools exist precisely to recognise people. But stopping fraud also protects users, and the law doesn’t forbid it. This post walks through how to think about device intelligence under the LOPDP and which product settings help. It is a practitioner’s view, not legal advice; for a binding answer, talk to an Ecuadorian data protection lawyer.

Device and IP data are personal data

The LOPDP defines personal data broadly: information that identifies or makes identifiable a natural person, directly or indirectly. The practical test is the same one used under the GDPR and Brazil’s LGPD. If you can link the data to an account, or to an individual by combining it with other data you hold, treat it as personal.

For fraud tooling, that covers:

• A persistent device identifier such as Prynt’s visitorId, especially once it’s linked to your account ids.
• IP addresses and their derived geolocation.
• Browser and hardware attributes used to compute the fingerprint.
• Behavioural signals, such as typing cadence and pointer movement, even when only aggregates are sent.

Assume all of it is in scope. The useful questions are about lawful basis, proportionality and rights, not about whether the law applies.

Lawful basis: legitimate interest and its alternatives

The LOPDP lists several lawful bases for processing: consent, performance of a contract, legal obligation, vital interests, public interest, and the legitimate interest of the controller or a third party. Check the implementing regulation and any current guidance from the Superintendencia for the conditions attached to relying on legitimate interest, since secondary rules are still being developed.

For fraud prevention, controllers usually consider three options:

• Legal obligation, where a sector regulator requires fraud or AML controls. This mostly applies to financial institutions.
• Contract, where fraud checks are necessary to deliver a service securely, for example protecting the user’s account.
• Legitimate interest, the most common choice for ecommerce, SaaS and marketplaces. Preventing fraud, abuse and account takeover is a recognised legitimate interest in most comparable laws.

Relying on legitimate interest means doing the balancing work and writing it down: what you process, why, why less intrusive means aren’t enough, what safeguards you apply, and why users’ rights aren’t overridden. The general method is the same as in legitimate interest for fraud prevention and fingerprinting; adapt it to the Ecuadorian rules.

Consent is a poor fit for fraud prevention. A fraudster simply declines, and a check that only runs on people who agree to it doesn’t protect anything. If your counsel nonetheless asks for consent in some flows, the agent supports a consent mode (requireConsent plus setConsent(true)), so identification waits until the user agrees.

Automated decisions

The LOPDP gives data subjects rights in relation to decisions based on automated assessments of their data. A fraud engine that refuses a sign-up or a payment on its own is exactly that.

Build for it rather than around it:

• Explainability. Prynt returns reason codes with every decision, such as MULTI_ACCOUNT, DATACENTER or TLS_AUTOMATION. Store them with the outcome so you can tell a user, or the authority, why a decision was made. See explainable fraud with reason codes.
• Human review for refusals that matter. Route challenge decisions to verification rather than refusal, and give refused users a channel to ask for a review.
• Proportionate responses. Requiring an extra verification step is less intrusive than an outright block. Use blocks for clear automation.

Minimization: collect and keep less

Proportionality is where product settings make a concrete difference. With Prynt:

• IP minimization. PRYNT_IP_MODE can be full, truncate or none. Truncation keeps enough for network-level signals while storing less precise addresses. On self-hosted deployments you set it directly; on the cloud, ask what’s configured for your account.
• Global Privacy Control. The browser agent honors GPC by default: when a browser sends it, no event is stored. Do Not Track can be honored too (respectDNT).
• Purpose tagging. Identify only on pages where there’s a fraud reason, such as sign-up, login, checkout or payout, and tag the event (tag: { action: 'signup' }). Running identification on every marketing page is hard to justify under a fraud-prevention purpose.
• No raw content. Behavioural signals are sent as aggregates, not keystroke logs.

Retention and erasure

Keep fraud signals as long as they serve the purpose and no longer. A device that farmed trials last month is useful to remember; raw events from three years ago rarely are. Retention in Prynt is set per plan, and self-hosted deployments control it directly. Write your retention period into your record of processing and justify it from your fraud patterns, such as the typical gap between sign-up abuse and chargebacks. See data retention for fraud signals for a way to set it.

Data subjects can request deletion. Prynt supports erasure by visitorId or by linkedId, so a request that comes in with an account id can be fulfilled without hunting for device ids. Some data may need to be kept despite a deletion request, for example where a legal obligation or an open fraud investigation requires it. Whether an exception applies is a question for your counsel; if you rely on one, document the reasoning case by case.

Transfers and processors

If you use a fraud vendor, it acts as your processor. You need a data processing agreement, and you need to look at where data is processed. The LOPDP restricts international transfers to countries without an adequate level of protection unless safeguards are in place. Prynt’s DPA describes its processing. If keeping data in-country or in a specific region is a requirement, self-hosting is an option because Prynt is open-core.

A short checklist

1. Record fraud prevention as a processing activity with its lawful basis and balancing test.
2. Update your privacy notice to mention device and network signals used for security and fraud prevention.
3. Limit identification to pages with a fraud purpose, and tag events.
4. Turn on IP truncation unless you have a documented need for full addresses.
5. Store reason codes with decisions and offer a human review path.
6. Set and document a retention period; test the erasure flow.
7. Sign a DPA with every fraud vendor and assess transfers.

If you also operate in Brazil, much of this carries over; compare with LGPD and device fingerprinting. Fraud prevention and data protection are not opposed. Both are about using exactly as much data as the job needs, and being able to explain it afterwards.