Offboarding

Process Overview

The offboarding process is asynchronous and involves validation of the role, role relations and the reason.

Upon successful completion of the process, a notification is sent to the partner via a webhook call:

• Offboarding Notification

• Customer Notification

• Natural Person Notification

• Joint Person Notification

• Legal Entity Notification

• Beneficial Owner Notification

• Proxy Notification

The offboarding process supports following types:

• Roles:

  • Customers

  • Proxies

• Entities related to roles:

  • Beneficial Owners (entity related to legal entity customers)

Regardless of the type, the sequence of actions for offboarding is similar. Partners are required to give the reason of the offboarding and then initiate the offboarding process.

Offboarding API

The offboarding API follows the entity-role separation of concerns architecture:

Role Offboarding (roles.yaml)

• Role offboarding endpoints are defined in roles.yaml

• Available at /roles/offboardings

• Used for offboarding:

  • Customers via POST /roles/offboardings with role type CUSTOMER

  • Proxies via POST /roles/offboardings with role type PROXY

Entity Offboarding (entities.yaml)

• Beneficial owner offboarding endpoints are defined in entities.yaml

• Available at /entities/offboardings

• Used for offboarding beneficial owners via POST /entities/offboardings with entity type BENEFICIAL_OWNER

• Beneficial owners must be offboarded separately from customer offboarding

Offboarding Types

The offboarding process supports three main types:

Customer Offboarding

Customer offboarding is handled through the roles API:

• Endpoint: POST /roles/offboardings

• Request body includes:

  • roleType: "CUSTOMER"

  • roleId: UUID of the customer

  • reason: Valid offboarding reason for the customer type

When a customer is offboarded:

• The entity with its customer role are offboarded

• Other entity roles are offboarded

• All proxies and beneficial owners associated with the customer are automatically offboarded (the entity of the proxy or beneficial owner is also offboarded if other roles aren't active)

Proxy Offboarding

Proxy offboarding is handled through the roles API:

• Endpoint: POST /roles/offboardings

• Request body includes:

  • roleType: "PROXY"

  • roleId: UUID of the proxy

  • reason: Valid offboarding reason for proxies

This process is specifically for offboarding existing proxies for active customers.

Beneficial Owner Offboarding

Beneficial owner offboarding is handled through the entities API:

• Endpoint: POST /entities/offboardings

• Request body includes:

  • entityType: "BENEFICIAL_OWNER"

  • entityId: UUID of the beneficial owner

  • reason: Valid offboarding reason for beneficial owners

This process is specifically for offboarding beneficial owners for active legal entity customers.

Prerequisites

• The partner is responsible for closing all customer products before starting the offboarding.

Statuses

The offboarding process has the following statuses:

• INVALID: Process not started due to invalid data during offboarding initiation.

• CREATED: Offboarding created but not yet started.

• PENDING: Process started. For Immediate, this means offboarding execution is in progress. For Ordinary, the process waits for the scheduler to trigger execution two months after offboarding initiation.

• REJECTED: Offboarding rejected after process initiation.

• CANCELED: Offboarding canceled; cancellation is only possible for Ordinary offboarding.

• APPROVED: Offboarding completed successfully.

Closure Types

There are two closure types for Offboarding: Ordinary and Immediate. The closure type is derived from thereason field:

• Ordinary:

  • CANCELLATION_BY_PARTNER_ORDINARY

• Immediate:

  • CUSTOMER_REQUEST_IMMEDIATE

  • CANCELLATION_BY_PARTNER_IMMEDIATE

  • DEATH_IMMEDIATE

  • DISSOLUTION_IMMEDIATE

  • INSOLVENCY_IMMEDIATE

  • COMPANY_STRUCTURE_CHANGES_IMMEDIATE

Changes for Customer during process

During the offboarding process, the customer undergoes the following changes:

1. Temporary Status: OFFBOARDING

   • While the offboarding process is in progress, the customer is assigned a temporary status: OFFBOARDING.

   • This status prevents any new products from being added to the customer during the offboarding process.

2. Cancellation Date

   • The cancellation date is set for the customer in the following way:

     • For Immediate Offboarding:

       • The cancellation date is set to the date when the offboarding process begins.

     • For Ordinary Offboarding:

       • The cancellation date is set to two months after the offboarding initiation date, when the process is scheduled for execution.

Process flow

• Immediate:

  • All validations are performed immediately, and the offboarding is executed right away.

  • The customer's cancellation date is set to the date the offboarding execution begins.

• Ordinary:

  • Initial data correctness validations are performed, excluding checks for whether all customer products are closed.

  • The customer's cancellation date is set to two months after the offboarding initiation date.

  • The process waits for a scheduler to trigger the remaining validations and offboarding execution.

  • At the scheduler-triggered execution, all validations are rechecked, including verifying whether all customer products are closed.

  • If products aren't closed, the process remains in the PENDING status. Currently, process resumption isn't possible.

Validations

The offboarding process involves the following validations:

1. Status Validation

   Before proceeding with the offboarding process, the system must validate whether the role or entity to be offboarded has an eligible status.

   The following statuses are allowed for role offboarding:

   • Customers:

     • ACTIVE

     • ESTATE

     • SUSPENDED

     • SUSPENDED_COMPLIANCE

   • Proxies:

     • ACTIVE

     • SUSPENDED

     • SUSPENDED_COMPLIANCE

   The following statuses are allowed for entity offboarding:

   • Beneficial Owners:

     • ACTIVE

     • SUSPENDED_COMPLIANCE

2. Existence Validation

   The system must verify whether the role or entity that is being offboarded exists in the database.

3. Offboarding Reason Validation

   A valid offboarding reason must be provided for the role or entity being offboarded. The valid reasons are documented in the table below:

   Offboarding Reason	Natural Person Customer	Joint Person Customer	Legal Entity Customer	Proxy	Beneficial Owner
   CUSTOMER_REQUEST_IMMEDIATE	valid	valid	valid	valid	invalid
   CANCELLATION_BY_PARTNER_IMMEDIATE	valid	valid	valid	valid	invalid
   CANCELLATION_BY_PARTNER_ORDINARY	valid	valid	valid	invalid	invalid
   DEATH_IMMEDIATE	valid	invalid	invalid	valid	invalid
   DISSOLUTION_IMMEDIATE	invalid	invalid	valid	invalid	invalid
   INSOLVENCY_IMMEDIATE	invalid	invalid	valid	invalid	invalid
   COMPANY_STRUCTURE_CHANGES_IMMEDIATE	invalid	invalid	valid	valid (signatory)	valid

4. Custody type for left guardians related to customer of offboarded guardian

   The system must verify whether the custody type for left guardians related to the customer of the offboarded guardian is set to SINGLE_CUSTODY.

5. Proxy type validation

   The system must verify whether the proxy type is other than LIQUIDATOR.

6. Customer Products Status Validation

   The system must verify whether all customer products are in status: CANCELLED.

If any data is invalid during the validation stage, the offboarding process will set the status:

• INVALID if the process has not started.

• REJECTED if the process has already started.