CLM Periodic Review process

This RFC aims to provide a solution for periodically review the information that Ebury holds of its clients.

Please note: this is a short term tactical solution - a following RFC will cover the strategically-aligned solution, please see the related RFC.

Reference Documents

Reference Document Location
EPIC01 Product Requirements - CLM Periodic Review Automation
EPIC02 Product Requirements - Automated PR journey
EPIC03 Product Requirements - Simplified PR
[1] Automation Platforms Overview

Problem Description

As per the current regulatory requirements, Ebury is required to ensure the information and documentation it holds on its clients is accurate and up to date. To fulfil this, Ebury has implemented real time monitoring of client data (Event Driven Reviews (“EDR”), Transaction monitoring), and periodic reviews (“PRs”) on a risk based approach (high risk, annually; medium risk, every three years; and low risk, every five years).

Problem statement:

  • The current periodic review process and requirements is burdened by the legacy of the KYC remediation, arduous and time consuming.
  • High volume of low and medium risk PRs expected within the next 3-15 months (approx. 4,700 in 2024).

With the substantial number of periodic reviews anticipated in the coming years, it is imperative to redefine our approach to ensure sustainability, scalability and efficiency and the outreach automation and integration between communications and JSM is a critical part of the process review.

Background

Current periodic review process - Workload and status managed in JIRA project - Full re-identification and verification of information and documentation (“CDD” requirements) required at onboarding and/or remediation - Conducting checks on the documentation obtained at onboarding and/or remediation - Manual client outreach and population of forms - Periodic Review done in FenX

PR current process

Current short-term changes to periodic review process: - Population of forms in PDF done automatically with data from BigQuery - Automation of client outreach email and chasers triggered from JIRA

PR short term changes

Solution

A solution to create a Periodic Review process for Medium and Low risk Corporate clients and that in the future might be applied to High Risk PRs. FenX would trigger the PR and an automated process will create the Jira issue consequently. When the KYC analyst marks the PR to be sent to the client, the Periodic Review service retrieve the information related to the PR and the client to create and form access link. The client information is extracted from BigQuery. This service would also send notifications and chasers to the client. When the form is submitted, the service would queue the client response to be send to the Analyst via PDF and will inform it on the PR Jira issue.

The PR process using the form is divided in two parts: a two-part interaction with an API—retrieving data (GET) and submitting data (POST), facilitated through a user interface and secured through user authentication. The API acts as the intermediary between the user interface and the database where the customers' data resides, handling both the retrieval and updating of data.

Retrieval of Data (GET)

  1. Interface:

  2. The user interacts with the system through this interface. Once authenticated, the interface requests data from the API using the token.

  3. Authentication:

  4. The user is authenticated using Firebase UI Auth, which is a drop-in authentication solution for web apps. It provides a fully functional UI for signing in users, as well as a backend API for verifying the user's identity.

  5. Authentication is done through a magic link sent via email. This link contains a token that uniquely identifies the user (including a token in the link). > We chose this method because we cannot leverage any existing SAML solution used by all the customers; magic links are secure and easy to use, and they don't require any additional setup on the developer's part.

  6. API (GET / Auth):

  7. We call the API included the identification token generated by Firebase UI Auth, which contains encoded user information, and uses it to retrieve the user-specific data.
  8. The API verifies the token's authenticity and decodes it to extract the user email.

  9. A call to the database (BigQuery) is made searching the data by the email extracted from the token to ensure the right user data is fetched.

  10. Interface:

  11. The interface receives the data from the API and displays it to the user.
  12. The questions are dynamically generated based on the data retrieved from the database, and only the relevant questions are displayed to the user.
  13. The questions are displayed conditionally based on the replies to previous questions; for example, if the user replies to the "is the legal address changed (yes/no)" question with "yes", then the "new legal address" input is displayed.

Submission of Data (POST)

  1. Interface:
  2. The user fills submits data through the interface; when the user is done it clicks on the "Submit" button.
  3. The data is consolidated, validated and then sent to the API.
  4. The POST request, same as the GET request, includes the identification token generated by Firebase UI Auth.
  5. Upon request, the API verifies the token's authenticity and decodes it to extract the user email.

  6. After the data is received by the API, it's placed in a queue to be processed.

    We won't process the data immediately to ensure the user doesn't have to wait for the data to be processed, as well as making the process more robust in case of errors.

  7. Processing Script:

  8. This script processes the data from the queue and updates the database (BigQuery) with the new data. This will be a Google Apps Script that will be executed periodically (every 5 minutes) to process the data in the queue.
  9. As soon as a submission is processed, the data is removed from the queue.

Proof of Concept

Here is a proof of concept of the solution hosted with Firebase hosting and using Firebase UI Auth to authenticate users: https://appscript-296515.web.app/.

Translations

The form is available in all the required languages, the translations are prepared for all of them; the language can be selected in a dropdown menu; the form is translated on the fly. At first run, the form is translated to the customer's preferred language based on their language preferences (obtained from BigQuery), if the language is not available, the form is translated to English.

Persistence of data

When the user fills the form, the data is persisted in the browser's local storage (IndexedDB). If the user closes the browser and opens it again, the data is retrieved from the local storage and the form is pre-populated with the data, allowing the user to continue filling the form where they left off.

Branding

As we plan to offer this form to our clients, the form can be dynamically branded. The form is branded with the Ebury logo and colours, but it can be easily changed to use the client's logo and colours.

An example of the form branded with the client's logo and colours: Acme Corp Periodic Review Form.

For an example, this is done via a URL parameter , but on a real implementation, this would be determined by the URL the client uses to access the form (f.i. https://periodic-review.ourcustomer.com). The form would be branded with the client's logo and colours.

PR solution

Service Ownership

New Service Service Name Service Owner
No Make (Phase 0) BPA Team
No Email service (Phase 0) BPA Team
No Data BigQuery Analytics Team
Yes PR Website BPA Team

Alternatives

Form Service

  • Avoka
    • Form has a tracking code
      • No log in, just the tracking code which is a security risk
    • Email with link to form
      • This would work for online and offline clients
    • Supports different languages. But different forms should be created.
    • Documents can be uploaded.
    • Avoka will be replaced with another tool in the close future.
  • Jotform
    • Email with link to portal that contains form.
    • Email with form’s password after verifying authentication.
    • Form passwords are shared between all the clients.
    • Not native way to verify the client.
  • EBO
    • It requires more time for implementation and would not be prepared for the increase in cases in the coming months.
    • It would be a good alternative when all customers are verified with the EBO SSO.

Authentication

  • Keycloak
    • Online clients: EBO SSO
    • Offline clients: magic link via email
    • Is not prepared yet for using magic-links, as the project has many other requirements and scarce resources allocated to it.

Caveats

N/A

Operation

This process will run as our clients are close to their Next Review Date. The process involves internal users (back office) and external users (clients).

Security Impact

The new services will expose new APIs through Google Cloud Functions. User authentication for these APIs will leverage Firebase Auth. Secrets will be stored in Google Secret Manager and service to service communication will be authenticated using Google Service Accounts.

Important note: Firebase Auth, Firebase hosting, Google Cloud Functions and Google Secret Manager all reside in the same Google Cloud project, which means communication between them can leverage built-in authentication mechanisms, making the implementation internally secure and robust.

Performance Impact

Services should not have a performance impact on any of the back-office services. The throughput of Periodic Review processes modified hourly is not expected to be massive in the usual daily work.

Developer Impact

The new services are developed trying to leverage to the maximum extent possible existing services and tools, thus aiming to deliver high quality and robust solutions in a short period of time.

Existing and new services to create will be build in a dynamic and modular way to be able to adapt to future changes and requirements, according to Automations Platforms Overview [1].

Data Contracts

No changes to data contracts are expected.

Data Sources

  • Input data sources: BigQuery, Jira, FenX

Deployment

The services will be deployed using the standard pipelines and procedures already in place.

Dependencies

The interface will use Chameleon as the UI framework, which is a UI framework developed by Ebury that provides a set of reusable components that can be used to build web applications. In this way, we ensure the UI is consistent with the rest of the Ebury applications.



Based on RFC Template Version 1.1