> ## Documentation Index
> Fetch the complete documentation index at: https://docs.loqate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Policies

> Built-in and custom policy frameworks for controlling verification decisioning.

Policies define the thresholds that determine whether contact data is accepted, flagged for review, or rejected. Every `verify` call evaluates results against a policy to produce an actionable recommendation.

## Built-in policies

Reach ships with four policies covering common use cases:

| Policy         | Address Confidence | Match Level | Email Confidence | Phone Required | Use case                          |
| :------------- | :----------------: | :---------: | :--------------: | :------------: | :-------------------------------- |
| **strict**     |        0.90        |   premise   |       0.85       |       yes      | KYC, fraud prevention, compliance |
| **shipping**   |        0.70        |    street   |       0.50       |       no       | Physical delivery, e-commerce     |
| **standard**   |        0.55        |    street   |       0.45       |       no       | General verification (default)    |
| **permissive** |        0.30        |   locality  |       0.30       |       no       | Lead capture, marketing           |

## Choosing a policy

<AccordionGroup>
  <Accordion title="strict — KYC and fraud prevention">
    Requires premise-level address matching (0.90 confidence), high email confidence (0.85), and phone verification. Use for financial services, identity verification, and any flow where false positives are costly.
  </Accordion>

  <Accordion title="shipping — Physical delivery">
    Requires street-level matching (0.70 confidence) and moderate email confidence (0.50). Phone is optional. Use for e-commerce checkout, delivery address validation, and logistics.
  </Accordion>

  <Accordion title="standard — General purpose">
    The default policy. Requires street-level matching (0.55 confidence) and basic email confidence (0.45). Suitable for most use cases where you want verification without being overly restrictive.
  </Accordion>

  <Accordion title="permissive — Lead capture">
    Accepts locality-level matching (0.30 confidence) with minimal thresholds. Use for lead forms, newsletter signups, and scenarios where you want to capture data even if it's imprecise.
  </Accordion>
</AccordionGroup>

## Using a policy

### CLI

```bash theme={null}
lqt verify -a "10 Downing St, London, GB" --policy shipping -o json
```

### Environment variable

<Tabs>
  <Tab title="macOS / Linux">
    ```bash theme={null}
    export LOQATE_POLICY=shipping
    lqt verify -a "10 Downing St, London, GB" -o json
    ```
  </Tab>

  <Tab title="Windows (PowerShell)">
    ```powershell theme={null}
    $env:LOQATE_POLICY="shipping"
    lqt verify -a "10 Downing St, London, GB" -o json
    ```
  </Tab>
</Tabs>

### Policy resolution order

When multiple policy sources are present, Reach resolves in this order:

1. `--policy-file` flag (custom policy JSON file)
2. `--policy` flag (named built-in policy)
3. `LOQATE_POLICY` environment variable
4. `.loqate-policy.json` file in the current directory
5. `standard` (default)

## Custom policies

Create a JSON file to define your own thresholds:

```json custom-policy.json theme={null}
{
  "name": "my-ecommerce-policy",
  "description": "Balanced policy for e-commerce checkout",
  "address": {
    "min_confidence": 0.65,
    "min_match_level": "street",
    "reject_verification_status": ["U", "R"]
  },
  "email": {
    "min_confidence": 0.50,
    "allow_catch_all": true,
    "reject_disposable": true
  },
  "phone": {
    "min_confidence": 0.40,
    "required": false
  }
}
```

### Custom policy fields

#### Address

| Field                        | Type   | Description                                                                            |
| :--------------------------- | :----- | :------------------------------------------------------------------------------------- |
| `min_confidence`             | number | Minimum confidence score (0–1) to accept                                               |
| `min_match_level`            | string | Minimum match level: `premise`, `street`, `locality`, `administrative_area`, `country` |
| `reject_verification_status` | array  | Verification statuses to auto-reject (e.g., `["U", "R"]`)                              |

#### Email

| Field               | Type    | Description                                          |
| :------------------ | :------ | :--------------------------------------------------- |
| `min_confidence`    | number  | Minimum confidence score (0–1) to accept             |
| `allow_catch_all`   | boolean | Whether to accept catch-all email domains            |
| `reject_disposable` | boolean | Whether to reject disposable/temporary email domains |

#### Phone

| Field            | Type    | Description                              |
| :--------------- | :------ | :--------------------------------------- |
| `min_confidence` | number  | Minimum confidence score (0–1) to accept |
| `required`       | boolean | Whether phone verification is mandatory  |

### Validate a custom policy

```bash theme={null}
lqt policy validate custom-policy.json
```

### Use a custom policy

```bash theme={null}
lqt verify -a "10 Downing St, London, GB" --policy-file custom-policy.json -o json
```

### Register via MCP

In an MCP session, use the `set_policy` tool to register a custom policy for the current session. This is useful when your agent needs to switch policies based on context.