> This page is for version v1.0.
> For other versions, use one of these documentation indexes:
> - v2.0 (default): https://docs.cable.tech/v-2-0/llms.txt
> - v1.0: https://docs.cable.tech/v-1-0/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.cable.tech/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cable.tech/_mcp/server.

# How to share externally verified data

If you are using Cable to perform Automated Assurance, you might have already come across checks of the type:

* All account owners have provided names; or
* All companies have provided addresses

This is the first information a financial institution gets when onboarding a new customer.

It is important to **verify** that this data is correct. Cable offers checks with a similar name but an important change:

* All account owners have either **verified** dates of birth or **verified** addresses; or
* All customers have **verified** names

> **Note**
>
> Notice the highlighted word **verified** - it indicates that the information was verified by a third party. When integrating with Cable, developers need to take this into consideration, to correctly send the required data.

Take some time to get familiar with the [IDV](https://docs.cable.tech/api-reference/customer-data-api/retail/v-1-retail-idv-info) endpoint.

When integrating with Cable, developers usually fall into one of two traps:

1. Not using the `externally_verified_data` block of the API, present in the IDV endpoint

![](/_fern-img/abbcdf313708c9b0053395ed4c507351955094163bd4b99ebc943757111107ca.webp)

2. Difficulty breaking down the data to get enough resolution.
   * i.e. the customer might validate that multiple pieces of information match with a person to get an identity check. They can’t say if the name matched with 100% certainty, they can only say that the information as a whole did.

---

To be able to run these checks, send the data making sure to:

1. Be very specific when defining the `payload.verification_type` and set it as the name of the test run.
   * For example: “Customer name verified”; with `payload.verfication_outcome` as the correct value, one of `True/False/None`

2. Integrate the `externally_verified_data` block into your payload, giving us exact details about which type of field was sent to the external service, and whether it was validated or not

Let's show some examples of good payloads to send to Cable:

### IDV endpoint examples

#### ✅ Example of a good IDV payload, using 'externally_verified_data'

```

    {
    "data": {
        "externally_verified_data": [
        {
            "is_externally_verified": true,
            "type": "first_name",
            "value": "Jane",
            "provider": "my_kyc_provider"
        },
        {
            "is_externally_verified": true,
            "type": "last_name",
            "value": "Doe",
            "provider": "my_kyc_provider"
        },
        {
            "is_externally_verified": false,
            "type": "telephone",
            "value": "+112345566555",
            "provider": "my_kyc_provider"
        }
        ],
        "verification_type": "kyc_verification",
        "verification_outcome": "true",
        "verification_provider": "my_kyc_provider"
    },
    "parent": {
        "id": "my_internal_id"
    },
    "timestamp": "1970-01-01T00:00:00.1234"
    }
]
```

#### ✅ Example of a good IDV payload, using 'verification_type' to define the type of external validation or tests passed

```json
[
    {
    "data": {
        "verification_type": "kyc_check",
        "verification_outcome": "pass",
        "verification_provider": "my_kyc_provider"
    },
    "parent": {
        "id": "my_internal_id"
    },
    "timestamp": "1970-01-01T00:00:00.1234"
    },
    {
    "data": {
        "verification_type": "kyc_phone_number_verified",
        "verification_outcome": "false",
        "verification_provider": "my_kyc_provider"
    },
    "parent": {
        "id": "my_internal_id"
    },
    "timestamp": "1970-01-01T00:00:00.1234"
    },
    {
    "data": {
        "verification_type": "kyc_full_name_verified",
        "verification_outcome": "true",
        "verification_provider": "my_kyc_provider"
    },
    "parent": {
        "id": "my_internal_id"
    },
    "timestamp": "1970-01-03T12:05:34.1234"
    }
]
```

#### 🛑 Example of a bad IDV payload, not 'externally_verified_data' where we can’t validate checks like 'verified phone number' or 'verified name'

```json
[
    {
    "data": {
        "verification_type": "kyc_verification",
        "verification_outcome": "true",
        "verification_provider": "my_kyc_provider"
    },
    "parent": {
        "id": "my_internal_id"
    },
    "timestamp": "1970-01-01T00:00:00.1234"
    }
]
```