Ebury Entity Migration

(UAE/Dubai Clients)

Background

As Ebury continues to grow and expand to many countries and jurisdictions, there could be a need to establish new subsidiary entities in those countries and transfer all rights and obligations, including customers and open transactions to the new entities.

This is a joint effort that spans many different teams in the company, from Finance, to Treasury, Product, CRM, Data, BAS, etc., so it needs to be coordinated with all of them.

Similar migrations have been performed in the past (for example, for Brexit, clients were moved from EPUK to EPBE), but this work has been historically done manually, which always introduces risks and liabilities. Lessons were learnt and a new operational flow for the Entity Migration was defined (this can be found here), but this remains a process that contains many manual touch points.

The purpose of this document is to describe the technical solution that will be developed in order to automate the parts of the framework of entity migration that relate to the updates that should be performed to the client records in scope, on the CRM (Salesforce) and CLM (FenX) systems.

This document will mainly focus on the Entity Migration for UAE/Dubai clients, as this is the next entity migration to perform, but a long term solution should be in place and utilized in any other Entity Migrations in the future.

Prerequisites

  • Requirements have been detailed in the PRD document, including data considerations (please refer to section Data/MI considerations / requirements of the PRD);
  • Stakeholders are identified and relevant technical teams are involved, also in the PRD document;
  • Business process is described in this set of diagrams;
  • Scope has been quantified (please refer to section BUSINESS CASE > Qualitative Impact of the PRD), however the actual data set of clients to be migrated has not been identified;
  • Delivery of development work is scheduled for January 2023 (provisionally); the Go-LIVE of the migration of the accounts and entities is scheduled for March 2023 (also provisionally).

Reference Documents

Reference Name / Location
EEM01 Dubai Migration - Product Requirements Document
EEM02 Ebury Branch Updates - Business Process Flow
EEM03 Ebury Entity/Branch Matrix
EEM04 Ebury Entity Migration - Playbook
EEM05 EPUK >> EPBE Migration (Brexit)
EEM06 Entity Migration - Dubai - Scope & Tracker

Problem Description

Ebury is working to introduce a new Ebury Entity for UAE/Dubai jurisdiction as well as migrate existing clients to this entity. This piece will affect many parts of the business (CRM, TRE, PAY, DATA, etc.).

There is a process flow defined with a lot of steps that are performed by different teams, but the process is very manual, which can create risks. In light that this type of work might be recurring in the future, we should find a way to make the process more seamless, eliminate manual touching points and automate steps as much as possible.

This document focuses on the "commercial/operational" side of the process (creating/updating the entities, updating the accounts). Things like the "legal" side or "transactional" are dealt with by other teams.

The process we follow on Salesforce to create/update an Ebury Entity and migrate client accounts goes like this:

  1. Create/Update the record Ebury_Entity__c on the system - if it's a new entity it should be created with Status = Inactive.
  2. If the new Ebury Entity has Ebury Branches associated, these need to be created as well, also with Status = Inactive.
  3. Activate the new Ebury Entity created.
  4. Activate the new Ebury Branch (es) created, if applicable.
  5. Update Accounts with the new Ebury Entity.
  6. Check that the Accounts were updated with the correct Ebury Branch , if applicable, after the auto-assignment. Note: Ebury Branches are updated on accounts via an automated process, based on some information like Ebury Entity, Client Country, Dealer Location, etc. The automated process is described in this document: Ebury Entity & Branches - Implementation Guide.
  7. Update Latest T&Cs on Accounts, when the T&Cs are sent to the clients.

This process could be automated in Salesforce, however because by the time the Dubai clients migration is ready to go-live, the FenX migration should be done, which means all clients, including Dubai clients will be mastered in FenX; if the clients are mastered in FenX this means that the entities cannot be updated in SF, (Ebury Entity is one of the fields mastered on FenX). So doing this in SF does not make much sense.

Scope (SF Data)

Entity Migration - Dubai - Scope

Solution

This section is split in two, for a short term solution and a long term solution.

Short Term Solution

The short term solution is based on performing mass upload(s), via CSV, to the account records in Salesforce, to update the following information: Ebury Entity, Ebury Branch and Latest T&Cs; full steps are described in the Problem Description section of this document.

This approach will apply if the migration of clients to the FenX system is not fully complete and because there is a possibility that the automated approach is not yet finished, and could be used in the future, but only as an alternative. The Entity Migration for UAE/Dubai clients falls under this assumption.

This approach does not require development, but it does require manual effort and testing of the end-to-end flow of the data, prior to the go-live.

Entity Migration - Dubai - Tracker

Long Term Solution

The long term solution is based on automating the updates via the Google Apps Script platform. This approach will apply when the migration of clients to the FenX system is fully complete and FenX becomes the "source of truth" (account records are Mastered in FenX ).

The solution is to create an automation that orchestrates the updates to FenX entities (= SF accounts) in FenX platform and later the integration between SF <> FenX will take care of synchronizing the records from FenX >> SF.

The approach to performing these updates in FenX is to create a tool like Salesforce's bulk update, making use of CSV. Each row contains the values to update for each entity, where each column is a field to change. The process internally performs an update for each entity as FenX does not offer the possibility to do a bulk update operation as in Salesforce.

As each entity update in turn needs to be performed through a journey, the steps required for each update are: 1. Creation of a Journey instance for that entity. 2. Creation of a Draft of the entity to be modified 3. Update the Draft with the new data 4. Completion of the Journey task

Service Ownership

Going forward, once the automated solution is in place, new requests for Entity Migration will be managed by the Services teams (BAS and BPA).

Alternatives

Modify data on salesforce (Automatically)

Initially we thought of modifying that data on salesforce and migrating that data to FenX. This alternative was discarded because the entities are mastered on FenX (some fields, in this case Ebury Entity is managed in FenX), at the end we thought it is better to modify the data on the source of truth.

Caveats

Operational

  • A large part of this process is manual - as depicted in the diagrams and in the playbooks, there are certain parts that cannot be automated. They have to be performed manually by users, which always introduces a level of risk.

  • The whole process has a lot of stages and has to be performed by different parts of the business - this can also be very difficult to coordinate, things can get lost in translation and it's very time consuming.

Technical

  • Once an account is onboarded and effectively becomes a Client , it means the account has gone through the Onboarding process in FenX and FenX becomes the "source of truth". The account is then Mastered in FenX and certain information on the account can only be updated in that system and then synced to Salesforce; it cannot be the other way around.

  • FenX API, currently, does not support bulkified operations. To do the migration for a single account, there are a number of operations and API calls that need to be done; to do this for a data set of accounts, we need to make a lot of calls 1 by 1, for all the accounts we need to modify. There are no plans on the FenX side to add this any time soon.

  • To ensure the migration process runs smoothly and the flow of information within the different systems is correct, we are not able to use dummy data, which is non-compliant with our Standards in Testing with Sensitive Data. Therefore a Security Exception will be raised to create a SF FullCopy sandbox.

Operation

Short Term Solution

The steps describing how this will be run are depicted in the following document: Entity Migration - Dubai - Tracker.

Long Term Solution

The tool provides Business Apps Support (BAS) with the ability to handle these updates independently. They must follow the bulk updates procedure reflected in the Policy for manually mass updates in FenX, where a Rollback plan is prepared.

Security Impact

It is important to consider whether the fields that need to be modified in order to carry out a migration affect the calculation of the Risk Rating. For now, the process is limited to those that do not impact in the process. If any field that impact the CRR need to be modified, we should change the process to force a recalculation of the CRR.

Performance Impact

As stated in the Caveats section, FenX API does not allow calls for bulkified operations, so the updates have to be done 1 by 1, per account, which could put a strain on the systems, could hit system limitations, etc.

However, specifically for the migration of UAE/Dubai clients, the volumes are not extremely high, but in the future, there could be a migration for a different entity, (for example, UK), and the volumes of operations could be in the thousands.

Developer Impact

Developing this new functionality will potentially lay the foundation for other future updates on accounts for other fields that are Mastered in FenX , using an automated system like make.

Data Contracts

No new data source is being introduced nor any schema definitions are being modified; only existing data will be modified.

Data Sources

  • Input data sources
    • Salesforce - source of truth for client accounts UAE/Dubai not Mastered in FenX.
    • FenX - source of truth for client accounts UAE/Dubai Mastered in FenX.
  • Transformation requirements
    • N/a
  • Output data
    • Salesforce
    • FenX
    • BOS - client accounts UAE/Dubai will be synced to BOS with the new Entity/Branch.
    • Data - will retrieve and validate the updates on client accounts UAE/Dubai and generate the relevant reports.
    • Treasury - will retrieve and validate the updates on client accounts UAE/Dubai and generate the relevant reports.

Deployment

Short Term Solution

Rollout & Rollback

The steps describing how this will be run and the teams involved are depicted in the following document Entity Migration - Dubai - Tracker.

The rollback, if needed, will be performed by reversing the steps performed, in the relevant order.

Long Term Solution

Proceed in a similar way to the previous solution.

Dependencies

N/A