AML update process

In order to comply with regulatory requirements, Solaris must follow up with customers on a regular basis to confirm the accuracy of their personal data.

How does the follow-up process work?

The primary components of the follow-up process are two properties on the person resource:

• aml_confirmed_on: Indicates the last instance when the customer confirmed their data for AML purposes.
• aml_follow_up_date: Indicates the next date when the customer must confirm their data.

Your solution must monitor each customer's aml_follow_up_date and display a prompt for them to confirm their data prior to that date. You may do so up to 60 days before the follow-up date.

• If the customer confirms the correctness of their data, then call the PATCH Update a person endpoint and supply the aml_confirmed_on property with the current date (UTC format).
• If the customer confirms that their data is outdated, then your solution must collect their updated data and pass it to Solaris using the PATCH Update a person endpoint. In the request body, supply all of the updated properties as well as the aml_confirmed_on property with the current date (UTC format).

When you submit this data, Solaris will calculate a new aml_follow_up_date for the customer.

Review cycles

Solaris calculates the aml_follow_up_date during the customer onboarding process based on the customer's risk profile and the branch. This information is returned in the response of the POST Create person call.

The following review cycles apply for each branch and risk class:

Germany:

• Low risk customers: every 7 years
• Medium risk customers: every 5 years
• High risk customers: yearly

FRITES (France, Italy, and Spain):

• Low risk customers: every 5 years
• Medium risk customers: every 3 years
• High risk customers: yearly

Data points to confirm

The data points that must be confirmed on each aml_follow_up_date depend on the customer segment (e.g., retail consumers, freelancers, etc.) and the branch (e.g., Germany, France, Italy, or Spain).

These are the data points you must confirm with your customers for each branch on each aml_follow_up_date:

Retail customers (B2C)

• Germany
• France
• Italy
• Spain

Freelancers

• Germany
• France
• Italy
• Spain

Example requests

No customer data change

Request:

// PATCH /v1/persons/:person_id
{
  "aml_confirmed_on" : "2021-09-20"
}

Response:

// 202 Accepted
{
  "id": "f7c393b881370514fb612db8c25b26a9csc",
  "updated_at": "2021-09-20T11:21:05.000Z",
  "status": "AUTHORIZATION_REQUIRED",
  "url": ":env/v1/change_requests/f7c393b881370514fb612db8c25b26a9csc/authorize"
}

Updated customer data

Request:

// PATCH /v1/persons/:person_id
{
  "address": {
    "line_1": "Musterstraße 123",
    "line_2": "",
    "postal_code": "10178",
    "city": "Berlin",
    "country": "DE",
    "state": "BE"
  },
  "aml_confirmed_on": "2021-09-20"
}

Response:

// 202 Accepted
{
  "id": "49a15f92f2f930a84e51998783db035bcsc",
  "updated_at": "2021-09-20T11:22:00.000Z",
  "status": "AUTHORIZATION_REQUIRED",
  "url": ":env/v1/change_requests/49a15f92f2f930a84e51998783db035bcsc/authorize"
}

(Sandbox testing) Patching the AML follow-up date

In order to test this functionality, you can use the endpoint described below to patch the AML follow up date:

Request URL:

PATCH /v1/persons/:person_id/update_for_development

Request example:

{
  "aml_follow_up_date": "2021-11-10"
}

Response: (Person's details with updated AML date)

{
  "id": "84bc4cd997af0c5a3bb402ce38b932dfcper",
  // ...
  "aml_follow_up_date": "2021-12-10",
  // ...
}

Click here to view the full API reference.