Verify provenance, consent and quality, before processing
Every request is checked for source, consent and quality before it moves on. Built into the platform you run under your own brand: captured, traceable and demonstrable, so under an audit there is nothing left to reconstruct.
As a lead generator, everything comes down to trust in the request. Is it real? Did the person actually ask for it? Are you allowed to process the data and pass it on to your buyer? In traditional lead trading those answers often only surface afterwards, when a buyer complains, or when the regulator comes knocking. By then the consent turns out to be recorded nowhere, and you have to hope a publisher still remembers something. OXIAE turns that around: verification is built into the platform. Provenance, consent and quality are checked the moment a request comes in, and the evidence is captured immediately, under your own brand, in your own environment.
The result is a request that carries its own file with it. You know where it came from, you see the consent with legal basis and timestamp, and you can show at any moment that the quality and fraud checks were completed. You do not have to build this yourself: it is already there, ready to use. Verification is the link between lead intake and matching & routing: what comes in is first checked and captured, and only then distributed and logged in the audit trail. Below we explain exactly what a watertight consent record is, how verification works step by step, and why capturing consent up front is incomparably stronger than reconstructing it afterwards.
What is a watertight consent record?
A consent record is not a checkbox and not a stray log line. It is a complete, coherent piece of evidence that demonstrates that someone gave consent, for what, when and in what context. Under a regulatory audit this is the document that makes the difference between “demonstrably in order” and “we think it was fine”. The platform captures this record by default for every request. A watertight record always contains these six fields:
Legal basis
The legal ground for the processing, in lead generation almost always consent (Article 6 GDPR). Under an audit this is the first thing a regulator wants to see: on what ground do you process this data?
Opt-in text & version
The exact text someone agreed to, including the version number. Texts change over time; storing the version alongside it lets you later prove precisely what someone said yes to at that moment.
Timestamp
The exact moment consent was given, down to the second. This makes the consent verifiable in time and links it to the correct text version and retention period.
Source URL
The page on which consent was given. It lets you trace the request back to the specific landing page or form and demonstrate the context of the opt-in.
IP address
The IP address the request was submitted from. It supports the provenance, helps detect fraud (repeated IP addresses) and strengthens the evidence that consent was genuinely given.
Retention period
Until when the record may be kept. The GDPR requires data minimisation; a defined retention period ensures data is not kept longer than necessary and expires automatically.
Want more detail on how consent and source are captured per lead, and how this aligns with GDPR principles?
How does verification work?
Every incoming request goes through four fixed checks before it enters your flow. Not a single step is optional, and you set the thresholds yourself, from one place.
Provenance check
The platform traces the request back to channel, campaign and publisher and checks whether the source URL is valid and belongs to the registered partner. A request without a traceable source goes no further.
Consent validation
The consent is tested: is there a legal basis, is the opt-in text with version captured, does the timestamp check out, and is the retention period set? Without a watertight consent record the request does not proceed.
Quality & plausibility check
Fields, formats and mutual logic are checked. Incomplete, illogical or unusable requests are set aside so that only clean data enters your flow.
Fraud detection
Risk signals are weighed: disposable email domains, suspicious completion speed, repeated IP addresses, duplicate submissions. Whatever crosses the threshold is blocked or flagged for manual review.
What the platform checks
Six checks stand between an incoming request and further processing, by default, on every lead. Below is what each check does and why it matters.
Provenance & source
Every request is traced back to the channel, the campaign and the publisher it came from. The platform checks whether the source URL exists and belongs to the registered publisher, and flags requests whose provenance is wrong or missing, so a lead never reaches your buyer without you knowing where it originated.
Consent
The consent given is captured at the moment of submission: the legal basis, the exact opt-in text with version number, a timestamp and the source URL. Nothing is reconstructed afterwards, so under an audit you can show under your own brand exactly what someone said yes to.
Quality & validation
Fields, formats and plausibility are checked before a request moves on. Postal codes, phone numbers and email addresses are tested for structure, and illogical combinations (a mobile number on a landline request, an age outside the valid range) are filtered out.
Duplicate requests
Identical and previously received requests are recognised and filtered out based on email, phone number and a hash of the core fields. That way you never pay a publisher twice for the same person, and your buyer is not annoyed by duplicate contact.
Completeness
Missing or unusable data is flagged before it enters the flow. A request without a reachable phone number, or without the fields your buyer needs, is set aside instead of being quietly forwarded.
Fraud signals
Suspicious patterns are flagged and stopped: disposable email domains, a completion speed that points to a bot, repeated IP addresses, and bursts of requests arriving from the same device within seconds. What looks like noise never enters your flow.
Captured and demonstrable
At OXIAE, verification is not a standalone step but evidence the request carries with it. Source, consent, quality and status are captured per lead and remain traceable at any moment, in your own white-label environment. The consent record alongside is an illustrative example of what is stored per request.
- Source verified: The provenance of the request has been checked and linked to publisher and channel.
- Consent captured: The consent given is stored with its legal basis and a watertight timestamp.
- Quality check completed: Validation, completeness and fraud signals are assessed before processing.
- Status traceable: Every step in the verification is visible and exportable at any moment.
- Source
- Publisher portal
- Consent
- Granted
- Time
- 12 March 2026, 14:02
- Legal basis
- Consent (GDPR)
- Status
- Verified
Capturing consent up front vs. reconstructing it afterwards
Consent the platform captures at the moment of submission is a fact. Consent you try to reconstruct later is an assumption, and assumptions do not hold up under an audit.
Withdrawing consent
Giving consent is not a one-way street. The GDPR gives everyone the right to withdraw consent at any moment, just as easily as they gave it. At OXIAE a withdrawal is not a stray action that disappears somewhere: the platform logs it, timestamps it and links it to the original consent record. That keeps the history accurate: you can see both when consent was given and when it was withdrawn.
A withdrawn consent means further processing for the relevant purpose stops, and the request is no longer routed or shared with your buyers. The link between the withdrawal and the original record means that under an audit you can demonstrably show not only the opt-in but also the opt-out. Read more about how this fits within privacy by design and retention periods on the pages about consent & provenance and GDPR.
Why verification & consent up front
Checking before processing gets you three things at once: cleaner data, demonstrable consent and less risk. Together they turn every request into something you can confidently pass on to your buyers, all within the platform you run under your own brand.
Only clean requests get through
Incomplete, duplicate or suspicious requests are stopped before they burden your flow.
Demonstrable consent
Consent and legal basis are captured per lead and remain auditable under your own brand.
Less risk
Verified provenance and consent reduce the risk for you as the operator and for your buyers.
Frequently asked questions about verification & consent
The questions we get most often about how provenance, consent and quality are checked and captured.
What makes a consent record “watertight”?
A watertight record contains the legal basis, the exact opt-in text with version number, a timestamp, the source URL, the IP address and the retention period. Together those fields show not only that someone gave consent, but also for what, when and in what context: exactly what a regulator wants to see under an audit. The platform captures them by default for every request.
Why is capturing consent up front better than reconstructing it afterwards?
Consent captured up front is a fact that travels with the request; reconstructing it afterwards is an assumption based on emails and logs. Under a regulatory audit the difference is crucial: you export the record and demonstrably show what happened, instead of hoping your story holds up.
What concrete fraud checks does the platform run?
Among other things it detects disposable email domains, a completion speed that points to a bot, repeated IP addresses, duplicate submissions, and bursts of requests arriving from the same device within seconds. Signals are weighed; whatever crosses the threshold is blocked or flagged for manual review. You set the thresholds yourself.
What happens to a request that does not pass the checks?
It is not quietly forwarded but set aside with the reason attached: incomplete, duplicate, unusable or suspicious. That way it does not burden your flow, the cause stays traceable, and you can hold your publishers accountable for quality.
How does OXIAE handle the withdrawal of consent?
A withdrawal is logged, timestamped and linked to the original consent record. Further processing for the relevant purpose stops, and under an audit you can demonstrably show both the opt-in and the opt-out.
Can I export the verification and consent data?
Yes. Every step in the verification and every consent record is visible and exportable at any moment via the audit trail, so under an audit or a buyer query you can produce evidence immediately, under your own brand.
“When the regulator asked for proof of consent, we exported the record with legal basis, text version and timestamp. No searching, no reconstruction, just showing what happened.”
Verify every request before processing
Book a demo and see how OXIAE checks and captures provenance, consent and quality by default, in the platform you run under your own brand.