Onboarding

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.

Onboarding Process

The onboarding process is asynchronous and involves several steps:

  1. Validation of customer data and required documents.

  2. Verification of reference accounts via SEPA.

  3. 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:

Natural Person Onboarding

We support two categories of natural person customers:

  • Adult Customers

  • Child customers (individuals under 18 years old)

Adult Customer Onboarding

To onboard a customer who is above 18 years old, the partner is required to:

  1. Send Natural Person data using the Create Natural Person endpoint.

  2. Send Natural Person Identification data with natural person id using the Create Natural Person Identification endpoint.

  3. Send customer data with natural person id using the Create Natural Person Customer endpoint.

  4. Execute Sign Document 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.

  5. Upload the Identification Verification PDF for Natural Person using the Upload Document endpoint.

  6. Start the onboarding process using the Start Onboarding endpoint.

Child Customer Onboarding

Onboarding a child customer (a natural person under 18 years old) is similar to regular customer onboarding, but with a few additional steps:

  1. If the natural person who is to become the child's guardian does not yet exist in the system, this must be added Create Natural Person. The natural person id obtained in the process should be used as a parameter to create natural person identification Create Natural Person Identification

  2. Partners need to provide information about the child's guardians as proxy type using the Create Proxy.

  3. Execute Sign Document 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)

  4. In cases of single custody, a Proof of Single Custody document is needed.

  5. If the child's last name differs from that of the guardian, additional documents proving custody are required.

  6. In the Contact section of the child customer, the contact details of one of the guardians must be provided.

Natural Person Wizard

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 Create Natural Person Wizard Instance. Each natural person data section can be added by using Update Natural Person Wizard Instance endpoint.

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.

Natural Person Scenarios Descriptions and Sequence Diagrams

Natural Person Customer onboarding sequence diagram

Natural Person Customer onboarding with matching manual review

In this scenario, when a data provided by the partner using Create Natural Person endpoint, requires manual review, the Natural Person status is set to REVIEW and the partner is notified about this change.

Natural Person Customer onboarding with base Natural Person Verification Failed

In this scenario, when a data provided by the partner using Create Natural Person endpoint, is deemed invalid, the Natural Person status is set to REJECTED and the partner is notified about this change.

Natural Person Customer onboarding with base Customer Verification Failed

In this scenario, when a data provided by the partner using Create Natural Person Customer endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.

Natural Person Customer onboarding with onboarding validation failed

In this scenario, when a data provided by the partner before starting the onboarding process using Start Onboarding endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:

  • Onboarding,

  • Customer,

  • Natural Person Documents,

  • All Customer Proxies,

  • All Customer Proxies Documents

and the partner is notified about these changes.

Natural Person Customer onboarding with KYC verification failed

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.

Natural Person Identification with external verifier

During the onboarding process, each natural person must be identified as per KYC requirements. We offer a choice to our partners:

  • either a certificate of identification can be uploaded through the Upload Document endpoint as a proof and an identity created through Create Natural Person Identification, or

  • partners can use our Create Identification Verification to use our service powered by WebID. This, if successfully completed, will automatically create two entities:

    • 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)

Legal Entity Onboarding

Legal Entity Customer Onboarding Process Steps

There are following steps in the Legal Entity Customer onboarding process:

  1. 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.

  2. 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.

  3. Create Legal Entity Customer: After the optional search, you will need to create a Legal Entity Customer. This can be done using Create Legal Entity Customer 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.

  4. Create Beneficial Owners: Partners need to provide information about the legal entity customer's beneficial owners using the Create Beneficial Owner endpoint. Each time a beneficial owner is created successfully, a "CREATED" notification is sent from us to the Partner's webhook server.

  5. 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 Create Natural Person. The natural person id obtained in the process should be used as a parameter to create natural person identification Create Natural Person Identification.

  6. Create Proxy (Signatory): Partners need to provide information about the child's guardians as proxy type using the Create Proxy. 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.

  7. Sign Document: Partners needs to execute Sign Document 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)

  8. Upload Document: After the customer has been created, you can begin uploading documents using the Upload Document 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.

  9. Start Onboarding: Once all necessary documents and data have been provided, the customer onboarding process can be initiated using the Start Onboarding endpoint.

  10. 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.

  11. 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.

  12. Beneficial Owners Activation: Post the customer activation, the platform begins beneficial owners activation. Notifications about the beneficial owner status (ACTIVE) are sent as webhooks.

  13. Proxies (Signatories) Activation: Post the customer activation, the platform begins activation of proxies. Notifications about the proxy status (ACTIVE) are sent as webhooks.

  14. Onboarding Completion: The entire onboarding process is considered complete.

Please follow these steps to successfully onboard a customer through our API.

Legal Entity Scenarios Descriptions and Sequence Diagrams

Legal Entity Customer onboarding sequence diagram

Legal Entity Customer onboarding with matching manual review

In this scenario when a data provided by the partner using Create Legal Entity Customer endpoint, requires manual review, the Legal Entity status is set to REVIEW and the partner is notified about this change.

Legal Entity Customer onboarding with base Customer Verification Failed

In this scenario when a data provided by the partner using Create Legal Entity Customer endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.

Legal Entity Customer onboarding with onboarding validation failed

In this scenario when a data provided by the partner before starting the onboarding process using Start Onboarding endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:

  • Onboarding,

  • Customer,

  • All Beneficial Owners related to Customer,

  • All Customer Proxies,

  • All Customer Proxies Documents

and the partner is notified about these changes.

Legal Entity Customer onboarding with KYC verification failed

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.

Joint Person Customer Onboarding

To onboard a joint person customer, the partner is required to:

  1. Send First Natural Person data using the Create Natural Person endpoint.

  2. Send Natural Person Identification data with first natural person id using the Create Natural Person Identification endpoint.

  3. Send Second Natural Person data using the Create Natural Person endpoint.

  4. Send Natural Person Identification data with second natural person id using the Create Natural Person Identification endpoint.

  5. Send customer data with natural person ids using the Create Joint Person Customer endpoint.

  6. For both natural person it is necessary to execute Sign Document 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.

  7. Upload the Identification Verification PDF for each of natural persons using the Upload Document endpoint.

  8. Start the onboarding process using the Start Onboarding endpoint.

Joint Person Onboarding Scenarios Descriptions and Sequence Diagrams

Joint Person Customer onboarding sequence diagram

Joint Person Customer onboarding with matching manual review

In this scenario when a data provided by the partner using Create Natural Person endpoint, requires manual review, the Natural Person status is set to REVIEW and the partner is notified about this change.

Joint Person Customer onboarding with base Natural Person Verification Failed

In this scenario when a data provided by the partner using Create Natural Person endpoint, is deemed invalid, the Natural Person status is set to REJECTED and the partner is notified about this change.

Joint Person Customer onboarding with base Customer Verification Failed

In this scenario when a data provided by the partner using Create Joint Person Customer endpoint, is deemed invalid, the Customer status is set to REJECTED and the partner is notified about this change.

Joint Person Customer onboarding with onboarding validation failed

In this scenario when a data provided by the partner before starting the onboarding process using Start Onboarding endpoint, is deemed invalid, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:

  • Onboarding,

  • Customer,

  • All Joint Person Natural Persons documents,

and the partner is notified about these changes.

Joint Person Customer onboarding with KYC verification failed

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.

Proxy Onboarding

After onboarding a customer, it might be required to add a new proxy. In such case:

  1. Create natural person for the proxy:

    1. Send natural person data using the Create Natural Person endpoint.

    2. Send natural person identification data with natural person id using the Create Natural Person Identification endpoint.

    3. Upload the identification verification PDF for natural person using the Upload Document endpoint.

    4. Execute Sign Document 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.

  2. Send proxy's data using customer and natural person ids with Create Proxy.

  3. Provide legal documents as required by the proxy type, e.g., proof of custody for a guardian proxy type.

  4. Start the onboarding process using the Start Onboarding endpoint.

Proxy Onboarding Scenarios Descriptions and Sequence Diagrams

Proxy onboarding sequence diagram

Verification on natural person creation failed

In this scenario when a data provided by the partner using Create Natural Person endpoint, is deemed invalid, the natural person status is set to REJECTED and the partner is notified about this change.

Verification on proxy creation Failed

In this scenario when a data provided by the partner using Create Proxy endpoint, is deemed invalid, the proxy status is set to REJECTED and the partner is notified about this change.

Proxy onboarding validation failed

In this scenario when a data provided by the partner before starting the onboarding process using Start Onboarding endpoint, is deemed invalid or KYC verification fails, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:

  • Onboarding,

  • Proxy,

  • All natural person and proxy documents,

and the partner is notified about these changes.

Beneficial Owner Onboarding

After onboarding a customer, it might be required to add a new beneficial owner. In such case:

  1. Send the beneficial owner's data using customer id with Create Beneficial Owner endpoint.

  2. Start the onboarding process using the Start Onboarding endpoint.

Beneficial Owner Onboarding Scenarios Descriptions and Sequence Diagrams

Beneficial owner onboarding sequence diagram

Verification on beneficial owner creation failed

In this scenario when a data provided by the partner using Create Beneficial Owner endpoint, is deemed invalid, the beneficial owner status is set to REJECTED and the partner is notified about this change.

Beneficial owner onboarding validation failed

In this scenario when a data provided by the partner before starting the onboarding process using Start Onboarding endpoint, is deemed invalid or KYC verification fails, the onboarding process stops, the status is changed from PENDING to REJECTED on following entities:

  • onboarding,

  • beneficial owner,

and the partner is notified about these changes.

Last updated