# The Investigator, the people you verify and their data Source: https://help.didit.me/investigations/investigator-end-users-and-privacy Updated: 2026-10-23 The Investigator can ask people for more information, explain each decision and let them contest it, while you control the data it reads and where it runs. In **Investigator → Settings → The person behind the verification**, turn on **Ask the person for more information** to let the Investigator ask people for what it's missing in a private thread, and **Explain each decision to the person** to give each decision a plain explanation the person can contest. In **How the Investigator reads and writes**, hide fields from the agent and choose the **EU zero-retention** model. > **Note:** These features are rolling out one by one and may not be switched on for your > application yet. Changing them needs permission to change the application's > settings, and every change is recorded in **Activity**. Nothing the Investigator sends to a person ever names a risk, a screening match or a reason that could tip them off. Neither feature works in the AML queue. ## Ask the person for more information When a review ends in a request for more information on a verification or a business verification, the Investigator can open a conversation with the person instead of only sending the steps back: 1. It drafts the first message in the person's language from your [Messages to people](https://help.didit.me/investigations/investigator-setup-and-policy): what to redo and why, step by step, and the deadline (7 days). 2. The person gets a private link, by email when you have their email address. The page carries your branding when you use white label. 3. The person answers in the thread with a short text and up to 3 photos, and redoes the reopened steps. 4. Their answer starts a new review that reads the whole thread. A review that weighed what the person wrote back is never decided automatically: a person always decides it, with the new facts. When the person only redoes the reopened steps, without writing back, the new review follows the queue's autonomy like any other. If there's no answer, the person gets up to 2 reminders, 48 hours apart, and the request is marked **Overdue** after the deadline. A request closes when the item is decided by anyone, when a newer request replaces it, or when a reviewer presses **Close request**. The Investigator doesn't open a request when the item has an open screening match or a reason that could tip the person off, when the item already had 3 requests, or when it was already resubmitted more times than the rule allows. In the report, the **Information request** section shows the thread, its status (**Pending**, **Answered**, **Overdue** or **Closed**) and the photos the person sent. Filter the queue by **Information requests** to see them all. An answered request moves the item up the queue. ## Explain each decision to the person Under the EU AML Regulation (article 76(5)) and the GDPR (article 22), people subject to an automated decision have the right to an explanation and to ask for a human review. With **Explain each decision to the person** on, each decision on a verification or business verification keeps a plain explanation in the person's language: - the outcome (**Approved**, **Declined** or **More information requested**), and whether it was **Decided automatically** or **Decided with a reviewer**; - the principles applied: your verification policy and what is checked on every verification; - for a decline or a request for more information, what would change the outcome, written for the person. When a reason must not be shared, for example an AML match or a fraud signal, the explanation only says that more details can't be shared, so nothing can tip the person off. It never contains a risk code, a score or a list name. The report's **Explanation** section shows exactly what the person reads. Press **Copy the person's link** to send it to them yourself. The link is private and expires after 90 days. ### When the person contests a decision From that page the person can ask for a human review once, with their view in a short text and an optional photo. A contest: - opens a [case](https://help.didit.me/investigations/cases) on the verification, with the person's view as a note; - marks the decision **Contested** in the queue, moves it up the queue, and is never decided automatically; - is written to **Activity** and can send a webhook. The explanations and the information request messages also appear under **End-user messages** in the verification's PDF report, so you can include them when you answer a data access request. ## Hide data from the agent **Hidden from the agent** lists the sections and fields the agent must never read, for example the person's address or a whole section such as the network. A hidden field never reaches the agent, so it never appears in its reports. **All images** also turns the visual review off, and you can hide one kind of image only, such as selfies. You can hide up to 50 sections and fields. Hide only what your policy doesn't need: the agent can't weigh what it can't see. ## Choose where the model runs **Model** sets how the agent's model is called for this application: | Profile | What it means | |---|---| | **Default** | Didit's default model and routing | | **EU zero-retention** | The model calls go through an EU endpoint, and only to providers that keep nothing from the prompt or the answer | The visual review always runs with zero data retention, whatever the profile. See [your DPA and data residency](https://help.didit.me/data-privacy/dpa-and-data-residency) for where the rest of your data is stored. ## Choose which websites it may read For business verifications and AML matches, the Investigator can research public websites and cites each source in its report. In **Web research sources**, list the **Allowed websites** (empty means any public website) and the **Blocked websites**, which it never reads even when allowed. These lists apply to every application in your organization, and only organization owners and admins can change them. Each list holds up to 100 domains, such as `example.com` or `*.example.com`. A report that used web research is never decided automatically, and what a website says can never make the Investigator take an action: it's only evidence. ## Report language **Report language** sets the language reports, reasoning and drafted notes are written in, for this application only. Quotes, codes and record numbers stay as written. The messages to the person are always written in the person's language. ## Regulatory report drafts For AML and transaction work, the Investigator can draft a suspicious activity or suspicious transaction report (SAR or STR) from the report: who, what, when, where, why and how, a narrative, and a goAML file checked against the schema with any missing fields listed. A person reviews it, completes it and signs it. **Didit never files a regulatory report**: the draft is yours to submit to your financial intelligence unit yourself, or to discard. The **Regulatory report** section appears on reports about cases, AML matches and transaction alerts, and on any report that recommends escalating: 1. **Draft it** Pick the **Report type**, **STR · suspicious transaction** or **SAR · suspicious activity**, and press **Draft the report**. The draft keeps one narrative over every alert, and says whether it's **Valid against the goAML schema** yet. 2. **Review and sign it** Edit the narrative if you need to. Under **Sign off**, type **Your full name, as you sign**, confirm that you reviewed the report and will file it yourself with your FIU, and press **Sign the report**. Or press **Discard** to drop the draft. 3. **File it yourself** Press **Download goAML XML** and file the report with your financial intelligence unit (FIU) yourself. The draft shows **Signed** with your name and the date, and Didit never files it. Drafting, signing and discarding need write access to the item, and each one is written to **Activity**.