Swiss Insurance Lead Handoffs: 16 Fields Before a Broker Calls

The decision in one minute

Do not send a Swiss health-insurance enquiry to a broker merely because a form contains a name, telephone number and a checked box. Before a handoff, the receiving team should be able to answer four separate questions: what did the person ask for, who is allowed to receive the record, which contact did the person request, and what evidence supports that interpretation? If any answer is unknown, hold the record for clarification instead of treating “lead delivered” as “permission granted.”

The practical asset below is a 16-field transfer contract, a 12-scenario acceptance matrix and a small Node.js validator. They check whether a record is complete enough for a human to review. They do not determine whether a campaign is lawful, whether a consumer consented under every applicable rule, whether a broker is authorised, or whether a phone call is permitted. A technical green result is only a completeness signal.

That distinction matters in Switzerland. The Federal Office of Public Health (FOPH) says cold telephone acquisition by insurance intermediaries has been prohibited since 1 September 2024, while its definition turns on whether contact was unsolicited and unannounced, whether a business relationship exists or ended more than 36 months ago, and whether the contact came through a recommendation from someone the person knows. A form submission can be relevant evidence, but the form, its wording, the named recipient and the requested channel still matter. The regulator’s current explanation of insurance intermediaries and unwanted calls should be read alongside the specific facts of the journey.

For a group-owned starting point, our guide to qualifying insurance leads for brokers covers the first qualification questions. This article goes one layer deeper: what must travel with a record so a receiving organisation can accept, reject, quarantine or later explain a handoff. The group page is commercial editorial, not an independent authority; the legal and research claims below rely on external sources.

The unresolved buyer problem: a call can be traceable and still be wrong

Buyers often procure “qualified” leads by asking about volume, exclusivity, territory, price and delivery speed. Those questions do not show whether a person expected a call from this recipient about this product. The common operational gap sits between the form and the call: the lead buyer may receive a person’s details without the exact page version, notice, recipient scope, request time or evidence reference that gives the record meaning.

This is not a hypothetical concern invented from a marketing checklist. In an August 2026 discussion, Swiss residents asked why supposed health-insurance advisers were calling repeatedly, whether cold calling was still prohibited, and how callers had obtained their information. Another discussion described a caller knowing specific details and the person not knowing which organization had received them. These are individual reports, not a representative survey, proof of a data leak, or evidence that any named broker broke a rule. They do show why a buyer needs a source and recipient trail that can be answered in plain language rather than a vendor’s unsupported “the lead opted in.”

Swiss public broadcasting has also surfaced the boundary problem. In a June 2025 SRF report, a listener asked whether door-to-door collection of addresses for later calls bypassed the telephone cold-calling ban; the report says the FOPH considered the described collection lawful. That is a reported case, not a general permission for every collection or later contact. Its useful lesson is narrower: acquisition channel, data collection and later telephone contact are separate events. A buyer should preserve which event actually happened and should not convert a vague collection into a recorded request for a specific call.

The procurement decision is therefore not simply “buy or do not buy leads.” It is: can the supplier deliver the context and controls needed for a human to decide whether this specific record can be used for this specific next step? If the supplier can only return a contact row, cannot name the onward recipient, or cannot reproduce the form and notice the person saw, the buyer does not have enough evidence to release it to sales.

What the Swiss sources say—and what they do not say

The FOPH describes the telephone cold-calling ban for insurance intermediaries and lists the circumstances that define cold calling in its guidance. It also describes where a person can report unwanted calls. This is the operating boundary for the contact journey, not a substitute for analysing whether a particular web form created an announced request or whether a separate marketing rule applies. A “phone” field is not itself proof that the person invited a call. A checked control is not self-explanatory unless the saved version shows what the person was told, who could receive the data and what kind of contact was being requested.

The Federal Data Protection and Information Commissioner (FDPIC) explains that a controller must inform people in advance and adequately when collecting personal data, even when the data is not collected directly from them. Its guidance says the information should be clear and accessible and should include the controller’s identity, purposes and, where applicable, recipients or recipient categories. When information comes from another source, the controller still needs to make sure the person is effectively informed, subject to limited exceptions. That supports keeping the notice version and collection source with a lead record. It does not mean that a single checkbox is always the legal basis for processing, nor that every downstream use is automatically covered.

The Swiss Federal Act on Data Protection sets requirements for purpose, proportionality, transparency, security and processor arrangements. The FDPIC’s outsourcing guidance says the controller remains responsible when a processor handles data and must select, instruct and monitor that processor. The operational implication for a buyer is to map vendors and onward parties rather than assuming a lead platform’s privacy page resolves every controller, processor or disclosure question. Roles depend on the real arrangement and should be reviewed with counsel.

Insurance distribution adds another control boundary. FINMA describes registration and governance requirements for insurance intermediaries, depending on the activity and tied or untied status. BCG’s 2024 review of digital insurance journeys assessed more than 70 insurers across 13 European markets and describes friction from excessive information requests and confusing forms. That is a commercial benchmark of sales journeys, not a Swiss legal assessment or lead-quality study. Its practical implication is to pass enough context for an adviser to continue a digital request without collecting every detail up front. Verify legal status and duties against FINMA and the applicable legislation. The entity buying a lead and the person who will call may differ; record both and whether onward transfer is permitted.

The product boundary also matters. Basic mandatory health insurance and supplementary cover do not have identical acceptance rules. The FOPH’s health-insurance FAQ explains that a basic insurer cannot refuse an applicant for basic cover because of age or health, while supplementary insurers can ask health questions, attach conditions or reject an application. A lead intake process should not collect or circulate health answers just because an adviser might later discuss supplementary cover. Keep the initial referral narrow; route underwriting questions into the insurer’s own controlled process, with suitable notice and safeguards. This is a minimisation recommendation, not a claim that every health-related detail is forbidden in every insurance workflow.

A proposed 16-field contract for each handoff

The contract is intentionally small. It is a buyer-designed transfer record, not a standard mandated by the FOPH, FDPIC or FINMA. Sixteen fields make the high-risk parts explicit: source, version, purpose, product, recipient, channel, request state, evidence reference and a sensitive-data flag. A buyer may need additional fields for its CRM, but should not remove the fields that allow the handoff to be explained.

Keep personal contact details in the protected lead payload, not in the idempotency key or an analytics event. The contract does not need to duplicate everything the broker may eventually ask. The point is to preserve enough context for a recipient to decide whether to accept the record and what to do next without receiving a complete health profile.

The most important design choice is the difference between requested_channel and contact_request_state. A person can provide a phone number because a form asks for one without asking for a call. They can request an email but not a phone call. They can request one named broker and not a network of downstream sellers. A system that collapses these into consent=true loses the distinctions the next operator needs.

request_evidence_ref should point to evidence held in a controlled system: form version, event timestamp, exact recipient disclosure and the action recorded. It should not be a public URL containing the person’s data. If the evidence cannot be retrieved later, the reference is not useful. If an operator changes the recipient after collection, create a new reviewed event rather than silently rewriting the old record.

The release rule: admit, hold, reject, then contact only after human review

Treat the transfer as a state machine, not a database import. A record can be technically complete and still be unsuitable for action. A practical buyer-side release gate has four dispositions:

The code should fail closed on unknown, not transform unknown into no objection or permission. That is a workflow control, not a legal conclusion. A qualified reviewer still needs to check the exact disclosure, the applicable basis for processing, the parties’ roles, contact rules and the product. The system can preserve evidence and stop an obvious mismatch; it cannot decide a nuanced legal question by matching a string.

The first phone call deserves its own gate. Before any call, confirm that the source record documents a request for that channel, that the request is still current, that the named recipient is the caller or an explicitly described permitted recipient, and that the current FOPH rules and the organisation’s own policies allow the next step. Do not use a lead’s age or a last-client date as an automated legal safe harbour. The FOPH’s 36-month definition is one part of its description of cold calling; the full facts and the applicable rule still matter.

For supplementary insurance, do not let “the person asked for an insurance comparison” become “the person agreed to a health questionnaire from any insurer.” The underlying insurer controls its underwriting process. Keep the broker’s initial contact to the stated request and move any health questions into the appropriate insurer-controlled journey. If the person asked about basic cover only, a supplementary offer is a different purpose and should not be smuggled in as an assumed next step.

Duplicate suppression, retries and corrections

Lead suppliers often deliver by API, CSV, email or shared CRM. Every one of those channels can retry. If a receiver creates a fresh task each time it sees the same lead_id, one original request can become multiple calls. Use the stable idempotency_key to make task creation idempotent, and keep an event log that distinguishes a repeated delivery from a new request.

Do not deduplicate people only by telephone number. Families may share a number, people change numbers, and a number can be mistyped. The event key should identify a delivery event; the protected customer record can use a separate matching process with human review. If two records may be the same person, hold them for reconciliation rather than merging them automatically and carrying one person’s request state into another person’s record.

Corrections must preserve history. If a person withdraws a request, record the withdrawal event and propagate a suppression instruction to the supplier, CRM, call queue, subcontractor and any other recipient that received the lead. A later correction should not erase the fact that an earlier task was created. Preserve the minimum audit trail needed to explain the action, with a retention period determined by purpose, legal duties and the organisation’s retention policy.

The runbook must also define what happens when the delivery result is uncertain. If the sender times out after transmitting a record, it may not know whether the buyer accepted it. Retrying with a new key can duplicate a task; not retrying can drop the record. The receiver should acknowledge the same key, expose a status query or provide a reconciliation file. The seller and buyer should agree whether an “unknown” result is held until reconciled. Avoid sending the same personal payload repeatedly as a substitute for transaction status.

A 12-scenario acceptance matrix

These are hand-authored synthetic scenarios for a buyer’s staging environment. They are not results from a live brokerage, insurer, form, campaign or set of people. Use them to check that the implementation routes records conservatively; do not report a pass percentage as evidence of legal compliance.

For each synthetic case, record the input, expected state, actual state, reason and software version. If the actual state differs, stop the release and fix the rule or its mapping. Keep the acceptance result separate from a compliance conclusion: a technical test only proves that your software followed the test case you supplied.

Runnable local completeness validator

This Node.js example validates required fields and conservative routing. It has no network calls, makes no legal determination and stores nothing. It intentionally avoids printing record contents. Save as validate-lead.js, then run node validate-lead.js sample.json. Replace the sample with synthetic data first; do not paste real consumer records into a public example or terminal history.

#!/usr/bin/env node
'use strict';

const fs = require('node:fs');
const REQUIRED = [
  'lead_id', 'idempotency_key', 'captured_at_utc', 'source_page',
  'source_version', 'notice_version', 'purpose_code', 'product_line',
  'need_category', 'recipient_id', 'recipient_scope', 'requested_channel',
  'requested_window', 'contact_request_state', 'request_evidence_ref',
  'sensitive_data_class',
];

function disposition(r) {
  const missing = REQUIRED.filter(k => r[k] === undefined || r[k] === null || r[k] === '');
  if (missing.length) return { state: 'hold_for_clarification', reason: 'missing_required_fields', count: missing.length };
  if (r.contact_request_state === 'withdrawn' || r.contact_request_state === 'not_requested') {
    return { state: 'reject', reason: 'no_active_contact_request' };
  }
  if (r.sensitive_data_class !== 'none') {
    return { state: 'restricted_review', reason: 'sensitive_or_unknown_data' };
  }
  if (r.contact_request_state === 'unknown' || r.requested_channel === 'unknown' || r.recipient_scope === 'other') {
    return { state: 'hold_for_clarification', reason: 'ambiguous_scope_or_request' };
  }
  if (!['basic', 'supplementary'].includes(r.product_line)) {
    return { state: 'hold_for_clarification', reason: 'unknown_product_line' };
  }
  if (!['phone', 'email', 'appointment', 'none'].includes(r.requested_channel)) {
    return { state: 'hold_for_clarification', reason: 'unsupported_channel' };
  }
  if (r.contact_request_state !== 'requested' || r.recipient_scope === 'named_only' && !r.recipient_id) {
    return { state: 'hold_for_clarification', reason: 'request_not_reconstructable' };
  }
  return { state: 'accept_for_review', reason: 'complete_for_human_review' };
}

if (process.argv.length !== 3) {
  console.error('Usage: node validate-lead.js <synthetic-record.json>');
  process.exit(2);
}

try {
  const record = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
  const result = disposition(record);
  process.stdout.write(JSON.stringify(result) + '\n');
  process.exitCode = result.state === 'accept_for_review' ? 0 : 1;
} catch {
  console.error('Invalid JSON or unreadable file; record contents were not printed.');
  process.exit(2);
}

The validator’s accept_for_review state is deliberately not named call_allowed or consent_valid. It does not examine whether the contact was announced, whether the person is a current customer, whether a known third party referred them, whether the recipient is registered where required, what the notice actually said, whether an onward transfer is lawful, or whether the person later opted out. Those checks belong in the human and system workflow around this small completeness gate.

One implementation caveat is that JSON values can be syntactically present yet semantically wrong. A fake timestamp, an unresolvable notice ID, or a recipient ID mapped to the wrong legal entity will pass a shallow presence check. In production, validate timestamp format, URL allowlists, enumerations, recipient registry, version lookup and signature or event integrity separately. Keep a versioned rule set and test it after every change to the form, partner list or contact queue.

Source control and evidence pack

Before buying a lead feed, test whether one sample record can be reconstructed end to end without asking the supplier to explain it from memory. The evidence pack should connect the delivered data to the form version, notice, stated purpose, named recipient, event timestamp and later contact disposition. An auditor should be able to answer: which page created this record, what disclosure did the person see, who received it, what contact did they request, and was that request later withdrawn?

The FDPIC guidance is especially relevant where records originate with a third party: controllers should make sure people are effectively informed and identify data recipients or recipient categories when applicable. Its page also describes exceptions, including cases where informing a person is impossible or disproportionate, but says these exceptions should be narrowly interpreted. The operational recommendation is to make transparency evidence retrievable by default and document any exception through a qualified review rather than silently omitting the notice reference.

Processor arrangements need their own evidence. The FDPIC states that assigning processing to a processor does not remove the controller’s responsibility; the controller should select, instruct and monitor the processor. A buyer should therefore document who can access the lead, whether a call-centre vendor is involved, where processing occurs, what data they receive, how opt-outs propagate and how deletion or correction requests are handled. Those are contract and governance questions; the exact legal duties depend on role and facts.

For the insurance recipient, make a separate partner file: legal entity, tied or untied status where relevant, person actually performing the activity, register check where required, permitted products, territory, subcontractors, contact channels, complaints route and review date. FINMA describes registration and governance obligations for specific categories of intermediary activity. KPMG’s overview highlights why insurer-side oversight extends beyond the first named partner to classifications, ongoing checks, complaints and broker chains. Neither source turns your lead contract into a substitute for reviewing the actual insurance relationship.

The proof pack should also preserve the commercial promise that caused the consumer to submit a form. A supplier may call a lead “exclusive,” “verified” or “requested.” Those words need operational definitions. Exclusive to which legal entity, for what time window, and under which delivery route? Verified by which method and at what time? Requested for which product and channel? If a supplier cannot answer, do not fill the gap with a sales representative’s assumption.

What the research and discussions add

The lead-marketing study by Vekaria and colleagues on arXiv is a useful warning about data-flow complexity, not a Swiss market estimate. Its abstract reports a measurement setup spanning more than 100 health-related lead-generation websites and 200 controlled phone numbers and email addresses, plus leads purchased from three platforms. It reports sensitive information reaching many third parties and describes cases of data augmentation or fabrication. The article is a preprint hosted on arXiv; it is not Swiss-specific, and its website sample and controlled identities cannot establish how common any practice is among Swiss insurance brokers. The relevant design implication is modest: record provenance and recipient scope so that a buyer can detect unexplained transformations instead of trusting a label.

People’s questions add a different kind of evidence. Reddit threads from Switzerland include reports of repeated calls and uncertainty about where information came from. SRF’s 2025 audio item describes a listener asking whether collecting addresses at the door for later calls circumvented the phone ban; the segment reports the FOPH’s position in that fact pattern. These sources are not equivalent to regulations or representative surveys. They identify a real ambiguity the form and contract should resolve: did the person request an adviser, or did someone only collect an address for later marketing?

There is contradictory evidence to preserve. The FOPH’s reported answer in the SRF case means a lead-buyer checklist should not claim that all address collection or all later calls are prohibited. A requested, properly disclosed interaction may be different from unsolicited cold acquisition. The reverse is also true: the existence of a web form or an address collected by a third party does not, by itself, prove that a particular intermediary may make an unannounced call. The control should record the facts and pause when they do not match.

KPMG’s insurance-intermediary guidance is commercial professional commentary, while FINMA and the FOPH publish the governing regulatory explanations. Deloitte’s global insurance outlook discusses data privacy and data integration as challenges insurers face when scaling AI; it is a survey-based industry view, not Swiss lead-transfer law. I do not use it to support a legal rule or a numeric market claim. Keeping these evidence types distinct prevents a consultant’s view, a consumer anecdote and an official rule from being blended into one false certainty.

A buyer’s acceptance test before signing a lead contract

Ask the supplier to walk through one synthetic record from capture to closure. Do not begin with a sales demo; begin with the raw fields and event trail. Ask for the exact form version, notice version, declared purpose, intended recipient, contact channel, recipient scope and withdrawal behavior. Then ask the receiving broker to show how the record is quarantined if the recipient differs or the contact state is unknown.

Ask how duplicate deliveries are handled. Request a retry with the same idempotency key and confirm that it does not create another task. Then submit a withdrawal event and ask the supplier and recipient to show how suppression reaches every system that previously received the record. If the supplier cannot state which onward parties are involved, the buyer cannot verify propagation. “We delete it in our CRM” is not a complete answer when another copy exists in an agency inbox or call-centre system.

Ask what happens to free-text fields. If a person types symptoms, medication, a diagnosis or another health detail into an open box, is that text copied into a sales queue? Can the system detect and quarantine the record without exposing the text to the broad sales team? A “health_present” flag can route it to restricted review while preserving the original only in a properly controlled system. Do not attach the raw text to analytics, Slack, email notifications or error logs.

Ask how the partner is identified and checked. The buyer should know the legal entity receiving the record and the individual or team likely to make contact. Where the planned activity is untied insurance intermediation, use FINMA’s register and guidance to check the relevant obligations. If the supplier says it resells to a network, request the exact recipient set and an enforceable change-control process before allowing new recipients. A list that can change without notice is not a stable scope.

Finally, define the acceptance unit in the contract. Is an accepted record one that passes schema checks, one that is contactable, one that results in a completed conversation, or one that converts? These are different commercial outcomes. Do not pay for one definition while expecting another. The contract should specify duplicate handling, rejection windows, evidence access, corrections, suppression, deletion, incident escalation, downstream disclosure and the remedy for a record whose request evidence cannot be produced.

Failure modes that should stop release

A phone number is treated as a phone request. The form required a number for identity or follow-up, but the person chose email or no preference. The queue sees only a populated phone column and creates a call task. Fix: store the requested channel separately from contact details and fail closed on unknown.

A general “partners” disclosure is mapped to unlimited onward sharing. The marketing text says a partner may contact the person, but the receiving architecture distributes the record to a broker network, call centre and insurer without a versioned recipient scope. Fix: bind the handoff to named entities or a precise category that has been reviewed; quarantine any recipient outside it.

Basic and supplementary products are merged. A basic-insurance comparison form is used to start a supplementary health sale, possibly gathering health information too early. Fix: preserve product_line, purpose and requested need; route supplementary underwriting into its own controlled process.

A “consent” flag survives a withdrawal. A person opts out, but the CRM retry, supplier copy or call-centre export overwrites the newer state. Fix: represent changes as append-only events and apply a current suppression state across every recipient before task creation.

A buyer treats a schema pass as a legal safe harbour. The validator returns accept_for_review, so a sales queue dials without checking the actual wording or current rule. Fix: name the result as review, separate technical completeness from legal permission, and require human release for contact.

The supplier silently enriches the record. A partner adds inferred age, health status, insurer or weight but marks it as user-provided. The buyer then uses the field as fact. Fix: distinguish submitted, observed, inferred and third-party-enriched values with provenance and transformation history; never treat an inference as a user statement.

A lost acknowledgement creates duplicate calls. The sender retries after a timeout with a new ID and the buyer schedules another attempt. Fix: idempotent receiver behavior, queryable status, reconciliation and a single contact-attempt ledger.

The real caller is hidden behind the contracted recipient. A broker accepts the record, then a sub-broker or call-centre agent contacts the person. Fix: make the recipient and subprocessor chain explicit, review changes before release and maintain a trail of which person or organisation made the attempt.

When any of these failures appears, stop the specific record or feed, preserve the relevant evidence, prevent additional contact, and route the issue to privacy, compliance or legal review. Do not “repair” a missing disclosure by editing the record after the call; preserve what was actually shown and when.

A practical rollout in three stages

Start with a sandbox, not a production feed. Create synthetic records covering each row in the acceptance matrix. Confirm the importer preserves all 16 fields, the receiver identifies the exact recipient, duplicate retries do not create duplicate tasks, and unknown or withdrawn states never enter a call queue. Use test recipients and test phone numbers only. The scope of this exercise is software behavior, not market performance or a legal opinion.

Next, run a limited shadow period with a human reviewer. The supplier can deliver records to a quarantine queue, but reviewers do not contact the person until the evidence pack is complete and the recipient’s legal/compliance owner has approved the actual journey. Log the reason for every hold, rejection and acceptance. This reveals which fields are genuinely missing without exposing incomplete records to sales action.

Only then consider controlled release. Define a narrow product, named recipients, approved channels, an escalation route and a stop condition. Monitor complaints, duplicates, request withdrawals, unknown-recipient rates, missing-evidence rates and suppression propagation. These are proposed operational measures, not benchmark targets; set thresholds based on your own risk appetite and legal review. Do not publish a “conversion uplift” from this workflow unless you measure it with a defined population, period, denominator and comparison method.

Re-run the sandbox suite whenever the form wording, privacy notice, supplier, recipient, CRM mapping, contact channel or intermediary structure changes. Keep the test version, rule version and results together. A change in a button label can alter what a person reasonably understood; a change in a partner list can change who receives the data. Treat both as release changes, not cosmetic edits.

Proof pack: claim, source and verification boundary

Method, scope and limits

This article was prepared on 13 November 2026 from the official FOPH, FDPIC and FINMA guidance linked above; the current Federal Act on Data Protection; the ETH Zurich Swiss Insurance Monitor 2026; a BCG digital-sales benchmark; public consumer discussion threads; and the SRF audio report. Search Console context: during 14 October–11 November 2026, the query “leads assurance” returned 2 impressions at an average position of 26 for the group’s professionals-assurance page. This is a small, site-specific observation, not demand measurement. It motivated a narrower buyer-side handoff contract that complements the existing service page. The original asset is a proposed 16-field buyer contract, a manually designed 12-scenario acceptance matrix and the Node.js completeness validator. The scenarios are synthetic and were written to demonstrate routing decisions. No real leads, consumers, broker databases, insurer systems, API integrations, CRM queues, campaigns, forms, conversion outcomes or contact rates were tested. No measured result, benchmark or legal-compliance rate is claimed.

ETH Zurich describes its 2026 Swiss Insurance Monitor as a survey of 1,981 residents and says it distinguishes health, property and life insurance. That source provides consumer-journey context, not evidence about the compliance of a particular lead or broker. BCG’s benchmark is commercial and spans European insurer sales journeys; it is not specific to Swiss health-insurance referrals. Reddit reports are self-selected anecdotes. The SRF item is a journalistic account of one question and a regulator’s reported response; it does not settle every form or telemarketing scenario. FINMA and the relevant legislation remain the authorities for legal duties.

The proposed schema deliberately excludes names, phone numbers and health answers from the example itself. It includes a sensitivity flag so that an unexpected health field can be quarantined, not because a flag resolves whether processing is permitted. The validator checks field presence and a few conservative state transitions. It does not verify timestamps, notice content, registry status, legal basis, contact suppression across systems, identity matching, retention periods, cross-border transfer conditions or the truth of user-provided information. Those require separate controls and qualified legal review.

The recommendation fails if your real operation has a different controller/processor structure, uses a distinct product or channel, is subject to sector-specific rules, or cannot provide the notice and event evidence described here. In those cases, pause the workflow, map the actual data flow and obtain advice for the exact facts. Never treat this framework as permission to call, sell or share a record.

Validation checklist before a buyer accepts the feed

• The record identifies the exact collection page, form version and notice version.
• The purpose and product line match what the person requested.
• The recipient is named, resolved to a legal entity and inside the disclosed recipient scope.
• The requested contact channel is distinct from the contact details supplied.
• The request event and its evidence can be retrieved without exposing data in logs.
• Withdrawals, objections and corrections override older task state across all recipients.
• Retry delivery uses the same idempotency key and cannot create another contact task.
• Unknown recipient, unknown channel or missing notice version leads to a hold.
• Unexpected health information goes to restricted review, not a standard sales queue.
• The receiving intermediary’s role and any applicable registration are checked independently.
• Subprocessors, sub-brokers and downstream recipients are mapped and governed.
• Complaint handling, contact-attempt logging, retention and deletion responsibilities are assigned.
• The technical validator result is labelled “for human review,” never “legal consent verified.”
• A synthetic test suite is rerun after changes to forms, notices, partners, products or channels.

The buyer’s release decision can be short: accept for human review only when source, purpose, recipient, channel and evidence are coherent; hold when the record can be clarified; reject when it is withdrawn or outside scope; and restrict access when sensitive data appears. That is a more defensible handoff than a CSV row whose only proof is a telephone number and a vendor’s assurance.

General information only — not legal, insurance or medical advice. The applicable rules depend on the parties, product, form wording and contact journey. Verify current FOPH, FDPIC and FINMA guidance and obtain qualified advice before transferring or contacting people.