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:
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:
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:
Send Natural Person data using the
Create Natural Person
endpoint.Send Natural Person Identification data with natural person id using the
Create Natural Person Identification
endpoint.Send customer data with natural person id using the
Create Natural Person Customer
endpoint.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.Upload the Identification Verification PDF for Natural Person using the
Upload Document
endpoint.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:
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 identificationCreate Natural Person Identification
Partners need to provide information about the child's guardians as proxy type using the
Create Proxy
.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)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.
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 throughCreate Natural Person Identification
, orpartners 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:
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.
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.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.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 identificationCreate Natural Person Identification
.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.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)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.Start Onboarding: Once all necessary documents and data have been provided, the customer onboarding process can be initiated using the
Start Onboarding
endpoint.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.
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:
Send First Natural Person data using the
Create Natural Person
endpoint.Send Natural Person Identification data with first natural person id using the
Create Natural Person Identification
endpoint.Send Second Natural Person data using the
Create Natural Person
endpoint.Send Natural Person Identification data with second natural person id using the
Create Natural Person Identification
endpoint.Send customer data with natural person ids using the
Create Joint Person Customer
endpoint.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.Upload the Identification Verification PDF for each of natural persons using the
Upload Document
endpoint.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:
Create natural person for the proxy:
Send natural person data using the
Create Natural Person
endpoint.Send natural person identification data with natural person id using the
Create Natural Person Identification
endpoint.Upload the identification verification PDF for natural person using the
Upload Document
endpoint.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.
Send proxy's data using customer and natural person ids with
Create Proxy
.Provide legal documents as required by the proxy type, e.g., proof of custody for a guardian proxy type.
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:
Send the beneficial owner's data using customer id with
Create Beneficial Owner
endpoint.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