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.
Solaris calculates the aml_follow_up_date
during the customer onboarding
process based on the customer's risk profile. This information is returned in
the response of the POST Create person
call.
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).
info
This endpoint requires a change request.
When you submit this data, Solaris will calculate a new aml_follow_up_date
for the customer.
warning
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.
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",
// ...
}