Sending Data Incrementally

Cable is the leader in Automated Assurance. To enable Cable to run checks for your organisation, you need to send Cable data about your entities (account owners, retail customers, businesses) and their onboarding journey. The onboarding journey includes the data they sent as they registered, and the IDV checks and screening checks they went through, both internally and externally.

The easiest way to integrate with Cable and provide that data is by using the API. At Cable, we want to track every change that an entity goes through, so that we can accurately provide results for the checks we run. This means that, as an entity changes through your system, for example by providing missing data or updating their details, you should forward that information to Cable.

We use that series of changes to calculate the latest state of the entity, and assure it’s meeting all the regulatory requirements.

Look at the example below, a retail customer going through onboarding. We will go through several steps, with examples of the payloads to share the data with Cable:

• Sharing personal information collected at sign up time (name, date of birth)
• Sharign an email collected at a later stage of onboarding (email)
• Sharing the results of a screening check ran on the retail customer (IDV screening)

Sharing the personal information

In this example we are sending information about retail customers, to the person_info retail endpoint https://api.cable.tech/v1/retail/person_info.

You’d create the retail customer entity as it gets created into your system. Suppose you collect name and date of birth first, you’d send the data to Cable with the following payload:

1
[
2
    {
3
      "is_test_user": false,
4
      "data": {
5
        "first_name": "Alex",
6
        "last_name": "Doe",
7
        "date_of_birth": "1991-10-10"
8
      },
9
      "id": "bank-abc-1",
10
      "timestamp": "2024-07-29T13:22:21.123455"
11
    }
12
]

Sharing the email

You are now sending an email address for the same retail customer collected at a second stage of onboarding. You just need to use the same id and a later timestamp corresponding to when the data was collected. They payload only needs to contain the changes, such as:

1
[
2
    {
3
      "is_test_user": false,
4
      "data": {
5
        "email": "alex.doe@example.com"
6
      },
7
      "id": "bank-abc-1",
8
      "timestamp": "2024-07-29T13:30:09.432156"
9
    }
10
]

Sharing information about a screening

Both of the previous examples were a demonstration of how to update a retail customer entity. What if data changes for another entity related to that retail customer? We can just follow the same thought process, paying special attention to the IDs used in the request.

Lets send data that is related to external verification of name to the idv_info endpoint - notice the parent.id referring to the person entity that was just shared.

1
[
2
    {
3
      "data": {
4
        "verification_type": "name",
5
        "verification_outcome": "pass",
6
        "verification_provider": "cognito"
7
      },
8
      "parent": {
9
        "id": "bank-abc-1"
10
      },
11
      "timestamp": "2024-07-29T13:34:34.123455"
12
    }
13
]