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.
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.
Retail Customer (B2C)
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).
This endpoint requires a change request.
When you submit this data, Solaris will calculate a new aml_follow_up_date
for the customer.
If the user does not confirm the accuracy of their data and the aml_follow_up_date
passes, then Solaris will block the customer's account with the reason AML_FOLLOW_UP_OVERDUE
. Solaris will unblock the account when the customer confirms their data.
Business Customers (B2B)
Solaris monitors each business customer's aml_follow_up_date
and a periodic review assessment is initiated by Solaris:
- Solaris will assess the business and might request additional information to assess the business data.
- In case any additional information requirement is identified, Solaris will contact you with specific requests on a case-by-case basis.
- Your solution should be able to send out this request to the end-Customer and provide the information back to Solaris for internal assessment.
If the business does not reply to Solaris with the requested information and the aml_follow_up_date
is due, solaris has the right to block the customers´s account with the reason KYC_DEBIT_BLOCK
. Once the customer provides the data requested, Solaris will assess the information and determine the next steps.
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
France, Italy, and Spain (FRITES):
- Low risk customers: every 5 years
- Medium risk customers: every 3 years
- High risk customers: yearly
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
:
address
line_1
line_2
postal_code
city
country
state
mobile
employment_status
address
(Personal address)line_1
line_2
postal_code
city
country
state
mobile
employment_status
business_purpose
nace_code
expected_monthly_revenue_cents
website_social_media
business_trading_name
business_address_line_1
business_address_line_2
business_postal_code
business_city
business_country
Below is an example of the common data points that are reviewed by Solaris during the Business periodic review. This list is not exhaustive and further data points may be requested on a case by case basis.
Germany
Germany
company_status
legal_form
address
(Business address)postal_code
city
country
state
business_purpose
nace_code
website
registration_number
registration_issuer
legal_representatives
ultimate_beneficial_owner
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"
}
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"
}
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",
// ...
}