Onboarding
Last updated
Last updated
The onboarding process supports three types of customers:
Legal entities
Natural persons
Joint persons
Regardless of the type, the sequence of actions for onboarding is similar. Partners are required to create customer, send necessary documents and other related elements, and then initiate the onboarding process.
After onboarding a customer, additional related proxies and beneficial owners can be onboarded separately, in subsequent onboarding processes.
Onboarded customers do not have any products activated. Partners must create customer products to allow customers to create transfers and orders. Partners should use the Get Product Definitions API to get the list of active products that can be created for their customers.
The onboarding process is asynchronous and involves several steps:
Validation of customer data and required documents.
Verification of reference accounts via SEPA.
Performing additional checks likes Know Your Customer (KYC).
Upon successful completion of the process, a notification is sent to the partner via a webhook calls:
We support two categories of natural person customers:
Adult Customers
Child customers (individuals under 18 years old)
To onboard a customer who is above 18 years old, the partner is required to:
Onboarding a child customer (a natural person under 18 years old) is similar to regular customer onboarding, but with a few additional steps:
In cases of single custody, a Proof of Single Custody document is needed.
If the child's last name differs from that of the guardian, additional documents proving custody are required.
In the Contact section of the child customer, the contact details of one of the guardians must be provided.
There are following sections in the Natural Person Wizard:
Personal Data
Birth Data
Address Data
Contact
Risk Data
Tax Data
Employment Data
Asset Disclosures Data
Updates natural person data from wizard works only for opened wizard instances (status other than FULLY_COMPLETED). Any number of sections can be sent as a request body and after validation overwrites previously sent sections data. If the partner considers the data complete, he should set the createNaturalPerson flag to true in the request. This will create a natural person based on the data provided in the wizard.
Onboarding,
Customer,
Natural Person Documents,
All Customer Proxies,
All Customer Proxies Documents
and the partner is notified about these changes.
To KYC verifications are sent customer and all related entities like proxies. In the scenario, when KYC verification fails for any of the entity, manual verification process is initiated for each entity individually and status REVIEW is set on the natural person and the role (customer / proxy). The review process always waits for the action from admin. The admin can accept or reject (status REJECTED / SUSPENDED_COMPLIANCE) globally the entity and all related entities. Status SUSPENDED_COMPLIANCE is set each time when entity was already active. In other situations there is set status REJECTED.
In the case admin accepts the entity, the status is set to previous one and process waits for receiving all entities sent to manual verification and then accepts following:
Onboarding,
Customer,
Natural Person Documents,
All Customer Proxies,
All Customer Proxies Documents.
In the case any of entities was rejected by admin, the onboarding process stops and the onboarding status is changed to REJECTED and following entities are globally rejected (status REJECTED / SUSPENDED_COMPLIANCE):
Natural Person,
Customer,
Customer proxies,
Proxies customers when proxy type is other than General_Power_of_Attorney/Liquidator/Information_Proxy.
The partner is notified about all entity changes related to him.
During the onboarding process, each natural person must be identified as per KYC requirements. We offer a choice to our partners:
a new document to the natural person with type IDENTIFICATION_CERTIFICATE
a new identity (object with identifying document metadata, such as passport or national ID)
There are following steps in the Legal Entity Customer onboarding process:
Search Legal Entities (Optional Step): As a Partner's API Client, you can perform an optional "Search Legal Entity". If this step is performed, our API fetches the required data from the Legal Entity Data Provider and returns it to you. As search parameters, the partner must specify the country in which the company is registered and the name of the company, here it should be emphasised that it does not have to be the full name. In response to this, a list of companies will be returned which contains the items which most closely match the given search criteria. Matching is done using fuzzy search mechanisms developed by the Legal Entity Data Provider.
Prepare Legal Entity (Optional Step): As a Partner's API Client, you can perform an optional "Prepare Legal Entity" request. This operation requests us to prepare data for a legal entity by the full name of the company and the country in which was registered. If this step is performed, our API orders all the necessary data from Legal Entity Data Provider and as a result of the operation, a unique search id is returned, which can be used on other endpoints.
Customer Verification and Activation: Post the onboarding initiation, our platform begins customer verification and activation. Notifications about the onboarding process (NEW, PENDING, APPROVED) and customer status (ACTIVE) are sent to the Partner's webhook server.
Transforming Legal Representatives (Optional Step): Post the customer validation data, our platform checks if beneficial owners with REAL_UBO_25 type exists if not begins transformation legal representatives to fictive beneficial owners. Notifications about the beneficial owner status (CREATED) are sent to the Partner's webhook server.
Beneficial Owners Activation: Post the customer activation, the platform begins beneficial owners activation. Notifications about the beneficial owner status (ACTIVE) are sent as webhooks.
Proxies (Signatories) Activation: Post the customer activation, the platform begins activation of proxies. Notifications about the proxy status (ACTIVE) are sent as webhooks.
Onboarding Completion: The entire onboarding process is considered complete.
Please follow these steps to successfully onboard a customer through our API.
Onboarding,
Customer,
All Beneficial Owners related to Customer,
All Customer Proxies,
All Customer Proxies Documents
and the partner is notified about these changes.
To KYC verifications are sent customer and all related entities like proxies, beneficial owners. In the scenario, when KYC verification fails for any of the entity, manual verification process is initiated for each entity individually and status REVIEW is set on the legal entity and the role (customer / proxy / beneficial owner). The review process always waits for the action from admin. The admin can accept or reject (status REJECTED / SUSPENDED_COMPLIANCE) globally the entity and all related entities. Status SUSPENDED_COMPLIANCE is set each time when entity was already active. In other situations there is set status REJECTED.
In the case admin accepts the entity, the status is set to previous one and process waits for receiving all entities sent to manual verification and then accepts following:
Onboarding,
Customer,
Legal Entity Documents,
All Customer Proxies,
All Customer Beneficial Owners,
All Customer Proxies Documents.
In the case any of entities was rejected by admin, the onboarding process stops and the onboarding status is changed to REJECTED and following entities are globally rejected (status REJECTED / SUSPENDED_COMPLIANCE):
Legal Entity,
Customer,
Customer Proxies,
Proxies customers when proxy type is other than General_Power_of_Attorney/Liquidator/Information_Proxy,
Customer Beneficial Owners.
The partner is notified about all entity changes related to him.
To onboard a joint person customer, the partner is required to:
Onboarding,
Customer,
All Joint Person Natural Persons documents,
and the partner is notified about these changes.
To KYC verifications are sent customer natural persons and all related entities like proxies. In the scenario, when KYC verification fails for any of the entity, manual verification process is initiated for each entity individually (there is one manual verification for joint person customer) and status REVIEW is set on the natural persons and the role (customer / proxy). The review process always waits for the action from admin. The admin can accept or reject (status REJECTED / SUSPENDED_COMPLIANCE) globally the entity and all related entities. Status SUSPENDED_COMPLIANCE is set each time when entity was already active. In other situations there is set status REJECTED.
In the case admin accepts the entity, the statuses are set to previous ones and process waits for receiving all entities sent to manual verification and then accepts following:
Onboarding,
Customer,
First Natural Person,
Second Natural Person,
Natural Persons Documents,
All Customer Proxies,
All Customer Proxies Documents.
In the case any of entities was rejected by admin, the onboarding process stops and the onboarding status is changed to REJECTED and following entities are globally rejected (status REJECTED / SUSPENDED_COMPLIANCE):
First Natural Person,
Second Natural Person,
Customer,
Customer proxies,
Proxies customers when proxy type is other than General_Power_of_Attorney/Liquidator/Information_Proxy.
The partner is notified about all entity changes related to him.
After onboarding a customer, it might be required to add a new proxy. In such case:
Create natural person for the proxy:
Provide legal documents as required by the proxy type, e.g., proof of custody for a guardian proxy type.
Onboarding,
Proxy,
All natural person and proxy documents,
and the partner is notified about these changes.
After onboarding a customer, it might be required to add a new beneficial owner. In such case:
onboarding,
beneficial owner,
and the partner is notified about these changes.
Send Natural Person data using the endpoint.
Send Natural Person Identification data with natural person id using the endpoint.
Send customer data with natural person id using the endpoint.
Execute which required natural person id and partner document id. Additionally, there is an option to set customer id in which context natural person can be active.
Upload the Identification Verification PDF for Natural Person using the endpoint.
Start the onboarding process using the endpoint.
If the natural person who is to become the child's guardian does not yet exist in the system, this must be added . The natural person id obtained in the process should be used as a parameter to create natural person identification
Partners need to provide information about the child's guardians as proxy type using the .
Execute which required natural person id and partner document id. Additionally, in this case it is required to sign a Terms and Conditions document in the context of the customer (customer id should be set in request body) for which the proxy is being set up. Data Private Policy will should only be sign if natural person has not already signed it (without customer context)
The Natural Person Wizard is a tool that helps partners create natural person. It is a step-by-step guide that helps partners provide all necessary information to create a natural person. To creates new wizard instance for a natural person, partners should execute . Each natural person data section can be added by using endpoint.
In this scenario, when a data provided by the partner using endpoint, requires manual review, the Natural Person status is set to REVIEW and the partner is notified about this change.
In this scenario, when a data provided by the partner using endpoint, is deemed invalid, the Natural Person status is set to REJECTED and the partner is notified about this change.
In this scenario, when a data provided by the partner using endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.
In this scenario, when a data provided by the partner before starting the onboarding process using endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:
either a certificate of identification can be uploaded through the endpoint as a proof and an identity created through , or
partners can use our to use our service powered by WebID. This, if successfully completed, will automatically create two entities:
Create Legal Entity Customer: After the optional search, you will need to create a Legal Entity Customer. This can be done using endpoint. The data obtained from the optional step can be used by the partner to create request data when creating the Legal Entity, in which case a searchId is required. Each time a Legal Entity Customer is created successfully, a "CREATED" notification is sent from us to the Partner's webhook server. When creating a customer, documents can be automatically added if the searchId is specified in the request, and they exist on the provider side. In such case, the partner will receive a "CREATED" webhook notification regarding the documents.
Create Beneficial Owners: Partners need to provide information about the legal entity customer's beneficial owners using the endpoint. Each time a beneficial owner is created successfully, a "CREATED" notification is sent from us to the Partner's webhook server.
Create Natural Person (Optional): Partners need to provide information about the natural person who is to become a signatory only if it does not already exist in the system. This can be achieved by creating a natural person . The natural person id obtained in the process should be used as a parameter to create natural person identification .
Create Proxy (Signatory): Partners need to provide information about the child's guardians as proxy type using the . When creating Proxy, it is crucial to set the proxyType to SIGNATORY. This type of proxy can be added if it is a Legal Representative of Legal Entity Customer. It means that the details of the Natural Person who was used to create the proxy should match those used to create the Legal Representative.
Sign Document: Partners needs to execute which required natural person id and partner document id. Additionally, in this case it is required to sign a Terms and Conditions document in the context of the customer (customer id should be set in request body) for which the proxy is being set up. Data Private Policy will should only be sign if natural person has not already signed it (without customer context)
Upload Document: After the customer has been created, you can begin uploading documents using the endpoint. Partners need to provide documents for each of its Proxies (Signatories). Each time a document is uploaded, a "CREATED" notification is sent to the Partner's webhook server.
Start Onboarding: Once all necessary documents and data have been provided, the customer onboarding process can be initiated using the endpoint.
In this scenario when a data provided by the partner using endpoint, requires manual review, the Legal Entity status is set to REVIEW and the partner is notified about this change.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner before starting the onboarding process using endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:
Send First Natural Person data using the endpoint.
Send Natural Person Identification data with first natural person id using the endpoint.
Send Second Natural Person data using the endpoint.
Send Natural Person Identification data with second natural person id using the endpoint.
Send customer data with natural person ids using the endpoint.
For both natural person it is necessary to execute which required natural person id and partner document id. Additionally, there is an option to set customer id in which context natural person can be active.
Upload the Identification Verification PDF for each of natural persons using the endpoint.
Start the onboarding process using the endpoint.
In this scenario when a data provided by the partner using endpoint, requires manual review, the Natural Person status is set to REVIEW and the partner is notified about this change.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the Natural Person status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner before starting the onboarding process using endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:
Send natural person data using the endpoint.
Send natural person identification data with natural person id using the endpoint.
Upload the identification verification PDF for natural person using the endpoint.
Execute which required natural person id and partner document id. Additionally, there is an option to set customer id in which context natural person can be active.
Send proxy's data using customer and natural person ids with .
Start the onboarding process using the endpoint.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the natural person status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the proxy status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner before starting the onboarding process using endpoint, is deemed invalid or KYC verification fails, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:
Send the beneficial owner's data using customer id with endpoint.
Start the onboarding process using the endpoint.
In this scenario when a data provided by the partner using endpoint, is deemed invalid, the beneficial owner status is set to REJECTED and the partner is notified about this change.
In this scenario when a data provided by the partner before starting the onboarding process using endpoint, is deemed invalid or KYC verification fails, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities: