📘

Definition

Portal is Ondorse's white-label onboarding solution. It helps you create a fluid and smart experience for your customers by integrating features such as auto-fill and suggestions. It leverages the know-how of Ondorse in business and individual onboarding while supporting a high degree of visual customisation.

A portal is a set of Ondorse-hosted web pages with a unique URL you can generate through Ondorse API. Once you have generated a portal and sent it to a customer, the information the customer fills in, including collected documents, will be sent to a case in the Ondorse case management.

Portal's web pages are based on the following logic:

• Business details, a web page to collect information on a legal entity (note that you can add custom questions)
• Relationships details, a web page to collect information about the relationships of the company (natural persons and entities) such as the directors of a company
• Documents, a web page to drop all required documents

Each portal is unique and persistent. It means that, until submitted, a customer can go back to its portal page to add more information or edit it.

Portal's features include:

• Search bar on entity names or registration number, with auto-complete to ease the search
• Auto-fill of fields powered by official register connections to reduce the burden on your customer and maximise conversion rate (note that customers can always edit and modify this information)
• Relationships (natural persons or entities) smart suggestions for directors and UBOs, depending on data availability
• Responsive design to fit seamlessly on any screen size

Portal links creation

Portal links can be created directly in the Portals section. By clicking "Create portal," a link is automatically generated, which can be shared with your customers for onboarding in Ondorse. All links are stored and retrievable in the Portals section.

Note: A link can be secured with an email, requiring users to verify their email when accessing the Portal link.

Example integration for onboarding

In this example integration, the account is created before the KYB verification. Until the KYB verification is done and approved, the account is kept inactive and has limited access to your application (example: wire transfers are disabled).

This design choice have several advantages:

1. While the KYB verification is pending, the user has already access to your application. You can already build engagement: complete the setup, train the user, etc.
2. With an account creation as first step of the process, you have more means to contact and re-engage the user in case of drip out.
3. You can pass down specific information to the KYB case such as: internal references (ex: account_id) or risk data (ex: acquisition channel).

Implementation guidelines

• Use the endpoint POST /api/portals (reference) to create a Portal link:
  • use the param default_custom_fields to pass custom case data such as account_id etc..
  • use the param redirect_url to redirect the user after the submission of the Portal
• Use the webhook event application.submitted to be notified when a case is submitted via Portal
  • in the payload, you have access to the application_id and custom_fields values (especially the ones coming from default_custom_fields)
• Use the endpoint GET /api/applications/{application_id} (reference) to get access to application content
  • use the field status_review to know the decision status
  • use the fields risk_score and risk_level to get information about the risk scoring
• Use the webhook event application.review_updated to be notified when a case gets an update on its status_review
• Use the webhook event collect.opened to be notified when a case needs an information from the customer
  • Use payload data.object.portals.link to access the link to the collect Portal that you can send to the customer.