As soon as a platform aggregates several sources of customer requests, two risks constantly threaten the quality of the flow moving between the two sides of the market. The first is the duplicate: the same request, from the same person for the same need, reaching a company more than once — because it was captured twice, resubmitted later, or picked up simultaneously by two different sources. The second is fraud: a request fabricated from scratch, fitted with invented contact details, recycled from an old file, or obtained without any genuine consent from the person concerned. On a two-sided model, these two risks are not marginal accidents but temptations inherent to the very structure of the marketplace.
This dossier explains, independent of any single category, how a serious marketplace organises its defence against both threats. It first draws the line between the duplicate and fraud — two problems of a different nature that call for different responses. It then describes the concrete mechanisms that keep them at bay: the technical deduplication that spots the same contact before it is distributed, the inventory of fraud types specific to this model, the traceability that ties every request to its exact source, and finally the trust scoring coupled with dispute handling, which turns every incident into an improvement signal for the whole system.
Duplicate and fraud: two distinct risks of a multi-source model
Duplicates and fraud are often conflated, even though they follow opposite logics. A duplicate is first of all a question of identity: two requests that point to the same person and the same need. It can arise in perfect good faith — someone filling in the same form twice because the page seemed unresponsive, or an intent captured simultaneously by two distinct partner sites at the moment it is expressed. A duplicate is therefore not necessarily malicious; it only becomes a problem if it goes unnoticed and results in a company working the same contact twice, or paying for the attention of a single prospect while believing it is reaching two.
Fraud, by contrast, presupposes an intent to deceive. It consists of passing off as a genuine request something that is not one: invented contact details, a person who never expressed the need attributed to them, an old request dressed up as a fresh one. On a multi-source marketplace, both risks are amplified by the structure of the model itself. Aggregation mechanically multiplies the points of capture, and therefore the chances that the same person is caught twice; and because a partner is valued according to the volume and quality of what it submits, an unscrupulous source may be tempted to inflate its flow artificially. That is precisely why a marketplace applies the same control rules to every source: defence against duplicates and fraud is only credible if it is symmetrical and systematic, never left to the goodwill of each individual partner.
How technical deduplication spots the same contact
Deduplication starts with normalising the contact data. The same phone number can be written a dozen ways — with or without a dialling code, with spaces, a leading zero, an international prefix — and the same e-mail address can vary by case or stray characters. The platform therefore reduces each detail to a single canonical form (number in a standardised international format, e-mail in lower case, name stripped of accents and abbreviations), then computes a stable fingerprint of it. It is this fingerprint, not the raw text entered, that serves as the comparison key: two requests whose fingerprints match almost certainly point to the same person.
Each new request is then checked against those already distributed within the same category and zone, over a defined time window — because the same need expressed months apart may legitimately be two distinct requests, whereas a repeat a few minutes later is almost certainly a duplicate. An approximate ("fuzzy") match complements the exact comparison to catch near variants: swapped first and last name, a typo in the address, a second number from the same household. Depending on when the duplicate is spotted, handling differs: caught before distribution, it is blocked or linked to the original request and never reaches a company twice; caught afterwards, it opens the door to a dispute. This upstream mechanism is what sets a structured marketplace apart from a plain file transfer, where the same contact can be delivered several times without anyone noticing.
The forms of fraud specific to a leads marketplace
On this kind of platform, fraud takes recognisable forms. The crudest is the entirely fabricated request: a form filled in by the source itself, with invented or borrowed details, purely to inflate a volume. Then comes the recycled lead, probably the most insidious form: a genuine but old request, already worked elsewhere and long since gone cold, resubmitted as though it had just been expressed. Added to this are stolen or misappropriated details, incentivised traffic — where a person fills in a form to obtain a reward with no real purchase intent — and abusive co-registration, where consent is buried in a pre-ticked box for a service the person never asked for.
These forms of fraud share a single engine: because a partner is valued according to what it submits, a dishonest source has an interest in maximising volume at the expense of the sincerity of the requests. Automated bots, submitting forms in bulk, are the industrial version of this abuse. The countermeasure therefore cannot be purely technical: filtering disposable addresses, checking whether a number is genuinely reachable, or detecting an abnormal submission rate is not enough if the incentive to cheat remains. A serious marketplace combines these automated checks with a continuous assessment of the source itself, so that fraud — even when it slips past a first filter — ends up turning against whoever produced it, through the erosion of their trust score.
Traceability: every request signed to its source
None of this would be possible without traceability. On a structured marketplace, every request carries, from the moment of capture, a provenance fingerprint: the source that produced it, the exact timestamp, the channel used, and the proof of consent obtained from the person. This signature travels with the request throughout its journey, from validation to distribution. It is what makes it possible, when a duplicate or fraud is found, to trace back to the precise source that introduced it — rather than to an anonymous mass of indistinct "providers" against which no sanction could ever be applied.
Traceability feeds three functions at once. It makes dispute arbitration possible, by supplying the objective elements that allow a complaint to be settled. It builds up each partner's track record, on which the trust score is founded. And it makes the system auditable, since a check can at any time verify that a given request really comes from where it claims to. This provenance data is deliberately kept to what the control requires: it serves to establish origin and consent, not to profile the person beyond the need they expressed. Without this layer of traceability, a marketplace could neither tell a reliable source from a failing one, nor prove anything in the event of a dispute — it would fall back to the level of a plain file reseller, unable to answer for the quality of what it distributes.
Source trust scoring and dispute handling
Trust scoring is where traceability, deduplication and anti-fraud converge. Each active source is assigned a score that evolves continuously from objective indicators: rate of duplicates produced, proportion of unreachable contacts, validated complaints, average freshness of requests, respect for consent. A source whose indicators deteriorate sees its flow gradually reduced, then placed under watch, and suspended if the drift persists — regardless of any commercial relationship, since it is precisely the uniform application of this rule that guarantees the average quality of the flow for all receiving companies.
On the companies' side, this is paired with a dispute procedure. A request deemed invalid — a proven duplicate, unreachable details, a need clearly outside the coverage area, or characterised fraud — can be flagged within a timeframe set in advance. The dispute is then examined in the light of traceability: the provenance fingerprint, the timestamp and the proof of consent allow it to be settled objectively, and a request found invalid gives rise to a replacement. The loop closes here: every validated dispute feeds back into the score of the source that produced it, reinforcing the incentive to submit only genuine, unique requests. It is this alignment of interests — the most honest source also being the best ranked and the most widely distributed — that makes duplicates and fraud structurally losing bets on a properly run marketplace.